Follow-up: move skills to @icp-sdk/core v6 once the dependency chain supports it

[marc0olo]

Follow-up to #364, which pins every skill to @icp-sdk/core@^5. This issue tracks flipping them to ^6 — do not action until the chain below is green.

Why we are on ^5

@icp-sdk/core 6.1.0 is published (6.0.0 on 2026-07-06, 6.1.0 on 2026-08-03), but nothing downstream accepts it:

Package	Latest	Requires core
@icp-sdk/signer	5.6.3	^5 (peer)
@icp-sdk/auth	8.0.3	^5 (peer)
@icp-sdk/vetkeys	0.5.0	^5.4.0 (dep)
@dfinity/oisy-wallet-signer	6.0.0	^4 (peer — see #364)
@icp-sdk/bindgen	0.4.0	no core dependency

Installing core 6 alongside @icp-sdk/auth is a hard failure:

npm error code ERESOLVE
npm error Found: @icp-sdk/core@6.1.0
npm error Could not resolve dependency:
npm error peer @icp-sdk/core@"^5" from @icp-sdk/auth@8.0.3

Forcing it with --legacy-peer-deps is worse — it installs two copies of core (5.4.0 nested for vetKeys, 6.1.0 at root), so Principal/HttpAgent class identities no longer match across the boundary vetKeys passes them over.

What core 6 actually broke

Not documented in the changelog (it lists only feats). From icp-js-signer#39, which fixed them:

• Agent.readState — first parameter is now InputTargetPrincipal ({ canisterId } | { subnetId }), was Principal | string
• DerEncodedPublicKey narrowed to Uint8Array<ArrayBuffer>
• Delegation gains an optional 4th constructor arg (permissions) — additive, not breaking

The documented API surface our skills use is unaffected: core 6.1.0 still exports ./agent/canister-env, ./principal, safeGetCanisterEnv, HttpAgent.create/createSync. This is purely a dependency-resolution blocker.

Upstream chain (in order)

1. dfinity/icp-js-signer#39 — "feat!: require @icp-sdk/core v6". APPROVED by a member on 2026-07-30, currently CONFLICTING on package-lock.json only, untouched since. Two signer releases have shipped past it (5.6.2 on 2026-08-03, 5.6.3 later) without including it. This is the blocker.
2. @icp-sdk/auth — bump signer to ^6, peer core to ^6. Code search finds 0 uses of readState and 0 of DerEncodedPublicKey; the 6 new Delegation sites are unaffected (4th arg optional). Likely a version bump plus CI.
3. @icp-sdk/vetkeys — bump dep core ^5.4.0 → ^6. No open PR; nobody has started. Same 0/0 result on the breaking symbols.
4. @dfinity/oisy-wallet-signer — currently on ^4, so it needs ^5 first (see Cross-skill version coherence: unpinned @icp-sdk/core installs resolve to incompatible majors #364) and then ^6. Furthest behind.
5. @icp-sdk/bindgen — nothing to do. No core dependency, and its generated output type-checks clean under strict against both 5.4.0 and 6.1.0.

What changes here when it is green

Three files, version strings only:

• skills/icp-cli/references/binding-generation.md — install line + the version note
• skills/icp-cli/references/dfx-migration.md — install line
• skills/icp-cli/SKILL.md:115 — the core wording
• skills/vetkeys/SKILL.md:25 — core ^5.4 → ^6, and @icp-sdk/vetkeys >=0.5 → >=0.6
• skills/wallet-integration/SKILL.md — unpin oisy once it supports the target major

Definition of done

npm i '@icp-sdk/core@^6' @icp-sdk/auth @icp-sdk/vetkeys @icp-sdk/canisters \
      @dfinity/oisy-wallet-signer @dfinity/utils zod

resolves with one copy of @icp-sdk/core at 6.x and no ERESOLVE. Until that command is clean, ^5 stays.

[marc0olo]

Update — the situation changed from "lagging" to "split", which raises the urgency here.

@icp-sdk/vetkeys 0.6.0 shipped, depending on @icp-sdk/core@^6.1.0. Current state:

Package	Latest	Requires core
@icp-sdk/core	6.1.0	—
@icp-sdk/vetkeys	0.6.0	^6.1.0 (dep)
@icp-sdk/auth	8.0.3	^5 (peer)
@icp-sdk/signer	5.6.3	^5 (peer)
@icp-sdk/canisters	3.6.0	^5 (peer)
@dfinity/oisy-wallet-signer	6.0.0	^4 (peer)

So the ecosystem now spans three core majors at once, and the two ends cannot be combined: a dapp using vetKeys and Internet Identity login has no valid single-core install.

Worse, it does not fail loudly. vetKeys declares core as a dependency rather than a peer, so npm i @icp-sdk/vetkeys @icp-sdk/auth succeeds while silently installing two copies of @icp-sdk/core (6.1.0 nested, 5.4.0 at root). The vetKeys clients take a caller-supplied HttpAgent, so an agent built from core 5 gets passed into code typed against core 6 — Principal/HttpAgent class identity stops matching across the boundary.

#368 pins @icp-sdk/vetkeys@^0.5 as the interim fix, keeping every skill on the 5.x line. That is a holding action: it pins users to a vetKeys release that will fall further behind.

The chain in this issue is unchanged and icp-js-signer#39 is still the blocker — approved since 2026-07-30, conflicting only on package-lock.json, and skipped by two signer releases since. What has changed is the cost of leaving it: it is no longer just "we cannot adopt core 6", it is "vetKeys and auth cannot be used together on any core version".

Suggested order once signer#39 lands: signer 6 → auth 9 → then flip the skills to @icp-sdk/vetkeys@^0.6 + @icp-sdk/core@^6 in one change. @dfinity/oisy-wallet-signer still needs ^5 before it can reach ^6, so wallet-integration may have to stay pinned longer than the rest.

[marc0olo]

Correction to my previous comment: calling icp-js-signer#39 "the blocker" was imprecise. It is the head of the chain, not the whole of it.

@icp-sdk/auth depends on @icp-sdk/signer@^5.6.2, so auth cannot move to core 6 until signer does — but signer landing does not by itself unblock anything downstream. auth still needs its own bump (signer ^6, peer core ^6) and its own release. The ordered list in the issue body remains the accurate version:

1. signer#39 merged + @icp-sdk/signer 6.x released
2. @icp-sdk/auth bumped to signer ^6 / peer core ^6, released
3. @icp-sdk/vetkeys — already done, 0.6.0 is on core ^6.1.0
4. @dfinity/oisy-wallet-signer — still on core ^4, needs ^5 before it can reach ^6
5. skills flipped to core ^6 + vetkeys ^0.6

Steps 1 and 2 are both required before anything here changes.

[marc0olo]

Filed dfinity/vetkeys#433 — @icp-sdk/vetkeys declares @icp-sdk/core as a plain dependency (its peerDependencies is literally {}), while auth, signer and canisters all use a peer.

That is the reason this failure is silent rather than an ERESOLVE, and it is worth tracking alongside this issue for one specific reason: realigning versions alone does not fix it. As long as core is a plain dependency, the next divergence between vetKeys and the rest of the SDK will silently duplicate core again instead of failing the install.

So the definition of done for this issue arguably includes upstream#433 landing — otherwise we flip the skills to core ^6 and simply wait for the same class of bug to recur in the other direction.

[marc0olo]

Update — @icp-sdk/vetkeys is no longer part of this chain.

0.7.0 shipped with core moved from a dependency to a peer spanning both majors:

"peerDependencies": { "@icp-sdk/core": "^5.0.0 || ^6.0.0" }

That resolves dfinity/vetkeys#433 and removes step 3 from the list below — vetKeys now works on core 5 and core 6, so it neither blocks the migration nor has to be migrated. It also means the silent duplicate-core failure this issue described is gone: vetkeys 0.7 + auth resolves to a single @icp-sdk/core@5.4.0, fully deduped.

Revised remaining chain:

1. icp-js-signer#39 merged + @icp-sdk/signer 6.x released — approved 2026-07-30, still CONFLICTING on package-lock.json, skipped by two releases since
2. @icp-sdk/auth bumped to signer ^6 / peer core ^6, released
3. @icp-sdk/vetkeys — done, accepts both majors
4. @dfinity/oisy-wallet-signer — still peers core ^4; needs ^5 before it can reach ^6
5. skills flipped to @icp-sdk/core@^6

Steps 1 and 2 remain jointly required. Step 4 is the long pole and may keep wallet-integration pinned after the others move.

Note that #368 does not become unnecessary. With core as a peer spanning two majors, npm i @icp-sdk/vetkeys alone now resolves core to 6.1.0 — so naming @icp-sdk/core@^5 explicitly matters more than it did when vetKeys forced the version. The skills document that.