The first release of a package often takes a different route from every release that follows. A maintainer publishes it manually, then the team connects the automated pipeline afterwards.
GitHub's 2 October 2026 npm update removes that requirement for staged publishing. The npm stage publish command can now create a new package using a local session or a granular access token, including a stage-only token.
The first version still needs promotion
The change covers public scoped and unscoped packages and private scoped packages. The first version enters a queue and requires a maintainer to promote it before it becomes available to install.
After package creation, the team can manage settings and configure trusted publishing. That makes the first release fit more naturally into a controlled release process.
Our assessment is that the review needs to show the maintainer what will ship. A prompt asking them to approve a version number alone offers little help.
Review the package that users will install
Check the package archive, not only the repository. Build output, declaration files, licence information and metadata all affect the installed result.
Look for files that should not be distributed, such as private configuration, test credentials or temporary exports. Also check that required files are present. A passing source test will not catch a missing file in a published archive unless the test covers that archive.
Use a clean test project to exercise the intended import or executable. If the package supports several environments, choose a small set representing the promises in its documentation.
Make the review easy to repeat
A release summary can include the commit, version, archive contents, test results and expected installation behaviour. Keep the summary tied to the candidate so reviewers know which build they are assessing.
Decide who can stage and who can promote. For a small team, those roles may overlap, but the process should still make the decision visible.
A stage-only credential can support a pipeline that prepares candidates while maintainers control promotion. Limit any credential to the work it needs to perform and store it in the approved secret system.
Have a plan for a faulty first release
Before promotion, agree what happens if the package is incomplete or the wrong version was staged. Review the current npm instructions for the available queue actions and package settings.
Also prepare the next release route. A first publication is the moment when support, ownership and release responsibilities become real commitments for the team.
Try the flow with an approved test package before using it for something customers depend on. Record the points where a maintainer must act and the evidence they will see.
Removing the manual first publish is useful. Pair it with a review of the actual installable package, and the new route can make the first release easier to explain and repeat.
Reporting checked on 13 October 2026.
