npm staged publishing adds human approval before package release

npm made staged publishing generally available on May 22, adding a deliberate pause between uploading a package and making it installable. A CI workflow or maintainer can send a prebuilt tarball to a stage queue, but a human maintainer must complete a two-factor-authenticated approval before release. GitHub’s npm changelog requires npm CLI 11.15.0 or newer for the npm stage commands.

Separate building from releasing

The strongest setup described by GitHub pairs staging with trusted publishing over OIDC. CI receives permission to submit a particular package to the queue without holding a long-lived publish token, while final promotion remains a separate maintainer action. A trusted-publisher configuration can be restricted to staging so a compromised workflow cannot switch back to direct npm publish.

This is an opt-in workflow decision. Existing direct publishing does not silently gain an approval step, and a human click does not validate package contents by itself. Teams still need provenance, tests, and review before promotion.

Design the approval as a real control

Change release automation to npm stage publish in a test package first. Confirm which files enter the tarball with npm pack --dry-run, then make the staged artifact and its source commit visible to the approver. The person approving should be able to compare version, integrity, provenance, and release notes without rerunning a mutable build.

Document who can approve, how abandoned stages expire or are rejected, and what happens during an urgent patch. Avoid sharing the same identity between the submitter and approver merely to keep old automation green. GitHub also announced explicit controls for Git, file, directory, and remote install sources in npm 11.15.0; those flags deserve a separate compatibility test because tightening them can affect development dependencies and monorepo workflows.