Zipper Tools

ESLint Migration Guides

How to migrate ESLint overrides to flat config arrays

Overrides in legacy config become separate array elements in flat config.

Start here

The safe first move

Each override becomes a separate config object in the array with its own files pattern.

Stop before automation when: Complex nested overrides with multiple extends. Overrides that depend on JS logic.

Target shape

module.exports = [
  { rules: { "no-console": "warn" } },
  {
    files: ["**/*.test.js"],
    rules: { "no-console": "off" },
  },
];

Repo fit check

Want to know if your repo has this pattern?

Run the matching scanner locally first. The fit-report add-on is not listed for this proof-only product yet, so use the proof page and scanner output before treating it as a purchase candidate.

  • Local scan; no repository upload.
  • Supported findings are separated from manual-review findings.
  • Buy only when the repeated pattern is worth automating.
Run the static-config scan View example report See when to buy 
Example scan summary
supported_findings: 38
manual_review_findings: 6
files_uploaded: 0
confidence: reviewable

Why this page exists

How to migrate ESLint overrides to flat config arrays

Overrides become array elements with files patterns in flat config.

Direct answer

What changes

Each override becomes a separate config object in the array with its own files pattern.

Example

Before and after

Before

{
  "rules": {"no-console": "warn"},
  "overrides": [{
    "files": ["*.test.js"],
    "rules": {"no-console": "off"}
  }]
}

After

module.exports = [
  { rules: { "no-console": "warn" } },
  {
    files: ["**/*.test.js"],
    rules: { "no-console": "off" },
  },
];

Decision path

If this repeats across the repo, open the evaluation pages next.

This product exists for the static-config subset. It does not pretend to evaluate JS config logic.

  • Teams migrating static .eslintrc JSON or YAML configs.
  • Repos that still store eslintConfig inside package.json.
  • The fit-report add-on is not listed for this proof-only product yet; use the proof page and scanner output before treating this as purchasable.

Before checkout

Product fit, proof, and price should all be one click away.

Current listed price is not published on the pricing page yet.

Typical symptoms

  • Legacy config uses overrides for test files or specific directories.
  • Teams need the override patterns preserved in flat config.
  • FlatCompat can carry simple overrides through.

What the product covers

  • Static override patterns in JSON/YAML configs.
  • FlatCompat handling of simple overrides.
  • Cross-links to the ignore pattern migration.

Manual-review boundary

  • Complex nested overrides with multiple extends.
  • Overrides that depend on JS logic.
  • Repos with multiple config sources.

Keep the migration narrow

Use the exact-problem guides as a triage layer, then decide whether the repo is inside the supported subset.

FAQ

Fast answers before you decide

What is the safest fix for eslint overrides flat config?

Each override becomes a separate config object in the array with its own files pattern.

Can eslint overrides flat config be automated?

Automate only the supported subset: Static override patterns in JSON/YAML configs. FlatCompat handling of simple overrides. Cross-links to the ignore pattern migration. Keep these cases in manual review: Complex nested overrides with multiple extends. Overrides that depend on JS logic. Repos with multiple config sources.

When should I buy ESLint Flat Config Migration Cleanup Pack?

Use ESLint Flat Config Migration Cleanup Pack only when this pattern repeats across enough files that manual cleanup is still costly. Run the public scan or read the proof first. The fit-report add-on is not listed for this proof-only product yet; if unsupported findings dominate, keep the work manual.