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
Add CLI option to report unused eslint-disable directives #9249
Comments
TSC Summary: This issue proposes adding a CLI flag to report unused TSC Question: Should we accept this proposal? |
This was accepted in today's TSC meeting. |
Thanks for great work @not-an-aardvark. |
This is only available as a command-line flag at the moment, and can't be enabled in a configuration file. (Since this is not a rule, it was decided in #6190 that it shouldn't be configured in the same way as a rule.) One potential solution would be a |
(Repost of #6190)
/* eslint-disable */
comments are useful to document when code is an exception to a given rule. If a piece of code was previously an exception, but now the rule is no longer being violated, it's useful to remove the comment so that it doesn't hide unintended problems in the future. Unfortunately, ESLint doesn't provide any way to detect unused comments, and it's not possible to do this with a custom rule using the public rule API because rules can't view the configurations of other rules to determine whether a directive is used.When this was discussed in #6190, there was consensus that if a behavior like this was added to core, it would have to be implemented as a CLI flag. The TSC decided to wait for a prototype before determining whether to accept the feature. A few months later, the issue was closed because
eslint-plugin-eslint-comments
was released, which achieves the same behavior in a plugin by monkeypatching ESLint's APIs.I'd like to reopen discussion on this because I think this would still be a useful feature, and I don't think using a plugin that monkeypatches core APIs is an acceptable solution in the long term, given that it breaks down the boundaries that we enforce between rules.
(Case in point: We recently refactored the
context.report
internals, causingeslint-plugin-eslint-comments
to break because it was trying to monkeypatch an API that no longer existed (#9193). We ended up adding this and this to prevent the monkeypatches ineslint-plugin-eslint-comments
from breaking, but those are hacks and I'd like to get rid of them.)The proposal is to add a
--report-unused-disable-directives
CLI flag (along with correspondingreportUnusedDisableDirectives
options inCLIEngine
andLinter
). When the flag is enabled, ESLint adds a new reported problem with error severity when it encounters an unusedeslint-disable
comment (or variants likeeslint-disable-line
).I've created a prototype implementation (#9250). The implementation is actually fairly simple -- most of the diff in the PR comes from additional tests, docs, and passthrough options.
There are a few edge cases to consider -- I've written a bit about them below.
Edge cases
Definitions:
Unused directives would need to be detected in core, since they depend on whether other rules report errors. Redundant directives could be detected by external rules (although they would sometimes have to use strange report locations to prevent their own reports from being suppressed). Because of this, I decided that the flag should only cause unused directives to be reported. Redundant directives are not reported unless they are also unused.
Examples:
First comment is unused, second comment is unused and redundant
First comment is unused, second comment is redundant
First comment is unused
First comment is unused
First comment is unused, second comment is redundant
Second comment is redundant and unused
First comment is unused, second comment is redundant and unused
Comment is redundant
/* eslint-enable */
The text was updated successfully, but these errors were encountered: