Best Practices & Anti-patterns

Key principles

DO: Use extends, prefer warn over error initially, commit configs to git. DON'T: Disable all rules, ignore formatter conflicts, skip CI checks.

Good vs bad patterns

Compare good and bad ESLint configuration patterns.

// GOOD: Use extends and overrides
{ "extends": ["eslint:recommended", "prettier"],
  "overrides": [{ "files": "*.test.js", "rules": { "no-console": "off" } }]
}

// BAD: Disable everything, no extends
{ "rules": { "no-unused-vars": "off", "no-undef": "off" } }

// GOOD: Gradual enforcement
{ "rules": { "no-console": "warn" } }

// BAD: Immediate strict errors on adoption
{ "rules": { "no-console": "error" } }

Output:

Good patterns use extends, overrides, and warn initially

Evolution over time

Start loose (warn, few rules) and tighten over time (error, more rules) as the team adapts. This reduces friction and improves adoption.

Quick check

Quick check: What's a best practice for team adoption?

• Start with warn, gradually move to error as team adapts.
• Enforce all rules as errors immediately.
• Disable most rules.