Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 25 additions & 9 deletions pnpm-lock.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

4 changes: 2 additions & 2 deletions pnpm-workspace.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -37,12 +37,12 @@
eventsource-parser: ^3.0.0
jose: ^6.1.3
runtimeServerOnly:
'@hono/node-server': ^1.19.9
'@hono/node-server': ^1.19.13
content-type: ^1.0.5
cors: ^2.8.5
express: ^5.2.1
fastify: ^5.2.0
hono: ^4.11.4
hono: ^4.12.12

Check warning on line 45 in pnpm-workspace.yaml

View check run for this annotation

Claude / Claude Code Review

Catalog bump narrows published hono peerDependency range (^4.11.4 → ^4.12.12)

Heads-up: this catalog entry is consumed as `peerDependencies.hono` in `packages/middleware/hono/package.json:47` and `packages/middleware/node/package.json:50`, so at `pnpm publish` the next release of `@modelcontextprotocol/hono` / `@modelcontextprotocol/node` will ship `peerDependencies.hono = "^4.12.12"` instead of `^4.11.4` (and `@hono/node-server` tightens to `^1.19.13`). Forcing the security-patched hono is probably desirable, but narrowing a published peer range is a public-contract chan
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Heads-up: this catalog entry is consumed as peerDependencies.hono in packages/middleware/hono/package.json:47 and packages/middleware/node/package.json:50, so at pnpm publish the next release of @modelcontextprotocol/hono / @modelcontextprotocol/node will ship peerDependencies.hono = "^4.12.12" instead of ^4.11.4 (and @hono/node-server tightens to ^1.19.13). Forcing the security-patched hono is probably desirable, but narrowing a published peer range is a public-contract change — worth a deliberate ack and a changeset rather than a silent Dependabot side-effect.

Extended reasoning...

What this changes beyond the lockfile

The runtimeServerOnly catalog is not only used for this repo's own dev/direct resolution — it is also referenced verbatim in published peerDependencies:

  • packages/middleware/hono/package.json:47"hono": "catalog:runtimeServerOnly" under peerDependencies
  • packages/middleware/node/package.json:50"hono": "catalog:runtimeServerOnly" under peerDependencies
  • packages/middleware/node/package.json:46"@hono/node-server": "catalog:runtimeServerOnly" under dependencies

pnpm's documented behavior is that the catalog: protocol (like workspace:) is replaced with the literal specifier from pnpm-workspace.yaml at pnpm pack / pnpm publish time, for all dependency fields including peerDependencies. So this PR doesn't just bump what the monorepo resolves locally — it changes what gets written into the tarballs published to npm.

Step-by-step proof

  1. Before this PR, pnpm-workspace.yaml has hono: ^4.11.4 in runtimeServerOnly. Running pnpm pack in packages/middleware/hono produces a package.json with "peerDependencies": { "hono": "^4.11.4", ... }.
  2. After this PR, the catalog entry is hono: ^4.12.12. The same pnpm pack now emits "peerDependencies": { "hono": "^4.12.12", ... }.
  3. A downstream consumer who has hono@4.11.6 (or anything in 4.11.44.12.11) installed alongside the next published @modelcontextprotocol/hono will now fail the peer check: npm prints an unmet-peer warning, and pnpm with strict-peer-dependencies / Yarn PnP hard-fails the install.
  4. The same substitution tightens @modelcontextprotocol/node's direct dep on @hono/node-server from ^1.19.9 to ^1.19.13 — less impactful (it's a direct dep so the package manager can just resolve higher), but still a published-range change.

Why nothing currently catches this

Dependabot bumped the catalog to satisfy the security advisory against the workspace's resolved versions; it has no awareness that this catalog key doubles as a public peer-range contract. The changeset-bot already noted "No Changeset found", so as-is the tightened peer range would land in the next release with no changelog entry.

Impact / severity

Low — both packages are 2.0.0-alpha.2, so semver guarantees are weak, and pushing consumers onto the security-patched hono (4.12.12 fixes GHSA-wmmm-f939-6g9c et al.) is arguably the right outcome anyway. This is flagged as a nit so it's a conscious maintainer decision rather than an accidental side-effect.

Suggested fix

Either (a) accept the narrowing intentionally and add a changeset for @modelcontextprotocol/hono and @modelcontextprotocol/node noting the tightened hono peer range, or (b) keep the catalog floor wide (e.g. leave hono: ^4.11.4) and rely on the lockfile to pin the workspace to 4.12.12, decoupling the published peer contract from the locally resolved version.

raw-body: ^3.0.0
runtimeShared:
'@cfworker/json-schema': ^4.1.1
Expand Down
Loading