BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News ESLint v10: Flat Config Completion and JSX Tracking

ESLint v10: Flat Config Completion and JSX Tracking

Listen to this article -  0:00

ESLint, the widely adopted JavaScript and TypeScript linter, released version 10, marking its most significant breaking-change milestone since the flat config system was introduced. The release finalises years of incremental architectural work, removes long-deprecated APIs, and ships a set of developer experience improvements aimed squarely at plugin authors and monorepo teams.

The most consequential change in v10 is the complete removal of the legacy eslintrc configuration system. Since v9, flat config (eslint.config.js) has been the default, but the old format was still accessible via LegacyESLint. That compatibility layer is now gone entirely. The defineParser(), defineRule(), defineRules(), and getRules() methods on Linter have been removed, and shouldUseFlatConfig() now unconditionally returns true. Teams still on .eslintrc files will need to migrate before upgrading.

The official migration tool makes the transition straightforward:

npx @eslint/migrate-config .eslintrc.json

This generates an eslint.config.mjs file that can be reviewed and adjusted from there. A full breakdown of every breaking change is available in the official migration guide, and a third-party walkthrough on DEV Community covers the practical upgrade steps in more detail.

Alongside the config cleanup, v10 changes how ESLint locates its configuration file. Rather than searching from the current working directory, it now starts from the directory of each linted file. This is a meaningful improvement for monorepo setups, where different packages may need different rules, and brings the lookup behaviour in line with what many developers already expected.

JSX reference tracking is another headline addition. Previously, ESLint did not recognise JSX identifiers as variable references, producing false positives with rules like no-unused-vars. A component imported and used only in JSX would be incorrectly flagged as unused. Plugin workarounds like @eslint-react/jsx-uses-vars, previously used to fix this, are no longer needed.

The RuleTester API has been strengthened with new assertion options: requireMessage, requireLocation, and requireData. These let plugin authors enforce stricter test definitions and ensure tests stay consistent with rule messages. Stack traces for failing tests now include the index and file location of the offending test case, cutting down the time spent hunting failures in large rule suites.

Node.js support has been tightened to ^20.19.0 || ^22.13.0 || >=24. All of v21.x and v23.x are dropped. The eslint:recommended configuration has also been updated to include additional rules, which may introduce new lint reports in existing codebases after upgrading.

A GitHub issue on eslint-plugin-react flagged that the plugin does not yet declare ESLint 10 support in its peer dependencies, causing install conflicts for many React developers. A similar issue was raised against eslint-config-next, the default ESLint config shipped with Next.js, opened as recently as March 2026 and still unresolved at time of writing.

Commentary on r/javascript highlighted some migration pains:

honestly the flat config idea is good in theory but the migration path was terrible. felt like every plugin had slightly different flat config support and you were just guessing and checking until it worked.

The release continues the competitive conversation around JavaScript tooling. Rust-based alternatives such as Biome and Oxlint have been gaining ground on the promise of significantly faster linting.

On the reddit annoucement post, there are a number of comments suggesting switching from ESLint to alternatives such as Biome or Oxlint:

I’ve already moved on to biome. It doesn’t have 100% but the rules but probably around 95%, which is enough to outweigh the performance hog eslint is.

Oxc's own benchmarks claim Oxlint is 50 to 100 times faster than ESLint depending on CPU core count, while Biome combines linting and formatting in a single tool. The trade-off is rule coverage: Oxlint does not yet match ESLint's full catalogue.

ESLint is an open-source, pluggable linting tool for JavaScript and TypeScript, originally created by Nicholas C. Zakas in 2013 and now maintained by the ESLint team under the OpenJS Foundation. It is published under the MIT license and accumulates over 120 million weekly npm downloads.

ESLint v10.0.1 and v10.0.3 have already followed with bug fixes, and v10.1.0 shipped on March 20, 2026.

About the Author

Rate this Article

Adoption
Style

BT