Skip to content

v3: move @icp-sdk/core to 5.x, coupled to dropping the dfx replica #652

Description

@Kamirus

mops is on @icp-sdk/core 4.0.2. It cannot move to 5.x while the dfx replica is supported, and that constraint was only discovered by a CI failure on #642 — worth recording before someone bumps it again.

@icp-sdk/core 5.x drops the IC HTTP API v2 endpoints, and v2 is the only version the dfx and dfx-pocket-ic replicas serve. Probed against dfx 0.29.1:

  • /api/v2/{call,query,read_state} — served
  • /api/v4/canister/<id>/call — 400 plus an HTML "canister id not resolved" page
  • /api/v3/canister/<id>/{query,read_state} — 404

5.x uses the three unsupported ones. Its fallback keys on a 404 for v4 only, so dfx's 400-plus-HTML never triggers it, and query/read_state have no fallback at all — the gateway's error page ends up verbatim in test output. There is no client-side setting that avoids this.

Projects with no pocket-ic pin still use the dfx replica, so bumping mops to 5.x breaks every unpinned replica test and benchmark. #642 therefore keeps mops on 4.0.2 and bundles pic's own 5.x inside dist/vendor/pic.mjs.

Do this bump as part of removing the dfx replica in v3 (NEXT-MAJOR.md, "Drop dfx coupling"). It also collapses the two @icp-sdk/core copies back into one and saves ~500 KB in the vendored bundle.

Metadata

Metadata

Assignees

No one assigned

    Labels

    clidependenciesPull requests that update a dependency file

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions