Prepare the registry identity

Publishing writes to a public namespace you cannot rename casually. Account and package identity deserve the same care as the code.

Confirm who you are logged in as

npm whoami
npm config get registry

You should see your npm username and https://registry.npmjs.org/. If registry points at a private mirror, you might publish to the wrong place.

Scoped packages default to restricted access. For a public library like @acme/slugify-title, set access explicitly on the first publish:

npm publish --access public

Later publishes inherit the access level unless you change it.

Protect the maintainer account

Turn on two-factor authentication for your npm account. npm enforces 2FA for popular packages and for accounts that publish frequently.

If your org supports trusted publishing through GitHub Actions, enable it so CI can publish without long-lived tokens sitting in secrets. That is the direction npm is pushing maintainers toward.

Check name and ownership before day one

Search the registry for name collisions:

npm view @acme/slugify-title version

An E404 means the name is free. A version string means someone else owns it.

Add co-maintainers early if a team owns the package:

npm owner add teammate @acme/slugify-title
npm owner ls @acme/slugify-title

Save a release checklist with read-only checks (whoami, owner ls, tarball dry run) and keep tokens out of that document. Run the checklist from a clean shell before the first real npm publish.

If you publish through CI, store the npm token or OIDC trust in the pipeline secrets, not in a maintainer laptop script. Rotate credentials when someone leaves the team.

Confirm the email on your npm account still works. Recovery flows for lost 2FA devices go through that address.