Top Related Projects
🚀 Automate versioning and package publishing
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
:package::rocket: Fully automated version management and package publishing
:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
🦋 A way to manage your versioning and changelogs with a focus on monorepos
A tool for writing better scripts
Quick Overview
np (short for "npm publish") is a better npm publish
command. It's a CLI tool that makes versioning and publishing npm packages easier and more consistent. np provides interactive prompts, runs tests, and performs various checks before publishing to ensure a smooth release process.
Pros
- Streamlines the npm package publishing process
- Runs tests and performs checks before publishing
- Supports various version control systems (Git, Mercurial)
- Provides interactive prompts for version selection and publishing confirmation
Cons
- Requires Node.js and npm to be installed
- May not be suitable for very complex publishing workflows
- Limited customization options for some steps in the process
- Might be overkill for simple projects or infrequent publishers
Getting Started
To use np, first install it globally:
npm install --global np
Then, in your npm package directory, simply run:
np
This will start the interactive publishing process. Follow the prompts to select the new version, run tests, and publish your package.
For more advanced usage, you can specify options:
np patch --yolo --no-publish
This example bumps the patch version, skips tests, and prepares the release without actually publishing it.
Competitor Comparisons
🚀 Automate versioning and package publishing
Pros of release-it
- More flexible and customizable with extensive configuration options
- Supports a wider range of version control systems (Git, SVN, Mercurial)
- Integrates with various CI/CD platforms and issue trackers
Cons of release-it
- Steeper learning curve due to more complex configuration
- May require more setup time for simple projects
- Less opinionated, which can lead to inconsistent release processes across teams
Code Comparison
release-it configuration example:
{
"git": {
"requireCleanWorkingDir": false,
"commitMessage": "Release ${version}",
"tagName": "v${version}"
},
"npm": {
"publish": true
}
}
np configuration example:
{
"yarn": true,
"contents": "dist",
"releaseDraft": true
}
Both tools aim to simplify the release process for npm packages, but they differ in their approach and feature set. release-it offers more flexibility and customization options, making it suitable for complex projects with specific release requirements. np, on the other hand, provides a more streamlined and opinionated approach, which can be beneficial for simpler projects or teams looking for a standardized release process.
release-it's extensive configuration options allow for fine-grained control over the release process, including support for various version control systems and CI/CD integrations. However, this flexibility comes at the cost of a steeper learning curve and potentially more setup time.
np focuses on simplicity and ease of use, with sensible defaults that work well for many npm packages. It may be more suitable for developers who prefer a quick and straightforward release process without extensive configuration.
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
Pros of standard-version
- Generates a CHANGELOG.md file automatically based on commit messages
- Supports custom commit types and scopes for more flexible versioning
- Can be used as a standalone CLI tool without integration into npm scripts
Cons of standard-version
- Requires adherence to Conventional Commits specification for optimal functionality
- Less opinionated about release process, which may require more manual configuration
- Doesn't include built-in features for publishing to npm or creating GitHub releases
Code comparison
standard-version:
{
"scripts": {
"release": "standard-version"
}
}
np:
{
"scripts": {
"release": "np"
}
}
Both tools can be integrated into npm scripts similarly, but np offers more out-of-the-box functionality for publishing and creating releases, while standard-version focuses primarily on versioning and changelog generation.
standard-version is better suited for projects that strictly follow Conventional Commits and need detailed changelog generation. np is more appropriate for projects that want a streamlined, opinionated release process with less configuration required.
:package::rocket: Fully automated version management and package publishing
Pros of semantic-release
- Fully automated release process, including changelog generation
- Integrates well with CI/CD pipelines
- Supports multiple package managers and languages
Cons of semantic-release
- Steeper learning curve and more complex setup
- Less flexibility for manual control over releases
- Requires strict adherence to commit message conventions
Code Comparison
semantic-release configuration:
{
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
"@semantic-release/github"
]
}
np usage:
np
Key Differences
- semantic-release is designed for fully automated releases, while np provides a more interactive and manual approach
- semantic-release relies on commit message conventions to determine version bumps, whereas np allows manual version selection
- semantic-release integrates more deeply with CI/CD systems, while np is typically run locally by developers
Use Cases
- Choose semantic-release for projects with frequent releases and well-established commit conventions
- Opt for np when you prefer more control over the release process or have a simpler project structure
Both tools aim to streamline the release process, but they cater to different workflows and team preferences. semantic-release excels in automation and consistency, while np offers simplicity and manual control.
:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
Pros of Lerna
- Designed for managing multiple packages in a monorepo
- Supports versioning and publishing of multiple packages simultaneously
- Provides tools for running commands across all packages
Cons of Lerna
- Steeper learning curve due to more complex configuration
- Can be overkill for single-package projects
- Requires more setup and maintenance
Code Comparison
Lerna (lerna.json):
{
"version": "independent",
"npmClient": "npm",
"command": {
"publish": {
"ignoreChanges": ["*.md"]
}
}
}
np (package.json):
{
"scripts": {
"release": "np"
}
}
Key Differences
- Lerna is focused on monorepo management, while np is designed for single-package publishing
- Lerna requires more configuration but offers more flexibility for complex projects
- np provides a simpler, more streamlined experience for individual package releases
Use Cases
- Choose Lerna for large projects with multiple interconnected packages
- Opt for np when working on single packages or smaller projects with simpler release processes
Both tools aim to simplify the package publishing process, but they cater to different project structures and complexity levels. The choice between them depends on your project's specific needs and scale.
🦋 A way to manage your versioning and changelogs with a focus on monorepos
Pros of Changesets
- Supports monorepo structures and multi-package releases
- Provides a more collaborative approach to version management
- Offers flexible configuration options for different project needs
Cons of Changesets
- Requires more setup and configuration compared to np
- May have a steeper learning curve for teams new to the concept
- Less suitable for single-package projects or simple versioning needs
Code Comparison
np:
import np from 'np';
await np({
cleanup: false,
yolo: true,
publish: false,
});
Changesets:
import { getPackages } from '@manypkg/get-packages';
import { createReleasePlan } from '@changesets/get-release-plan';
const packages = await getPackages(process.cwd());
const releasePlan = await createReleasePlan(packages);
Summary
Changesets is better suited for complex, multi-package projects and teams looking for a more collaborative versioning approach. It offers greater flexibility but requires more setup. np, on the other hand, is simpler to use and ideal for single-package projects or quick releases. The choice between the two depends on project structure, team size, and versioning complexity.
A tool for writing better scripts
Pros of zx
- Focuses on simplifying shell scripting with JavaScript, offering a more versatile scripting environment
- Provides built-in functions for common shell operations, making it easier to write cross-platform scripts
- Allows seamless integration of JavaScript and shell commands in a single script
Cons of zx
- Less specialized for npm package publishing compared to np
- May require more setup and configuration for specific npm-related tasks
- Lacks some of the automated checks and safeguards that np provides for package publishing
Code Comparison
np:
import np from 'np';
await np({
cleanup: false,
yarn: false,
contents: 'dist'
});
zx:
#!/usr/bin/env zx
await $`npm version patch`
await $`npm publish`
await $`git push --follow-tags`
Summary
While np is specifically designed for streamlining npm package publishing with various checks and automations, zx offers a more general-purpose scripting solution that combines JavaScript and shell commands. np excels in its focused approach to npm publishing, whereas zx provides greater flexibility for a wide range of scripting tasks, including but not limited to npm-related operations.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
np
A better
npm publish
Why
- Interactive UI
- Ensures you are publishing from your release branch (
main
andmaster
by 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
latest
dist-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
- Supports npm 9+, Yarn (Classic and Berry), and pnpm 8+
Why not
- Monorepos are not supported.
- Custom registries are not supported (but could be with your help).
- CI is not an ideal environment for
np
. It's meant to be used locally as an interactive tool.
Prerequisite
- Node.js 18 or later
- npm 9 or later
- Git 2.11 or later
Install
npm install --global np
Usage
$ 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
Interactive UI
Run np
without arguments to launch the interactive UI that guides you through publishing a new version.
Config
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
ormaster
by default).cleanup
- Cleanupnode_modules
(true
by default).tests
- Runnpm 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 tofalse
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 usesv%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.
Tips
npm hooks
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"
}
}
Release script
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": "*"
}
}
User-defined tests
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": "*"
}
}
Signed Git tag
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
Private packages
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.
Public scoped packages
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.
Private Org-scoped packages
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"
}
Publish to a custom registry
Set the registry
option in package.json to the URL of your registry:
"publishConfig": {
"registry": "https://my-internal-registry.local"
}
Package managers
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.
Publish with a CI
If you use a Continuous Integration server to publish your tagged commits, use the --no-publish
flag to skip the publishing step of np
.
Publish to gh-pages
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"
}
Initial version
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.
Release an update to an old major version
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
The prerequisite step runs forever on macOS
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.
Ignore strategy
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
.
FAQ
I get an error when publishing my package through Yarn
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"
}
Maintainers
Top Related Projects
🚀 Automate versioning and package publishing
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
:package::rocket: Fully automated version management and package publishing
:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
🦋 A way to manage your versioning and changelogs with a focus on monorepos
A tool for writing better scripts
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot