Skip to content

add release:publish and count an upload npm failed but the registry has - #461

Merged
xandreeddev merged 2 commits into
mainfrom
release-publish-registry-check
Nov 3, 2026
Merged

xandreeddev merged 2 commits into
mainfrom
release-publish-registry-check

Conversation

@xandreeddev

@xandreeddev xandreeddev commented Nov 2, 2026 •

Copy link
Copy Markdown
Owner

What

  • Add bun run release:publish to install locked dependencies, build all packages, run the publishing dry run, publish in dependency order, confirm the registry has every package, and push the release tag that deploys the docs. Interactive npm authentication is preserved.
  • Add --verify for packed Node/Bun validation and --dry-run to stop before publication and tagging.
  • Check release tag conflicts before uploads and again before tagging. Existing core versions must carry registry commit metadata matching HEAD; built manifests record gitHead so partial releases resume from their original source.
  • Confirm registry publication after an npm error so a successful upload followed by E409 does not halt the release. Stop if the registry cannot confirm it.
  • Preserve the native memory, RAG and PostgreSQL changes when integrating current main. Document the release workflow and its preconditions.

Checks

  • Repository commit gates and scripts TypeScript: pass; empty baseline.
  • bun test scripts: 89 pass, 0 fail.
  • Isolated release tests cover stale or missing provenance, tag conflicts before uploads, registry failures, valid resumes and a tag changed during publication. No live upload or tag push was performed.
  • Required CI on the integrated head: all checks pass, including live PostgreSQL and packed Node/Bun consumers.

`bun run release:publish` runs a release from a clean checkout of its merge
commit in one command: an install without lifecycle scripts, so the docs
site's optional `sharp` cannot fail it with a native build, the build, the
publish dry run and the publish, each attached to the terminal for npm's
second factor. Once the registry has every package of the build it creates
the `v<version>` tag on HEAD and pushes it, keeping a tag already there and
refusing one that names another commit. `verify:packages`, which CI already
runs on the merge commit, is opt-in with `--verify`; `--dry-run` stops before
the upload.

`publish:packages --publish` no longer stops when npm fails an upload that
went through, as with E409 "Cannot publish over previously staged version"
after a retried request: it asks the registry for that version for up to
about a minute, which also waits out the CDN's 404s, and counts it as
published when it is there. The decisions (`confirmation`, `releaseSteps`,
`tagPlan`, `notCleanTree`) are pure functions in `publish-plan.ts`; the
registry reads moved to `npm-registry.ts`. The release skill and the
publishing guide describe the one command and these traps.
Keep the native memory and retrieval packages alongside the release publishing helper. Check release tags and registry commit metadata before uploads, carry the captured build commit into every package manifest, and preserve the final tag check so interrupted releases resume only from their original source.

Retain both sets of changelog entries and cover the release preflight with isolated command and registry fixtures.
@xandreeddev
xandreeddev merged commit 13d6609 into main Nov 3, 2026
1 check passed
@xandreeddev xandreeddev mentioned this pull request Nov 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant