| Release | Initial Release | Active LTS Start | Maintenance Start | End-of-life
|--|--|--|--|--
| Node.js 10 | 2018-04-24 | 2018-10-30 | 2020-05-19 | 2021-04-30
| Node.js 12 | 2019-04-23 | 2019-10-21 | 2020-11-30 | 2022-04-30
| Node.js 14 | 2020-04-21 | 2020-10-27 | 2021-10-19 | April 2023
As the EOL date for Node.js 10 is nearing, support from the ecosystem is starting to decline. This is primarly due to the ES2019 and ES2020 specifications for JavaScript (adopted in Node.js 12) being relatively big in terms of added capabilities.
Specifically, capabilities that can't easily run-time polyfilled, such as Node.js natively supporting the dynamic `import()` keyword for reading the `.mjs` file format, which older Node.js versions can't read (by default).
Use of native ESM is pretty much an all-or-nothing deal when packages are choosing to use it, they are forced to drop Node 10 at the same time. This won't immediately break anything since that will (hopefully) be a SemVer-Major change. But it does mean we might start to have some challenges updating packages, especially if there is an indirect dependency somewhere deep in the tree that didn't follow SemVer. At that point it would take a long time to chase down the whole chain and encourage each one to pin the version of the previous one. (Yay for npm not supporting shrinkwrap/lockfile for libraries.)
This means when developers update package.json locally and check-in package-lock.json, it will pass locally but fail in CI. Or if they use Node 10 locally as well, it'll fail both ways. I'm not actually sure there's even a clear way to fix that apart from manual package-lock.json patching for each update.
Anyway, //this// task is for creating a Node 14 base image for WMF CI. To be closed once:
* [ ] The images `node14`, `node14-test`, `node14-test-browser` exist in integration-config.
* [ ] The `node14-test-browser` image is used by the JJB job of at least one Gerrit repository and passing.
For further adoption, separate small or big parent tasks should be filed.