jscutlery / semver

Nx plugin to automate semantic versioning and CHANGELOG generation.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

@jscutlery/semver NPM package @jscutlery/semver coverage status

@jscutlery/semver

Nx plugin for versioning using SemVer and CHANGELOG generation powered by Conventional Commits.

Setup

Install

npm install -D @jscutlery/semver
nx g @jscutlery/semver:install

This package allows you to manage your Nx workspace using one of two modes: Synced or Independent.

Independent mode (default)

Allow multiple projects to be versioned independently. This way you release only what you want and consumers don't get updates they don't need. This allows small, rapid and incremental adoption of your packages.

Synced mode

Allow multiple projects to be versioned in a synced/locked mode. Use this if you want to automatically tie all package versions together. This mode is useful when you are working with only one product. One issue with this approach is that a major change in any project will result in all projects having a new major version.

Usage

Release

Independent mode

Release project independently by running:

nx run my-project:version [...options]

You can leverage the affected command to only version changed packages:

nx affected --target version [...options]

Synced mode

Release workspace by running:

nx run workspace:version [...options]

When run, this executor does the following

  1. Retrieve the current version by looking at the last git tag.
  2. Bump package.json version based on the commits.
  3. Generates CHANGELOG based on the commits (uses conventional-changelog-angular under the hood).
  4. Creates a new commit including the package.json file and updated CHANGELOG.
  5. Creates a new tag with the new version number.
  6. Pushes the version to the remote repository.
  7. Runs post-targets hook to publish the version on NPM, GitHub or GitLab.

Available options

name type default description
--dryRun boolean false run with dry mode
--noVerify boolean false skip git hooks
--push boolean false push the release to the remote repository
--syncVersions boolean false lock/sync versions between projects
--skipRootChangelog boolean false skip generating root changelog
--skipProjectChangelog boolean false skip generating project changelog
--origin string 'origin' push against git remote repository
--baseBranch string 'main' push against git base branch
--changelogHeader string undefined custom Markdown header for changelogs
--releaseAs string undefined specify the level of change (details)
--preid string undefined specify the prerelease identifier (eg: alpha, beta) (details)
--tagPrefix string undefined specify the tag prefix (details)
--postTargets string[] [] specify the list of target to execute post-release (details)
--trackDeps boolean false bump dependent packages (bump A if A depends on B) (details)
--allowEmptyRelease boolean false force a patch increment even if library source didn't change
--skipCommitTypes string[] [] treat commits with specified types as non invoking version bump (details)
--skipCommit boolean false skips generating a new commit, leaves all changes in index, tag would be put on last commit (details)
--commitMessageFormat string undefined format the auto-generated message commit (details)
--preset string | object 'angular' customize Conventional Changelog options (details)
--commitParserOptions object undefined customize the commit parserConfig (details)

Guides

Overwrite default configuration

You can customize the default configuration using the definition file:

{
  "executor": "@jscutlery/semver:version",
  "options": {
    "baseBranch": "master",
    "preset": "atom",
    "tagPrefix": "{projectName}@"
  }
}

Customizing Conventional Changelog

This tool comes with a list of pre-configured presets:

Complete list of presets

The preset is highly configurable, following the conventional-changelog-config-spec. As an example, suppose you're using GitLab, rather than GitHub, you might modify the following variables:

{
  "executor": "@jscutlery/semver:version",
  "options": {
    "preset": {
      "commitUrlFormat": "{{host}}/{{owner}}/{{repository}}/commit/{{hash}}",
      "compareUrlFormat": "{{host}}/{{owner}}/{{repository}}/compare/{{previousTag}}...{{currentTag}}",
      "issueUrlFormat": "{{host}}/{{owner}}/{{repository}}/issues/{{id}}",
      "types": [
        { "type": "feat", "section": "✨ Features" },
        { "type": "fix", "section": "🐞 Bug Fixes" },
        { "type": "chore", "hidden": true }
      ]
    }
  }
}

Note

When customizing a preset it will implicitly use the conventionalcommits preset and override the default settings with the given configuration.

It is possible to customize any preset by passing its name.

