/commitlint

📓 Lint commit messages

Primary LanguageTypeScriptMIT LicenseMIT

Lint commit messages

Demo generated with svg-term-cli

cat docs/assets/commitlint.json | svg-term --out docs/assets/commitlint.svg --frame --profile=Seti --height=20 --width=80

npm latest CircleCI

  • 🚓 Be a good commitizen
  • 📦 Share configuration via npm
  • 🤖 Tap into conventional-changelog

Contents


What is commitlint

commitlint checks if your commit messages meet the conventional commit format.

In general the pattern mostly looks like this:

type(scope?): subject  #scope is optional; multiple scopes are supported (current delimiter options: "/", "\" and ",")

Real world examples can look like this:

chore: run tests on travis ci
fix(server): send cors headers
feat(blog): add comment section

Common types according to commitlint-config-conventional (based on the Angular convention) can be:

  • build
  • ci
  • chore
  • docs
  • feat
  • fix
  • perf
  • refactor
  • revert
  • style
  • test

These can be modified by your own configuration.

Benefits using commitlint

Getting started

# Install commitlint cli and conventional config
npm install --save-dev @commitlint/{config-conventional,cli}
# For Windows:
npm install --save-dev @commitlint/config-conventional @commitlint/cli

# Configure commitlint to use conventional config
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

To lint commits before they are created you can use Husky's commit-msg hook:

# Install Husky v6
npm install husky --save-dev
# or
yarn add husky --dev

# Activate hooks
npx husky install
# or
yarn husky install

# Add hook
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

Check the husky documentation on how you can automatically have Git hooks enabled after install for different yarn versions.

Detailed Setup instructions

CLI

  • Primary way to interact with commitlint.
  • npm install --save-dev @commitlint/cli
  • Packages: cli

Config

  • Configuration is picked up from commitlint.config.js, .commitlintrc.js, .commitlintrc.json, or .commitlintrc.yml file or a commitlint field in package.json
  • Packages: cli, core
  • See Rules for a complete list of possible rules
  • An example configuration can be found at @commitlint/config-conventional

Shared configuration

A number of shared configurations are available to install and use with commitlint:

⚠️ If you want to publish your own shareable config then make sure it has a name aligning with the pattern commitlint-config-emoji-log or commitlint-config-your-config-name — then in extend all you have to write is emoji-log or your-config-name.

API

  • Alternative, programmatic way to interact with commitlint
  • Packages:
    • format - Format commitlint reports
    • lint - Lint a string against commitlint rules
    • load - Load shared commitlint configuration
    • read - Read commit messages from a specified range or last edit
  • See API for a complete list of methods and examples

Tools

Roadmap

Ideas: conventional-changelog/commitlint#94

commitlint is considered stable and is used in various projects as development tool.

We identify ease of adoption and developer experience as fields where there is room and need for improvement. The items on the roadmap should enhance commitlint regarding those aspects.

Version Support

  • Node.js LTS >= 10.21.0
  • git >= 2.13.2

Related projects

License

Copyright by @marionebl. All commitlint packages are released under the MIT license.

Development

commitlint is developed in a mono repository.

Install and run

git clone git@github.com:conventional-changelog/commitlint.git
cd commitlint
yarn
yarn run build # run build tasks
yarn start # run tests, again on change

For more information on how to contribute please take a look at our contribution guide.

Package dependency overview

commitlint-dependencies

Publishing a release

Before publishing a release do a yarn run publish --dry-run to get the upcoming version and update the version in the should print help test.
Commit that change before creating the new version without --dry-run.

npm login
yarn clean
yarn install
yarn run build
yarn test
yarn run publish --otp <one-time password>

Publish a next release

npm login
yarn clean
yarn install
yarn run build
yarn test
npx lerna publish --conventional-commits --dist-tag next --otp <one-time password>

If for some reason this stops in between, you can manually publish missing packages like this:

npm publish <package-name> --tag next --otp <one-time password>
Move next to latest
npm login
npx lerna exec --no-bail --no-private --no-sort --stream -- '[ -n "$(npm v . dist-tags.next)" ] && npm dist-tag add ${LERNA_PACKAGE_NAME}@$(npm v . dist-tags.next) latest --otp <one-time password>'

Remove next:

npx lerna exec --no-bail --no-private --no-sort --stream -- '[ -n "$(npm v . dist-tags.next)" ] && npm dist-tag rm ${LERNA_PACKAGE_NAME} next --otp <one-time password>'