fix(sdk-coin-iota): constrain @iota/iota-sdk to node-20 range

[gianchandania]

Problem

@iota/iota-sdk raised engines.node from >=20 to >=24 in 1.11.0 — a minor release. Since this package declares "@iota/iota-sdk": "^1.6.0", any fresh resolve now picks 1.15.x and fails engine checks on Node 20:

npm error code EBADENGINE
npm error engine Not compatible with your version of node/npm: @iota/iota-sdk@1.15.0
npm error notsup Required: {"node":">=24"}
npm error notsup Actual:   {"npm":"10.8.2","node":"v20.20.2"}

The boundary is clean:

version	engines.node	published
1.10.0	>=20	2025-12-18
1.10.1	>=20	2026-01-08
1.11.0	>=24	2026-02-26
1.15.1	>=24	—

Why this matters for BitGoJS itself

modules/sdk-coin-iota/package.json declares "engines": { "node": ">=20" }, and .github/workflows/ci.yml runs node-version: [20.x, 22.x, 24.x]. So this package claims Node 20 support that its own dependency range can silently forbid.

The Node 20 CI leg passes today only because yarn.lock happens to pin @iota/iota-sdk at 1.6.1. Any lockfile refresh that re-resolves ^1.6.0 breaks it. This is latent, not hypothetical.

Why downstream consumers can't work around it

sdk-coin-iota is a hard dependency of the @bitgo/bitgo aggregate — not optional, not peer — so every consumer inherits the constraint, including repos that never touch IOTA.

They also cannot pin it themselves. Once @bitgo/bitgo is bumped, npm stops hoisting sdk-coin-iota and vendors it under node_modules/@bitgo/bitgo/node_modules/, and npm overrides do not bind to that nested edge. Verified across npm 10.8.2 / 10.9.4 / 11.6.4 with flat, nested, deep-path and range override forms, plus a root-level hoisting pin — all still resolved 1.15.0. A control override of an ordinary transitive dependency in the same tree worked, so this is not a syntax or npm-version issue.

The change

Cap the range below the Node-24 break. 1.10.1 is the newest release that still supports Node 20:

-  "@iota/iota-sdk": "^1.6.0",
+  "@iota/iota-sdk": ">=1.6.0 <1.11.0",

What moves in the lockfile

Regenerated with yarn install (yarn 1.22.22). The resolved version goes to the new ceiling, and two transitive deps move inside iota-sdk's own subtree:

package	before	after
@iota/iota-sdk	1.6.1	1.10.1
@iota/bcs (under iota-sdk)	1.2.0	1.4.0
valibot (under iota-sdk)	^0.36.0	^1.2.0 → 1.2.0

valibot@1.2.0 was already present in the tree, so that entry dedupes rather than adding a new version.

Risk

All @iota/iota-sdk imports in this module are stable subpaths:

@iota/iota-sdk/transactions      @iota/iota-sdk/utils
@iota/iota-sdk/cryptography      @iota/iota-sdk/keypairs/ed25519

Reviewer note — please confirm via CI: I was not able to get a clean local build of this module to run its unit tests. The build fails on my checkout inside sdk-core (@bitgo/secp256k1 missing bip32utils, @bitgo/sdk-lib-mpc missing MPSComms), and I confirmed it fails identically on pristine master with this change stashed — a stale-dist artifact of my local clone, unrelated to this diff. So the 1.6.1 → 1.10.1 move is not locally test-verified and should be validated by CI's Node 20/22/24 matrix.

If the four-minor jump is not wanted right now, the alternative is to keep the range fix and pin the resolution at 1.6.1, which constrains downstream consumers with zero dependency movement here. Happy to switch to that if preferred.

Context

Blocks @bitgo-beta SDK bumps in prime-microservices (#7596 has the background). Note that prime-microservices #7546 currently has @iota/iota-sdk@1.15.0 baked into its lockfile as a nested copy; it will break npm ci for Node 20 developers if it lands before this is fixed.

TICKET: GOA-1525

🤖 Generated with Claude Code

[linear-code]

GOA-1525