ESLint Config Generator

What this tool is used for

• Producing a config with the extends and environment settings you want.
• Getting a starting config for a stack you set up rarely.
• Standardising a config across several repositories.
• Adding rules deliberately rather than inheriting a large preset.
• Comparing a generated config against an inherited one.

Frequently Asked Questions

What changed with flat config?

ESLint 9 made `eslint.config.js` the default, replacing `.eslintrc`. Configuration is now an exported array of objects with explicit imports rather than string-based `extends`, which removed the resolution magic that made plugin conflicts so hard to debug.

What is the difference between a rule and a plugin?

A rule is one check; a plugin packages rules, and often a recommended config that enables a subset of them. `extends` pulls in someone's opinion about which rules to enable — which is why two shared configs can conflict on the same rule.

Should the formatter and the linter overlap?

No, and this is settled practice now. Prettier owns formatting, ESLint owns correctness, and `eslint-config-prettier` turns off every stylistic ESLint rule so the two cannot fight. Running both with overlapping rules produces changes that reverse each other.

What do error and warn actually mean?

`error` exits non-zero and fails CI; `warn` reports and passes. The useful discipline is that warnings accumulate and are ignored, so a rule worth having is usually worth setting to error — and a rule not worth failing on is often not worth enabling.

Why is type-aware linting slower?

Because rules that need type information require the TypeScript program to be built, which is the same work as compiling. It buys checks nothing else can make — unhandled promises, unsafe `any` propagation — at a real cost in lint time.

Common errors and gotchas

• Extending several presets whose rules conflict, where the last one silently wins.
• Enabling a large rule set on an existing codebase at once, which buries the real problems.
• Using the legacy config format where the project expects flat config, or the reverse.
• Setting an environment that does not match the runtime, so globals are flagged or missed.
• Configuring a rule that a formatter also handles, which makes the two fight.