@theunderscorer/nx-semantic-release

nx plugin for automated releases, powered by semantic-release

How it works

Under the hood, it uses project graph from nx to analyze commits for every configured project and filters out these commits that doesn't affect given project or it's dependencies.

Installation

Run:

npm install -D @theunderscorer/nx-semantic-release
nx g @theunderscorer/nx-semantic-release:install

For now this package supports only Independent versioning mode, synced mode is planned to be added soon.

Usage

In order to release your projects, add this executor to your configuration file (ex. project.json), bare minimal configuration looks like this:

{
  "semantic-release": {
    "executor": "@theunderscorer/nx-semantic-release:semantic-release"
  }
}

Hint: You can also use our generator nx g @theunderscorer/nx-semantic-release:setup-project $PROJECT_NAME to generate this configuration.

After running this, the executor will do the following:

Filter commits retrieved by semantic-release in order to find only these that affects selected project or it's dependencies.
Perform semantic-release using following plugins (in this order:)
- @semantic-release/commit-analyzer
- @semantic-release/release-notes-generator
- @semantic-release/changelog
- @semantic-release/npm
- @semantic-release/git
- @semantic-release/github
The result will be a fully versioned project. If you are releasing it as npm package, the package will be built, version in package.json will be updated and package itself will be published.

Configuration

Options can be configured in 3 ways:

cli: Passing them on the cli command
config file: Including them in a global nxrelease config file in the root of your monorepo (see below)
project: Within the options section of the executor for each project (project.json)

Multiple configurations are fully supported, allowing for global configuration options in the config file and then project specific overrides in the project.json. Options merged in the following order of precedence:

cli flags > project > config file > defaults

Note: Object/Array type options are shallowly merged. For example, if gitAssets is set in both the config file and the project options, the whole of the project options version will be used and the config file option will be discarded.

Configuration file

nx-semantic-release's options can be set globally via either:

a nxrelease key in the project's package.json file
a .nxreleaserc file, written in YAML or JSON, with optional extensions: .yaml/.yml/.json/.js
a nxrelease.config.js file that exports an object

The following examples are all the same.

Via nxrelease key in the monorepo package.json file:

{
  "nxrelease": {
    "repositoryUrl": "https://github.com/TheUnderScorer/nx-semantic-release"
  }
}

Via .nxreleaserc YAML file:

---
repositoryUrl: 'https://github.com/TheUnderScorer/nx-semantic-release'

Via nxrelease.config.js file:

module.exports = {
  repositoryUrl: 'https://github.com/TheUnderScorer/nx-semantic-release',
};

Via CLI arguments:

$ nx semantic-release app-c --repositoryUrl "https://github.com/TheUnderScorer/nx-semantic-release"

Available Options

name	type	default	required	description
dryRun	boolean	false	no	See what commands would be run, without committing to git or updating files
ci	boolean	true	no	Set to false to skip CI checks.
changelog	boolean	true	no	Whether to generate changelog.
changelogFile	string	${PROJECT_DIR}/CHANGELOG.md	yes	Path to changelog file.
repositoryUrl	string	repositoryUrl	no	The URL of the repository to release from.
tagFormat	string	${PROJECT_NAME}-v${version}	no	Tag format to use. You can refer to semantic-release configuration
npm	boolean	true	no	Whether to bump package.json version and publish to registry (if package is public).
git	boolean	true	no	Whether to create git commit representing the new version. Setting to false disables the @semantic-release/git plugin.
github	boolean	true	no	Whether to create github release.
githubOptions	object	{}	no	Options for @semantic-release/github plugin
buildTarget	string		no	The target of the build command. If your package is public and you want to release it to npm as part of release, you have to provide it. Plugin will use it to build your package and set version in package.json before releasing it to npm registry.
outputPath	string	${WORKSPACE_DIR}/<`outputPath` from `options` of the specified `buildTarget`>	no	The path to the output directory. Provide that if your package is public and you want to publish it into npm.
commitMessage	string	chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}	no	The commit message to use when committing the release. You can refer to @semantic-release/git.
gitAssets	string[]		no	Path to additional assets that will be commited to git with current release.
plugins	PluginSpec[]		no	Additional plugins for semantic-release. Note: these plugins will be added before @semantic-release/git, which means that you can assets generated by them to git as well. Supports the same format as semantic-release
branches	BranchSpec[]		no	Branches configuration for workflow release. Supports the same format as semantic-release
packageJsonDir	string	${PROJECT_DIR}	no	Path to package.json file (usable only if npm is true). Note: it should point to directory in which package.json can be found, not to file itself.
parserOpts	object		no	Parser options used by commit-analyzer and @semantic-release/release-notes-generator and @semantic-release/changelog
writerOpts	object		no	Writer options used by commit-analyzer and @semantic-release/release-notes-generator
linkCompare	boolean	true	no	Whether to include a link to compare changes since previous release in the release note.
linkReferences	boolean	true	no	Whether to include a link to issues and commits in the release note.
releaseRules	string or object[]		no	Release rules are used when deciding if the commits since the last release warrant a new release. Supports the same format as @semantic-release/commit-analyzer

