ESLint Config Generator

ESLint config generator for the modern flat format

ESLint Config Generator prepares a readable eslint.config.js for a current JavaScript toolchain. Choose a language, framework, runtime globals, and Prettier compatibility; the tool then places imports and configuration objects in a deliberate order. The result is text for review. It installs nothing and never executes code from your project.

Why flat config replaces .eslintrc

Flat config is the native format in ESLint 9. Instead of a hidden chain of extends entries, it exports an array of ordinary JavaScript objects. Order is significant because later entries can supplement or disable earlier rules. File scopes, parsers, plugins, globals, and exceptions are visible in one place. This is easier to debug, but every plugin must expose a compatible flat configuration.

Browser and Node.js environments

ESLint should know only the global objects available where code actually runs. Browser mode adds names such as window and document; Node mode provides server-runtime globals. A full-stack repository may select both, although precise repositories often create separate configuration objects for client and server directories.

The generator requires at least one environment instead of producing a deceptively complete file without runtime context. This is a safe starting point, not a substitute for architecture review. Add runner-specific globals only to test files. Keep generated artifacts and dependency directories outside analysis with an appropriate Gitignore Generator policy.

TypeScript, React, and Vue without stray extensions

The files scope is assembled from selected technologies. Plain JavaScript does not accidentally receive Vue or TSX extensions. React adds JSX and, when TypeScript is active, TSX. The React and React Hooks plugins use their flat presets, while React version detection reads the installed project version.

Vue receives its recommended flat rules. With TypeScript selected, a separate object points Vue script blocks at the TypeScript parser. A mature application can still require project-aware rules, an import resolver, aliases, or typed checks linked to tsconfig.json. Those decisions depend on repository layout and should not be guessed by a generic generator.

Prettier and formatting responsibility

eslint-config-prettier neither runs Prettier nor edits source files. It disables stylistic ESLint rules that would conflict with the formatter, so the entry belongs at the end of the array. Run formatting as a separate command and verify it separately in CI. This keeps code-quality failures distinct from whitespace or line-wrapping changes.

Share indentation, encoding, and line-ending basics with the EditorConfig Generator. EditorConfig, Prettier, and ESLint have different jobs: the first guides editors, the second formats code, and the third analyzes syntax and program rules.

Installing packages and verifying the result

1. Select JavaScript or TypeScript and the framework actually present in the repository.
2. Enable the runtimes where code executes and decide whether Prettier owns formatting.
3. Copy the result to eslint.config.js at the project root.
4. Install exactly the packages shown by imports as development dependencies.
5. Run npx eslint ., review every finding, and add exceptions only with a clear reason.

Run lint against a clean dependency installation in automation and preserve a nonzero exit code on errors. A suitable job can be added with the GitHub Actions Generator. Avoid unreviewed --fix runs against production code because some fixes can alter program behavior.

Security properties of the generated file

Language and framework choices are limited to known values. The tool does not accept arbitrary imports or JavaScript fragments, so a modified Livewire request cannot append statements to the output. A configuration file is still code executed by Node.js: review package names, lock versions, and verify the source of every dependency before installation.

Plugin upgrades can change preset names and behavior. After a major ESLint update, run lint locally and in CI and treat migration messages as part of the change. This generator provides a conservative baseline. Domain rules, module boundaries, and generated-file exceptions must come from the repository itself.

Frequently asked questions