Filing here since forcedotcom/sfdx-core has issues disabled.
Summary
@salesforce/core declares engines.node: ">=18.0.0" but its dependency range on @jsforce/jsforce-node now resolves to versions that require Node >=22, crashing at load time on Node 18/20.
@jsforce/jsforce-node@3.10.17 (published 2026-06-25) bumped engines.node from >=18 to >=22 and moved to undici@^8.5.0 (engines.node: ">=22.19.0") — in a patch release. Because @salesforce/core depends on it with a caret range (^3.10.17 since core 8.31.4, and older versions' ^3.10.13 also resolves to 3.10.18), every fresh install of any @salesforce/core version now pulls the Node-22-only tree.
npm only warns on the engines mismatch (EBADENGINE), so installs succeed and the failure surfaces at runtime:
TypeError: webidl.util.markAsUncloneable is not a function
at Object.<anonymous> (.../node_modules/undici/lib/web/cache/cachestorage.js:20)
Steps to reproduce
On Node 20.x (or 18.x):
npm install @salesforce/core
node -e "require('@jsforce/jsforce-node')"
Observed in CI here: sf CLI plugin installs on Node 20 crash at CLI load (sfdx-git-delta e2e matrix — Node 20 legs fail on all OSes since jsforce-node 3.10.17 was published, Node 22/24 pass).
Expected
Either @salesforce/core bumps its own engines.node to >=22 (semver-major), or the jsforce-node engines/undici bump is reverted out of the 3.10.x patch range so the declared Node 18 support holds. Note that consumers cannot work around this themselves: caret resolution happens at install time in downstream trees (e.g. sf plugins install), where lockfiles and overrides of the intermediate package don't apply.
Versions
@salesforce/core 8.31.5 (latest): engines.node >=18.0.0, depends @jsforce/jsforce-node@^3.10.17@jsforce/jsforce-node 3.10.16: engines >=18 / 3.10.17+: engines >=22, undici@^8.5.0 (>=22.19.0)
Filing here since forcedotcom/sfdx-core has issues disabled.
Summary
@salesforce/coredeclaresengines.node: ">=18.0.0"but its dependency range on@jsforce/jsforce-nodenow resolves to versions that require Node >=22, crashing at load time on Node 18/20.@jsforce/jsforce-node@3.10.17(published 2026-06-25) bumpedengines.nodefrom>=18to>=22and moved toundici@^8.5.0(engines.node: ">=22.19.0") — in a patch release. Because@salesforce/coredepends on it with a caret range (^3.10.17since core 8.31.4, and older versions'^3.10.13also resolves to 3.10.18), every fresh install of any@salesforce/coreversion now pulls the Node-22-only tree.npm only warns on the engines mismatch (
EBADENGINE), so installs succeed and the failure surfaces at runtime:Steps to reproduce
On Node 20.x (or 18.x):
Observed in CI here: sf CLI plugin installs on Node 20 crash at CLI load (sfdx-git-delta e2e matrix — Node 20 legs fail on all OSes since jsforce-node 3.10.17 was published, Node 22/24 pass).
Expected
Either
@salesforce/corebumps its ownengines.nodeto>=22(semver-major), or the jsforce-node engines/undici bump is reverted out of the 3.10.x patch range so the declared Node 18 support holds. Note that consumers cannot work around this themselves: caret resolution happens at install time in downstream trees (e.g.sf plugins install), where lockfiles and overrides of the intermediate package don't apply.Versions
@salesforce/core8.31.5 (latest):engines.node >=18.0.0, depends@jsforce/jsforce-node@^3.10.17@jsforce/jsforce-node3.10.16:engines >=18/ 3.10.17+:engines >=22,undici@^8.5.0(>=22.19.0)