Automatically Version with Conventional Commits

If you wish to bypass the versioning prompt, you can configure Nx Release to defer to the Conventional Commits standard to determine the version bump automatically. This is useful for automating the versioning process in a CI/CD pipeline.

Enable Automatic Versioning

To enable automatic versioning via conventional commits, set the release.version.conventionalCommits property to true in nx.json:

1{ 2 "release": { 3 "version": { 4 "conventionalCommits": true 5 } 6 } 7} 8

Determine the Version Bump

Nx Release will use the commit messages since the last release to determine the version bump. It will look at the type of each commit and determine the highest version bump from the following list:

  • 'feat' -> minor
  • 'fix' -> patch

For example, if the git history looks like this:

1 - fix(pkg-1): fix something 2 - feat(pkg-2): add a new feature 3 - chore(pkg-3): update docs 4 - chore(release): 1.0.0 5

then Nx Release will select the minor version bump and elect to release version 1.1.0. This is because there is a feat commit since the last release of 1.0.0. To customize the version bump for different types of commits, or to trigger a version bump with custom commit types, see the Customize Conventional Commit Types recipe.

No changes detected

If Nx Release does not find any relevant commits since the last release, it will skip releasing a new version. This works with independent releases as well, allowing for only some projects to be released and some to be skipped.

Usage with Independent Releases

If you are using independent releases, Nx Release will determine the version bump for each project independently. For example, if the git history looks like this:

1 - fix(pkg-1): fix something 2 - feat(pkg-2): add a new feature 3 - chore(pkg-3): update docs 4 - chore(release): publish 5

Nx Release will select the patch version bump for pkg-1 and minor for pkg-2. pkg-3 will be skipped entirely, since it has no feat or fix commits.

Determining if a commit affects a project

Note that this determination is made based on files changed by each commit, not by the scope of the commit message itself. This means that feat(pkg-2): add a new feature could trigger a version bump for a project other than pkg-2 if it updated files in another project.

An example partial output of running Nx Release with independent releases and conventional commits enabled:

❯

nx release

1 2NX Running release version for project: pkg-1 3 4pkg-1 🔍 Reading data for package "@myorg/pkg-1" from packages/pkg-1/package.json 5pkg-1 📄 Resolved the current version as 0.4.0 from git tag "pkg-1@0.4.0". 6pkg-1 📄 Resolved the specifier as "minor" using git history and the conventional commits standard. 7pkg-1 ✍️ New version 0.5.0 written to packages/pkg-1/package.json 8 9NX Running release version for project: pkg-2 10 11pkg-2 🔍 Reading data for package "@myorg/pkg-2" from packages/pkg-2/package.json 12pkg-2 📄 Resolved the current version as 0.4.0 from git tag "pkg-2@0.4.0". 13pkg-2 📄 Resolved the specifier as "patch" using git history and the conventional commits standard. 14pkg-2 ✍️ New version 0.4.1 written to packages/pkg-2/package.json 15pkg-2 ✍️ Applying new version 0.4.1 to 1 package which depends on pkg-2 16 17NX Running release version for project: pkg-3 18 19pkg-3 🔍 Reading data for package "@myorg/pkg-3" from packages/pkg-3/package.json 20pkg-3 📄 Resolved the current version as 0.4.0 from git tag "pkg-3@0.4.0". 21pkg-3 🚫 No changes were detected using git history and the conventional commits standard. 22pkg-3 🚫 Skipping versioning "@myorg/pkg-3" as no changes were detected. 23 24

Recipes

Reference