ESLint Migration Guides

How to migrate env and globals settings to ESLint flat config

Move env and globals from legacy config into the flat config languageOptions object.

Start here

The safe first move

Move env settings to languageOptions.globals using the globals package, and move globals directly into languageOptions.globals.

Stop before automation when: Dynamic env selection based on file patterns. Overlapping globals from multiple sources.

Target shape

const globals = require("globals");

module.exports = [{
  languageOptions: {
    globals: {
      ...globals.browser,
      ...globals.node,
      myGlobal: "readonly",
    },
  },
}];

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 env and globals settings to ESLint flat config

env and globals move into languageOptions in flat config.

Direct answer

What changes

Move env settings to languageOptions.globals using the globals package, and move globals directly into languageOptions.globals.

Example

Before and after

Before

{
  "env": {"browser": true, "node": true},
  "globals": {"myGlobal": "readonly"}
}

After

const globals = require("globals");

module.exports = [{
  languageOptions: {
    globals: {
      ...globals.browser,
      ...globals.node,
      myGlobal: "readonly",
    },
  },
}];

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 still uses env for browser/node globals.
  • Custom globals need to move into the new structure.
  • Teams want the env/globals migration handled with the config bridge.

What the product covers

  • Static env configuration mapping to globals package imports.
  • Custom globals migration to languageOptions.globals.
  • Integration with FlatCompat bridge generation.

Manual-review boundary

  • Dynamic env selection based on file patterns.
  • Overlapping globals from multiple sources.
  • Repos with JS-backed legacy config logic.

FAQ

Fast answers before you decide

What is the safest fix for eslint env globals flat config?

Move env settings to languageOptions.globals using the globals package, and move globals directly into languageOptions.globals.

Can eslint env globals flat config be automated?

Automate only the supported subset: Static env configuration mapping to globals package imports. Custom globals migration to languageOptions.globals. Integration with FlatCompat bridge generation. Keep these cases in manual review: Dynamic env selection based on file patterns. Overlapping globals from multiple sources. Repos with JS-backed legacy config logic.

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.