Add @eslint-community/eslint-comments dependency #26
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@eslint-community/eslint-comments can replace eslint-plugin-bestpractices as it is a community-wide eslint plugin.
https://eslint-community.github.io/eslint-plugin-eslint-comments/rules/ to see the rules.
The rule that specifically replaces the old bestpractices/no-eslint-disable is require-description. It does basically the same. The difference is that it only affects real eslint-disable directives. For example, it doesn't affect
// eslint-disable-nextas that doesn't actually disable any linting rules. See https://eslint.org/docs/latest/use/configure/rules.The plugin adds its recommended rules automatically. Those rules are: disable-enable-pair, no-aggregating-enable, no-duplicate-disable, no-unlimited-disable, no-unused-disable, no-unused-enable. They are all treated as errors. The only way to turn them off is to turn them off individually as the plugin doesn't allow consumers to just get the plugin and define which rules to turn on. I do think those rules are nice to have though, so I think it is fine to keep them. I particularly like the no-unlimited-disable to make developers be specific on what they are disabling.
I updated the example test to do a common eslint disable directive (eslint-disable-next-line) that actually disables a eslint rule on the next line. This triggers both the @eslint-community/eslint-comments/require-description and @eslint-community/eslint-comments/no-unlimited-disable rules.
To-Dos