Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Change Request: Enable `reportUnusedDisableDirectives` config option by default

See original GitHub issue

2022-12 UPDATE

I have opened an RFC for this:

ESLint version


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:


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

Additional comments

No response

Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:7
  • Comments:20 (18 by maintainers)

github_iconTop GitHub Comments

bmishcommented, Jan 5, 2022

@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)
bmishcommented, Dec 9, 2022

I have opened an RFC for this:

Read more comments on GitHub >

github_iconTop Results From Across the Web

Add reportUnusedDisableDirectives to ESLint config - GitLab
What does this MR do? Replaces --report-unused-disable-directives command line flag from ESLint with corresponding config option. see.
Read more >
Command Line Interface - ESLint - Pluggable JavaScript Linter
The CLI has a variety of options that you can pass to configure ESLint. ... comments from changing config or rules --report-unused-disable-directives Adds ......
Read more >
@nrwl/linter:eslint | Nx
ESLint Lint Target. Options can be configured in project.json when defining the executor, or when invoking it. Read more about how to configure...
Read more >
@scottnonnenberg/eslint-config-thehelp - Package Manager
⚠ BREAKING CHANGES · typescript: Remove es2015 sub-configuration, remove functional from core configuration, enable reportUnusedDisableDirectives, add 'es2020' ...
Read more >
`eslint-plugin-jsdoc` options, if present, are in the form of an object supplied ... tagNamePreference` to configure a preferred alias name for a JSDoc...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found