Found while closing out #790 (2026-10-09, main at e44f1fe).
release.yml publishes every npm package through OIDC trusted publishing only (#837 dropped the token steps). npm attaches a trusted publisher only to a package that already exists (npm/cli#8544), so a brand-new package fails its first npm publish in the release run. docs/release-checklist.md has the manual step ("First-time packages": publish once by hand, then configure the trusted publisher, before tagging), but nothing mechanical checks it.
scripts/release-dry-run.sh has the right loop and the wrong question: step 6 runs npm view "${pkg}@${ROOT_VER}" version for each published package and warns when the version already exists. A package that has never been published returns the same 404 as a not-yet-released version, so the loop passes silently. The full dry-run on main today passed every package check with @debugmcp/adapter-dart returning 404 for the package itself.
What would have happened at the next tag: publish_if_missing adapter-dart fails (E404/permission) before publish_if_missing mcp-debugger, so the CLI is not published, the GitHub Release assets are not packed, and the MCP Registry job waits on an npm mcpName that never appears. Recovery is the first publish by hand, the trusted publisher, then gh run rerun --failed (after deleting the run's release-artifacts artifact).
Proposed:
- In the dry-run loop, add
npm view "${pkg}" name: an E404 on the bare name is fail "never published: first publish by hand + trusted publisher before tagging (docs/release-checklist.md, First-time packages)", distinct from the existing "already published" warning. A non-404 error stays a warning (registry lag).
- Optionally the same probe as a
::warning in release.yml's build-and-test job, so a tag cut without the manual step says why it is about to fail before the npm job runs.
Not a code change here; this issue records the gap so the next new package (or this one, before the next tag) does not learn it from a half-finished release run.
Found while closing out #790 (2026-10-09,
mainat e44f1fe).release.ymlpublishes every npm package through OIDC trusted publishing only (#837 dropped the token steps). npm attaches a trusted publisher only to a package that already exists (npm/cli#8544), so a brand-new package fails its firstnpm publishin the release run.docs/release-checklist.mdhas the manual step ("First-time packages": publish once by hand, then configure the trusted publisher, before tagging), but nothing mechanical checks it.scripts/release-dry-run.shhas the right loop and the wrong question: step 6 runsnpm view "${pkg}@${ROOT_VER}" versionfor each published package and warns when the version already exists. A package that has never been published returns the same 404 as a not-yet-released version, so the loop passes silently. The full dry-run onmaintoday passed every package check with@debugmcp/adapter-dartreturning 404 for the package itself.What would have happened at the next tag:
publish_if_missing adapter-dartfails (E404/permission) beforepublish_if_missing mcp-debugger, so the CLI is not published, the GitHub Release assets are not packed, and the MCP Registry job waits on an npmmcpNamethat never appears. Recovery is the first publish by hand, the trusted publisher, thengh run rerun --failed(after deleting the run'srelease-artifactsartifact).Proposed:
npm view "${pkg}" name: an E404 on the bare name isfail "never published: first publish by hand + trusted publisher before tagging (docs/release-checklist.md, First-time packages)", distinct from the existing "already published" warning. A non-404 error stays a warning (registry lag).::warninginrelease.yml'sbuild-and-testjob, so a tag cut without the manual step says why it is about to fail before the npm job runs.Not a code change here; this issue records the gap so the next new package (or this one, before the next tag) does not learn it from a half-finished release run.