Interactive UI

Ensures you are publishing from your release branch (mainand masterby default)

Ensures the working directory is clean and that there are no unpulled changes

Reinstalls dependencies to ensure your project works with the latest dependency tree

Ensures your Node.js and npm versions are supported by the project and its dependencies

Runs the tests

Bumps the version in package.json and npm-shrinkwrap.json (if present) and creates a git tag

Prevents accidental publishing of pre-release versions under the latestdist-tag

Publishes the new version to npm, optionally under a dist-tag

Rolls back the project to its previous state in case publishing fails

Pushes commits and tags (newly & previously created) to GitHub/GitLab

Supports two-factor authentication

Enables two-factor authentication on new repositories (does not apply to external registries)

Opens a prefilled GitHub Releases draft after publish

Warns about the possibility of extraneous files being published

See exactly what will be executed with preview mode , without pushing or publishing anything remotely

Supports GitHub Packages

Node.js 10 or later

npm 6.8.0 or later

Git 2.11 or later

Run npwithout arguments to launch the interactive UI that guides you through publishing a new version.

npcan be configured both locally and globally. When using the global npbinary, you can configure any of the CLI flags in either a .np-config.js, .np-config.cjsor .np-config.jsonfile in the home directory. When using the local npbinary, for example, in a npm runscript, you can configure npby setting the flags in either a top-level npfield in package.jsonor in a .np-config.js, .np-config.cjsor .np-config.jsonfile in the project directory. If it exists, the local installation will always take precedence. This ensures any local config matches the version of npit was designed for.

Currently, these are the flags you can configure:

anyBranch- Allow publishing from any branch (falseby default).

branch- Name of the release branch (masterby default).

cleanup- Cleanup node_modules(trueby default).

tests- Run npm test(trueby default).

yolo- Skip cleanup and testing (falseby default).

publish- Publish (trueby default).

preview- Show tasks without actually executing them (falseby default).

tag- Publish under a given dist-tag (latestby default).

yarn- Use yarn if possible (trueby default).

contents- Subdirectory to publish (.by default).

releaseDraft- Open a GitHub release draft after releasing (trueby default).

testScript- Name of npm run script to run tests before publishing (testby default).

2fa- Enable 2FA on new packages (trueby default) (setting this to falseis not recommended).

message- The commit message used for the version bump. Any %sin the string will be replaced with the new version. By default, npm uses %sand Yarn uses v%s.

For example, this configures npto never use Yarn and to use distas the subdirectory to publish:

.np-config.jsor .np-config.cjs

Note:The global config only applies when using the global npbinary, and is never inherited when using a local binary.

You can use any of the test/version/publish related npm lifecycle hooks in your package.json to add extra behavior.

For example, here we build the documentation before tagging the release:

You can also add npto a custom script in package.json. This can be useful if you want all maintainers of a package to release the same way (Not forgetting to push Git tags, for example). However, you can't use publishas name of your script because it's an npm defined lifecycle hook .

If you want to run a user-defined test script before publishing instead of the normal npm testor yarn test, you can use --test-scriptflag or the testScriptconfig. This can be useful when your normal test script is running with a --watchflag or in case you want to run some specific tests (maybe on the packaged files) before publishing.

For example, np --test-script=publish-testwould run the publish-testscript instead of the default test.

Set the sign-git-tag npm config to have the Git tag signed:

Or set the version-sign-git-tag Yarn config:

You can use npfor packages that aren't publicly published to npm (perhaps installed from a private git repo).

Set "private": truein your package.jsonand the publishing step will be skipped. All other steps including versioning and pushing tags will still be completed.

To publish scoped packages to the public registry, you need to set the access level to public. You can do that by adding the following to your package.json:

To publish a private Org-scoped package , you need to set the access level to restricted. You can do that by adding the following to your package.json:

Set the registry option in package.json to the URL of your registry:

If you use a Continuous Integration server to publish your tagged commits, use the --no-publishflag to skip the publishing step of np.

To publish to gh-pages(or any other branch that serves your static assets), install branchsite , an np-like CLI tool aimed to complement np, and create an npm "post" hook that runs after np.

For new packages, start the versionfield in package.json at 0.0.0and let npbump it to 1.0.0or 0.1.0when publishing.

To release a minor/patch version for an old major version, create a branch from the major version's git tag and run np:

If you're using macOS Sierra 10.12.2 or later, your SSH key passphrase is no longer stored into the keychain by default. This may cause the prerequisitestep to run forever because it prompts for your passphrase in the background. To fix this, add the following lines to your ~/.ssh/configand run a simple Git command like git fetch.

If you're running into other issues when using SSH, please consult GitHub's support article .

The ignore strategy , either maintained in the files-property in package.jsonor in .npmignore, is meant to help reduce the package size. To avoid broken packages caused by essential files being accidentally ignored, npprints out all the new and unpublished files added to Git. Test files and other common files that are never published are not considered. npassumes either a standard directory layout or a customized layout represented in the directoriesproperty in package.json.

If you get an error like this…

…please check whether the command npm access ls-collaborators my-awesome-packagesucceeds. If it doesn't, Yarn has overwritten your registry URL. To fix this, add the correct registry URL to package.json:

Sindre Sorhus

Sam Verschueren

Itai Steinherz