1.1.1 • Published 4 years ago

@episerver/commitlint-config v1.1.1

Weekly downloads
1
License
MIT
Repository
github
Last release
4 years ago

@episerver/commitlint-config

Shareable commitlint config enforcing the Episerver commit convention.

Installation

yarn

yarn add --dev @commitlint/cli @episerver/commitlint-config

npm

npm install --save-dev @commitlint/cli @episerver/commitlint-config

Usage

Configure commitlint to use the episerver configuration via a commitlint.config.js file or a commitlint field in package.json.

commitlint.config.js

module.exports = {
    extends: ['@episerver']
};

package.json

"commitlint": {
    "extends": ["@episerver"]
}

Commit Message Format

Commits should adhere to the following format:

<type>(<scope>): <subject>

<body>

<footer>

<references>

The following rules apply to the above format:

  1. A commit message consists of a header, body, footer, and references.
  2. The header is the only mandatory part of the commit message.
  3. The header must have a type and a subject; scope is optional.
  4. Scope should be surrounded by parenthesis; otherwise they are omitted.
  5. The type and scope should be lower case.
  6. The subject and body should be sentence case.
  7. The subject should not end with a dot.
  8. The header line is limited to 72 characters.
  9. Any other line should be wrapped at 100 characters.

Types

Must be one of the following:

TypeDescription
choreBuild process or auxiliary tool changes
docsDocumentation only changes
featA new feature
fixA bug fix
refactorA code change that neither fixes a bug or adds a feature
releaseCreate a release commit
revertRevert a previous commit
testAdd missing tests

Revert

If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Footer

The footer should only contain information about breaking changes and should use the following format:

BREAKING CHANGE: <description>

The description should be a concise explanation of the breaking change. The body can be omitted if the breaking change description and subject give enough information to understand the commit.