ESLint

ESLint is the de facto standard for identifying and enforcing code quality patterns in JavaScript and TypeScript projects. It parses source code into an abstract syntax tree using Espree and walks that tree to apply rules, every one of which is itself a plugin, so teams can enable, disable, or write their own without touching ESLint’s core. With flat config (eslint.config.js), rule sets, parsers, and language options are expressed as plain JavaScript arrays and objects rather than the legacy cascading .eslintrc format, making configuration composition explicit and easy to reason about.

With 294 built-in rules covering ESM/CommonJS quirks, unused variables, unreachable code, and stylistic conventions, plus first-class support for custom parsers (TypeScript, Babel) and processors (Markdown, Vue), ESLint underpins the linting layer of nearly every major JavaScript toolchain. Downloaded over 159 million times a week from npm, it’s typically wired into CI, editor integrations, and pre-commit hooks to catch bugs and enforce consistency before code ships.

What You Get

• 294 built-in core rules spanning correctness, best practices, and stylistic conventions, each independently toggleable and configurable.
• A flat config system (eslint.config.js) that composes rule sets, parsers, and language options as plain JS, replacing the legacy cascading .eslintrc resolution.
• A pluggable parser/processor pipeline, so TypeScript, JSX, Vue SFCs, and Markdown code blocks can all be linted through the same CLI and API.
• An autofix engine (--fix) that safely rewrites source files for any rule that defines a fixer, plus a suggestions mechanism for editor-driven fixes.
• A public Node.js API (Linter, ESLint classes) for embedding linting in custom tooling, editors, and CI systems beyond the CLI.

Common Use Cases

• Enforcing a shared style guide across a team by extending a shared config (e.g. eslint-config-airbnb) and layering project-specific overrides.
• Catching real bugs before merge — unused variables, unreachable code, unsafe comparisons — as a required CI check on every pull request.
• Linting TypeScript codebases by pairing ESLint’s rule engine with @typescript-eslint’s parser and type-aware rules.
• Powering editor-integrated real-time feedback in VS Code and other IDEs via the ESLint language server.

Under The Hood

Architecture Execution starts at the CLI entry point (lib/cli.js), which hands off to the ESLint class (lib/eslint/eslint.js), a high-level orchestrator that resolves configuration via ConfigLoader/FlatConfigArray (lib/config/), optionally fans work out across worker threads (node:worker_threads), and delegates per-file linting to lib/eslint/worker.js. The actual rule-running core lives in the Linter class (lib/linter/linter.js): it builds a SourceCode object from the parsed AST, traverses it via SourceCodeTraverser, applies each active rule’s visitor, resolves inline eslint-disable directives (apply-disable-directives.js), and iterates SourceCodeFixer up to MAX_AUTOFIX_PASSES (10) when autofixing. Cross-cutting concerns are split into dedicated services (lib/services/: parser-service, processor-service, suppressions-service, warning-service), and the JS-specific parsing/traversal logic is isolated behind a Language interface (lib/languages/js) implementing the @eslint/core contract, decoupling the linting engine from JavaScript so it can, in principle, target other languages.

Tech Stack ESLint is plain CommonJS Node.js (engines ^20.19.0 || ^22.13.0 || >=24), authored without a TypeScript build step but shipping hand-maintained .d.ts type definitions validated against multiple TypeScript versions (5.3, 5.x, and the native-preview 7.x compiler) in CI. Core dependencies include Espree for AST parsing, eslint-scope for variable scope analysis, esquery for AST querying, Ajv for JSON-schema validation of rule options, and the newer @eslint/config-array, @eslint/plugin-kit, and @eslint/core packages that back the flat-config and language-plugin system. The repo is an npm workspace (packages/*) hosting companion packages, tested with Mocha for the core suite and Cypress for browser bundle tests, bundled for the browser via Webpack, and formatted with Prettier.

Code Quality The test suite is extensive — individual rule test files run into the thousands of lines (tests/lib/rules/no-unused-vars.js alone is over 5,000 lines) — and every rule is exercised through a dedicated RuleTester harness (lib/rule-tester/rule-tester.js) that standardizes valid/invalid test cases and autofix assertions. Coverage is collected with c8 (lcov, cobertura, and text-summary reporters) and ESLint dogfoods itself: eslint.config.js lints ESLint’s own source with directory-specific overrides for internal packages, layered with eslint-plugin-eslint-plugin for meta-linting rule modules and Prettier for formatting. CI (ci.yml, types-integration.yml, codeql-analysis.yml, ecosystem-tests.yml) runs the full test/type-check/lint matrix across supported Node and TypeScript versions and additionally re-lints real downstream projects on every change to catch regressions before release.

API Design ESLint offers both a zero-config CLI (npx eslint) and a granular public API (Linter, ESLint, SourceCode, RuleTester) for embedding linting into other tools, editors, and build systems. Flat config replaced the older cascading .eslintrc resolution algorithm — long a source of confusion — with plain JS arrays/objects composed via defineConfig and globalIgnores helpers. Rule authors work against a consistent meta/create contract with JSON-schema-validated options and a context.report API for messages, fixers, and suggestions, and the public API surface ships with full TypeScript types and an extensive per-rule documentation site, lowering the barrier for both end users and third-party plugin authors.