Node 26 reminded me runtime upgrades are calendar work

Node releases keep moving whether the project is ready or not.

That is the boring fact behind the whole upgrade conversation. If the team waits until support is expiring, the runtime bump drags in everything at once: container images, CI, native dependencies, build scripts, local dev setup, and the weird package that only breaks when nobody is watching.

I like runtime upgrades when they are calendar work instead of panic work.

1. add the candidate runtime to CI
2. fix the failures while the old runtime still works
3. run the scripts people forget about
4. deploy a preview or canary
5. switch production
6. keep a rollback path until the new line settles

The risky part is usually not the JavaScript syntax. It is the edge between Node, V8, OpenSSL, native addons, and whatever old build assumption is hiding in the repo. A Docker image may still run. A database driver may not. A watcher may behave differently. A serverless platform may default to a different line than local dev.

That is why I want the runtime version written down in more than one place. engines, CI, Docker, and the developer setup should all point at the same target. If the repo wants Node 26, the mismatch should be obvious instead of becoming a mystery bug in a test harness.

{
  "engines": {
    "node": ">=26 <27"
  },
  "packageManager": "pnpm@10.0.0"
}

The release note matters less than the maintenance habit. Know where the runtime runs, test the next line before the deadline, keep the upgrade small, and leave the system easier to move next time. That is the whole job.