Change Request: Config to Disallow Disable
See original GitHub issueESLint 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:
eslintrc: "noExtraSemi": ["error", "dissalowDisable"]
"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
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:31 (23 by maintainers)
Top Results From Across the Web
Disable the creation of an unauthorized change request
Navigate to Change > Administration > Unauthorized Change Properties. Clear the Enable event processing property check box. Click Update. Result.
Read more >Disable Authorization check per Change Request step in MDG
Hi All, What authorization checks are disabled when I remove authorization check for a change request step. Using IMG Activity "Configure ...
Read more >Disable Spring Security for OPTIONS Http Method
... the following in the configure() method to allow for the OPTION requests to be permitted by Spring Security without authentication for a...
Read more >Disable a patch file - Sitecore Documentation
To disable a single patch file: Navigate to the patch file in the file system, and rename it to end in something other...
Read more >Disabling security certificate settings - IBM
For the changes to take effect, restart the application server. Disable the Restrict cookies to HTTPS sessions: In WebSphere Integrated Solutions Console, click ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Not to repeat myself, but there’s an RFC open for this issue.
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 ofeslint-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
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 codefrom 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.