{
  "executor": "@jscutlery/semver:version",
  "options": {
    "preset": {
      "name": "angular",
      "types": [
        { "type": "feat", "section": "✨ Features" },
        { "type": "fix", "section": "🐞 Bug Fixes" }
      ]
    }
  }
}

See the conventional-changelog-config-spec for available configuration options.

Customizing the commit parser

You may customize the config for the commit parser. This can be helpful when you are using an adapted version of conventional commit for instance.

{
  "executor": "@jscutlery/semver:version",
  "options": {
    "commitParserOptions": {
      "headerPattern": "^([A-Z]{3,}-\\d{1,5}):? (chore|build|ci|docs|feat|fix|perf|refactor|test)(?:\\(([\\w-]+)\\))?\\S* (.+)$",
      "headerCorrespondence": ["ticketReference", "type", "scope", "subject"]
    }
  }
}

See the conventional-commits-parse specification for available configuration options.

Version calculation

This package is tag-based, which means it never reads the package.json to retrieve the current version. Instead, it looks for a tag matching the --tagPrefix (i.e demo-x.y.z). Then, if no tag is found it fallbacks to 0.0.0, and calculates the initial version based on all changes since the first commit. In the other case, if there are matching tags, it retrieves the last one and calculates the new version from it.

Important

To detect a new version this package looks into the commit history and checks if any source files changed since the last version. Note that merge commits are ignored by the tool when calculating next version to bump.

Major zero version 0.x.y is for initial development. Anything may change at any time so the consumer won't get any new minor version using the caret or tilde compatibility range, for instance version 0.3.1 won't be resolved if the consumer wants ^0.2.0.

Specify the level of change

The --releaseAs option allows you to release a project with a version that is incremented by a specified level.

Level can be one of major, minor, patch, premajor, preminor, prepatch, or prerelease, for instance:

nx run workspace:version --releaseAs=major
nx run workspace:version --releaseAs=minor
nx run workspace:version --releaseAs=patch
nx run workspace:version --releaseAs=prerelease --preid=alpha
nx run workspace:version --releaseAs=prerelease --preid=beta

Initial prerelease version

When using the --releaseAs=prerelease option, the initial prerelease version takes into account the commit history to determine the recommended bump type. As an illustration, let's assume the current version is 1.0.0, and the commit history includes the following:

  • Commit 1: feat(my-project): abc
  • Commit 2: fix(my-project): def

Running the following command:

nx version my-project --releaseAs=prerelease --preid=alpha

Would yield the version 1.1.0-alpha.0. Subsequent executions of the command would result in incremented prerelease versions, such as 1.1.0-alpha.1.

Tag prefix customization

The --tagPrefix option allows you to customize the tag prefix.

In sync mode only one tag is created for the whole workspace, the tag prefix is set to v by default, which is resolved for instance to v0.0.1.

In independent mode, the tag prefix uses the contextual project name, the default value is {projectName}- which is resolved for instance to my-project-0.0.1. Note that each project in the workspace is versioned with its tag.

Commit message customization

The --commitMessageFormat option allows you to customize the commit message. By default, the commit message is formatted as the following:

chore({projectName}): release version {version}

Contextual variables resolved by this option:

  • version the current release version (for instance 1.0.0)
  • projectName the project name to be versioned (for instance my-project)

Note that it's the right place to add common keywords to skip CI workflows, for example: [skip ci] for GitHub, eg:

release: bump {projectName} to {version} [skip ci]

Skipping release for specific types of commits

To avoid releasing a new version if something non-influencing on release was changed (for example, documentation), you can provide skipCommitTypes option. In this case, any commit with a specified type would be ignored when calculating if there is a need to bump version. For example, if you had only one commit from the last version:

docs(project): update documentation about new feature

would not cause a new release (because --skipCommitTypes=docs,ci was specified).

And two commits:

docs(project): update documentation about new feature
fix(project): get rig of annoying bug

would produce a patch bump.

Note

Please keep in mind that changelog would be generated by conventional-changelog which ignores some types by design (i.e. docs, test and others).

