Hono Just Adopted Staged Publishing. 50M Weekly Downloads, 33 Hours After the Issue.
Issue filed Saturday. PR merged Monday. The release.yml diff is one line.
On June 21, 2026 I filed honojs/hono#5034: a request to enable npm Staged Publishing on Hono. The package serves 50M weekly downloads with a single publisher (Yusuke Wada), so a stolen credential or compromised CI token would push directly to latest with no human in the loop.
Yusuke replied 12 minutes later: “I’m considering switching to Staged Publishing just now. I may do it soon.”
On June 22, 2026 at 11:42 UTC, PR #5035 — “ci: use npm Staged publishing” merged. Issue closed in the same commit. Total elapsed: 33 hours from issue file to workflow change in main.
The diff
The change to .github/workflows/release.yml is exactly what npm’s docs prescribe:
- run: npm publish --provenance --access public
+ run: npm stage publish --provenance --access public
One word. stage.
What it does: after CI runs, the new version sits in a staging area on the registry. It is not yet the default install target. A human with 2FA must approve it before latest moves. If an attacker steals an OIDC token from the runner—the exact mechanism behind TanStack’s May 2026 attack and Red Hat’s June 1 incident—the malicious version stages but never goes live. No silent push to latest. No npm install hono pulling the compromise.
Hono already had OIDC provenance (shipped June 18 in PR #5028). Provenance answers the question “was this built by the expected pipeline?”—but when the pipeline itself is compromised, the answer is yes and the package still ships. Staged Publishing closes the remaining window between “CI ran” and “users install it.”
Verification, reproducible
Two ways to confirm Hono now uses staged publishing without taking my word for it:
1. Read the workflow file directly.
gh api repos/honojs/hono/contents/.github/workflows/release.yml \
--jq '.content' | base64 -d | grep -E 'npm stage'
Expected output: run: npm stage publish --provenance --access public
2. Ask the Commit API.
curl -s 'https://poc-backend.amdal-dev.workers.dev/api/audit' \
-H 'Content-Type: application/json' \
-d '{"packages":["hono"],"ecosystem":"npm"}'
The response now includes hasStagedPublishing: true and scoreBreakdown.stagedPublishing: 2 for Hono. Before June 22 it was false/0. The scoring picked the change up automatically—no human re-tagged anything—because the detector scans CI workflow files for npm stage patterns.
What this means for the supply chain wave
Three weeks ago, “use OIDC provenance” was the strongest defense most packages had. TanStack proved that wasn’t enough. Red Hat proved it again. PostCSS’s Andrey Sitnik called the problem in postcss/postcss#2096 and moved nanoid + nanospy in a week. Preact’s team shipped it without an announcement. Now Hono.
That is the curve. Sole-publisher packages at massive scale (nanoid 208M/wk, preact 23M/wk, hono 50M/wk) are adopting the gate that makes the recent attack class survivable. Each adoption removes one of the highest-leverage targets from the “one stolen token = global compromise” category.
And the gap between “an outside observer asks for it” and “the maintainer ships it” is collapsing. 33 hours, in this case. The reason it’s fast: the diff is one word. The friction is reading the docs once, not refactoring a pipeline. Once a few high-profile maintainers do it publicly, the rest of the long tail has a working pattern to copy.
What still needs the gate
Today, the same scan API will tell you cross-spawn, chalk, esbuild, lodash, and minimatch all still publish to latest with no human in the loop. Several have shipped provenance; none have shipped the approval gate. Combined weekly downloads: north of 1.5 billion.
That’s the next batch. Filing useful issues against them is slow work—1 per repo per week, only when the implementation steps are concrete and verifiable, only against active maintainers—but Hono moved in 33 hours, and nanoid moved in less than that. The pattern works when the work is done right.
Watch your dependencies for the upgrade
npx proof-of-commitment
The CLI scans your lockfile and flags packages where a single publisher controls >10M weekly downloads. The output now includes whether each package uses OIDC provenance, Staged Publishing, both, or neither. When one of your CRITICAL dependencies adopts the gate, the score moves up and the flag clears—automatically, the moment the CI workflow file changes on main.
Free API key watches 3 packages with a weekly digest. Developer ($15/mo) watches 15 with daily scans and instant alerts — you find out the moment a CRITICAL becomes safer, or the reverse.