This rule raises an issue when ESLint disable comments (eslint-disable, eslint-disable-line, or eslint-disable-next-line) are used without specifying which rules to disable.

Why is this an issue?

ESLint disable comments allow developers to suppress linting warnings and errors in specific parts of their code. While this can be useful for legitimate cases where a rule doesn’t apply, using blanket disable comments without specifying rules creates several problems.

When you use /* eslint-disable / without naming specific rules, you disable *all ESLint rules for that section of code. This means that if new issues are introduced later - like undefined variables, syntax errors, or security vulnerabilities - they won’t be reported by ESLint.

Blanket disables also make code reviews less effective. When reviewers see // eslint-disable-line, they don’t know what specific rule is being bypassed or whether the disable is still necessary. This lack of transparency can lead to technical debt accumulating over time.

Specific disable comments like // eslint-disable-line no-console are much more intentional. They clearly communicate what rule is being bypassed and why, making the code more maintainable and the intent more obvious to other developers.

What is the potential impact?

Using blanket ESLint disable comments can hide important code quality issues, security vulnerabilities, and syntax errors. This reduces the effectiveness of static analysis and can lead to bugs making it into production. It also makes code reviews less thorough and reduces code maintainability over time.

How to fix?

Replace blanket disable comments with specific rule names. Identify which ESLint rules are being violated and explicitly name them in the disable comment.

Non-compliant code example

/* eslint-disable */
console.log('Debug message');
const unusedVar = 'test'; // Noncompliant

Compliant code example

/* eslint-disable no-console, no-unused-vars */
console.log('Debug message');
const unusedVar = 'test';

Documentation