ESLint 10 is breaking some of my older projects, especially where plugins and extensions have not been updated yet. So far, I've avoided the affected updates, but manually pinning versions feels awkward and hard to maintain. How are you handling backward-compatibility issues with ESLint 10? Are you migrating your configurations, staying on an older version, or switching to another tool?
4 Answers
I’ve mostly kept older projects on ESLint 9 for now. There’s no real benefit in forcing an upgrade before the configurations and plugins they depend on are ready. For new projects, I’m evaluating other linters instead.
For projects that need to stay on ESLint, I’d pin a known-good major or minor version and upgrade deliberately rather than chasing every release. The official migration codemod can help with the core changes, but it won’t fix extensions that haven’t been updated. In those cases, cleaning up the configuration or waiting for the dependency maintainers is usually more practical.
Oxlint has been a good replacement for me. It’s much faster, and its built-in rules cover a lot without needing a separate plugin for every use case. I’d still check compatibility with the specific rules your project relies on before migrating.
That was my experience too—the simpler configuration and lower dependency count made the switch worthwhile.
I switched several projects to Biome. It removed a lot of dependencies from the package files, simplified the setup, and made CI noticeably faster. The breaking changes and unsupported plugins were a big part of why I made the change.
The main issue I’m seeing is outdated extensions rather than ESLint itself. I tried the codemod, but it produced enough configuration noise that I’m using this as an opportunity to simplify the setup and investigate alternatives.