Why does a scoped npm package need the public access option?

Scoped npm packages, the ones named like a username or organization followed by a slash and a name, are published with private visibility by default. To make one public you publish it with the public access option. Without it, you may end up with a package nobody can install.

The rule

The npm documentation states that by default scoped packages are published with private visibility, and that you make one public with the access option set to public on publish. This is the reason first-time maintainers see a confusing result: the publish seems to work, but the package page says private, or anonymous installs fail.

npm publish --access public

Unscoped packages are public by default, so the issue only shows up with scopes.

The first publish, step by step

The npm page describes this path for a public scoped package:

1. Create an npm account. For an organization scope, create the organization as well.
2. In the package directory run init with the scope, using your username for a user scope or the organization name.
3. Fill in the prompts to create package.json.
4. Add a README and your code.
5. Test locally by installing from the folder path.
6. Publish with the public access option.

Direct publishing also needs either 2FA on your account or a granular token with bypass 2FA, per the same page. See which npm 2FA setup a solo publisher should use.

Why scopes help a solo developer

A scope puts everything you publish under a name that only you or your organization can use. That reduces one kind of confusion: another person cannot publish a package that appears to be yours inside your scope. It does not stop look-alike names outside it. For that angle read scopes and package name collisions.

The npm page shows the user scope and the organization scope as the same pattern and does not describe other differences, so check "About scopes" if you need to compare them.

Make the choice hard to get wrong

• Record the intent in the project. Some teams use the private field to block accidental publishing of internal code, covered in private true and files stop accidental npm publish.
• Preview the tarball before the first release. See npm pack dry run.
• If you will use provenance, the npm provenance page says first-time publishes should add the public access option too. Details are in what npm provenance requires.

What public means for security

Once public, anyone can install and read the files in the tarball. Check for .env files, keys, test fixtures with real data and internal URLs before the first publish. A package you meant to keep private is the more serious mistake in the other direction, so confirm visibility on the package page right after the release.

Quick check

Sources

• npm docs: Creating and publishing scoped public packages
• npm docs: Generating provenance statements

Last reviewed: 19 October 2026.