ESLint Isn't Magic: How ASTs Turn Code Style Rules Into Machine-Readable Checks
Understanding the AST traversal model turns ESLint from a black-box config file into a programmable quality gate. Developers who grasp that rules are just node-matching visitors can write custom lint rules for project-specific footguns instead of relying solely on presets.
A static analysis tool that never executes code, ESLint converts JavaScript and TypeScript into an AST—a structured tree of nodes like VariableDeclaration and Literal. Each rule, from `no-var` to `indent`, is a pattern matcher that traverses that tree and reports violations when it finds a forbidden shape. The flat config format (`eslint.config.mjs`) replaces the old nested `.eslintrc` with a flat array of configuration objects, each specifying file globs, plugins, language options, and rules.
Rule severity uses three levels: error (2) blocks commits for unambiguous mistakes like `var`, warn (1) flags suspicious patterns like `console.log` that require human judgment, and off (0) disables a rule entirely. The `--fix` flag auto-corrects style violations where the correct answer is deterministic—semicolons, quotes, indentation—but leaves judgment-call rules untouched.
A working setup pulls in four packages: the `eslint` core engine, `@eslint/js` for recommended rules, `globals` to declare browser or Node globals so ESLint doesn't falsely report `window is not defined`, and `typescript-eslint` to parse TypeScript syntax that ESLint's native parser cannot understand.
The distinction between error and warn levels encodes a practical philosophy: automate what's certain, defer to humans what's ambiguous. This prevents linting from becoming either too permissive or an obstructive gate that blocks legitimate code.
Flat config's array-of-objects structure makes configuration composable in a way the old nested `.eslintrc` format resisted—you can now merge, override, and share config slices as plain JavaScript values rather than wrestling with cascade semantics.
The AST-based rule model means ESLint's power is bounded by parser accuracy. Any syntax the parser cannot turn into correct AST nodes (like new TypeScript features before `typescript-eslint` updates) is invisible to all rules, creating a silent blind spot.