Swiftpack.co - Package - webpro/release-it

Release It! 🚀

CLI release tool for Git repos and npm packages.

Release It! automates the tedious tasks of software releases:

Build Status npm version Greenkeeper badge

Table of Contents (click to expand)

💾 Installation


As a globally available CLI tool:

npm install --global release-it


As a devDependency in your project:

npm install --save-dev release-it

Add this as a script to package.json:

  "name": "my-package",
  "version": "1.0.0",
  "scripts": {
    "release": "release-it"
  "devDependencies": {
    "release-it": "^4.2.0"

Now you can run npm run release from the command line.

▶️ Usage

Release a new patch (increments from e.g. 1.0.4 to 1.0.5):


Release a patch, minor, major, or specific version:

release-it minor
release-it 0.8.3

See manage pre-releases for versions like 1.0.0-beta.2 and npm install my-package@next.

You can also do a "dry run", which won't write/touch anything, but does output the commands it would execute, and show the interactivity:

release-it --dry-run

⚙️ Configuration

Out of the box, release-it has sane defaults, and plenty of options to configure it. Put the options to override in .release-it.json in the project root. Example:

  "src": {
    "tagName": "v%s"
  "github": {
    "release": true
  • Only the settings to override need to be in .release-it.json. Everything else will fall back to the default configuration.
  • You can use --config if you want to use another path for the local .release-it.json.

Any option can also be set on the command-line, and will have highest priority. Example:

release-it minor --src.tagName='v%s' --github.release

Boolean arguments can be negated by using the no- prefix:

release-it --no-npm.publish

🤖 Interactive vs. non-interactive mode

By default, release-it is interactive and allows you to confirm each task before execution:

On a Continuous Integration (CI) environment, or by using the -n option, this is fully automated. No prompts are shown and the configured tasks will be executed. This is demonstrated in the first animation above. An overview of the default tasks:

Task | Option | Default | Prompt | Default :--|:--|:-:|:--|:-: Ready (confirm version) | N/A | N/A | - | Y Show staged files | N/A | N/A | prompt.src.status | N Git commit | src.commit | true | prompt.src.commit | Y Git push | src.push | true | prompt.src.push | Y Git tag | src.tag | true | prompt.src.tag | Y GitHub release | github.release | false | prompt.src.release | Y npm publish | npm.publish | true | prompt.src.publish | Y

The left columns are default options in non-interactive (or CI) mode.

The prompt.* options on the right in the table are used for the default answers in interactive mode. You can still change the answer to either Y or N as the questions show up (or cancel the process with Ctrl-c).

Also, if e.g. npm.publish is false, the related prompt (prompt.src.publish) will not be shown (regardless of its default answer).

🔗 Command Hooks

The command hooks are executed from the root directory of the src or dist repository, respectively:

  • src.beforeStartCommand
  • beforeChangelogCommand
  • buildCommand - before files are staged for commit
  • src.afterReleaseCommand
  • dist.beforeStageCommand - before files are staged in dist repo
  • dist.afterReleaseCommand

All commands can use configuration variables (like template strings):

"buildCommand": "tar -czvf foo-${src.tagName}.tar.gz ",
"afterReleaseCommand": "echo Successfully released ${version} to ${dist.repo}."

The variables can be found in the default configuration. Additionally, version, latestVersion and changelog are exposed in custom commands. Also the repo object (with properties remote, protocol, host, owner, repository and project) is available.

📡 SSH keys & git remotes

The tool assumes you've configured your SSH key and Git remotes correctly. In short: you're fine if you can git push. Otherwise, the following GitHub help pages might be useful: SSH and Managing Remotes.

✏️ GitHub Release

See this project's releases page for an example.

To create GitHub releases:

  • The github.release option must be true.
  • Obtain a GitHub access token (release-it only needs "repo" access; no "admin" or other scopes).
  • Make sure the token is available as an environment variable. Example:
export GITHUB_TOKEN="f941e0..."

Do not put the actual token in the github.tokenRef configuration, it should be the name of the environment variable.

📦 Release Assets

To upload binary release assets with a GitHub release (such as compiled executables, minified scripts, documentation), provide one or more glob patterns for the github.assets option. After the release, the assets are available to download from the GitHub release page. Example:

"github": {
  "release": true,
  "assets": "dist/*.zip"

🐣 Manage Pre-releases

With release-it, it's easy to create pre-releases: a version of your software that you want to make available, while it's not in the stable semver range yet. Often "alpha", "beta", and "rc" (release candidate) are used as identifier for pre-releases.

For example, if you're working on a new major update for awesome-pkg (while the latest release was v1.4.1), and you want others to try a beta version of it:

release-it major --preRelease=beta

This will tag and release version 2.0.0-beta.0. This is actually a shortcut for:

release-it premajor --preReleaseId=beta --npm.tag=beta --github.preRelease

Consecutive beta releases (v2.0.0-beta.1 and so on) are now easy:

release-it --preRelease=beta

Installing the package with npm:

npm install awesome-pkg         # Installs v1.4.1
npm install awesome-pkg@beta    # Installs v2.0.0-beta.1

You can still override e.g. the npm tag being used:

release-it --preRelease=rc --npm.tag=next

See semver.org for more details.

Custom or Conventional Changelog

Recommended Bump

If your project follows for example the Angular commit guidelines, the special conventional:angular increment shorthand can be used to get the recommended bump based on the commit messages:

  "increment": "conventional:angular"

Please find the list of available conventions (angular, ember, etc).

Generate Custom Changelog

You can use tools like conventional-changelog-cli to generate the changelog for the GitHub release. Make sure that the changelogCommand outputs the changelog to stdout. In the next example, beforeChangelogCommand is also used, to update the CHANGELOG.md file (and part of the release commit).

  "increment": "conventional:angular",
  "beforeChangelogCommand": "conventional-changelog -p angular -i CHANGELOG.md -s",
  "changelogCommand": "conventional-changelog -p angular | tail -n +3",
  "safeBump": false

The safeBump option was introduced for this use case, to make sure the bump is done as late as possible, as in this case the conventional-changelog tool needs to run from the current version.

🚚 Distribution Repository

Some projects use a distribution repository. Reasons to do this include:

Overall, it comes down to a need to release generated files (such as compiled bundles, documentation) into a separate repository. Some examples include:

To use this feature, set the dist.repo option to a git endpoint. This can be a branch (also of the same source repository), like "git@github.com:webpro/release-it.git#gh-pages". Example:

"dist": {
  "repo": "git@github.com:components/ember.git"

The repository will be cloned to dist.stageDir, and the dist.files (relative to dist.baseDir) will be copied from the source repository. The files will then be staged, commited and pushed back to the remote distribution repository.

Make sure to set dist.github.release and dist.npm.publish to true as needed. The dist.github.* options will use the github.* values as defaults. Idem dito for dist.npm.* options, using npm.* for default values.

During the release of a source and distribution repository, some "dist" tasks are executed before something is committed to the source repo. This is to make sure you find out about errors (e.g. while cloning or copying files) as soon as possible, and not after a release for the source repository first.

📝 Notes

  • The "private": true setting in package.json will be respected and the package won't be published to npm.
  • You can use src.pushRepo option to set an alternative url or name of a remote as in git push <src.pushRepo>. By default this is null and git push is used when pushing to the remote.

🐛 Troubleshooting & debugging

  • Use --verbose to output commands that release-it executes.
  • Use --debug to output configuration and additional (error) logs.
  • Use DEBUG=octokit:rest* release-it [...] for debug logs with GitHub releases & assets.

⏩ Using release-it Programmatically

From Node.js scripts, release-it can also be used as a dependency:

const releaseIt = require('release-it');

releaseIt(options).then(output => {
  // { version, latestVersion, changelog }

💼 Examples

📚 Resources

🎁 Contributing

Please see CONTRIBUTING.md.

❤️ Credits

Major dependencies:

The following Grunt plugins have been a source of inspiration:

🎓 License



Stars: 732
Help us keep the lights on


Used By

Total: 0


7.2.1 - Mar 4, 2018

  • Update deps (7a08685)
  • Remove preset check for conventional-changelog (fixes #260) (32f85cb)

7.2.0 - Feb 23, 2018

  • Update deps (63ab486)
  • Include all conventional-changelog presets (resolves #250) (d920e81)

7.1.0 - Feb 22, 2018

  • Update dependencies (223c9e5)
  • Fix missing debugger (e4fcbe6)
  • Wrap up "extra args" feature (63fdd74)
  • Add git commit/push extra arguments option (#247) (b09a6c5)
  • Fix Typo (#244) (a34f6a8)
  • Add unit tests around pre-releases (14e7d39)
  • Fix test (669f35c)

7.0.2 - Feb 10, 2018

  • Fix error output (060b298)
  • Fix host for github client (d054777)

7.0.1 - Feb 10, 2018

  • Update readme (closes #224) (aabedd7)
  • Migrate from github to @octokit/rest (closes #219) (2384f91)
  • Update changelog (8a5f2a4)