UNPKG

20.6 kBMarkdownView Raw
1# Release It! 🚀
2
3CLI release tool for Git repos and npm packages.
4
5**Release It!** automates the tedious tasks of software releases:
6
7<img align="right" src="./assets/release-it.gif?raw=true" height="170">
8
9- Execute test & build commands
10- Bump version (in e.g. `package.json`)
11- Git commit, tag, push
12- [Create release at GitHub](#github-releases) (and [upload assets](#release-assets))
13- [Create release at GitLab](#gitlab-releases) (and [upload assets](#release-assets))
14- [Generate changelog](#changelogs)
15- [Publish to npm](#publish-to-npm)
16- [Manage pre-releases](#manage-pre-releases)
17- [Script Hooks](#scripts)
18- Extend with [plugins](#plugins)
19
20[![Build Status](https://travis-ci.org/release-it/release-it.svg?branch=master)](https://travis-ci.org/release-it/release-it)
21[![npm version](https://badge.fury.io/js/release-it.svg)](https://badge.fury.io/js/release-it)
22[![codecov](https://codecov.io/gh/release-it/release-it/branch/master/graph/badge.svg)](https://codecov.io/gh/release-it/release-it)
23
24## Links
25
26- **NEW**: [release-it supports plugins](https://github.com/release-it/release-it/issues/501) (since v11), so virtually
27 any functionality can be added to your release process.
28- For **updates**, see [CHANGELOG.md](CHANGELOG.md) for major updates, and
29 [releases](https://github.com/release-it/release-it/releases) for a detailed version history.
30- To **contribute**, please read [CONTRIBUTING.md](CONTRIBUTING.md) first.
31- Please [open an issue](https://github.com/release-it/release-it/issues/new) if anything is missing or unclear in this
32 documentation.
33
34<details>
35 <summary><strong>Table of Contents</strong> (click to expand)</summary>
36
37<!-- toc -->
38
39- [Installation](#installation)
40- [Usage](#usage)
41- [Configuration](#configuration)
42- [Interactive vs. non-interactive mode](#interactive-vs-non-interactive-mode)
43- [Latest version](#latest-version)
44- [Git](#git)
45- [GitHub Releases](#github-releases)
46- [GitLab Releases](#gitlab-releases)
47- [Changelogs](#changelogs)
48- [Publish to npm](#publish-to-npm)
49- [Manage pre-releases](#manage-pre-releases)
50- [Scripts](#scripts)
51- [Plugins](#plugins)
52- [Distribution repository](#distribution-repository)
53- [Metrics](#metrics)
54- [Troubleshooting & debugging](#troubleshooting--debugging)
55- [Use release-it programmatically](#use-release-it-programmatically)
56- [Example projects using release-it](#example-projects-using-release-it)
57- [Resources](#resources)
58- [Credits](#credits)
59
60<!-- tocstop -->
61
62</details>
63
64## Installation
65
66### Global
67
68As a globally available CLI command:
69
70```bash
71npm install --global release-it
72```
73
74### Local
75
76As a `devDependency` in your project:
77
78```
79npm install --save-dev release-it
80```
81
82Add this as a `script` to `package.json`:
83
84```json
85{
86 "name": "my-package",
87 "version": "1.0.0",
88 "scripts": {
89 "release": "release-it"
90 },
91 "devDependencies": {
92 "release-it": "*"
93 }
94}
95```
96
97Now you can run `npm run release` from the command line.
98
99## Usage
100
101Release a new version:
102
103```bash
104release-it
105```
106
107You will be prompted to select the new version. To skip the first prompt, provide a specific increment or version:
108
109```bash
110release-it minor
111release-it 0.8.3
112```
113
114For a "dry run", to show the interactivity and the commands it _would_ execute:
115
116```bash
117release-it --dry-run
118```
119
120Note: read-only commands are still executed (`$ ...`), while the rest is not (`! ...`):
121
122```
123$ git rev-parse --git-dir
124.git
125! git add package.json
126! git commit --message="Release 0.8.3"
127```
128
129## Configuration
130
131Out of the box, release-it has sane defaults, and [plenty of options](conf/release-it.json) to configure it. Put the
132options to override in `.release-it.json` in the project root. Example:
133
134```json
135{
136 "git": {
137 "tagName": "v${version}"
138 },
139 "github": {
140 "release": true
141 }
142}
143```
144
145Or in a `release-it` property in `package.json`:
146
147```json
148{
149 "name": "my-package",
150 "devDependencies": {
151 "release-it": "*"
152 },
153 "release-it": {
154 "github": {
155 "release": true
156 }
157 }
158}
159```
160
161Notes:
162
163- Only the settings to override need to be in `.release-it.json` (or `package.json`). Everything else will fall back to
164 the [default configuration](conf/release-it.json).
165- You can use `--config` if you want to use another path for `.release-it.json`.
166- You can also use a regular JavaScript file, for example `.release-it.js`, as long as you point to it using `--config`.
167 This can be useful if your configuration depends on something else, so you have all JavaScript power to use instead of
168 a static JSON. Make sure you export the config with `module.exports`.
169
170Any option can also be set on the command-line, and will have highest priority. Example:
171
172```bash
173release-it minor --git.tagName='v${version}' --github.release
174```
175
176Boolean arguments can be negated by using the `no-` prefix:
177
178```bash
179release-it --no-npm.publish
180```
181
182## Interactive vs. non-interactive mode
183
184By default, release-it is **interactive** and allows you to confirm each task before execution:
185
186<img src="./assets/release-it-interactive.gif?raw=true" height="290">
187
188By using the `-n` option (i.e. **non-interactive**), the process is fully automated without prompts. The configured
189tasks will be executed as demonstrated in the first animation above.
190
191On a Continuous Integration (CI) environment, the non-interactive mode is activated automatically.
192
193## Latest version
194
195For projects with a `package.json`, its `version` will be used. Otherwise, release-it uses the latest Git tag to
196determine which version should be released. In any case, as a last resort, `0.0.0` will be used as the latest version.
197
198Use `--no-npm` (or `"npm": false`) to ignore and skip bumping `package.json` (and skip `npm publish`).
199
200Alternatively, a plugin can be used to get the version from anywhere else. Also see [plugins](docs/plugins/README.md).
201
202## Git
203
204### SSH keys & Git remotes
205
206SSH keys and Git remotes are assumed to be configured correctly. If a manual `git push` from the command line works,
207release-it should be able to do the same.
208
209The following help pages might be useful: [SSH](https://help.github.com/articles/connecting-to-github-with-ssh/) and
210[Managing Remotes](https://help.github.com/categories/managing-remotes/) (GitHub),
211[SSH keys](https://confluence.atlassian.com/bitbucket/ssh-keys-935365775.html) (Bitbucket),
212[SSH keys](https://gitlab.com/help/ssh/README.md) (GitLab).
213
214### Remote repository
215
216By default, `release-it` uses `origin` as the remote name to push to. Use `git.pushRepo` to override this with a
217different remote name (or a different git url).
218
219### Extra arguments
220
221In case extra arguments should be provided to Git, these options are available:
222
223- `git.commitArgs`
224- `git.tagArgs`
225- `git.pushArgs`
226
227For example, use `"git.commitArgs": "-S"` to sign commits (also see
228[#35](https://github.com/release-it/release-it/issues/350)).
229
230### Skip Git steps
231
232To skip the Git steps (commit, tag, push) entirely (e.g. to only `npm publish`), use the shorthand:
233
234```
235release-it --no-git
236```
237
238Use e.g. `git.tag: false` or `--no-git.tag` to skip a single step.
239
240### Untracked files
241
242By default, untracked files are not added to the release commit. Use `git.addUntrackedFiles: true` to override this
243behavior.
244
245## GitHub Releases
246
247The "Releases" tab on GitHub projects links to a page to store the changelog. To add
248[GitHub releases](https://help.github.com/articles/creating-releases/) in your release-it flow:
249
250- Configure `github.release: true`.
251- Obtain a [personal access token](https://github.com/settings/tokens) (release-it only needs "repo" access; no "admin"
252 or other scopes).
253- Make sure the token is available as an environment variable. Example:
254
255```bash
256export GITHUB_TOKEN="f941e0..."
257```
258
259Do not put the actual token in the release-it configuration. It will be read from the `GITHUB_TOKEN` environment
260variable. You can change this variable name by setting the `github.tokenRef` option to something else.
261
262Obviously, release-it uses this feature extensively:
263[release-it's releases page](https://github.com/release-it/release-it/releases).
264
265### Release notes
266
267By default, the output of `git.changelog` is used for the GitHub release notes. This is the printed `Changelog: ...`
268when release-it boots. Override this with the `github.releaseNotes` option. This script will run just before the actual
269GitHub release itself. Make sure it outputs to `stdout`. An example:
270
271```
272{
273 "github": {
274 "release": true,
275 "releaseNotes": "generate-release-notes.sh ${latestVersion} ${version}"
276 }
277}
278```
279
280### Release assets
281
282To upload binary release assets with a GitHub release (such as compiled executables, minified scripts, documentation),
283provide one or more glob patterns for the `github.assets` option. After the release, the assets are available to
284download from the GitHub release page. Example:
285
286```json
287{
288 "github": {
289 "release": true,
290 "assets": ["dist/*.zip"]
291 }
292}
293```
294
295## GitLab Releases
296
297[GitLab releases](https://docs.gitlab.com/ee/workflow/releases.html#releases) work just like GitHub releases:
298
299- Configure `gitlab.release: true`.
300- Obtain a [personal access token](https://gitlab.com/profile/personal_access_tokens) (release-it only needs the "api"
301 scope).
302- Make sure the token is available as an environment variable. Example:
303
304```bash
305export GITLAB_TOKEN="f941e0..."
306```
307
308The output of `git.changelog` (or `gitlab.releaseNotes` if set) will be attached to the latest tag.
309
310GitLab 11.7 introduces [Releases](https://docs.gitlab.com/ce/user/project/releases.html) to create release entries (much
311like GitHub), including release assets. For GitLab 11.6 and lower, release-it will automatically fall back to
312[attach releases notes to a tag](https://docs.gitlab.com/ce/workflow/releases.html). In this case, assets will not get
313included.
314
315Uploading assets work just like [GitHub Release assets](#release-assets), e.g. `--gitlab.assets=*.dmg`.
316
317## Changelogs
318
319By default, release-it generates a changelog, to show and help select a version for the new release. Additionally, this
320changelog serves as the release notes for the GitHub or GitLab release.
321
322The [default command](conf/release-it.json) is based on `git log ...`. This setting (`git.changelog`) can be overridden.
323To customize the release notes for the GitHub or GitLab release, use `github.releaseNotes` or `gitlab.releaseNotes`.
324Make sure any of these commands output the changelog to `stdout`.
325
326Instead of executing a shell command, a (Handlebars) template can be used to generate the changelog. See
327[auto-changelog](#auto-changelog) below for more details.
328
329Some projects keep their changelog in e.g. `CHANGELOG.md` or `history.md`. To auto-update this file with the release,
330the recommended configuration is to use a command that does this in `scripts.beforeStage`. See below for examples and
331workflows.
332
333### Auto-changelog
334
335A tool like [auto-changelog](https://github.com/CookPete/auto-changelog) is a great companion to release-it:
336
337```json
338{
339 "git": {
340 "changelog": "npx auto-changelog --stdout --commit-limit false -u --template ./changelog.hbs"
341 },
342 "scripts": {
343 "beforeStage": "npx auto-changelog -p"
344 }
345}
346```
347
348With this `git.changelog`, the changelog preview is based on the `changelog.hbs` template file. This would be used for
349[GitHub](#github-releases) or [GitLab releases](#gitlab-releases) as well.
350
351Additionally, `scripts.beforeStage` will update the `CHANGELOG.md` with each release to get included with the release
352commit. This can be omitted if the project does not keep a `CHANGELOG.md` or similar.
353
354See the [auto-changelog recipe](docs/recipes/auto-changelog.md) for an example setup and template.
355
356### Conventional Changelog
357
358If your project follows conventions, such as the
359[Angular commit guidelines](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits), the
360`@release-it/conventional-changelog` plugin is useful.
361
362```bash
363npm install @release-it/conventional-changelog --save-dev
364```
365
366Use this plugin to get the recommended bump based on the commit messages, generate a conventional changelog, and update
367the `CHANGELOG.md` file:
368
369```json
370{
371 "plugins": {
372 "@release-it/conventional-changelog": {
373 "preset": "angular",
374 "infile": "CHANGELOG.md"
375 }
376 }
377}
378```
379
380- Omit the `infile` at will. If set, but the file does not exist yet, it's created with the full history.
381- Please find the
382 [list of available presets](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages)
383 (`angular`, `ember`, etc).
384- The options are sent verbatim to
385 [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog/README.md).
386
387## Publish to npm
388
389With a `package.json` in the current directory, release-it will let `npm` bump the version in `package.json` (and
390`package-lock.json` if present), and publish to the npm registry.
391
392### Tags
393
394Use e.g. `--npm.tag=beta` to tag the package in the npm repository. With the `--preRelease=beta` shorthand, the npm
395dist-tag will have the same value (unless `--npm.tag` is used to override this). The default tag is "latest".
396
397For a pre-release, the default tag is "next". The tag will be derived from the pre-release version (e.g. version
398`2.0.0-alpha.3` will result in tag "alpha"), unless overridden by setting `npm.tag`.
399
400### Public scoped packages
401
402A [scoped package](https://docs.npmjs.com/misc/plugin) (e.g. `@user/package`) is either public or private. To
403[publish scoped packages](https://docs.npmjs.com/misc/plugin#publishing-scoped-packages), make sure this is in
404`package.json`:
405
406```json
407{
408 "publishConfig": {
409 "access": "public"
410 }
411}
412```
413
414By default, `npm publish` will
415[publish a scoped package as private](https://docs.npmjs.com/creating-and-publishing-private-packages) (requires paid
416account).
417
418### Two-factor authentication
419
420In case two-factor authentication (2FA) is enabled for the package, release-it will ask for the one-time password (OTP).
421
422The OTP can be provided from the command line (`--npm.otp=123456`). However, providing the OTP without a prompt
423basically defeats the purpose of 2FA (also, the OTP expires after a short period).
424
425### Monorepos
426
427Monorepos do not require extra configuration, but release-it handles only one package at a time. Also see how
428[Git steps can be skipped](#skip-git-steps) (e.g. if tagging the Git repo should be skipped).
429
430### Misc.
431
432- The `"private": true` setting in package.json will be respected, and `release-it` will skip this step.
433- Getting an `ENEEDAUTH` error while a manual `npm publish` works? Please see
434 [#95](https://github.com/release-it/release-it/issues/95#issuecomment-344919384).
435
436## Manage pre-releases
437
438With release-it, it's easy to create pre-releases: a version of your software that you want to make available, while
439it's not in the stable semver range yet. Often "alpha", "beta", and "rc" (release candidate) are used as identifier for
440pre-releases.
441
442An example. The `awesome-pkg` is at version 1.3.0, and work is done for a new major update. To publish the latest beta
443of the new major version:
444
445```
446release-it major --preRelease=beta
447```
448
449This will tag and release version `2.0.0-beta.0`. Notes:
450
451- A normal installation of `awesome-pkg` will still be at version 1.3.0.
452- The [npm tag](https://docs.npmjs.com/cli/dist-tag) will be "beta", install it using `npm install awesome-pkg@beta`
453- A GitHub release will be marked as a "Pre-release".
454
455The above command is actually a shortcut for:
456
457```
458release-it premajor --preReleaseId=beta --npm.tag=beta --github.preRelease
459```
460
461Consecutive beta releases (`2.0.0-beta.1` and so on):
462
463```
464release-it --preRelease
465```
466
467And when ready to release the next phase (e.g. release candidate, in this case `2.0.0-rc.0`):
468
469```
470release-it --preRelease=rc
471```
472
473And eventually, for `2.0.0`:
474
475```
476release-it major
477```
478
479<img src="./assets/release-it-prerelease.gif?raw=true" height="524">
480
481Notes:
482
483- Pre-releases work in tandem with [recommended bumps](#recommended-bump).
484- You can still override individual options, e.g. `release-it --preRelease=rc --npm.tag=next`.
485- See [semver.org](http://semver.org) for more details about semantic versioning.
486
487## Scripts
488
489These script hooks can be used to execute commands (from the root directory of the repository):
490
491- `scripts.beforeStart`
492- `scripts.beforeBump`
493- `scripts.afterBump`
494- `scripts.beforeStage`
495- `scripts.afterRelease`
496
497All commands can use configuration variables (like template strings). An array of commands can also be provided, they
498will run one after another. Some examples:
499
500```json
501{
502 "scripts": {
503 "beforeStart": ["npm run lint", "npm test"],
504 "afterBump": "tar -czvf foo-${version}.tar.gz",
505 "afterRelease": "echo Successfully released ${name} v${version} to ${repo.repository}."
506 }
507}
508```
509
510The variables can be found in the [default configuration](conf/release-it.json). Additionally, the following variables
511are exposed:
512
513```
514version
515latestVersion
516changelog
517name
518repo.remote, repo.protocol, repo.host, repo.owner, repo.repository, repo.project
519```
520
521## Plugins
522
523Since v11, release-it can be extended in many, many ways. Please head over to [plugins](docs/plugins/README.md) for more
524details.
525
526## Distribution repository
527
528Some projects use a distribution repository. Generated files (such as compiled assets or documentation) can be
529distributed to a separate repository. Or to a separate branch, such as a `gh-pages`. Some examples include
530[shim repositories](https://github.com/components) and a separate
531[packaged Angular.js repository](https://github.com/angular/bower-angular) for distribution on npm and Bower.
532
533The `dist.repo` option was removed in v10, but similar setups can still be achieved. Please see the
534[distribution repository](docs/recipes/distribution-repo.md) recipe for example configurations.
535
536## Metrics
537
538Use `--disable-metrics` to opt-out of sending some anonymous statistical data to Google Analytics. For details, refer to
539[lib/metrics.js](lib/metrics.js). Please consider to not opt-out: more data means more support for future development.
540
541## Troubleshooting & debugging
542
543- With `release-it --verbose`, release-it prints every command and its output.
544- Prepend `DEBUG=release-it:* release-it [...]` to print configuration and more error details.
545- Use `DEBUG=* release-it [...]` to include debug output for dependencies, such as
546 [@octokit/rest](https://github.com/octokit/rest.js).
547
548## Use release-it programmatically
549
550While mostly used as a CLI tool, release-it can be used as a dependency to ingrate in your own scripts. See
551[use release-it programmatically](docs/recipes/programmatic.md) for example code.
552
553## Example projects using release-it
554
555- [react-navigation/react-navigation](https://github.com/react-navigation/react-navigation)
556- [swagger-api/swagger-ui](https://github.com/swagger-api/swagger-ui)
557- [StevenBlack/hosts](https://github.com/StevenBlack/hosts)
558- [react-native-community/react-native-tab-view](https://github.com/react-native-community/react-native-tab-view)
559- [callstack/linaria](https://github.com/callstack/linaria)
560- [blockchain/blockchain-wallet-v4-frontend](https://github.com/blockchain/blockchain-wallet-v4-frontend)
561- [infor-design/enterprise](https://github.com/infor-design/enterprise)
562- [tsqllint/tsqllint](https://github.com/tsqllint/tsqllint)
563- [segmentio/typewriter](https://github.com/segmentio/typewriter)
564- [Repositories that depend on release-it](https://github.com/release-it/release-it/network/dependents)
565- GitHub search for
566 [projects with .release-it.json](https://github.com/search?o=desc&q=in%3Apath+.release-it.json&s=indexed&type=Code)
567
568## Resources
569
570- [semver.org](http://semver.org)
571- [GitHub Help](https://help.github.com) (→ [About Releases](https://help.github.com/articles/about-releases/))
572- [npm Blog: Publishing what you mean to publish](https://blog.npmjs.org/post/165769683050/publishing-what-you-mean-to-publish)
573- [npm Documentation: package.json](https://docs.npmjs.com/files/package.json)
574- [Prereleases and npm](https://medium.com/@mbostock/prereleases-and-npm-e778fc5e2420)
575- [Glob Primer (node-glob)](https://github.com/isaacs/node-glob#glob-primer) (release-it uses
576 [globby](https://github.com/sindresorhus/globby#readme))
577
578## Credits
579
580Major dependencies:
581
582- [ShellJS](https://documentup.com/shelljs/shelljs)
583- [Inquirer.js](https://github.com/SBoudrias/Inquirer.js)
584- [@octokit/rest](https://github.com/octokit/rest.js)
585
586The following Grunt plugins have been a source of inspiration:
587
588- [grunt-release](https://github.com/geddski/grunt-release)
589- [grunt-release-component](https://github.com/walmartlabs/grunt-release-component)