Make @emdash-cms/cloudflare share the site's emdash instead of pinning its own copy

[swissky]

Problem

@emdash-cms/cloudflare lists emdash as a regular dependency with an exact version (workspace:*, published as e.g. "emdash": "1.0.1"). When a site upgrades emdash but not the adapter, or the other way round, the package manager installs a second copy of emdash just for the adapter. Nothing warns about it, and astro build succeeds.

I reproduced this in an empty project with emdash@1.1.0 and @emdash-cms/cloudflare@1.0.1: node_modules/.pnpm then contains both emdash@1.0.1 and emdash@1.1.0.

The adapter imports more than the public API. It uses emdash/migrations, the migration lock, the plugin host wire, emdash/request-context and the database instrumentation. With two copies, these come from the older version while the site runs the newer one. I haven't traced a concrete failure from this yet, but it is the kind of drift that only shows up as an odd production bug.

Use case

Any Cloudflare site that upgrades with pnpm update emdash or npm install emdash@latest without touching the adapter. The templates use caret ranges for both packages (^1.0.1), so it is easy to end up with mismatched versions. I ran into it while testing the 1.0.1 to 1.1.0 upgrade.

All core packages are released in a changesets fixed group, so the adapter and emdash always share a version number. The rule users need is simple: both must be the same version.

Current workarounds

Upgrade both packages together, for example pnpm add emdash@latest @emdash-cms/cloudflare@latest. A separate fix PR adds a build warning when the two versions differ, so the mismatch is at least visible. The warning does not remove the second copy.

Options for a structural fix:

1. Move emdash to peerDependencies with an exact version (workspace:*), keeping it as a dev dependency for local builds. The site then has a single emdash. pnpm and Yarn warn on a mismatch; npm 7+ stops the install with ERESOLVE unless --legacy-peer-deps is used. That stops the bad state where it happens, but projects that already have a mismatch would fail to install on npm, so this needs a clear changeset and probably a minor release.
2. A caret peer dependency (workspace:^). I would not choose this one: it only flags an adapter that is newer than emdash, while the reported case is emdash being newer.
3. Keep the regular dependency and rely on the build warning plus upgrade docs. This is the least disruptive, but two copies still get installed.

Does option 1 match how the project wants to treat the adapter, and should it wait for a minor release?

Drafted with help from Claude Opus 5.5; I reviewed and edited it.

Your involvement

• I am requesting this capability.
• I am offering to champion the design in a feature plan or RFC.
• I am offering to implement it after the design is accepted.

[ascorbic]

I'm not sure why we don't have it as a peer dependency actually!