Lint test files differently with ESLint overrides

The problem: one rule set for every file

You enable no-console to keep debug logs out of production code. Your CI pipeline passes, until a teammate adds console.log to a test file to troubleshoot a flaky test. ESLint flags it, the build fails, and now you are choosing between weakening the rule for everything or carving out an exception by hand.

ESLint’s overrides block solves this by applying a separate rule set to files that match a glob pattern. You keep the strict base rule for source files and relax it only for test files, without duplicating your entire configuration.

How overrides match files

In the eslintrc format (ESLint v8 and earlier), the top-level overrides array holds configuration objects. Each object can use files to match files by glob, excludedFiles to carve out exceptions, and rule settings that merge with or replace the base config. ESLint evaluates overrides in order; a later override that matches the same file wins.

A glob is a pattern-matching string, such as **/*.test.js, that matches file paths rather than exact filenames.

Worked example: relax no-console for tests only

Assume your repository uses ESLint v8 with an .eslintrc.json at the project root.

{
  "root": true,
  "env": {
    "node": true,
    "es2022": true
  },
  "rules": {
    "no-console": "error"
  },
  "overrides": [
    {
      "files": ["**/*.test.js", "**/__tests__/**"],
      "excludedFiles": ["**/fixtures/**"],
      "rules": {
        "no-console": "off"
      }
    }
  ]
}

This configuration keeps no-console as an error for most files. Any file matching **/*.test.js or **/__tests__/**, except files under fixtures, gets no-console turned off.

Run and verify

1. Open a terminal in <project-root>, where .eslintrc.json lives.
2. Make sure ESLint is installed locally or available through npx. You need read access to the config and the files you lint.
3. Run npx eslint src/app.js tests/app.test.js.
4. Expected check: src/app.js reports a no-console error if it contains console.log; tests/app.test.js does not report that rule.
5. For a deeper diagnostic, run npx eslint --print-config tests/app.test.js and inspect the resolved rules.no-console value. It should show off for that file.

Risk: an overly broad glob such as **/*.js in an override can silently apply to more files than intended. Keep patterns specific, and review --print-config output when in doubt.

Trade-offs and limitations

• Order matters. If two overrides match the same file, the later one in the array takes precedence. Place broad overrides before narrow ones if you want narrow exceptions to win.
• Overrides merge with base rules; they do not replace the whole config unless you explicitly set every rule you care about.
• This behavior applies to the eslintrc format. ESLint v9’s flat config (eslint.config.js) handles file-specific rules differently and does not use an overrides key.

Rollback

Editing .eslintrc.json changes repository state. To roll back, restore the previous file from version control, for example git checkout -- .eslintrc.json, or remove the overrides block and commit the change.

Closing

Start with your most common exception—test files, build scripts, or legacy directories—and add one targeted override. Verify with --print-config, keep globs narrow, and document why the override exists so the next person does not delete it thinking it is redundant.