Node.js 22

Node.js 22 moved the runtime to a newer V8 engine than Node.js 20 and added or matured several developer-facing capabilities. The line includes a built-in WebSocket client, a stable watch mode, the node --run command for running package scripts, and experimental support for loading eligible ECMAScript modules through require(). It also introduced the experimental node:sqlite module, module compile-cache controls, and native TypeScript type stripping for erasable TypeScript syntax. These additions reduce the need for some external tooling, but several of the newer module, SQLite, compile-cache, and TypeScript facilities require version-specific validation before they become production dependencies.

Node.js 22 remains within its active support window, so staying on the latest available 22 patch can still receive fixes supplied for that line. The practical cost is chiefly opportunity cost and deferred compatibility work: a team does not receive the newer runtime, platform APIs, and language-engine changes available in successor lines, and its eventual upgrade will span more changes at once. The main technical risks are applications or dependencies that rely on undocumented V8 behavior, native add-ons or prebuilt binaries that need a newer runtime build, and CommonJS/ESM edge cases exposed by newer module-loading behavior. Remaining on 22 is reasonable when it is the tested production baseline, but it should not substitute for continuous testing against the intended next major line.

Keep production on the latest Node.js 22 patch that your deployment platform supports, and run the full unit, integration, build, and startup test suite against both that patch and the next target major line in CI. Inventory dependencies with Node engine constraints, native add-ons, prebuilt binaries, custom loaders, test runners, and build tools; verify that each supports the target runtime and rebuild native artifacts where required. Add focused tests for CommonJS-to-ESM loading, top-level await in imported modules, WebSocket behavior, file watching, and any use of TypeScript stripping or node:sqlite. Treat experimental Node APIs as opt-in dependencies: pin the runtime range used to validate them, document their fallback or replacement path, and avoid making them a migration prerequisite unless their behavior has been verified in the exact deployed runtime.