Contents
In brief
npm and pnpm rolled out staged publishing: a version lands on the registry in a draft-like state, gets verified, then promotes to default install resolution. JavaScript Weekly #787 frames it as a supply-chain response — fewer chances a broken or malicious tarball spreads worldwide within minutes of npm publish.
What happened
Classic npm publish makes a version immediately resolvable. Anyone on ^1.2.0 can fetch the tarball seconds after upload. A CI mistake, stolen token, or malicious maintainer action scales faster than humans can yank the release.
Staged publishing inserts a gate. The package is visible for targeted testing — direct version installs, internal pipelines, checksum checks, consumer smoke tests — before it becomes the default answer for semver ranges. For monorepos and compliance-heavy teams, it resembles blue-green deploy more than one-shot upload.
Around the same ecosystem news in issue #787:
- pnpm 11.3 — trust policies via
trustLockfile, new package-management commands; - npm 12.0 — prerelease with expanded registry capabilities;
- periphery: Firefox 151 adds Web Serial, Storybook 10.4 improves TanStack React and complex app setups.
Staged publishing is the central supply-chain signal; the rest is weekly context.
Why it matters
npm attacks are familiar: typosquatting, maintainer takeover, malicious postinstall scripts. Defenses include lockfiles, npm audit, provenance, and delayed major upgrades. Staged publishing targets a different gap — the window between publish and mass consumption.
If the registry supports a pause, security and release engineers gain time:
| Phase | What staging enables |
|---|---|
| Pre-promote | Install only by explicit version/channel, not floating ranges |
| Verification | Consumer CI, tarball size checks, scanning |
| Post-promote | Normal semver resolution for everyone |
It does not replace maintainer 2FA or fix a compromised laptop, but it shrinks blast radius for mistaken releases.
In practice
- Read npm/pnpm docs — exact staged publish/promote CLI may differ; document in your internal runbook.
- Wire CI — after staged publish, run integration tests on dependent services; promote only on green.
- pnpm trustLockfile — align with who may enter the lockfile without manual approval.
- Downstream consumers — pin versions and consider update delays on critical paths instead of chasing freshest ranges.
- npm 12 prerelease — exercise on a staging registry before moving production publish pipelines.
Staged publishing may feel heavy for tiny OSS libs; for packages with millions of weekly downloads it is a sensible layer after provenance.
Takeaway
Staged publishing treats npm releases as production deploys, not a checkbox after merge. Together with pnpm trust policies and npm 12 maturity, the ecosystem moves toward a more controlled supply chain. Add a staged step to your release checklist while it is optional — enterprise consumers will expect it soon.