Update consumers for the breaking release

[field123]

Parent

#553 — Spec: one session for Elastic Path identity

What to build

The applications and build environments inside this repository keep working across the breaking
release — the example storefront, the two bundle environments, and the internal development host,
which today renders Elastic Path components only because the browser client works standalone and
would otherwise break entirely.

Ships with the breaking release.

Spec story 35.

Acceptance criteria

• The example storefront builds and runs against the breaking release, with the cart route that no longer exists removed.
• The three consumers that install the package resolve the new version, with their lockfiles updated — the manifests alone move nothing, because the publishing pipeline installs frozen.
• A hostless publish succeeds against those updated lockfiles.
• The internal development host still renders Elastic Path components, by gaining the session-free design route and nothing else — no new secret, no new environment variable, no middleware.
• The example storefront's committed dependency still points at a published version, so it reflects what a customer installs.
• Local verification of unreleased changes still works through the documented tarball workflow.

Blocked by

• Delete the browser token surface and mark the unremovable registrations inert #544 — Delete the browser token surface and mark the unremovable registrations inert

The tracker's dependency graph on this issue is authoritative; this list mirrors it.

---

Below is the original ticket, kept intact — it carries the research and decisions from #486, #495, #523 and #524.

In brief

The apps and build environments inside this repository that use the package, updated for the breaking release.

Three kinds of change: delete an API route in the example storefront that no longer exists in the package; bump the version and the lockfiles in the three places that install it; and add one file to the internal development host, which today renders Elastic Path components only because the browser client works standalone and would otherwise break entirely.

The lockfiles are the part that actually matters — the publishing pipeline installs with --frozen-lockfile, so bumping a version number alone changes nothing.

Part of the ADR-0003 token architecture. Ships with the breaking release. Scope from #495.

Work

examples/ep-commerce-app-router — delete app/api/ep/cart/[[...path]]/route.ts, the only createCartRoutes caller in the repo. app/api/ep/proxy/[fn]/route.ts already exists and is the survivor.

Version and lockfile bumps in the example app, platform/canvas-packages and platform/loader-bundle-env. The lockfiles are the load-bearing change — publish-hostless installs with --frozen-lockfile, so bumping manifests alone moves nothing.

plasmicpkgs-dev gains app/api/ep/design/[fn] and nothing else. It has no lib/ep-auth.ts, no middleware.ts and no /api/ep/* routes today; it renders Elastic Path components purely because the browser SDK client works standalone, so once client.ts goes every hook there 404s. The design route is session-free — no auth, no middleware, no new secret — and needs no new env var, since the dev host loads a Plasmic project and extractEpProviderConfig can read clientId/host off the bundle. One additive file touching no upstream code.

The example app's committed dependency stays on the published version. Local verification uses the npm pack tarball workflow already documented at its README.md:42-73, which also records why file: on the directory is wrong — it drags the package's node_modules in, landing a second @plasmicapp/host and a second React, so DataProvider publishes into one React context while the loader reads $ctx from the other and data vanishes silently. Session-bearing verification happens there.

Blocked by: the deletion issue.

---

ADR-0003: plasmicpkgs/commerce-providers/elastic-path/docs/adr/0003-one-session-for-elastic-path-identity.md. Map: #486. Issue set: #496.