[nissa-seru]

An open issue labelled release-hold now stops a release. Whoever finds that releasing main as it stands would harm someone running it files one, saying what has to happen first, and closes it once that has happened.

@antra-tess @Anarchid, this changes how you release, so please look before it merges. npm version and npm publish now ask GitHub for open holds first, and the publish workflow asks again for a tag.

Why

Nothing in the release read such a thing before. #300, the uncapped retryAfterMs sleep, was opened on Oct 12 at 16:15Z and closed on Oct 14 at 04:08Z, once #251 merged. 0.21.1 (Oct 13, 13:37Z) and 0.22.0 (Oct 13, 18:32Z) were both published while it was open. 0.22.0 required membrane ^0.5.87, the first release carrying antra-tess/membrane#56, which attaches a provider's whole retry-after hint to the errors it returns. #300 itself said hosts shouldn't take that membrane before the fix, and a host that installed 0.22.0 got the sleep.

The change

• scripts/release-holds.mjs lists the repository's open issues labelled release-hold, reading every page, and exits 1 naming each while any is open. A pull request with the label isn't a hold, since it isn't on main until it merges. The repository is the GitHub repository that package.json's repository field names, as a URL or in npm's shorthand, so a fork asks the package's home. GITHUB_REPOSITORY is used only when package.json names none. A token in GH_TOKEN or GITHUB_TOKEN is sent when present, and a public repository's issues read without one.
• If it can't read the holds, it stops too, since an open hold can't be ruled out. Its message says what to do: for a network error, its code; for an answer GitHub refused, the token, the rate limit, or the setting that named the repository.
• npm version runs it as preversion, so a held release stops before anything is bumped, committed or tagged. With no hold open, it costs one request to GitHub.
• npm publish runs it as prepublishOnly, before the build, so a release published by hand stops too.
• The publish workflow runs it for a tag in its build job, and again in each job that releases. The npm job checks through prepublishOnly, and the release-notes job has a step of its own. A held tag reaches neither npm nor the GitHub release notes, and a hold filed after the build job's check still stops both. Each of the three jobs gets issues: read and passes the job's token. A dispatch on a branch releases nothing, so it isn't held.
• The stop message says how to go on where it ran: re-run the workflow for the tag, or run npm version or npm publish again.
• CONTRIBUTING says when to file a hold and what it stops, and that npm's --ignore-scripts skips it, as it skips every lifecycle script.

It doesn't stop a hazard nobody files, or a publish with npm's scripts turned off.

Tests

test/release-holds.test.ts runs the real script against a local stand-in for GitHub's issues endpoint, each case in a throwaway directory with its own package.json. It covers:

• no open hold, a hold beside a labelled pull request, only labelled pull requests, several holds, and a hold behind a full page of labelled pull requests;
• which repository it asks: each form npm reads in the repository field, package.json over GITHUB_REPOSITORY, GITHUB_REPOSITORY when package.json names none, a field that names no GitHub repository, a package.json that isn't JSON, and no repository at all;
• the token it sends, from GH_TOKEN, or from GITHUB_TOKEN alone;
• what each refusal tells the maintainer, with and without a token, including a 404 that names the setting that named the repository; a server error; an answer that isn't a list; GitHub out of reach; and an API URL with a trailing slash;
• the stop message's next step in the workflow, under npm version and under npm publish.

The last three cases run npm itself with this repository's preversion and prepublishOnly entries. With a hold open, npm version stops before the bump and npm publish refuses. With none, npm version bumps.

Evidence

At cb2a3365, on Linux:

• npm run typecheck and npm run build are clean.
• The full suite passes 2010/2010 across 140 files on Node 24.21.0, with --test-force-exit and without, and on Node 20.20.2 with it. release-holds passes 22/22 in each run.
• With the 404 hint's earlier wording put back, the test for the setting that named the repository fails, and the other 21 pass.

Ezra-2423 also ran it by hand. With a hold open, npm version patch exits 1 and leaves the version as it was. Against GitHub itself, with no token, the check exits 0.

Review

The review workflow's two batteries read the change at 97487d58, and the fixes for its findings are in e1525a84. Ezra-2423 (Claude Opus 5.5) read each version, 94d02ee9, 97487d58, e1525a84 and cb2a3365, and approved each. His six points on the first are in 693459f1 and 97487d58, and cb2a3365 takes his note on the 404's wording.

We'll merge this once our pre-merge checks pass on its merge with the then-current main, and not before 15:00 UTC on October 14. After it merges, we'll create the release-hold label.

— Ada-1017 (Claude Opus 5.5)

[greptile-apps]

Confidence Score: 5/5

[Critical impact] The PR appears safe to merge; no actionable issues were found.

Summary

Adds checks for open release-hold issues before versioning, publishing, and creating GitHub release notes.

• Open release-hold issues now stop npm and tag releases.

_{Reviews (1) · Last reviewed commit: "build(release): a 404 names the setting ..." · Reviewed by Greptile}