Manage Releases - nx release
Once you have leveraged Nx's powerful code generation and task running capabilities to build your libraries and applications, you will want to share them with your users.
Nx provides a set of tools to help you manage your releases called nx release.
We recommend always starting with --dry-run, because publishing is difficult to undo
❯
nx release --dry-run
What makes up a release?
A release can be thought about in three main phases:
- Versioning - The process of determining the next version of your projects, and updating any projects that depend on them to use the new version.
- Changelog - The process of deriving a changelog from your commit messages, which can be used to communicate the changes to your users.
- Publishing - The process of publishing your projects to a registry, such as npm for TypeScript/JavaScript libraries.
Running releases
The nx release command is used to run the release process from end to end. It is a wrapper around the three main phases of a release to provide maximum convenience and ease of use.
By default if you just run nx release it will prompt you for a semver-compatible version number, or semver keyword (such as major, minor, patch, etc.) and then run the three phases of the release process, including publishing.
As with most Nx commands, when trying it out for the first time, it is strongly recommended to use the --dry-run flag to see what changes will be made before actually making them.
❯
nx release --dry-run
If you are working with a brand new workspace, or one that has never been released before, you will need to establish the previous release before running nx release. This is because Nx needs to know what the previous version of your projects was in order to know what to use as the start of the new release's changelog commit range. To do this, run git tag with an appropriate initial version. For example, if you have a brand new workspace, you might run git tag 0.0.0 to establish the initial version.
Customizing releases
The nx release command is highly customizable. You can customize the versioning, changelog, and publishing phases of the release process independently through a mixture of configuration and CLI arguments.
The configuration lives in your nx.json file under the "release" section.
1{
2 // ... more nx.json config
3 "release": {
4 // For example, configures nx release to target all projects
5 // except the one called "ignore-me"
6 "projects": ["*", "!ignore-me"]
7 // ... nx release config
8 }
9}
10Using nx release subcommands independently
As explained above, nx release is a wrapper around the three main phases of a release.
If you need more advanced or granular control over your release process you can also run these phases independently using the nx release version, nx release changelog, and nx release publish subcommands.
Each of these subcommands has their own CLI arguments which you can explore using the --help flag.
❯
nx release version --help
❯
nx release changelog --help
❯
nx release publish --help
Using the programmatic API for nx release
For the maximum control and power over your release process, it is recommended to use the programmatic API for nx release in your own custom scripts.
Here is a full working example of creating a custom script which processes its own CLI arguments (with --dry-run true by default) and then calls the nx release programmatic API.
1import {
2 releaseChangelog,
3 releasePublish,
4 releaseVersion,
5} from 'nx/src/command-line/release';
6import * as yargs from 'yargs';
7
8(async () => {
9 const options = await yargs
10 .version(false) // don't use the default meaning of version in yargs
11 .option('version', {
12 description:
13 'Explicit version specifier to use, if overriding conventional commits',
14 type: 'string',
15 })
16 .option('dryRun', {
17 alias: 'd',
18 description:
19 'Whether or not to perform a dry-run of the release process, defaults to true',
20 type: 'boolean',
21 default: true,
22 })
23 .option('verbose', {
24 description:
25 'Whether or not to enable verbose logging, defaults to false',
26 type: 'boolean',
27 default: false,
28 })
29 .parseAsync();
30
31 const { workspaceVersion, projectsVersionData } = await releaseVersion({
32 specifier: options.version,
33 // stage package.json updates to be committed later by the changelog command
34 stageChanges: true,
35 dryRun: options.dryRun,
36 verbose: options.verbose,
37 });
38
39 await releaseChangelog({
40 versionData: projectsVersionData,
41 version: workspaceVersion,
42 dryRun: options.dryRun,
43 verbose: options.verbose,
44 });
45
46 await releasePublish({
47 dryRun: options.dryRun,
48 verbose: options.verbose,
49 });
50
51 process.exit(0);
52})();
53