Skipping commit

In some cases, your release process relies only on tags and you don't want a new commit with version bumps and changelog updates to be made. To achieve this, you can provide the --skipCommit flag and changes made by the library would stay in the index without committing. The tag for the new version would be put on the last existing commit.

Triggering executors post-release

The --postTargets option allows you to run targets post-release. This is particularly handful for publishing packages on a registry or scheduling any other task.

Here is a configuration example using @jscutlery/semver:github to create a GitHub Release and ngx-deploy-npm:deploy to publish on NPM:

{
  "targets": {
    "build": {
      /* ... */
    },
    "version": {
      "executor": "@jscutlery/semver:version",
      "options": {
        "push": true,
        "postTargets": ["build", "npm", "github"]
      }
    },
    "github": {
      "executor": "@jscutlery/semver:github",
      "options": {
        "tag": "{tag}",
        "notes": "{notes}"
      }
    },
    "npm": {
      "executor": "ngx-deploy-npm:deploy",
      "options": {
        "access": "public",
        "distFolderPath": "dist/packages/my-package"
      }
    }
  }
}

Contextual variables resolved by this option:

  • projectName versioned project name
  • version semver version
  • tag formatted git tag
  • notes release notes
  • previousTag previous version tag
  • dryRun dry run mode

Note

The specified targets are going to be executed as is, without triggering any dependencies. It will not trigger the target's dependsOn and Nx caching is not considered

Built-in post-targets

Tracking dependencies

The --trackDeps option indicates that direct dependencies in the project's dependency graph should be taken into account when incrementing the version. If no version-incrementing changes are present in the project but are present in one or more dependencies, then the project will receive a patch version increment.

If you wish to track changes at any depth of your dependency graph, then you should do the following:

  1. Enable versioning for each project in the dependency graph
  2. Set the trackDeps option to true on each of the projects
  3. Make sure that version is run on projects in the right order by configuring version's target dependencies in nx.json:
{
  "targetDefaults": {
    "version": {
      "dependsOn": ["^version"]
    }
  }
}

This setup will cause a cascade of version increments starting at the deepest changed dependency, then continuing up the graph until the indicated project is reached. Additionally, if used in conjunction with nx run-many --all, or nx affected, then it will avoid attempting to version dependencies multiple times.

Warning

Be aware that this feature has known limitations.

CI/CD usage

GitHub Actions

Here is an example running semver in a GitHub workflow:

name: release

on:
  - workflow_dispatch

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'
      - name: Setup Git
        run: |
          git config user.name "GitHub Bot"
          git config user.email "gituser@example.com"
      - run: yarn install --frozen-lockfile
      - name: Version
        shell: bash
        run: yarn nx affected --base=last-release --target=version
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Tag last-release
        shell: bash
        run: |
          git tag -f last-release
          git push origin last-release --force

Note that secrets.GITHUB_TOKEN is automatically provided by the GitHub Actions, you don't need to set up anything.

GitLab CI

Here is an example running semver in the GitLab CI:

stages:
  - release

release:
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
      when: manual
  stage: release
  image: node:16.13.2
  before_script:
    - git config --global user.name "GitLab Bot"
    - git config --global user.email "gituser@example.com"
    - git remote set-url origin http://gitlab-ci-token:${DEPLOY_KEY}@gitlab.com/org/project.git
  script:
    - yarn install --frozen-lockfile
    - yarn nx affected --target=version --base=last-release
    - git tag -f last-release
    - git push origin last-release --force -o ci.skip

Note that you might need to configure a deploy key in order to push to your remote repository.

Nx Release migration

If you want to migrate to Nx Release, run the following command:

nx g @jscutlery/semver:migrate-nx-release

By executing this generator, the existing @jscutlery/semver configuration will be removed, and Nx Release will be appropriately configured for your projects.

Note

The migration process does not currently support the sync mode. Complex or highly customized configurations may require additional manual adjustments after running the migration generator. After running this generator, you will need to adjust any custom scripts or CI workflows related to versioning and releases to align with the new Nx release workflow.

For more details on using Nx Release, refer to the official Nx documentation.

