Publish and verify

npm publish returning success is not the final proof. The registry artifact and a fresh install from npm are.

Publish only the state that already passed your release gate. Do not rebuild between npm pack --dry-run and npm publish unless you rerun the gate afterward.

Publish the checked version

npm run release:check
npm publish --access public

npm uploads the tarball built from your current tree. Note the version and integrity from the output.

Record in your release notes: git commit hash, CI run URL, tarball file list, and the exact version string.

Verify from the registry

In a clean temp directory:

mkdir /tmp/registry-check && cd /tmp/registry-check
npm init -y
npm install @acme/[email protected]
node -e "import('@acme/slugify-title').then(m => console.log(m.slugifyTitle('Hi')))"

Expected output:

hi

Inspect registry metadata:

npm view @acme/slugify-title version dist-tags repository

You should see 0.1.0, { latest: '0.1.0' }, and your git URL.

Practice on a private scope first

If you are nervous about the first release, create a private test package under a scope you control, publish once, and run the same install smoke test. Delete or deprecate it after you confirm the flow.

Never publish from a dirty tree or with a version number you already used. Both create recovery work that is harder than waiting five minutes for CI to finish.

Compare tarball integrity before and after publish if you want extra confidence:

shasum -a 512 acme-slugify-title-0.1.0.tgz
npm view @acme/[email protected] dist.integrity

The hashes should match the artifact npm hosts.

If your org uses provenance attestations, confirm they appear on the npm package page after publish. That link helps consumers trace a version back to the CI job that built it.

Wait a minute after publish before the registry smoke test. npm replication is usually fast, but a retry loop in CI avoids flaky false failures on the first install attempt.