Fine‑Grained ESLint Linting: Using Overrides to Allow console.log in Tests Only

Why Override Rules for Test Files?

In many projects the no-console rule is enforced to keep production code clean, but test suites often rely on console.log for debugging. ESLint’s overrides field lets you keep the strict rule for source files while relaxing it for test files without touching the base configuration.

How the Override Mechanism Works

The overrides array contains objects that match files via glob patterns. Each object can specify its own rules section. Overrides are processed after the base config, so they can add or remove rules for matched files. If multiple overrides match the same file, the last one in the array wins for any rule that appears in more than one override.

Concrete Example

Assume a project structure:

src/
├─ index.js
└─ utils.test.js

Create .eslintrc.json with the following content:

{
  "env": {"browser": true, "node": true, "es2021": true},
  "extends": "eslint:recommended",
  "rules": {
    "no-console": "error"
  },
  "overrides": [
    {
      "files": ["**/*.test.js", "**/*.spec.js", "**/*.test.ts", "**/*.spec.ts"],
      "rules": {
        "no-console": "off"
      }
    }
  ]
}

Run ESLint from the project root:

# Check the source file – should flag console.log
eslint src/index.js

# Check the test file – should pass without errors
eslint src/utils.test.js

To verify the effective rule set for a file, use:

eslint --print-config src/utils.test.js

The output will show "no-console": "off" only for the test file.

Common Pitfalls and How to Avoid Them

• Glob Pattern Typos: A small mistake like **/*.tests.js will never match *.test.js files. Double‑check spelling and use the --print-config command to confirm matches.
• Override Ordering: If you add another override that also turns no-console on for **/*.test.js, the last override will override the first. Place the most specific overrides last.
• Partial Overrides: Turning off no-console in an override only affects that rule. Other rules (e.g., eqeqeq) still apply unless explicitly overridden.
• Global vs. Local: The base rule remains active globally. Accidentally adding console.log to a production file will still trigger the error.

Limitations

Overrides are evaluated per file, not per directory. If you need different rules for different sub‑folders, include separate override objects with appropriate glob patterns. Also, complex patterns can lead to performance overhead in very large projects.

Practical Checklist

1. Define no-console as "error" in the base rules section.
2. Add an override that matches all test file patterns and sets no-console to "off".
3. Run eslint --print-config on a sample test file to confirm the rule is disabled.
4. Run eslint --print-config on a production file to ensure the rule remains enabled.
5. Commit the configuration and add a linting step to your CI pipeline.

By following this pattern, you maintain strict linting for production code while granting developers the flexibility to debug tests with console statements.