ESLint 10 is breaking some of my older projects. For now, I've avoided updates between 10.0.0 and 10.1.0, but manually pinning around specific releases feels awkward and hard to maintain. How are you handling backward-compatibility issues with ESLint? Are you using the migration tools, waiting for plugins to catch up, staying on an older version, or switching to another linter?
4 Answers
The official migration guide recommends running the v9-to-v10 codemod with `npx codemod @eslint/v9-to-v10`. It can help with the core migration, although projects with unusual setups or outdated extensions may still need manual cleanup. If the codemod creates a lot of noise, that may be a sign to wait before upgrading.
Projects managed through Nx may need to wait for its migration support instead of applying every change manually.
I’m keeping older projects on ESLint 9 for now. There’s no real benefit in forcing an upgrade before the configuration and plugin ecosystem is ready, and pinning a known-good version keeps builds consistent.
I switched to Oxlint for a few projects. It’s much faster and has a simpler out-of-the-box setup, so there’s less need to assemble a plugin for every use case. For stable production projects, though, I’d still avoid switching just to escape one breaking release unless the existing setup is already causing trouble.
I moved some projects to Biome. It removed several dependencies, made CI noticeably faster, and avoided a lot of plugin compatibility problems. It isn’t necessarily the right choice for every existing codebase, but it has been a good alternative for projects where the ESLint setup became too difficult to maintain.
In my case, the main issue was extensions that hadn’t been updated yet rather than ESLint itself. We used the migration as a chance to simplify the configuration and reduce our dependency on plugins.