Customize Conventional Commit Types
Nx release allows you to leverage the conventional commits standard to automatically determine the next version increment.
By default, this results in:
feat(...)triggering a minor version bump (1.?.0)fix(...)triggering a patch version bump (1.?.x)BREAKING CHANGEin the footer of the commit message or with an exclamation mark after the commit type (fix(...)!) triggers a major version bump (?.0.0)
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 while others are skipped.
However, you can customize how Nx interprets these conventional commits, for both versioning and changelog generation.
Disable a Commit Type for Versioning and Changelog Generation
To disable a commit type, set it to false.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 // disable the docs type for versioning and in the changelog
6 "docs": false,
7 ...
8 }
9 }
10 }
11}
12If you just want to disable a commit type for versioning, but still want it to appear in the changelog, set semverBump to none.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 // disable the docs type for versioning, but still include it in the changelog
6 "docs": {
7 "semverBump": "none",
8 ...
9 },
10 ...
11 }
12 }
13 }
14}
15Changing the Type of Semver Version Bump
Assume you'd like docs(...) commit types to cause a patch version bump. You can define that as follows:
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 "docs": {
6 "semverBump": "patch",
7 ...
8 },
9 }
10 }
11 }
12}
13Renaming the Changelog Section for a Commit Type
To rename the changelog section for a commit type, set the title property.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 ...
6 "docs": {
7 ...
8 "changelog": {
9 "title": "Documentation Changes"
10 }
11 },
12 ...
13 }
14 }
15 }
16}
17Hiding a Commit Type from the Changelog
To hide a commit type from the changelog, set changelog to false.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 ...
6 "chore": {
7 "changelog": false
8 },
9 ...
10 }
11 }
12 }
13}
14Alternatively, you can set hidden to true to achieve the same result.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 ...
6 "chore": {
7 "changelog": {
8 "hidden": true
9 }
10 },
11 ...
12 }
13 }
14 }
15}
16Defining non-standard Commit Types
If you want to use custom, non-standard conventional commit types, you can define them in the types object. If you don't specify a semverBump, Nx will default to patch.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 "awesome": {}
6 }
7 }
8 }
9}
10Including Invalid Commits in the Changelog
Nx Release ignores all commits that do not conform to the Conventional Commits standard by default. A special __INVALID__ type is available in situations where you want to process invalid messages.
It's worth noting that this type will only include invalid commits. e.g. those that do not follow the <type>: <message>... format. Commits that are otherwise valid, but with a type that is not enabled, will not be matched by this group.
This can be useful in cases where you have not managed to be consistent with your use of the Conventional Commits standard (e.g. when applying it retroactively to an existing codebase) but still want a changelog to be generated with the contents of each commit message and/or for invalid commits to still affect project versioning.
If you cannot adhere to the Conventional Commits standard for your commits, file based versioning via Nx Release Version Plans could be a good alternative for managing your releases. See our docs on File Based Versioning for more information.
1{
2 "release": {
3 "conventionalCommits": {
4 "types": {
5 "__INVALID__": {
6 "semverBump": "patch", // Note: the default is "none"
7 "changelog": {
8 "title": "Uncategorized changes"
9 }
10 }
11 }
12 }
13 }
14}
15