Compatibility overview with Nx

Version Required Package
v5.0.0 @nx/devkit ^18.0.0
v4.0.0 @nx/devkit ^17.0.0
v3.0.0 @nx/devkit ^16.0.0
v2.28.0 @nrwl/devkit ^15.0.0
v2.23.0 @nrwl/devkit ^14.0.0
v2.12.0 @nrwl/workspace ^13.0.0
v2.4.0 @nrwl/workspace ^12.0.0
v1.0.0 @nrwl/workspace ^11.0.0

Changelog

For new features or breaking changes see the changelog.

Contributors

This project follows the all-contributors specification.

Younes Jaaidi
Younes Jaaidi

πŸ› πŸ’» πŸ“– πŸ’‘ πŸ€”
Edouard Bozon
Edouard Bozon

πŸ› πŸ’» πŸ“– πŸ’‘ πŸ€”
Gleb Mikheev
Gleb Mikheev

πŸ€”
Richard Lea
Richard Lea

πŸ’»
Katona
Katona

πŸ› πŸ’»
ntziolis
ntziolis

πŸ›
RicardoJBarrios
RicardoJBarrios

πŸ’» πŸ€”
Sylvain Arnouts
Sylvain Arnouts

πŸ›
GethsLeader
GethsLeader

πŸ’» πŸ€”
Shahar Kazaz
Shahar Kazaz

πŸ’»
MiloΕ‘ Lajtman
MiloΕ‘ Lajtman

πŸ› πŸ’»
Charley Bodkin
Charley Bodkin

πŸ›
Jeffrey Bosch
Jeffrey Bosch

πŸ’»
RaviTejaVattem
RaviTejaVattem

πŸ’»
Abishek PY
Abishek PY

πŸ’» πŸ“–
Stefan Schneider
Stefan Schneider

πŸ’»
Travis Jones
Travis Jones

πŸ’» πŸ“– πŸ€”
Hichri Hassen
Hichri Hassen

πŸ›
Gareth John
Gareth John

πŸ’»
Diego Juliao
Diego Juliao

πŸ› πŸ’» πŸ€”
Charlie Francis
Charlie Francis

πŸ›
Pierre Huyghe
Pierre Huyghe

πŸ’»
William Sedlacek
William Sedlacek

πŸ’» πŸ€”
Tycho Bokdam
Tycho Bokdam

πŸ€”
nicolashzmor
nicolashzmor

πŸ›
RaΓΊl JuliΓ‘n LΓ³pez CaΓ±a
RaΓΊl JuliΓ‘n LΓ³pez CaΓ±a

πŸ› πŸ’»
Miguel Suarez
Miguel Suarez

πŸ’»
Katya Pavlenko
Katya Pavlenko

πŸ› πŸ’» πŸ€”
Hoon Oh
Hoon Oh

πŸ’» πŸ€”
Kurt Hoyt
Kurt Hoyt

πŸ›
Riain Condon
Riain Condon

πŸ’» πŸ“– πŸ’‘
lukelukes
lukelukes

πŸ›
Ian Luca
Ian Luca

πŸ’» πŸ€”
Matthias Stemmler
Matthias Stemmler

πŸ›
Giora Guttsait
Giora Guttsait

πŸ›
Derek Burgman
Derek Burgman

πŸ› πŸ’»
James
James

πŸ› πŸ’»
ndrsg
ndrsg

πŸ’» πŸ€” πŸ›
Fabian Schneider
Fabian Schneider

πŸ› πŸ’»
JD
JD

πŸ“–
Daniel Beck
Daniel Beck

πŸ’» πŸ“–
Florian Guitton
Florian Guitton

πŸ’»
Sam Yong
Sam Yong

πŸ› πŸ’»
Jamie Thompson
Jamie Thompson

πŸ›
Michael Be
Michael Be

πŸ“–

License

This project is MIT licensed.

About

Nx plugin to automate semantic versioning and CHANGELOG generation.

License:MIT License


Languages

Language:TypeScript 99.3%Language:JavaScript 0.5%Language:Shell 0.2%