Ability to print out the list of top disabled rules

The problem you want to solve.

In a large codebase, there can easily be hundreds or even thousands of places where inline disable directive comments (like // eslint-disable-line no-console) have been used.

There is not currently a convenient method to find out what rules developers are disabling like this other than manually searching the codebase or writing a custom regexp parsing script. In fact, I put together a custom script for exactly this purpose, but it’s a bit buggy and not easily available across different projects.

Gaining an understanding / summary statistics of what rules are being most frequently disabled by contributors can be useful for a variety of reasons:

• determining what kinds of tech debt exist in a codebase
• determining what rules may be buggy and in need of improvements
• determining what issues developers need more education about
• etc

Your take on the correct solution to problem.

I’m proposing a new CLI option --list-disable-directives (or similar name) that would show the complete list of inline-disabled rules by count (descending order).

yarn eslint --list-disable-directives .

[normal eslint output goes here]

Rule                   | Count | Relative 
:----------------------|------:|--------:
no-console             |   125 |    40.1%
no-unused-vars         |   104 |    33.3%
radix                  |    43 |    18.8%
node/no-missing-import |    22 |     7.1%
import/order           |    15 |     4.8%
prettier/prettier      |     2 |     0.6%
no-undef               |     1 |     0.3%

This matches the output format of the TIMING environment variable which can be used to see summary statistics about rule performance.

Are you willing to submit a pull request to implement this change?

Yes

[btmills]

The reasons you listed for this being potentially useful are compelling. For codebases that don’t configure globals, envs, or rule options inline, --no-inline-config can do this today: the new errors with that option would be the ones that were disabled inline.

[nzakas]

This is an interesting idea. I’m not sure if this exact proposal is complete enough to dig in too deep, but I think we can at least discuss the overall direction and if the team is interested, we could progress to an RFC.