-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: move getShortLang outside markdown processor #291
Conversation
@@ -49,6 +49,9 @@ ESLinter.prototype.verify = function ( | |||
{} | |||
|
|||
processorOptions.lintCodeBlocks = settings['mdx/code-blocks'] === true | |||
processorOptions.languageMapper = settings[ | |||
'mdx/language-mapper' | |||
] as ProcessorOptions['languageMapper'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense for languageMapper
to have it's own type/interface which could be used directly in this cast?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a ESLintMdxSettings
interface
But after digging some other plugins like https://github.com/yannickcr/eslint-plugin-react#configuration or https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-extraneous-import.md#shared-settings, a namespaced object settings could be used easyier.
{
"settings": {
"mdx": {
"codeBlocks": true,
"languageMapper": {}
}
}
}
What do you think? And I don't know if it should be considered as BREAKING CHANGE, because it's very easy to migrate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Released! |
{index}_
prefix is hard coded at https://github.com/eslint/eslint/blob/master/lib/linter/linter.js#L1303