Shareable commitlint config enforcing the episerver commit convention
Last updated 9 months ago by ben_mckernan .
MIT · Repository · Original npm · Tarball · package.json
$ cnpm install @episerver/commitlint-config 
SYNC missed versions from official npm registry.


Shareable commitlint config enforcing the Episerver commit convention.



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


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


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


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


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

Commit Message Format

Commits should adhere to the following format:

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




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.


Must be one of the following:

Type Description
chore Build process or auxiliary tool changes
docs Documentation only changes
feat A new feature
fix A bug fix
refactor A code change that neither fixes a bug or adds a feature
release Create a release commit
revert Revert a previous commit
test Add missing tests


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.


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.

Current Tags

  • 1.1.0                                ...           latest (9 months ago)

2 Versions

  • 1.1.0                                ...           9 months ago
  • 1.0.0                                ...           a year ago
Today 0
This Week 0
This Month 0
Last Day 0
Last Week 0
Last Month 0
Dependencies (0)
Dev Dependencies (0)
Dependents (0)

Copyright 2014 - 2017 © taobao.org |