@avolantis/commitlint-config

Shared commitlint configuration for Avolantis commit conventions

Install

pnpm add -D commitlint husky @avolantis/commitlint-config
pnpm husky install

If using workspaces, install at workspace root with -WD.

Then add or modify the .husky/commit-msg file with the following content:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

pnpm commit-msg -- --edit "$1"

Then add a prepare (preinstall) and a commit-msg script to your package.json (at workspace root):

{
  "scrips": {
    "commit-msg": "commitlint -x @avolantis/commitlint-config",
    "prepare": "huksy install"
  }
}

Rules

General format of commit messages:

type(scope)!: subject (reference)

body

footer

• Providing a type in lowercase is mandatory
• A scope must be enclosed in () but is optional and depends on project-level conventions
• The type and scope might be followed by ! to indicate breaking changes
• The subject is the "title" of the commit, which must not be cased sentence-like and must not be terminated by .
• The subject must follow the type and scope after a colon (:) and a single space
• Ticket references are required when there is a related ticket and must follow the subject
• Each ticket reference must be enclosed in () individually, multiple refs are separated by a single space
• The header (type+scope+subject+references) must not be longer than 100 characters
• The body is optional and may span multiple paragraphs but none of its lines can be longer than 100 characters, if present
• The body can also contain a markdown-formatted short list of additional changes or details
• The body can also contain longer explanation of the changes, in sentences
• The body must not contain git squash-like messages (use fixup)
• The footer is optional, but none of its lines can be longer than 100 characters, if present
• The footer can indicate BREAKING CHANGES: in addition to the ! following the type and scope

Commit types

| Type | Description | Use when | | ---------- | ------------------------ | ----------------------------------------------- | | cr | Change requests | customers requested changes in behavior | | feat | New features | new functionality is added | | fix | Bug fixes | a bug in the main code is fixed | | perf | Performance improvements | changes only affect performance | | build | Build ecosystem | the build pipeline or a dependency is changed | | chore | Other | repository settings or the tooling is changed | | ci | Continuous integration | CI or CD settings have been changed | | docs | Project documentation | changes only affect documentation | | style | Styling and design | changes only affect styling or design | | refactor | Code refactoring | changes do not change the meaning of the code | | revert | Commit reverts | only for git commit reverts (in whole) | | test | Test related | changes to automated test suites or pipelines | | wip | Work in progress | the commit is not yet considered final |

Examples

Without scoping:

feat: paypal payment gateway integration (#69)

With scoping enabled:

perf(parser): refactor the tokenizer to have smaller time complexity