Change Request: Enable `reportUnusedDisableDirectives` config option by default

2022-12 UPDATE

I have opened an RFC for this:

• https://github.com/eslint/rfcs/pull/100

ESLint version

8.5.0

What problem do you want to solve?

Outdated/unused ESLint disable directive comments (e.g. notConsole(); // eslint-disable-line no-console) are currently a blind spot for most apps/repositories. These leftover comments cause clutter and confusion, and detecting them requires going out of one’s way by using one of the following existing solutions:

1. Run linting with eslint --report-unused-disable-directives (errors, but only applies during CLI)
2. Add reportUnusedDisableDirectives: true to .eslintrc.js config file (warns)
3. Enabling third-party rule eslint-comments/no-unused-disable (errors, but requires third-party plugin)

These existing solutions are fine but they lack discoverability and require manual work to adopt in every single repository so are thus not commonly used.

What do you think is the correct solution?

As a breaking change, I propose changing the default value for the config option reportUnusedDisableDirectives from false to true. This will cause users to see additional warnings if they have unused disable directives.

Displaying these warnings should help raise awareness about the problem of unused disable directives, and encourage many users to remove unused disable directives caused by their changes.

Note that since these are just warnings, users could also choose to ignore them and let them pile up, as a potential downside. But luckily, the new functionality from running eslint --fix --report-unused-disable-directives could be used to fix/remove all of them at any time.

Another note is that we need to limit any default behavior to warnings and not errors for this due to our semver policy. More context in:

• https://github.com/eslint/eslint/pull/14699#discussion_r650863268

  …because of our semver policy, which says that bug fixes that produce fewer errors should not break builds.

• https://github.com/eslint/eslint/issues/12703#issuecomment-568582014

  If we allowed for errors to be reported with reportUnusedDisableDirectives, we would limit what kind of changes we could publish in a semver-patch release (since fixing a bug that would result in fewer errors could create additional unused disable directives).

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[bmish]

@nzakas your questions have got me thinking that the current boolean design of these options is particularly confusing and unintuitive, making it hard to predict the interplay.

What if I described a new “explicit severity” design:

• The config and CLI options are both changed to accept standard severity values: off, warn, error
• If both options are present, the CLI option takes precedence over (overrides) the config option
• If only one of the options is present, the value of the present option is used
• If neither option is present, the default value is used
• Note: There’s only one underlying setting, and the config and CLI options are just two different ways of controlling it

Benefits of this design:

• The user should always be able to achieve the desired effect (off / warn / error), regardless of where they set the option from
• No confusing inconsistency where one of the options triggers errors but the other triggers warnings
• reportUnusedDisableDirectives: 'error' can now be part of a shareable config

On top of this design, we can still debate what the default value should be:

• Today: Default is off
• Conservative proposal: Default changed to warn
• Aggressive proposal: Default changed to error (potential semver implication, but this is my preference if acceptable)

[bmish]

I have opened an RFC for this:

• https://github.com/eslint/rfcs/pull/100