Maintenance branches need to specify a base branch or tag for conventional commit versioning

[tristanzander]

Hello! My team has been using NX in production for roughly a year in order to enforce module separation in our monorepo. Now that we have several major versions, we're having a problem going back and updating them in an automated way. I have provided an example and proposed solution, and would like to see if anybody else has any takes on this problem as well.

Example

Let's say we have a simple monorepo with the following packages:

/packages
    /my-module-1
    /my-module-2
/nx.json

There latest versions are as follows:

• my-module-1 is versioned at 4.2.0 and tagged at release/my-module-1/4.2.0
• my-module-2 is versioned at 1.1.3 and tagged at release/my-module-2/1.1.3

At some point, we realize that [email protected] needs a hotfix to be applied. In a conventional repo, you would perform the following actions:

1. Create a branch called release/v3 with the contents of the tree when 3.9.0 was published
2. Apply the hotfix as feat: my fix
3. Run npx semantic-release to create a version for [email protected]

When you introduce multiple packages with independent versions, it starts to become difficult to use existing tooling. If a patch is applied to both my-module-1 and my-module-2, then they would both get the same version that the branch was named (in this example, v3). In the case of nx release version, it appears that it always tries to read the latest git tag when using the git-tag config. (in this example, release/my-module-1/4.2.0). With this config, it's not possible to use nx release to publish a patch to a maintenance branch unless we were to either version manually or keep all our versions aligned with each other.

Solution

Rather than telling NX to version based on the latest tag, we'd like to be able to use the version on the disk and determine the version number from conventional commits since a specific revision on the git history.

nx.json

{
    "release": {
        "projectsRelationship": "independent",
        "version": {
            "conventionalCommits": true
            "resolver": "disk"
        }
    }
}

cli invocation

nx release version -p my-module-1 --since-revision $(git rev-parse release/my-module-1/3.9.0)

The --since-revision flag would need to point to a valid git revision/tag/branch, and the resolver would determine how many semantic commits were made in that timeframe to determine which modules should be published and which versions.

Are there potentially any easier ways of doing this, or any methods that exist in nx release version that I'm not currently seeing? It'd be a huge help to see this sort of feature added so that we don't have to write our own versioning scripts that do exactly what nx release can already do with the latest tag.

[tristanzander]

Using automaticFromRef like Changelog generation may also work as well. For maintenance branches specifically, I've come up with this as a workaround since we'll likely only release patches on maintenance branches for now.

PROJECTS=$(npx nx show projects --affected --base "${{ github.event.before }}" | tr '\n' ',')
if [[ -z "$PROJECTS" ]]; then
    exit 0
fi
npx nx release --projects="$PROJECTS" patch