@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