ESLint v10 Finalizes Flat Config, Drops Legacy Support

ESLint v10 marks the culmination of a multi-year architectural shift, removing the legacy eslintrc configuration system entirely and shipping developer experience improvements that signal the tool's evolution in a competitive linting landscape.

The End of an Era: Legacy Config Removed

The most significant breaking change in ESLint 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.

Configuration File Location Changes

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: No More False Positives

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. This change alone will eliminate a common source of confusion for React developers who have wrestled with ESLint incorrectly flagging JSX components as unused imports.

Enhanced RuleTester API

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 and Configuration Updates

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.

Plugin Compatibility Issues

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.

Community Migration Pains

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 Rust Alternative Threat

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 announcement 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.

About ESLint

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.

Looking Forward

The flat config migration represents ESLint's most significant architectural change since its inception. While the transition has been challenging for some teams, the removal of legacy support and the addition of features like JSX reference tracking position ESLint for the next decade of JavaScript development.

The emergence of Rust-based alternatives adds pressure on the ESLint team to maintain performance while preserving the extensive plugin ecosystem that has made ESLint the de facto standard for JavaScript linting. Whether ESLint can continue to evolve while keeping pace with performance-focused alternatives remains an open question as the JavaScript tooling landscape continues to fragment and specialize.