npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@semantic-release/commit-analyzer

v12.0.0

Published

semantic-release plugin to analyze commits with conventional-changelog

Downloads

5,176,137

Readme

commit-analyzer

semantic-release plugin to analyze commits with conventional-changelog

Build Status npm latest version npm next version npm beta version

| Step | Description | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | analyzeCommits | Determine the type of release by analyzing commits with conventional-changelog. |

Install

$ npm install @semantic-release/commit-analyzer -D

Usage

The plugin can be configured in the semantic-release configuration file:

{
  "plugins": [
    [
      "@semantic-release/commit-analyzer",
      {
        "preset": "angular",
        "releaseRules": [
          { "type": "docs", "scope": "README", "release": "patch" },
          { "type": "refactor", "release": "patch" },
          { "type": "style", "release": "patch" }
        ],
        "parserOpts": {
          "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES"]
        }
      }
    ],
    "@semantic-release/release-notes-generator"
  ]
}

With this example:

  • the commits that contains BREAKING CHANGE or BREAKING CHANGES in their body will be considered breaking changes.
  • the commits with a 'docs' type, a 'README' scope will be associated with a patch release
  • the commits with a 'refactor' type will be associated with a patch release
  • the commits with a 'style' type will be associated with a patch release

Note: Your commits must be formatted exactly as specified by the chosen convention. For example the Angular Commit Message Conventions require the BREAKING CHANGE keyword to be followed by a colon (:) and to be in the footer of the commit message.

Configuration

Options

| Option | Description | Default | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | preset | conventional-changelog preset (possible values: angular, atom, codemirror, ember, eslint, express, jquery, jshint, conventionalcommits). | angular | | config | npm package name of a custom conventional-changelog preset. | - | | parserOpts | Additional conventional-commits-parser options that will extends the ones loaded by preset or config. This is convenient to use a conventional-changelog preset with some customizations without having to create a new module. | - | | releaseRules | An external module, a path to a module or an Array of rules. See releaseRules. | See releaseRules | | presetConfig | Additional configuration passed to the conventional-changelog preset. Used for example with conventional-changelog-conventionalcommits. | - |

Notes: in order to use a preset it must be installed (for example to use the eslint preset you must install it with npm install conventional-changelog-eslint -D)

Note: config will be overwritten by the values of preset. You should use either preset or config, but not both.

Note: Individual properties of parserOpts will override ones loaded with an explicitly set preset or config. If preset or config are not set, only the properties set in parserOpts will be used.

Note: For presets that expects a configuration object, such as conventionalcommits, the presetConfig option must be set.

releaseRules

Release rules are used when deciding if the commits since the last release warrant a new release. If you define custom release rules the default rules will be used if nothing matched. Those rules will be matched against the commit objects resulting of conventional-commits-parser parsing. Each rule property can be defined as a glob.

Rules definition

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

{
  "plugins": [
    [
      "@semantic-release/commit-analyzer",
      {
        "preset": "angular",
        "releaseRules": [
          { "type": "docs", "scope": "README", "release": "patch" },
          { "type": "refactor", "scope": "core-*", "release": "minor" },
          { "type": "refactor", "release": "patch" },
          { "scope": "no-release", "release": false }
        ]
      }
    ],
    "@semantic-release/release-notes-generator"
  ]
}
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 glob core-*) will be associated with a patch release.
  • Commits with scope no-release will not be associated with a release type.
Default rules matching

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

With the previous example:

  • Commits with a breaking change will be associated with a major 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.
  • Commits with scope no-release will not be associated with a release type even if they have a breaking change or the type 'feat', 'fix' or 'perf'.
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 release 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 determined by the plugin will be minor.

Specific commit properties

The properties to set in the rules will depends on the commit style chosen. 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:

{
  "plugins": [
    [
      "@semantic-release/commit-analyzer",
      {
        "preset": "eslint",
        "releaseRules": [
          { "tag": "Docs", "message": "*README*", "release": "patch" },
          { "tag": "New", "release": "patch" }
        ]
      }
    ],
    "@semantic-release/release-notes-generator"
  ]
}

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).
  • 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:

{
  "plugins": [
    [
      "@semantic-release/commit-analyzer",
      {
        "preset": "angular",
        "releaseRules": "./config/release-rules.cjs"
      }
    ],
    "@semantic-release/release-notes-generator"
  ]
}
// File: config/release-rules.cjs
module.exports = [
  { type: "docs", scope: "README", release: "patch" },
  { type: "refactor", scope: "core-*", release: "minor" },
  { type: "refactor", release: "patch" },
];