Your team wants to publish its first JavaScript library from its automated pipeline. Who creates the package, who reviews its content, and when is the identity of the pipeline validated? Both npm changes announced on October 2, 2026 make this sequence more important. A package ready to be examined and a valid trust configuration are two different states.
The first package adds a step to the launch
Our October 1st article on the stages and permissions of publication npm details the separation of rights; this article examines the new packages and the trust validation cycle announced on October 2.
Let's take a fictional library, reserved for our scenario. Its archive contains the code intended for other applications. The pipeline prepares this archive, but a person must be able to examine it before a usable version is distributed. The question is not just 'can automation publish?': it is also necessary to know what it can prepare and who decides on making it available.
On October 2, npm announced the possibility of creating a new package with npm stage publish, from a local session or a granular token, including a token limited to preparation. The submitted version enters a review queue and must be promoted by a maintainer before becoming installable. The package configuration and trusted publishing can then be organized. Announcement about the new packages.
Staged publishing refers to this publication waiting for approval. Trusted publishing is a separate mechanism: it allows a recognized automated environment to act on the package. So you can have an archive pending and unvalidated trust, or validated trust with an archive still not approved. The article examines these states, rather than putting the whole release under a 'publish' button.
The 48-hour change concerns unvalidated trust
The other announcement of October 2 concerns unvalidated trusted publishing configurations. They expire 48 hours after their creation. A successful first publication validates them and exempts them from this expiration. A change in the repository or project identity requires a new trust relationship; an ordinary modification does not reset the counter to zero. Expired configurations remain visible and must be recreated to open a new window. npm announcement about expiration.
The same announcement specifies the refusal of tokens from GitHub Actions events issue_comment, in addition to the restriction already applied to pull_request_target. A workflow trigger describes the situation in which the pipeline starts. Here, a denied context does not become authorized because its archive has been approved. Restriction of publication contexts.
Do not turn the 48 hours into the lifespan of all your secrets or into the universal deadline for promoting a version. This window concerns a specific state of the configuration. The exact scenario that validates trust must be observed in your process: the mere presence of a pending archive is not enough to prove it.
Draw the path before starting the automation
Write a sheet with the package name, its maintainer, the expected repository, and the initial version. Add the component that produces the archive, the person who reviews it, and the one who can promote it. The same person can hold multiple roles, but these decisions must remain identifiable.
The npm documentation consulted on October 6 describes a draft version 0.0.0-stage created when a package does not yet exist. This placeholder is public; the submitted version and its content remain pending until approval. Staging therefore has a visible effect on the registry before the distribution of your actual archive. The documentation also indicates npm CLI 11.15.0 or newer and Node 22.14.0 or newer. Staged publishing documentation.
For our fictional library, the first check is to compare the archive to what was supposed to be delivered. Examine the included files, the dependencies, and the scripts that might run during installation. Do this in an isolated environment suitable for your project. The fact that an archive comes from a known pipeline does not establish that its content matches the request.
Then document the transition between preparation and promotion. The person who approves must know which archive has been reviewed and which version it corresponds to. Proof of reviewing another file, even with a similar name, is not proof for this artifact. Your tracking can use a file fingerprint in private logs, without cluttering the message intended for users.
Follow the two life cycles
The table below is a proposed tracking method, based on the announced trust states. It does not describe an invented npm interface.
| State of trust | Meaning to be checked | Team action |
|---|---|---|
| Not validated | First successful publication not yet observed | Prepare the validation in the designated window |
| Validated | First successful publication observed | Monitor identity and permissions |
| Expired | Validation window completed | Recreate the relationship after reviewing the reason |
| Identity changed | Different repository or project | Examine and establish the new relationship |
Next to it, keep an independent record of the archive: prepared, reviewed, approved, and then distributed. The expiration of a trust does not prove that a version has been withdrawn. The approval of an archive does not prove that another pipeline is authorized. By separating these states, you can identify the right person responsible when an operation fails.
For the identity mechanism, explain to the team what OpenID Connect, often abbreviated OIDC, means: the pipeline presents a proof tied to its execution context, rather than a simple permanent secret copied everywhere. The useful decision remains the identity actually admitted. An OIDC label in a configuration does not replace the review of the repository, the workflow, and the trigger.
Add an operational alert suitable for the launch: who notices a configuration that is still not validated, where is the creation date recorded, and who decides on a recreation? Do not automatically recreate the relationships without understanding why they expire. A coordination difficulty between preparation, review, and launch could otherwise remain invisible.
Test refusals with a local model
Before any action on a registry, you can build a local simulation of the states. It receives a fictitious configuration, a creation date, and a fictitious publication result. It calculates whether the relationship is unvalidated, validated, or expired according to your announcement model. The schedules are test inputs, not observations on npm.
Prepare four cases: relationship not validated in the window, relationship not validated after expiration, validated relationship, and modified identity. For each case, indicate the expected transition and the decision that a manager will have to make. This simulation tests your understanding and your procedure; it does not by itself qualify the behavior of the registry.
Add refusals related to the archive: missing content, reviewed version different from the proposed version, missing approval. Also add a forbidden execution context. The resulting message must indicate which dimension is involved, without displaying any identity proof or secret. The appropriate response to an unreviewed archive is not to modify the pipeline trust.
For a later authorized trial on a registry, first check the namespace, the owners, and the effects of public creation. The commands cited in this article are used to identify the mechanisms; no package has been created and no prepare, publish, or promote command has been executed to produce this content.
Plan for a comprehensible resumption
If the window expires, start with the timeline: when was the relationship created, which event was supposed to validate it, and what observation is missing? Check if the pipeline actually reached the publication step, if its identity matches, and if the context is authorized. Recreation takes place after this review, with the launch manager.
If the archive remains pending, look towards the examination and approval side. Do not force a direct publication just to unlock a schedule. The procedure must specify who can decide to abandon a version, correct the archive, or resume the sequence. This way, you preserve the usefulness of the separation of roles.
For your first package, keep in mind five criteria: inspected artifact, reviewed identity, actually observed validation, assigned promotion rights, and documented expiration procedure. This grid does not measure any overall security gain; it provides concrete decisions to verify. When a criterion is missing, complete the corresponding preparation before extending the pipeline to subsequent versions.
The launch becomes easier to explain when everyone knows how to distinguish 'package created', 'content approved', and 'trust validated'. The October 2 announcements modify these steps, but your team rule keeps the sequence together. First, try going through it with dummy data and planned rejections: you will then know what evidence to collect in an authorized real trial.
Sources and verification date
Open sources on October 6, 2026: expiration of trust, creation of a new package in staging and documentation npm. Both announcements are dated October 2; the living documentation provides context. The scenario and the simulation are offered, without any actual publication or claimed result.