Yes. After publishing, and ideally before announcing, install the exact artifact users will receive into a fresh, empty environment and run a basic check. Unit tests run against your source tree. Users run the packaged file, and the two can differ.
What a clean install catches
- Missing files. Something that existed in your working directory but not in the package.
- Extra files. Test fixtures, local config or other content that should not ship.
- Wrong metadata. A version string, licence or dependency range that is off.
- Changed behaviour from different dependency versions. A fresh install resolves dependencies afresh, as your users do.
Some of these are security issues. Stray files in a package can leak internal paths or data, and dependency ranges that resolve to unexpected versions change your real exposure.
A simple routine
- Build the artifact the way CI does. For npm, the pack command creates a tarball from a package, and its documentation lists a dry run option that reports what would be done without making changes.
- List the contents and read them.
- Install from the tarball or the registry into an empty directory or a throwaway container.
- Run a smoke test: import the package, call one function, run the command line tool with its version flag.
- Compare the reported version with the tag.
npm pack --dry-run
mkdir /tmp/cleancheck && cd /tmp/cleancheck
npm init -y
npm install ../path/to/my-package-2.4.0.tgz
node -e "console.log(require('my-package/package.json').version)"
Adapt the same idea to your ecosystem: a clean virtual environment for Python, a scratch module for Go, a fresh container for images.
Where to run it
| Environment | Pro | Con |
|---|---|---|
| Throwaway container | Truly empty, repeatable | Needs setup once |
| Fresh CI job | Automatic on every release | Shares CI network and cache settings |
| Your laptop | Quick | Full of leftovers that hide problems |
A CI job triggered after publish, running on an empty runner, is the best default. Have it fail loudly and notify the maintainers.
When something is wrong
If the clean install fails or the contents are wrong after you published, do not overwrite the version. Publish a fixed version, and use the registry's deprecation or yank features on the bad one. See can you overwrite a published package version.
What to automate
A post publish job can do the whole routine without a human. It starts on an empty runner, installs the version just published by exact number, imports the package, runs one command, and compares the reported version with the tag. If the registry has not finished replicating the new version, the job can retry a few times before failing. Have it open an issue or message the maintainers on failure, and keep its credentials read only, since it needs no write access. Because it runs after every release, a broken package is noticed in minutes rather than when the first user complains.
Quick check
Is a dry run the same as a clean install?
No. A dry run shows what would be included. A clean install proves the result works in an empty environment.
Do I need this for every patch release?
Automate it so it costs nothing per release. Manual checks get skipped under time pressure.
Sources
Last reviewed: 19 October 2026.
