Node 24 upgrade #16910
Description
With node base image running different versions for bedrock vs. springfield, and the upcoming Node 20 EOL in a few months, it's probably good to harmonize all the projects, images, CI, dependencies and developer environments to use the same stack — with Node 24 the newest LTS to stick around for a bit.
Luckily the past years have shown great compatibility, both backwards and forwards, with no issues running these projects using anything from Node 16 to Node 25 without noticing a glitch, so the actual bump should be uneventful.
The only question might be how to inform the ideal versions for both automation, and developers working locally.
(The motivation for this is Dependabot, newly defaulting to using npm@11 — which introduces bugs and dirty lockfiles, and may need a semver constraint, otherwise unnecessary, to stop fighting over diffs with developers.)
Normally the engines field in package is only informational, and to emit compatibility warnings for downstream consumers of such package when on an "incompatible" runtime, but in itself can't enforce a runtime version to be used. (Dependabot however takes that object as a requirement, and will resolve versions to be used for update PRs according to that.)
Other means as .npmrc or .nvmrc would need to be used for that, but generally speaking none of that really forces a developer's runtime to switch versions, there might be tools for that as "n" that can observe the dotfile versions defined and switch accordingly. Easiest is probably to just document the version used, and leave that to developers to adhere to the docs — and prefer methods that constrain the versions in CI the most reliable, for stable automation in the first place.
Currently a hard pin on a patch version docker image is used for reproducibility, as there were some build hangs on node base minor/patch updates in the past, so this was left to manual bumps after verifying the pinned version performs OK in both CI and docker use on Intel and ARM machines (or, was regularly being downpinned after experiencing issues post-update…)
Dependabot is set to keep proposing the docker node image version bumps once in a while, but it either got silenced, or there's an ancient PR with such updates buried in the history so no new versions are really surfaced. Referencing just the major version image has the upside of not having to care too much about updates, but means having not exactly reproducible CI, as things shift beneath it all the time.
Success Criteria
- WMO and FXC use the same builder images
- MZP build and deployment, and other MEAO packages are moved to Node 24 stack too