Publish the new version under a separate dist tag such as next, so a normal install keeps getting the stable release while volunteer apps opt in. After a few teams have run it, promote the version to latest. This gives you real world feedback before every app is exposed.
How npm tags make this work
The npm documentation explains that publishing sets the latest tag by default unless you pass the tag option, for example publishing with the beta tag. It also says a plain install of a package, with no version or tag, installs the version under latest. The dist-tag command can add, remove and list tags on a package afterwards.
So a version published under next sits in the registry without being anyone's default. Teams who run an install with the next tag, or pin the exact version, receive it. Everyone else is unaffected. More background is in npm dist-tags: what latest means for your installs.
A rollout in steps
- Merge the change to the library and run all gates: unit, visual, build of a sample app, and a dependency scan.
- Publish under the next tag. Use a pre release version number, as semver.org allows for pre release labels, so it is clear this is not final.
- Pick two or three pilot apps with different shapes: one large, one small, one with unusual styling. See the idea in pilot group for patch testing: who to pick.
- Ask pilots to install it in a branch, run their own tests, and report problems in one place.
- Fix and republish under next as needed.
- Promote by tagging the verified version as latest, and write release notes.
- Remove the next tag or move it to the following pre release so the channel stays meaningful.
What to watch during the pilot
| Signal | What it tells you |
|---|---|
| Install errors in pilot apps | Peer range or lockfile conflicts |
| Visual diffs in their own tests | Style or token changes that your stories missed |
| Bundle size change | New or duplicated dependencies |
| Runtime errors in staging | Behavior changes unit tests did not cover |
| New findings in their scans | Transitive dependencies you introduced |
Security fixes and previews
A preview channel suits feature work and risky upgrades. A security fix usually needs speed over ceremony: give it a short pilot or use your fast lane, as discussed in should a security dependency fix wait for the next release train. The idea of trying a fix on a small slice first is also covered in canary a dependency fix before full rollout.
Pitfalls
Do not let next become a second stable channel that apps stay on for months. Do not publish breaking changes under latest by mistake: check the tag in the publish output. And do not skip the dependency scan because it is only a preview, since pilot apps may deploy to staging with real credentials.
Safeguard can scan the pre release's dependency tree before you promote it, so a new transitive package does not slip in unnoticed. A free scan is available at gold.safeguard.sh/scan.
Quick check
Does publishing under next change latest?
No. With a tag specified, npm publishes to that tag and leaves latest where it was.
How long should a preview run?
Long enough for each pilot app to run its full test suite and deploy to staging. Set the exit criteria before you start.
Sources
Last reviewed: 19 October 2026.