Available Tokens

Token	Expands into
${RELATIVE_PROJECT_DIR}	Resolves to the current project relative directory within the current workspace (ex. `apps/app-a`)
${PROJECT_DIR}	Resolves to the current project directory (ex. `/Users/theunderscorer/nx-monorepo/apps/app-a`)
${PROJECT_NAME}	Resolves to the current project name (ex. `app-a`)
${WORKSPACE_DIR}	Resolves to the current workspace directory (ex. `/Users/theunderscorer/nx-monorepo`)

Every available option support tokens - this included nested objects and arrays.

You may see other tokens like ${nextRelease.version}, those are tokens that are replaced by semantic-release itself.

^*: The replacement of tokens in plugins only occurs for plugins which are specified with options, using semantic-release's syntax For example:
plugins: [
            '@fake/plugin-without-options1', 
            [
              '@semantic-release/exec',
              {
                prepareCmd: 'cp LICENSE dist/packages/${PROJECT_NAME} && cp README.md dist/packages/${PROJECT_NAME}',
                execCwd: '${WORKSPACE_DIR}',
                fakeStringArrayOption: ['${WORKSPACE_DIR}/src', '${WORKSPACE_DIR}/dist'],
                fakeBooleanOption: true,
                fakeNumberOption: 10
              }
            ],
            '@fake/plugin-without-options2', 
        ]
In above example, tokens will be replaced only for @semantic-release/exec plugin, and only for its string|string[] options, others will be left untouched.

Build target

By setting buildTarget option plugin will run your build executor as part of the release, which is useful if ex. you want to publish released package to npm registry.

Skipping commits

You can skip commits for given projects using [skip $PROJECT_NAME] in its body. Ex:

  feat: update something

  [skip my-app1]
  [skip my-app2]

During analysis this commit will be skipped for release pipeline for my-app1, my-app2. You can also use [skip all] to skip commit for all projects or one single [skip my-app1, my-app2] to skip commits related to my-app1, my-app2 at once.

Alternatively you can include only particular projects in given commit by using [only $PROJECT_NAME]. Ex:

  feat: update something

  [only my-app1]
  [only my-app2]

During analysis this commit will be included only for release pipeline for my-app, my-app2. You can also use one single [skip my-app1, my-app2] to skip commits related to my-app1, my-app2 at once.

Releasing multiple apps/libraries at once

You can release multiple apps/libraries at once by using nx run-many:

npx nx run-many --target=semantic-release --parallel=false

Note: --parallel=false is required to run tasks sequentially, otherwise nx run-many will run tasks in parallel and semantic-release will fail.

Gitlab support

In order to use this plugin on Gitlab, install @semantic-release/gitlab@9.5.1 (>= 10.0.0 is not supported for now due to ES format) and set the following in your configuration file:

{
  "plugins": [
    "@semantic-release/gitlab"
  ],
  "github": false,
}

CI/CD

Example of GitHub actions workflow:

name: default

on:
  push:
    branches:
      - 'master'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: configure git
        run: |
          git config user.name "${GITHUB_ACTOR}"
          git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"

      - run: npm ci

      - run: npx nx run my-app:semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

README.md

README.md

@theunderscorer/nx-semantic-release

How it works

Installation

Usage

Configuration

Configuration file

Available Options

Available Tokens

Build target

Skipping commits

Releasing multiple apps/libraries at once

Gitlab support

CI/CD

Files

README.md

Latest commit

History

README.md

File metadata and controls

@theunderscorer/nx-semantic-release

How it works

Installation

Usage

Configuration

Configuration file

Available Options

Available Tokens

Build target

Skipping commits

Releasing multiple apps/libraries at once

Gitlab support

CI/CD