@semantic-release/commit-analyzer

What is @semantic-release/commit-analyzer?

The @semantic-release/commit-analyzer npm package is a plugin for the semantic-release ecosystem that analyzes commits to determine the type of version bump (if any) that should be applied according to semantic versioning principles. It uses commit messages to figure out the next semantic version based on the changes made.

What are @semantic-release/commit-analyzer's main functionalities?

Analyze Commits

This feature analyzes an array of commit messages and determines the type of version bump needed. In the code sample, a commit message is analyzed, and the callback function logs the release type, which in this case is 'patch'.

const analyzeCommits = require('@semantic-release/commit-analyzer');

analyzeCommits({}, {commits: [{message: 'fix(pencil): stop graphite breaking when too much pressure applied'}]}, (err, type) => {
  console.log(type); // prints 'patch'
});

Configuration

This feature allows users to configure the commit analyzer by specifying custom release rules and parser options. The code sample shows a configuration object that defines custom rules for determining the release type based on commit types and scopes.

{
  "releaseRules": [
    {"type": "feat", "release": "minor"},
    {"type": "fix", "release": "patch"},
    {"type": "perf", "release": "patch"},
    {"scope": "no-release", "release": false}
  ],
  "parserOpts": {
    "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES"]
  }
}

Other packages similar to @semantic-release/commit-analyzer

conventional-changelog

Conventional Changelog is a set of tools for parsing conventional commit messages. It's similar to @semantic-release/commit-analyzer in that it can be used to determine version bumps and generate changelogs, but it provides a more comprehensive set of tools for generating changelogs from git metadata.

commitlint

Commitlint checks if your commit messages meet the conventional commit format. While it doesn't directly analyze commits to determine version bumps, it ensures that commit messages are formatted in a way that tools like @semantic-release/commit-analyzer can accurately analyze them.

standard-version

Standard Version is a utility for versioning using semver and CHANGELOG generation powered by Conventional Commits. It automates the versioning and changelog process but does not provide the same plugin-based architecture as @semantic-release/commit-analyzer.

README

commit-analyzer

Customizable commit-analyzer plugin for semantic-release based on conventional-changelog

Options

By default commit-analyzer uses the angular format described in Angular convention.

Additionnal options can be set within the plugin definition in package.json to use a different commit format and to customize it:

{
  "release": {
    "analyzeCommits": {
      "preset": "angular",
      "releaseRules": [
        {"type": "docs", "scope":"README", "release": "patch"},
        {"type": "refactor", "release": "patch"},
        {"type": "style", "release": "patch"}
      ],
      "parserOpts": {
        "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES", "BREAKING"]
      }
    }
  }
}

Option	Description	Default
preset	conventional-changelog preset (possible values: angular, atom, codemirror, ember, eslint, express, jquery, jscs, jshint).	angular
config	NPM package name of a custom conventional-changelog preset.	-
releaseRules	An external module, a path to a module or an Array of rules. See Release rules.	See Release rules
parserOpts	Additional conventional-commits-parser options that will extends ones loaded by preset or config. See Parser options.	-

NOTE: config will be overwritten by the values of preset. You should use either preset or config, but not both. Individual properties of parserOpts will overwrite ones loaded with preset or config.

Release Rules

Rules definition

This is an Array of rule objects. A rule object has a release property and 1 or more criteria.

{
  "release": {
    "analyzeCommits": {
      "preset": "angular",
      "releaseRules": [
        {"type": "docs", "scope": "README", "release": "patch"},
        {"type": "refactor", "scope": "/core-.*/", "release": "minor"},
        {"type": "refactor", "release": "patch"}
      ]
    }
  }
}

Rules matching

Each commit will be compared with each rule and when it matches, the commit will be associated with the release type in the rule's release property. If a commit match multiple rules, the highest release type (major > minor > patch) is associated with the commit.

See release types for the release types hierarchy.

With the previous example:

• Commits with type 'docs' and scope 'README' will be associated with a patch release.
• Commits with type 'refactor' and scope starting with 'core-' (i.e. 'core-ui', 'core-rules', ...) will be associated with a minor release.
• Other commits with type 'refactor' (without scope or with a scope not matching the regexp /core-.*/) will be associated with a patch release.

Default rules matching

If a commit doesn't match any rule in releaseRules it will be evaluated agaisnt the default release rules.

With the previous example:

• Commits with a breaking change will be associated with a minor release.
• Commits with type 'feat' will be associated with a minor release.
• Commits with type 'fix' will be associated with a patch release.
• Commits with type 'perf' will be associated with a patch release.

No rules matching

If a commit doesn't match any rules in releaseRules or in default release rules then no release type will be associated with the commit.

With the previous example:

• Commits with type 'style' will not be associated with a release type.
• Commits with type 'test' will not be associated with a release type.
• Commits with type 'chore' will not be associated with a release type.

Multiple commits

If there is multiple commits that match one or more rules, the one with the highest realease type will determine the global release type.

Considering the following commits:

• docs(README): Add more details to the API docs
• feat(API): Add a new method to the public API

With the previous example the release type determine by the plugin will be minor.

Specific commit properties

The properties to set in the rules will depends on the commit style choosen. For example conventional-changelog-angular use the commit properties type, scope and subject but conventional-changelog-eslint uses tag and message.

For example with eslint preset:

{
  "release": {
    "analyzeCommits": {
      "preset": "eslint",
      "releaseRules": [
        {"tag": "Docs", "message":"/README/", "release": "patch"},
        {"type": "New", "release": "patch"}
      ]
    }
  }
}

With this configuration:

• Commits with tag 'Docs', that contains 'README' in their header message will be associated with a patch release.
• Commits with tag 'New' will be associated with a patch release.
• Commits with tag 'Breaking' will be associated with a major release (per default release rules).
• Commits with tag 'Fix' will be associated with a patch release (per default release rules).
• Commits with tag 'Update' will be associated with a minor release (per default release rules).
• Commits with tag 'New' will be associated with a minor release (per default release rules).
• All other commits will not be associated with a release type.

External package / file

releaseRules can also reference a module, either by it's npm name or path:

{
  "release": {
    "analyzeCommits": {
      "preset": "angular",
      "releaseRules": "./config/release-rules.js"
    }
  }
}

// File: config/release-rules.js
module.exports = [
  {type: 'docs', scope: 'README', release: 'patch'},
  {type: 'refactor', scope: /core-.*/, release: 'minor'},
  {type: 'refactor', release: 'patch'},
];

Parser Options

Allow to overwrite specific conventional-commits-parser options. This is convenient to use a conventional-changelog preset with some customizations without having to create a new module.

The following example uses Angular convention but will consider a commit to be a breaking change if it's body contains BREAKING CHANGE, BREAKING CHANGES or BREAKING. By default the preset checks only for BREAKING CHANGE and BREAKING CHANGES.

{
  "release": {
    "analyzeCommits": {
      "preset": "angular",
      "parserOpts": {
        "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES", "BREAKING"],
      }
    }
  }
}