How to disable an ESLint rule

You can disable an ESLint rule at four levels: a single line, a block of code, a whole file, or the entire project. The trick is picking the smallest scope that solves your problem.

What can you do to disable one ESLint rule that is perhaps set automatically by your tooling?

Consider the case where your tooling set the no-debugger and no-console rules.

There might be a valid reason for production code, but in development mode, having the ability to access the browser debugger and the Console API is essential.

Disable a rule for a file or a block

You can disable one or more specific ESLint rules for a whole file by adding on a few lines:

/* eslint-disable no-debugger, no-console */
console.log('test')

or you can just do so in a block, re-enabling it afterwards:

/* eslint-disable no-debugger, no-console */
console.log('test')
/* eslint-enable no-debugger, no-console */

Disable a rule for a single line

Or you can disable the rule on a specific line:

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

debugger // eslint-disable-line no-debugger

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

If the line is long, the comment can go on the line above it instead:

// eslint-disable-next-line no-console
console.log('test')

Both do the same thing. I prefer this one because it keeps the code line clean.

This is my favorite scope. Disabling a rule on one line documents exactly where and why you’re making an exception, without hiding real problems elsewhere in the file.

Disable a rule for the whole project

Another way is to disable it globally for the project.

In package.json you can find the eslintConfig rule, which might have some content already, like this:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },

Here you can disable the rules you want to disable:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ],
    "rules": {
      "no-unused-vars": "off"
    }
  },

If your project uses a separate ESLint configuration file instead, the same rules object goes in there.

A rule takes one of three values: "off" disables it, "warn" reports it without failing the lint run, and "error" fails it. Downgrading a rule to "warn" is often better than turning it off: you still see the problem, it just doesn’t block you.

Be careful with the bare disable comment

One pitfall to watch out for: writing /* eslint-disable */ without naming any rule. That turns off every rule from that point to the end of the file, so real errors slip through unnoticed.

I’ve seen files pass linting for months while accumulating unused variables, because someone silenced everything to hide one warning. Always name the rules you’re disabling.