English for ESLint Flat Config

Flat config replaced ESLint’s old .eslintrc cascading system with a single JavaScript array, and that structural shift comes with new vocabulary — “config objects” instead of “extends chains” — that’s worth using precisely when discussing a lint setup with a team still thinking in the old model.

Key Vocabulary

Config array — the eslint.config.js file’s top-level export, an ordered array of config objects that ESLint merges sequentially, replacing the old cascading .eslintrc file hierarchy. “The config array has four objects: base JS rules, the TypeScript override, the React plugin block, and a final ignores entry for generated files.”

Config object — a single object within the config array specifying files (which paths it applies to), rules, plugins, and languageOptions for that scope. “We added a separate config object scoped to **/*.test.ts so test files can use looser rules than production code without a nested override file.”

Flat plugin format — the requirement that plugins be imported as JavaScript modules and referenced by object reference in the config, rather than loaded by string name as in the legacy format. “The upgrade broke because the old plugin only shipped the legacy format — we had to switch to a fork that exports itself in the flat plugin format.”

languageOptions — the config object key defining parser, parser options, ECMAScript version, and global variables for the files it applies to, consolidating what used to be spread across parserOptions, env, and globals. “Browser globals like window were undefined-flagged because we hadn’t set languageOptions.globals for that config object — the old env: browser setting has no flat equivalent by default.”

ignores — a config object property (or a standalone object containing only ignores) that excludes matching paths from linting entirely, replacing .eslintignore. “We moved everything from .eslintignore into a single ignores-only config object at the top of the array — flat config no longer reads a separate ignore file by default.”

Common Phrases

• “Is this rule set in a config object scoped to specific files, or does it apply globally?”
• “Is the plugin imported in flat format, or is it still the legacy string-based one?”
• “Where are the language options defined for this file — is languageOptions actually covering it?”
• “Is this file excluded through an ignores entry, or is it just not being linted by accident?”
• “Does the config array order matter here — does a later object override an earlier rule?”

Example Sentences

Explaining a migration in a PR description: “Migrated from .eslintrc.json to flat config: four config objects instead of an extends chain, plugins imported directly instead of by name, and ignores consolidated into a single object.”

Debugging an unexpected lint failure: “This rule is coming from the base config object, and the TypeScript-specific object further down the array doesn’t override it — we need to add an explicit override there.”

Reviewing a config change: “Good call scoping that rule to a config object for just the test files — it was too strict for mocks and fixtures, but we still want it enforced in production code.”

Professional Tips

• Say config object rather than “the config” when there are multiple — flat config’s whole point is scoping rules per file pattern, and vague references undercut that.
• Confirm flat plugin format compatibility before proposing a plugin upgrade — a legacy-only plugin is a common blocker discovered mid-migration, not before.
• Reference languageOptions by name when debugging parser or globals issues — “the parser settings” is ambiguous about which config object actually applies.
• Consolidate exclusions into an explicit ignores object early in a migration and say so in the PR — a missing ignores entry silently re-lints generated files and confuses reviewers.

Practice Exercise

1. Write a sentence describing what a config object with files and rules does.
2. Explain, in your own words, the difference between the legacy and flat plugin formats.
3. Describe how you’d migrate a project’s ignore rules to flat config.