ELSEIF
Your brief EB
302 stories from 78 feeds 110 clusters Refreshed 11 minutes ago next pull 07:35

DEV TOOLS Signal 454

npm Staged Publishing Available, Adding a Human Approval Step Before Packages Go Live

npm now requires a maintainer-approved, two-factor-authenticated step before a published version becomes installable.

WHY IT MATTERS

The extra approval gate blocks automated supply-chain attacks that exploit compromised CI credentials. Engineers must adjust their build pipelines to stage releases and arrange a manual 2FA approval, adding a small operational overhead but improving security.

Written by elseif from the cluster below · every claim links back to a source

The three things worth knowing

01

Staged publishing queues a tarball and only makes it live after a maintainer passes a 2FA challenge.

02

Adoption requires npm CLI 11.15.0+ and Node 22.14.0+, plus replacing `npm publish` with the `npm stage` subcommands in CI scripts.

03

The feature works with any token type for staging, but approval cannot be automated, so a human step is mandatory.

THE READ

What the cluster adds up to.

ORIGINAL ANALYSIS

npm has introduced a staged publishing workflow that separates the upload of a package from its availability to consumers. When a developer runs the staging command, the package is stored in a queue visible on both the website and the CLI. It only becomes installable after a maintainer explicitly approves it by completing a two-factor authentication challenge. This replaces the previous immediate-publish model and adds a deliberate human checkpoint.

To use the new flow, teams must upgrade to npm CLI 11.15.0 or later and run on Node 22.14.0 or newer. The CI pipeline should be changed from `npm publish` to `npm stage publish`, followed by `npm stage list` or `npm stage view` to monitor pending releases. When a version is ready, a maintainer runs `npm stage approve` (or `reject`) which prompts for 2FA, completing the promotion. Existing token-based authentication continues to work for the staging step, so non-interactive builds are not broken.

The security impact is that any compromise of CI credentials can no longer push malicious code directly to users; the attacker would still need the maintainer’s 2FA device to approve the release. This addresses a common class of supply-chain incidents where automated pipelines are hijacked. By forcing a manual verification, the window for malicious code to spread is dramatically reduced.

Staged publishing only applies to packages that already exist on the npm registry, so it cannot be used to publish brand-new package names. The approval step cannot be scripted, meaning that fully automated releases will now require a human to intervene before the version is visible. Future npm releases will also change defaults for flags such as `--allow-git`, which may require additional configuration adjustments.

Other package managers have quickly added comparable staging commands, indicating that the industry is moving toward a similar safety net. Teams that already use trusted publishing via OIDC can reuse their configuration, but they must ensure that direct publishes are rejected in favor of the staged flow. Adoption will depend on whether maintainers consistently use the approval step, as the benefit is lost if the feature is ignored.

Written by elseif from the cluster below · checked for specifics the sources never contained

THE CLUSTER

Same story, 1 feed.

ORDERED BY FIRST SEEN
InfoQ npm Staged Publishing Available, Adding a Human Approval Step Before Packages Go Live Open ↗