GitHub has shipped a useful npm supply-chain change: package versions can now be published into a staging queue, then approved by a human maintainer before they become installable.
The feature is called staged publishing. GitHub announced on May 22 that it is generally available for npm, alongside new install-source flags in npm CLI 11.15.0. The timing puts it squarely in the Monday issue window: the changelog item was published at 18:27 UTC on Friday, May 22, or 19:27 in London, and was checked against the live GitHub Changelog on May 25.
The idea is simple. Instead of a direct `npm publish` making a package version available to everyone immediately, the package tarball is uploaded to a staged queue. A maintainer then has to approve it explicitly, with a two-factor authentication challenge, before the version is released to the registry.
That does not remove automation. It changes where automation stops.
For teams already using trusted publishing with OIDC, GitHub says the recommended setup is to have CI publish to the stage queue and have a maintainer approve from a trusted device. The workflow can be configured as stage-only, so a normal publish from that CI workflow is rejected and only `npm stage publish` is accepted.
That is a sensible trade-off. Modern package publishing should not require a maintainer to build artefacts by hand on a laptop. Reproducible CI builds and OIDC identity are better than long-lived tokens copied into release scripts. But direct publishing from automation still creates a sharp edge: compromise the workflow, release job, dependency chain or maintainer account at the wrong moment, and the malicious version can hit the public registry before anyone notices.
Staged publishing inserts a deliberate pause.
For Laravel and PHP teams, this is not only a Node ecosystem story. Most Laravel applications have a Node side: Vite, Tailwind, component tooling, admin panels, front-end build pipelines, test runners, and internal packages used across client projects. Agencies often have small shared npm packages for design systems, build conventions or private UI components. Those packages may not be famous, but they sit in the path between developer machines, CI and production assets.
The practical question is whether the release flow has a human checkpoint where it matters. If a package is only consumed internally, staged publishing may sound like extra ceremony. But it is exactly the kind of ceremony that can be valuable for packages with broad blast radius: anything used by many projects, included in build steps, or published from CI with elevated permissions.
GitHub’s second change is more local but also relevant. npm CLI 11.15.0 adds new `--allow-*` install-source flags: `--allow-file`, `--allow-remote` and `--allow-directory`, complementing the existing `--allow-git` flag. These controls let users restrict the kinds of sources that an npm install is allowed to pull from.
That matters because package manifests can point beyond the registry. In many teams, a dependency coming from a file path, directory, Git URL or remote tarball is not always a problem. There are legitimate development and monorepo uses. But it is also a place where review discipline can slip, especially in large pull requests or hurried client work. Making allowed source types explicit gives teams another lever for hardening installs in CI.
The wider pattern is clear: package security is moving away from “trust the publish token” and toward layered controls around identity, approval, provenance and install policy. npm’s staged publishing fits that direction. It is not a full solution to dependency risk, and GitHub’s changelog does not claim that it is. It does not audit package contents, prove that a release is safe, or save a team from approving the wrong artefact. It creates a better hand-off between automation and human responsibility.
The operational work is modest. Teams that want staged behaviour need npm CLI 11.15.0 or newer and must update release workflows from `npm publish` to `npm stage publish`. Maintainers also need to decide who can approve staged packages and when approval is required. The highest-value candidates are shared packages, public packages, and any package whose release process currently runs unattended from CI.
There is a cultural implication too. Fast release systems often optimise for removing friction. Supply-chain incidents have shown that some friction is useful when it is placed at the right boundary. A two-factor approval step at the moment a built tarball becomes globally installable is not the same as asking developers to do manual release theatre from start to finish.
The caveat is adoption. The benefit appears only if maintainers opt into the staged flow and keep approval meaningful. A rushed click-through approval from the same compromised context would reduce the value. Teams should pair the feature with trusted publishing, protected release workflows, limited maintainer permissions and routine package review.
Still, this is the kind of platform change worth noticing. It does not ask developers to abandon automation. It asks them to make the final release act more intentional.
The useful next step is boring but concrete. Maintainers should list the packages they publish, identify which ones are released from CI, and decide which packages deserve stage-only publishing. The answer will not be every package. It should include shared front-end libraries, packages used across multiple client apps, and anything public enough that a bad release would affect people outside the team.
For internal teams, this is also a good moment to document who is allowed to approve releases. Staged publishing only helps if approval is owned, auditable and separate from the automation that built the tarball.