Don't like ads? Go Ad-Free Today 

ESLint Config Generator

DataDeveloper

ADVERTISEMENT · REMOVE?

INPUT

Auto Process Client Side

Config Format

Flat config is the default since ESLint v9. Legacy is for older projects still on v8.

Framework / Environment

Selects sensible parser, plugins, and base rules for your stack.

Style Guide

Shareable config extended after the base. Prettier should be added last.

Use TypeScript (@typescript-eslint)

Language Options

ecmaVersion

JavaScript syntax version the parser accepts.

sourceType

How files should be parsed.

Environments

browser globals (window, document, fetch)

node globals (process, require, __dirname)

jest globals (describe, test, expect)

mocha globals

Common Rules

semi (require semicolons)

quotes

indent

no-unused-vars

no-console

eqeqeq (strict equality)

prefer-const

no-var

Output Options

Include inline comments explaining each option

Include descriptive header comment

Include npm install command at top

OUTPUT

Client Side

ADVERTISEMENT · REMOVE?

Guide

ESLint Config Generator

Generate a ready-to-use ESLint configuration for your project in seconds. Pick your framework, language version, environments, and rule severities, then copy the output directly into your repo. Supports both the modern flat config (eslint.config.js, ESLint v9+) and the legacy .eslintrc.json format used by ESLint v8.

How to Use

Choose your config format: flat (ESLint v9+) or legacy (.eslintrc.json).
Select the framework you are using — vanilla JS, Node.js, React, Next.js, Vue 3, or TypeScript.
Optionally pick a style guide (Airbnb, Standard, Google, Prettier) to extend.
Toggle TypeScript support if your stack mixes JS with TS.
Adjust language options, environments, and rule severities to match your codebase.
Copy the generated config and paste it into eslint.config.js or .eslintrc.json, then install the printed dependencies.

Features

Flat & legacy formats – Emit either eslint.config.js for ESLint v9+ or .eslintrc.json for v8.
Framework presets – Vanilla JS, Node.js, React, Next.js, Vue 3, and TypeScript with correct plugins and recommended configs wired up.
Style guides – Optional Airbnb, Standard (via neostandard for flat), Google, and Prettier integrations.
Common rule toggles – Curated severity controls for semi, quotes, indent, no-unused-vars, no-console, eqeqeq, prefer-const, and no-var.
Install command – Prints the matching npm install -D line so you know exactly which packages to add.
Inline comments – Optional explanatory comments next to each option so the config doubles as documentation.
Client-side only – Everything runs in your browser; no code is uploaded.

 FAQ

What is the difference between flat config and legacy .eslintrc?

Flat config is a single JavaScript module that exports an array (or the result of helpers like tseslint.config()). It replaced the legacy .eslintrc cascade in ESLint v9 and uses real imports instead of string lookups, which makes it easier to reason about and works better with native ES modules. The legacy .eslintrc system still works in ESLint v8 but is no longer the default in newer versions.
Why must Prettier be applied last?

eslint-config-prettier turns off ESLint rules that conflict with Prettier's formatter, so applying it last guarantees those formatting rules are disabled regardless of what earlier configs enabled. If you put Prettier earlier, a later config can re-enable a rule that fights with Prettier and you will see noisy lint errors on otherwise-formatted code.
What does the env / globals option actually do?

It tells the parser which predefined global variables exist so rules like no-undef do not complain about them. The browser environment adds window, document, fetch, etc.; the node environment adds process, require, __dirname. Without the right globals declared, valid code can be flagged as referencing undefined variables.
What is the difference between error, warn, and off severities?

A rule set to error makes ESLint exit with a non-zero status, which fails CI and pre-commit hooks. A rule set to warn surfaces the message but does not fail the build. Setting off disables the rule entirely. Most teams reserve error for code-correctness rules and use warn for style or migration noise they are not ready to enforce.