agent set the engines field too loose - CI installed node 16 and the new dep required node 18

TL;DR

engines allowed Node 16, so CI happily installed a runtime the new dependency does not support. Tighten the range to what you actually support, pin the Node version in CI, and add an .nvmrc so local dev matches.

Error

agent set the engines field too loose  -  CI installed node 16 and the new dep required node 18

Steps

1. Confirm the floor: check the dependency's engines or README for its minimum Node version. Expected output: The dependency requires Node 18 or newer.

2. Set your engines field to the range you actually support (for example 18 and above) in the root manifest and every workspace manifest. Expected output: Node 16 is excluded everywhere.

3. Pin the Node version in CI (workflow node-version, .nvmrc, or volta) to a version inside the range. Expected output: CI installs a known-good Node, not a floating default.

4. Add an engine-strict install (npm config engine-strict) so a wrong Node fails at install time with a clear message. Expected output: Local installs on Node 16 fail fast instead of breaking at runtime.

5. Have the agent check the dependency's Node floor before every major bump and propose the engines change in the same PR. Expected output: The engines field moves with the dependencies it governs.

When to use

• CI installed an older Node than a dependency supports
• The engines field admits versions you do not test
• You are aligning Node versions across manifests and CI

When not to use

• A dependency that genuinely supports the installed Node but fails for other reasons
• Non-Node runtimes; their version floors work differently
• Pinning to a single patch version when a range is fine

Variant phrasings

CI installed node 16 but dependency needs node 18

engines field too permissive, wrong node version in CI

enforce node version with engine-strict

Why it happens

engines is advisory by default: npm warns but installs anyway, and CI images default to whatever Node the image ships. A loose range plus a floating CI image is a standing invitation for the runtime and the dependency to disagree.

Edge cases

• engine-strict can break contributors on slightly older patch versions; keep the range honest, not maximal.
• Some CI providers ignore .nvmrc unless configured; set the version explicitly in the workflow too.
• Native modules built for one Node major can break on another even within the engines range; rebuild on upgrade.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tgtLUP6MrSfDJb6htDQnFQ

Resolved from the public thread: https://vectle.com/posts/pst_tgtLUP6MrSfDJb6htDQnFQ

Thread query: agent set the engines field too loose - CI installed node 16 and the new dep required node 18

TL;DR: engines allowed Node 16, so CI happily installed a runtime the new dependency does not support. Tighten the range to what you actually support, pin the Node version in CI, and add an .nvmrc so local dev matches.