ESLint review: what it is, pros, cons and setup

ESLint parses each file into an abstract syntax tree, using its own parser for JavaScript or a plugin parser such as typescript-eslint’s for TypeScript. It then walks the tree, and every enabled rule receives the node types it subscribed to, such as call expressions or functions, and reports problems with a location and, where it is safe, a fix or a suggestion. Rules work on one file at a time and know nothing about other files unless a parser supplies type information or a plugin resolves imports. That design is why plain ESLint is fast and predictable, and why the checks that need types, such as unawaited promises, require the slower typed setup.

Configuration lives in eslint.config.js, or .mjs, .cjs or TypeScript variants, which exports an array of configuration objects. Each object can name the files it applies to, files to ignore, language options such as globals and parser, plugins, and rules. Objects later in the array override earlier ones for the files they match, and defineConfig adds an extends key for building on shared configs. Nothing is linted until you enable rules or extend a shared config. In version 10, ESLint looks for the configuration file starting from the directory of each file being linted and searches upwards, so a monorepo package can carry its own config.

Some of the most valuable rules for test code need type information: no-floating-promises must know that a call returns a promise before it can complain that nothing awaits it. typescript-eslint provides these through its TypeChecked shared configs, with parserOptions.projectService set to true so the TypeScript language service supplies types for each file. The cost is speed, since the compiler now runs inside the linter, and a subtle interaction with caching: the ESLint documentation warns that cached results do not track dependencies between files, so type-aware rules can report stale results when another file changes.

Each rule is off, warn or error. Errors make ESLint exit with code 1; warnings do not affect the exit code unless --max-warnings sets a threshold, which is why warning counts tend to climb unnoticed. Inline comments can disable a rule for a line or file. For adopting a rule across an existing codebase, bulk suppressions record current violations of error-level rules in an eslint-suppressions.json file, so only new violations fail. When a suppressed violation is fixed, ESLint reports the unused suppression and exits non-zero until it is pruned, which keeps the list honest.

Keep one config file and scope each block with files globs: application rules for src, test-framework rules for the test folders, and a block for configuration files that run in Node. Test plugins should never apply to application code, where rules such as expect-expect make no sense. Give test files the globals their runner expects through languageOptions.globals or the plugin’s own config, rather than turning off no-undef. Put generated folders such as reports, coverage and build output in a global ignores block at the top. A useful habit is to promote the rules that indicate real defects to error, such as focused tests and fixed waits, and leave stylistic preferences at warn or off so the lint output stays meaningful.

The most expensive bug in async test code is an action that is not awaited: the test moves on, fails somewhere else, or passes when it should not. eslint-plugin-playwright’s missing-playwright-await covers Playwright’s own APIs, and typescript-eslint’s no-floating-promises covers every promise, including your page object methods. The latter needs type information, which recommendedTypeChecked and projectService provide. Apply typed rules to TypeScript files only, make sure every linted file is covered by a tsconfig, and expect lint time to rise noticeably on large suites.

Lint is the cheapest check in a pipeline, so run it first and fail fast. Pass --max-warnings 0 if warnings are meant to be acted on, otherwise they are just noise. --concurrency auto spreads files across threads on multi-core runners. Be careful with --cache in CI when type-aware rules are enabled, since cached results do not track cross-file changes; a full typed run on pull requests and a cached syntax-only run locally is a reasonable split. The built-in json formatter, selected with --format json, turns results into something other tools can read and annotate.

Turning a rule such as no-floating-promises on across a large existing test suite usually produces hundreds of findings, and the classic outcome is that the rule is switched back to warn and forgotten. Bulk suppressions avoid that. Enable the rule as an error, run eslint --fix --suppress-rule with the rule name so auto-fixable cases are fixed rather than suppressed, and commit eslint-suppressions.json. From then on, new code must comply, while the suppressions file is a visible backlog that shrinks with every fix. Run --prune-suppressions after cleanup sessions. Only error-level rules can be suppressed this way; warnings are not recorded.

Version 10.0.0 was released on 6 February 2026 and the 10.x line has continued with minor releases since. The upgrade is mostly configuration work. ESLint publishes codemods: npx codemod @eslint/v9-to-v10 removes legacy flags and environment variables and updates custom rules and API usage. Check Node.js first, including the version your editor’s ESLint extension uses. Move any remaining .eslintrc configuration to flat config, since the old format and the ESLINT_USE_FLAT_CONFIG switch are gone. Expect new findings: eslint:recommended now enables no-unassigned-vars, no-useless-assignment and preserve-caught-error, and JSX references are now tracked, which changes no-unused-vars results in component tests. Check each plugin’s supported ESLint range; eslint-plugin-cypress 7, for example, requires ESLint 10.