No. Unless engine-strict is enabled, the engines field is advisory and only produces warnings when your package is installed as a dependency. To keep a client build on the right Node version, pin it in several places: a version file, CI, the container image and the hosting setting, and make them agree.
What the documentation says
The npm package.json documentation describes engines as specifying which Node.js and npm versions your package works with. It states that, unless the user enables the engine-strict setting, the field is advisory only and will only produce warnings when installed as a dependency.
Two things follow. A mismatch will not fail your build by default. And the field is about compatibility, not about support status. It does not tell you whether a version still receives security fixes.
Why agencies get bitten
A project is built on one agency laptop with one version, tested in CI with a second, and deployed to hosting with a third. Everything seems fine until a dependency behaves differently, or an old runtime that no longer receives fixes sits under the client's site for years.
Runtime versions are part of the supply chain. The language runtime, the package manager and the base image are all code you ship.
Where to pin
| Place | What to set | Why |
|---|---|---|
| package.json | engines with a version range | Documents intent; warns on mismatch |
| Version file | A file such as .nvmrc or .node-version | Lets tools and developers switch automatically |
| CI | The same version number | Builds match local |
| Container image | A specific tag, ideally a digest | Same runtime in every environment |
| Hosting | The platform's Node version setting | Production matches CI |
| README | One line stating the version and where it is set | Next team can find it |
Keep one source of truth where possible, such as the version file, and have CI read it.
Make it strict
Set engine-strict in the project's npm configuration file so installs fail on mismatch. The failure is annoying for a day and then saves hours. Use npm ci in CI so lockfile problems fail too, as covered in why agencies should commit lockfiles.
Check support status
Each runtime publishes a release schedule showing which versions get security fixes and until when. Look up the current schedule on the project's own site rather than relying on a blog post from last year, and put the end of support date for the pinned version in the handover pack. Add a calendar item for that date.
Plan upgrades
When a runtime nears the end of support, upgrade in a small, separate change: bump the version file, update CI, run tests, check dependency compatibility, and deploy. Do not combine it with feature work.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and see which packages sit in the tree. Each of them has its own runtime expectations, which is why one pinned version across environments matters.
Quick check
Is an old Node version a vulnerability?
An unsupported runtime stops receiving security fixes, so new flaws stay unpatched. That is a risk even if no specific advisory has been raised for your app.
Should we pin the exact patch version?
Pin the major version in the version file at minimum, and use an exact image tag or digest for production builds if you want identical runtimes.
Sources
Last reviewed: 19 October 2026.
