Skip to content

How to Upgrade Node.js 22 to 22.23.3 and Verify npm 10.9.9

This practical Node.js 22.23.3 upgrade tutorial shows how to update Node and npm, verify projects, test HTTPS, and keep Docker and CI environments consistent.

How to Upgrade Node.js 22 to 22.23.3 and Verify npm 10.9.9

On this page

Node.js 22.23.3 was released on September 23, 2026, and the update is more than a routine version bump. The maintenance release updates OpenSSL to 3.5.8, refreshes trusted root certificates, upgrades the bundled npm to 10.9.9, and updates several other runtime dependencies. If your web project still runs Node.js 22.23.2 or an earlier 22.x release, this tutorial walks through the upgrade without replacing your application or rebuilding its dependencies unnecessarily.

What Node.js 22.23.3 actually changes

Node.js 22.23.3 is an LTS maintenance release, so you should not approach it like a major framework migration. The release updates OpenSSL, the cryptographic library used by Node.js for secure connections, to 3.5.8 and updates the root certificate bundle to NSS 3.125. It also moves the bundled npm version to 10.9.9 and Corepack to 0.36.0. For developers running web servers, build tools, package managers, or development scripts on Node.js 22, these changes are useful because the runtime and its bundled tooling move together instead of leaving an older npm installation alongside the newer Node executable.

The release also updates ICU to 78.3 and Undici to 6.28.1. Undici is the HTTP client implementation used by Node's built-in networking APIs, while ICU provides internationalization functionality such as locale-sensitive formatting. Node-API also gains support for SharedArrayBuffer in typed-array creation APIs. Most application developers will not need to change code for these updates, which is one reason a maintenance release can usually be installed with much less risk than a major Node.js upgrade.

Check your current Node.js and npm versions first

Before changing anything, record what the project is actually using. Open a terminal in the environment where you run the application and execute the following commands. The first command reports the Node.js runtime, while the second checks the npm bundled with or selected by your installation.

node --version
npm --version

If you see v22.23.2 or an older 22.x release, you have a direct reason to update. If the terminal reports another major version, do not blindly install 22.23.3 just because this release exists. Projects can have explicit runtime requirements, and changing major versions can introduce compatibility work that a maintenance update does not require.

It is also worth checking the version from inside the project rather than assuming the system installation is the one being used. A version manager such as nvm can place several Node.js releases on the same machine, and your shell may select a different one from the version you expected.

Upgrade Node.js 22.23.3 with a version manager

If your project uses nvm, upgrading is straightforward because the existing Node.js installation does not have to be manually removed first. Install the exact maintenance release and then activate it for the current shell.

nvm install 22.23.3
nvm use 22.23.3

Now verify the runtime before touching your project dependencies.

node --version
npm --version

The expected Node.js version is v22.23.3, and the release bundles npm 10.9.9. If npm reports a different version, your shell may be resolving another npm executable, or you may have installed a separate npm version globally. That does not automatically mean the Node upgrade failed, but it is worth checking before you continue.

Upgrade without nvm on Windows, macOS, or Linux

If you installed Node.js directly rather than through a version manager, use the official Node.js installer for the 22.23.3 release and install it over the existing 22.x installation. Close terminals and development tools that may still have the old Node executable open, complete the installation, then start a new terminal. This matters because an already-open shell can retain an older executable path even after the installation has changed.

After reopening the terminal, run the same version checks again.

node --version
npm --version

Do not manually delete your project directory or its node_modules folder merely because Node.js was upgraded. A patch-level Node.js update does not by itself require every package to be reinstalled. Start by verifying the runtime, then test the existing project.

Check the project before reinstalling dependencies

Move into the application directory and inspect the project's package configuration. Look for an engines field in package.json, a version file such as .nvmrc, or another project-specific runtime declaration. If the project deliberately pins a different Node.js version, changing the machine-wide version may not be the correct solution.

Once the project is confirmed to support Node.js 22, install dependencies using the package manager and lockfile already used by the project. For an npm project with a lockfile, npm ci is useful for reproducing the dependency tree exactly from the lockfile, while npm install can update the lockfile when dependency resolution needs to change.

