The np package is a tool for publishing npm packages with ease. It automates the process of versioning, tagging, and publishing your package to the npm registry, ensuring that all necessary steps are completed correctly and efficiently.
Automated Versioning
This command automates the process of versioning your npm package. It prompts you to select the new version, updates the version in package.json, and creates a git tag.
npx npAutomated Publishing
After versioning, np will automatically publish your package to the npm registry. It ensures that all necessary steps, such as running tests and building the project, are completed before publishing.
npx npGit Integration
np integrates with git to ensure that your repository is in a clean state before publishing. It checks for uncommitted changes and ensures that you are on the correct branch.
npx npPre-publish Checks
np runs a series of checks before publishing your package, such as running tests and linting your code, to ensure that your package is in a good state before it is published.
npx nprelease-it is a versatile tool for automating versioning and package publishing. It offers more customization options compared to np, allowing you to define custom scripts and hooks for different stages of the release process.
semantic-release automates the versioning and package publishing process based on the commit messages. It follows the Semantic Versioning specification and generates changelogs automatically. It is more complex to set up compared to np but offers more advanced features.
standard-version is a tool for versioning and changelog generation based on conventional commits. It does not publish the package to the npm registry but can be used in conjunction with other tools to automate the release process.
A better
npm publish
main and master by default)latest dist-tagnp. It's meant to be used locally as an interactive tool.npm install --global np
$ np --help
Usage
$ np <version>
Version can be:
patch | minor | major | prepatch | preminor | premajor | prerelease | 1.2.3
Options
--any-branch Allow publishing from any branch
--branch Name of the release branch (default: main | master)
--no-cleanup Skips cleanup of node_modules
--no-tests Skips tests
--yolo Skips cleanup and testing
--no-publish Skips publishing
--preview Show tasks without actually executing them
--tag Publish under a given dist-tag
--contents Subdirectory to publish
--no-release-draft Skips opening a GitHub release draft
--release-draft-only Only opens a GitHub release draft for the latest published version
--test-script Name of npm run script to run tests before publishing (default: test)
--no-2fa Don't enable 2FA on new packages (not recommended)
--message Version bump commit message, '%s' will be replaced with version (default: '%s' with npm and 'v%s' with yarn)
--package-manager Use a specific package manager (default: 'packageManager' field in package.json)
Examples
$ np
$ np patch
$ np 1.0.2
$ np 1.0.2-beta.3 --tag=beta
$ np 1.0.2-beta.3 --tag=beta --contents=dist
Run np without arguments to launch the interactive UI that guides you through publishing a new version.
np can be configured both globally and locally. When using the global np binary, you can configure any of the CLI flags in either a .np-config.js (as CJS), .np-config.cjs, .np-config.mjs, or .np-config.json file in the home directory. When using the local np binary, for example, in a npm run script, you can configure np by setting the flags in either a top-level np field in package.json or in one of the aforementioned file types in the project directory. If it exists, the local installation will always take precedence. This ensures any local config matches the version of np it was designed for.
Currently, these are the flags you can configure:
anyBranch - Allow publishing from any branch (false by default).branch - Name of the release branch (main or master by default).cleanup - Cleanup node_modules (true by default).tests - Run npm test (true by default).yolo - Skip cleanup and testing (false by default).publish - Publish (true by default).preview - Show tasks without actually executing them (false by default).tag - Publish under a given dist-tag (latest by default).contents - Subdirectory to publish (. by default).releaseDraft - Open a GitHub release draft after releasing (true by default).testScript - Name of npm run script to run tests before publishing (test by default).2fa - Enable 2FA on new packages (true by default) (setting this to false is not recommended).message - The commit message used for the version bump. Any %s in the string will be replaced with the new version. By default, npm uses %s and Yarn uses v%s.packageManager - Set the package manager to be used. Defaults to the packageManager field in package.json, so only use if you can't update package.json for some reason.For example, this configures np to use unit-test as a test script, and to use dist as the subdirectory to publish:
package.json
{
"name": "superb-package",
"np": {
"testScript": "unit-test",
"contents": "dist"
}
}
.np-config.json
{
"testScript": "unit-test",
"contents": "dist"
}
.np-config.js or .np-config.cjs
module.exports = {
testScript: 'unit-test',
contents: 'dist'
};
.np-config.mjs
export default {
testScript: 'unit-test',
contents: 'dist'
};
Note: The global config only applies when using the global np binary, 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:
{
"name": "my-awesome-package",
"scripts": {
"version": "./build-docs && git add docs"
}
}
You can also add np to 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 publish as name of your script because it's an npm defined lifecycle hook.
{
"name": "my-awesome-package",
"scripts": {
"release": "np"
},
"devDependencies": {
"np": "*"
}
}
If you want to run a user-defined test script before publishing instead of the normal npm test or yarn test, you can use --test-script flag or the testScript config. This can be useful when your normal test script is running with a --watch flag or in case you want to run some specific tests (maybe on the packaged files) before publishing.
For example, np --test-script=publish-test would run the publish-test script instead of the default test.
{
"name": "my-awesome-package",
"scripts": {
"test": "ava --watch",
"publish-test": "ava"
},
"devDependencies": {
"np": "*"
}
}
Set the sign-git-tag npm config to have the Git tag signed:
$ npm config set sign-git-tag true
Or set the version-sign-git-tag Yarn config:
$ yarn config set version-sign-git-tag true
You can use np for packages that aren't publicly published to npm (perhaps installed from a private git repo).
Set "private": true in your package.json and 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:
"publishConfig": {
"access": "public"
}
If publishing a scoped package for the first time, np will prompt you to ask if you want to publish it publicly.
Note: When publishing a scoped package, the first ever version you publish has to be done interactively using np. If not, you cannot use np to publish future versions of the package.
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:
"publishConfig": {
"access": "restricted"
}
Set the registry option in package.json to the URL of your registry:
"publishConfig": {
"registry": "https://my-internal-registry.local"
}
If a package manager is not set in package.json, via configuration (packageManager), or via the CLI (--package-manager), np will attempt to infer the best package manager to use by looking for lockfiles. But it's recommended to set the packageManager field in your package.json to be consistent with other tools. See also the corepack docs.
If you use a Continuous Integration server to publish your tagged commits, use the --no-publish flag 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.
npm install --save-dev branchsite
"scripts": {
"deploy": "np",
"postdeploy": "bs"
}
For new packages, start the version field in package.json at 0.0.0 and let np bump it to 1.0.0 or 0.1.0 when 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:
$ git checkout -b fix-old-bug v1.0.0 # Where 1.0.0 is the previous major version
# Create some commits…
$ git push --set-upstream origin HEAD
$ np patch --any-branch --tag=v1
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 prerequisite step to run forever because it prompts for your passphrase in the background. To fix this, add the following lines to your ~/.ssh/config and run a simple Git command like git fetch.
Host *
AddKeysToAgent yes
UseKeychain yes
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.json or in .npmignore, is meant to help reduce the package size. To avoid broken packages caused by essential files being accidentally ignored, np prints out all the new and unpublished files added to Git. Test files and other common files that are never published are not considered. np assumes either a standard directory layout or a customized layout represented in the directories property in package.json.
If you get an error like this…
❯ Prerequisite check
✔ Ping npm registry
✔ Check npm version
✔ Check yarn version
✖ Verify user is authenticated
npm ERR! code E403
npm ERR! 403 Forbidden - GET https://registry.yarnpkg.com/-/package/my-awesome-package/collaborators?format=cli - Forbidden
…please check whether the command npm access list collaborators my-awesome-package succeeds. If it doesn't, Yarn has overwritten your registry URL. To fix this, add the correct registry URL to package.json:
"publishConfig": {
"registry": "https://registry.npmjs.org"
}
FAQs
A better `npm publish`
The npm package np receives a total of 126,129 weekly downloads. As such, np popularity was classified as popular.
We found that np demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 3 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.
Security News
The npm package for the LottieFiles Player web component was hit with a supply chain attack after a software engineer's npmjs credentials were compromised.