Node.js 26

Apply the JavaScript ES2026 baseline first. These rules target the Node.js 26 runtime, which is the Current release until it enters long-term support in October 2026 and which ships a broader permission model, a deprecated asynchronous loader API, and several runtime-deprecated crypto paths.

Release line and upgrade posture

• Run the newest Node.js 26 release, including new minors, and redeploy when the Node.js project ships a 26.x security release; this Current line moves faster than an LTS line. Prefer a base image tag that follows the line, such as node:26-slim rebuilt with docker build --pull, or a digest an update bot keeps current, and when a Dockerfile or CI matrix needs an exact version you can't check on nodejs.org, leave a placeholder that fails the build rather than a version you remember.
• Check the runtime against Node.js security releases with is-my-node-vulnerable, installed as a locked dev dependency rather than fetched by a bare npx call, because npm audit covers packages, not Node.js itself.
• Treat Node.js 26 as Current until it becomes LTS in October 2026, and keep an LTS line available as a fallback for workloads that cannot absorb a semver-major change.
• Re-test on each 26.x minor before rollout, since a Current line still lands semver-minor runtime behavior that can change parsing, TLS, or module resolution.
• Test and ship the same image, or point every image and CI runner at one digest an update bot keeps current, so build and production run the same 26.x release; a line-following tag resolves to whatever is newest when each build