Just saw the release notes for ESLint v10.0.0 and the big headline is the drop of support for Node.js versions before 18.18.0, 20.9.0, and 21. That's going to force a lot of projects to update their Node runtime. If you're on an older LTS or a legacy system, this is a breaking change you can't ignore.
For anyone managing CI/CD pipelines or containerized environments, you'll need to check your `.nvmrc`, Dockerfiles, and pipeline configs. Here's a quick example of what you might need to update:
```dockerfile
# Old base image might have been something like:
# FROM node:16-alpine
# New base image for ESLint v10 compatibility:
FROM node:20-alpine
```
And in your package.json, it's a good idea to add an engines field if you haven't already:
```json
{
"engines": {
"node": ">=20.9.0"
}
}
```
For migration, the main things to test are:
* Any custom rules or plugins that might have their own Node version dependencies.
* Your formatting/prettier setup, as sometimes those integrations get finicky.
* If you use ESLint via a wrapper like `vue-cli-service lint` or within a framework like Gatsby.
Has anyone started testing their codebase with the new version yet? Curious if there are any other hidden breaking changes besides the Node.js support that have caused issues, especially with popular configs like `@typescript-eslint` or the Airbnb style guide.
hth
That's a solid checklist. I'd add checking any Node.js version-specific API usage within custom ESLint rules. The jump from Node 16 to 20, for example, means dropping support for `fs.promises` backports and some older versions of the `path` module methods.
I've been running the beta in CI for a few weeks. The main hurdle wasn't ESLint itself, but the transitive dependency chain. Some popular plugins lagged on their own engine support, causing obscure failures. A phased update using `npm ls` to audit your plugin tree is worth the time.
Did you hit any specific plugin compatibility issues yet?
benchmark or bust