npm ci

Do not switch from npm ci to npm install simply because Node.js was upgraded. The purpose of this step is to determine whether the existing dependency set still installs cleanly under the new runtime. Keeping the dependency graph unchanged makes a failed test much easier to diagnose.

Run the web application's tests and build

With Node.js 22.23.3 active and dependencies installed, run the commands defined by the project's scripts. A typical frontend project may have a test and build script, but the exact names belong to your project rather than Node.js itself.

npm test
npm run build

If the application does not define one of these scripts, check the scripts section of package.json and use the project's actual commands. For a server application, start the application in its normal development or test mode and exercise the routes that use networking, file access, authentication, and database connections. The goal is not simply to prove that node --version changed; it is to prove that the application still behaves correctly on the updated runtime.

Pay particular attention to HTTPS and package installation

The OpenSSL and certificate updates are especially relevant to applications that make secure network connections. If your project communicates with an HTTPS API, database service, package registry, or another TLS-protected endpoint, test those connections after the upgrade. A certificate update can expose an environment that was already relying on an outdated or improperly configured trust chain, so an HTTPS error after the upgrade does not necessarily mean Node.js introduced a bug.

The bundled npm update also matters for development and deployment environments. Node.js 22.23.3 includes npm 10.9.9, replacing the earlier npm version bundled with the preceding Node.js 22 release. Check the actual version used by your build environment rather than assuming that updating the local machine automatically updates a CI runner, Docker image, or deployment server.

Do not update only your laptop. If production, continuous integration, or container builds still use an older Node.js image, you can end up testing with 22.23.3 locally while deploying with a different runtime and npm version.

Verify Docker and CI environments separately

Containerized applications have their own Node.js installation, so upgrading your host machine does not upgrade the runtime inside an existing container. Check the Node.js version from the same container image used for development or deployment. If your Dockerfile selects a Node 22 base image, update the image reference according to your project's versioning policy and rebuild the image before testing.

docker run --rm node:22 node --version

The same principle applies to continuous integration. A workflow can use a Node.js version selected by an action, a container, or a preconfigured runner. Your local node --version output tells you nothing about that separate environment. After changing the runtime configuration, run the complete CI test and build process so that dependency installation and application execution are both tested under the same Node.js version you intend to deploy.

Know when 22.23.3 is not the right target

Node.js 22.23.3 is useful when you need to remain on the Node.js 22 line, but it is not the newest Node.js release line. The Node.js project also lists newer 24.x LTS releases and the 26.x Current line. Moving from 22 to another major line is a separate migration decision because application compatibility, native modules, framework requirements, and deployment images can all be affected.

That distinction is important when maintaining an older web application. A maintenance upgrade from 22.23.2 to 22.23.3 keeps the same major and minor release line while incorporating updated runtime dependencies and bundled tooling. A move from Node.js 22 to Node.js 24 or 26 changes the runtime generation and deserves its own compatibility testing rather than being treated as the same operation.

Use this final check before committing the upgrade

Once the application passes its tests and production-style build, record the versions that were actually tested. This gives the rest of the team a reproducible baseline instead of a vague instruction to use "latest Node."

node --version
npm --version
npm test
npm run build

For Node.js 22 users, the meaningful checkpoint is v22.23.3 with npm 10.9.9. The release was published on September 23, 2026, so it is recent enough to warrant checking project and deployment environments rather than assuming every machine has already received it. If the upgrade works locally but fails in CI or production, compare those environments first: the Node version, npm version, lockfile handling, native dependencies, and TLS configuration are more useful clues than immediately changing application code.

Muhammad Saleem profile photo

Written by

Muhammad Saleem

I’m Muhammad Saleem, a web developer and the owner of TechWare House, a software house focused on practical web and software solutions. With over 14 years of experience, I’ve built and managed hundreds of websites and custom , PHP/MySQL, Python, Django applications. I share hands-on insights about web development, software, technology, and digital solutions on WizTechnoz.com

66 posts published

All posts by this author

0 Comments

No comments yet. Be the first to share your thoughts.

Join the conversation

Log in or create a free account to leave a comment. You can edit or delete your own comments any time.