Change Request: Config to Disallow Disable

ESLint version

8.0.0

What problem do you want to solve?

ESLint currently allows users to disable rules. In large codebases with MANY Prs, some users disable lint rules without really knowing what they are doing. This slips by PRs because reviewers sometimes don’t actually review ¯\_(ツ)_/¯

There exists rules such as no-abusive-eslint-disable but that in and of itself can be disabled

What do you think is the correct solution?

I’d like ESLint to allow users to configure certain rules to be exempt from all comment style disables

eslintrc: "noExtraSemi": ["error", "dissalowDisable"] eslintrc: "noExtraSemi": ["forbid"]

so in code

// eslint-disable-next-line noExtraSemi
const foo = 5;;

Would still result in an error

Participation

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

Additional comments

No response

[nzakas]

Not to repeat myself, but there’s an RFC open for this issue.

[joshwilsonvu]

Hi, sorry if that came across harshly, let me explain what I was thinking. My main thought is that I don’t think ESLint should go farther than rules like eslint-comments/no-restricted-disable. If the purpose of lint rules is to define and maintain a set of standards that an organization adheres to, then the purpose of eslint-disable directives is to signal exceptions to these standards.

These exceptions should be red flags in code reviews, and every disable directive should have clear & obvious reasoning behind it. If it becomes normal to disable a specific rule, then the organization should probably turn the rule off, or find and fix all of these occurences if the rule is deemed important. I’m sure you agree, more or less. As it relates to your scenario with mandated rules, as I understand it the community solution forces you to write

// eslint-disable-next-line eslint-comments/no-restricted-disable
// eslint-disable-next-lline foo/some-restricted-rule
forbidden(code);

to disable foo/some-restricted-rule. I honestly sympathize with your frustration that code like this is written and gets checked in, but if a red flag like this slips past code review, what’s to stop this code

"rules": {
- "foo/some-restricted-rule": "forbid"
+ "foo/some-restricted-rule": "error"
}

from getting in unnoticed? It feels like a technical band-aid to an organizational problem.

The benefit of the community solution is that you can grep for it, as you’ve seen for yourself: eslint-comments/no-restricted-disable or your rule of choice will be there every time this happens. It should be possible to get the number of these comments down to zero with some work, without breaking your build in the meantime. Afterwards, if you’re still concerned about missing these double-disable-directives, it may just be simplest to grep for these from time to time and instruct PR reviewers not to pass PRs with them. You’d have to check for changes in .eslintrc from time to time anyway.

With all due respect for the tough situation you’re in, I’m just a little doubtful how much value there is in adding "forbid", when in my opinion ESLint is already doing its job—automatically maintaining standards, and leaving exceptions for human review.