Disable ESLint Rules: Inline, Config, or CLI

ESLint is an essential tool for maintaining consistent code quality across JavaScript projects. However, real-world scenarios often require exceptions. You may need to disable a rule temporarily, adjust it for legacy code, or exclude auto‑generated files entirely. ESLint provides several structured ways to do this while keeping the rest of your codebase clean and maintainable.

This article explains the four primary methods of disabling ESLint rules and how to use each correctly.

Reasons to Disable ESLint Rules

There are valid reasons for disabling or relaxing linting rules:

1. Legacy codebases that do not follow modern conventions.
2. Third‑party or auto‑generated code that should not be linted.
3. Experimental work where strict linting gets in the way.
4. Scripts or configuration files that require exceptions.

Rather than disabling ESLint entirely, it is better to apply targeted exceptions using one of the methods below.

Method 1: Disable ESLint Rules Using Configuration Overrides

The most scalable and recommended method is modifying your ESLint configuration to apply different rules to specific files.

Step 1: Use the overrides Option

In .eslintrc.json, .eslintrc.js, or eslint.config.js:

{
  "overrides": [
    {
      "files": ["legacy/**/*.js"],
      "rules": {
        "no-console": "off",
        "no-unused-vars": "off"
      }
    }
  ]
}

This approach is ideal for:

• Legacy directories
• Vendor imports
• Script folders requiring custom rules

ESLint will still lint these files but will skip the specified rules.

Method 2: Disable Rules Inline with ESLint Comments

Inline comments are useful when you need to disable rules only in specific parts of a file.

Disable All Rules for the Entire File

Place this at the top:

/* eslint-disable */

Disable a Specific Rule

/* eslint-disable no-console */

Disable Only a Single Line

console.log('debug'); // eslint-disable-line no-console

Disable Only the Next Line

// eslint-disable-next-line no-alert
alert('test');

Re-enable Rules Later in a File

/* eslint-disable no-console */
console.log('allowed here');
/* eslint-enable no-console */

This allows fine‑grained control without affecting the rest of the codebase.

Method 3: Exclude Files Entirely Using .eslintignore

If you want ESLint to skip certain files or folders completely, use .eslintignore.

Example:

build/
dist/
coverage/
vendor/
legacy/*.js

This is ideal for:

• Build output
• Large libraries
• Auto‑generated code
• Dependency bundles

ESLint will not analyze ignored files at all.

Method 4: Disable Rules via the ESLint CLI

If you need a one‑off exception during manual linting or within CI scripts, you can temporarily disable rules using command‑line flags.

Disable a Rule for a Single Run

eslint yourfile.js --rule "no-console: off"

Disable Multiple Rules

eslint yourfile.js --rule "no-console: off" --rule "no-unused-vars: off"

CLI‑based disabling is useful for debugging or for running custom lint tasks without modifying source code.

Additional Tips and Best Practices

Prefer Config Overrides for Long‑Term Exceptions

If you disable the same rule repeatedly, configure an override instead of relying on inline comments.

Keep Inline Comments Minimal

Inline disables should be rare, not the default approach.

Document Why a Rule Was Disabled

A short comment can help future maintainers understand the context.

Avoid Disabling Core Safety Rules

Rules like no-undef, no-dupe-keys, or no-unreachable protect against real bugs.
Disable them only when absolutely necessary.

Refactor When Possible

If you frequently suppress a rule, consider adjusting the code or updating your ESLint config to better match your coding style.

Conclusion

ESLint provides several structured methods for disabling rules without compromising overall code quality. Whether you need a temporary exception, a file‑wide override, or a configuration‑level adjustment, ESLint makes it flexible to manage exceptions safely.

Use:

• configuration overrides for folders and file patterns
• inline comments for isolated exceptions
• .eslintignore for excluding files
• CLI flags for one‑time runs

With the right approach, you can maintain a clean codebase while still accommodating the unique needs of your project.