What to know
- Staged publishing can now create public and private scoped packages and public unscoped packages.
- The first staged version is not installable until a maintainer promotes it.
- Trusted publishing can be configured after the package is created.
Package creation no longer requires immediate distribution
GitHub announced on October 2 that npm staged publishing can create new packages. A maintainer can use npm stage publish with a session or an appropriate granular access token, including a token limited to staging. The capability covers public unscoped packages, public scoped packages and private scoped packages.
The initial version enters the staged queue and remains unavailable for installation until a maintainer promotes it. Once the package exists, its settings can be used to configure trusted publishing for subsequent releases. The change separates creating the registry record and uploading a candidate version from making that version available to consumers. Promotion remains an explicit step in the documented workflow.
Source: GitHub: npm staged publishing supports creating new packages
Analysis: Review should follow the artifact
A staged release creates a point at which maintainers can inspect what will actually be distributed. That matters because a repository and a package archive are not always identical. Build steps can generate files, omit required assets or include material that was never intended for consumers. A source review can therefore miss a problem introduced during packaging.
The useful review object is the exact candidate artifact, together with its package metadata and provenance. Maintainers can check the included files, entry points, declared dependencies and installation behavior before promotion. For a new package, they should also verify its name and scope. An error in the first release can affect how downstream projects discover and reference the package, even if the implementation itself is correct.
Separating upload from promotion also allows the two actions to use different authority. An automated builder may be allowed to create a candidate while a maintainer controls distribution. That arrangement is meaningful only if the promoter reviews the candidate that will be released. Rebuilding the package after approval or promoting a different queued version can break the connection between the review and the distributed artifact.
Release status needs to be visible to maintainers
Teams adopting staged creation should make the release state clear in their pipeline and documentation. A successful upload means that a candidate exists; it does not mean that consumers can install it. Automated announcements and downstream jobs should wait for the distribution state they require. Otherwise, a first release can appear complete internally while installation still fails for users.
A promotion checklist can remain brief and concrete. It can identify the candidate version, the reviewer, the artifact checks and the intended audience. Private scoped packages also need the appropriate organization access controls. After the first promotion, maintainers can configure the trusted publisher and confirm how later candidates will be staged and approved.
Staging does not establish that a package is safe or suitable for every application. It creates a practical pause between producing an artifact and distributing it. The quality of that pause depends on the checks performed and the authority assigned to the final action. The new package support makes the same separation available at the start of a project’s registry history.
Sources & further reading
Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.
The event date records the source announcement or documented operation. The coverage edition groups recent developments and is separate from the publication date. Actual publication is recorded above.
Corrections policy · About this byline
