In this tutorial we will examine the npm-access and npm-add-user cli options.


The npm-access sets the access level on published packages.


npm access public [<package>]
npm access restricted [<package>]

npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]

npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]


Npm-access is used to set control on private package.

  • For all the subcommands below, npm access performs actions on the packages in the current working directory if you don't pass in a package name in the subcommand.
  • public / restricted: This will set a package to be either publicly accessible or restricted.
  • grant / revoke: This subcommand either adds or removes the ability of users and teams to have read-write or read-only access to a package.
  • ls-packages: This will show all of the packages a user or a team is able to access, along with the access level, with the exception of read-only public packages (it will not print the whole registry listing)
  • ls-collaborators: This shows all of the access privileges for a package. It will only show permissions for packages to which you have at least read access. If you pass in <user>, the list will be filtered only to teams that user happens to belong to.
  • edit: This will set the access privileges for a package at once using $EDITOR.


npm access will always operate directly on the current registry, which is configurable from the command line using --registry=<registry url>.

Unscoped packages will always be public.

By default, scoped packages are restricted, but you can publish them either as public using npm publish --access=public, or you set their access as public using npm access public after the initial publish.

You need to have privileges to set the access of a package:

  • You have to be an owner of an unscoped or scoped package.
  • You have to be a member of the team that owns a scope.
  • You must have been given read-write privileges for a package, either as a team member or as an owner.

If enabled two-factor authentication, then you'll have to pass in an otp with --otp when making access changes.

If you don't have a paid account, and you attempt to publish scoped packages, it will fail with an HTTP 402 status code (logically enough), unless you are using --access=public.

You can manage teams and team membership using the npm team command.


This cli option adds a registry user account.


npm adduser [--registry=url] [--scope=@orgname] [--always-auth] [--auth-type=legacy]```
```aliases: login, add-user


You can create or verify a user that is named <username> in the specified registry, and then save the credentials to the .npmrc file. When no registry is specified, the default registry is used.

The username, password, and email will be read in from prompts.

If you need to reset your password, you need to go to https://www.npmjs.com/forgot

If you want to change your email address, you should go to https://www.npmjs.com/email-edit

You can use this command multiple times with the same user account to authorize on a new machine. Whenever you are authenticating on a new machine, the username, password and email address should match all match with your existing record.

npm login is an alias of adduser and will behave exactly the same way.



Default: https://registry.npmjs.org/

This is base URL of the npm package registry. If you also specify scope, this registry is only used for packages that has that scope. scope will default to the scope of the project directory you are currently in, if any.


Default: none

If specified, the user and login credentials given are associated with the specified scope. You can use both of them at the same time, e.g.

npm adduser --registry=http://myregistry.example.com --scope=@myco

This sets a registry for the given scope and login or creates a user for that registry at the same time.


Default: false

If specified, it will save configuration indicating that all requests to the given registry has to include authorization information. It is useful for private registries. It can be used with --registry and / or --scope, e.g.

npm adduser --registry=http://private-registry.example.com --always-auth

This ensures that all requests to that registry (including for tarballs) include an authorization header. This setting might be necessary for use with private registries where package tarballs and metadata are stored on hosts with different hostnames.


Default: 'legacy'

Type: 'legacy', 'sso', 'saml', 'oauth'

This determines the authentication strategy to use with adduser/login. Some of npm registries (for example, npmE) might support alternative auth strategies besides the classic username/password entry in legacy npm.

Previous: Semver
Next: npm-audit, npm-bin and npm-bug

Follow us on Facebook and Twitter for latest update.