Skip to content

Commitlint configuration to enforce commit message best practices on public projects

Notifications You must be signed in to change notification settings

logdna/commitlint-config

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

commitlint-config

Commitlint Configuration to enforce commit message best practices on public repositories

Installation

$ npm install commitlint @logdna/commitlint-config

Usage

To enable commit linting, you need two things in package.json

  1. npm script exposing commitlint
  2. commitlint configuration that extends the logdna base configuration Adding a script to expose commitlint in the package.json scripts. Below is an example of linting all commits on the active branch that have not been merged into main
"commitlint": {
  "extends": "@logdna/commitlint-config"
},
"scripts": {
  "commitlint": "commitlint --from=origin/main --to=HEAD",
  "pretest": "npm run commitlint"
}

Command Line Tool

This package may additionally be installed globally as a command lint tool (commitlint-mezmo)

$ npm install -g @logdna/commitlint-config
$ commitlint-mezmo <options>

or executed immediately with npx

$ npx @logdna/commitlint-config -f origin/master

OPTIONS

  -h, --help                 show help and usage
  -v, --version              show version
  -f, --from [origin/main]   the git ref where linting should begin
  -t, --to [HEAD]            the git ref where linting should end
  -p, --pwd <path>           set the root directory
  --config <path>            path to an alternate commitlint config module

Commit Format

Commit message should follow the Conventional Commit Standard, and be be written in imperative form.

  • A proper title - This summarizes what was done in the commit
  • A descriptive commit body. This says WHY the change was made in addition to what it was. A blank line should start and end the commit body.
  • BREAKING CHANGE: (case-sensitive) in the footer to indicate a major change
  • Break lines of text at 72 columns. This is for readability.
  • Fixes: tag at the bottom of the body to associate the changes with an open issue

Example:

fix(test): Add tests for component XYZ

The component for XYZ was missing a test which resulted in a
production bug.  There was an unchecked reference that caused
a `TypeError`.  This change adds the reference fix and a
corresponding test.

Fixes: #35

Valid Types

The first bit of the commit message is the type, which has a finite list of acceptable values:

  • build
  • ci
  • chore
  • doc
  • feat
  • fix
  • lib
  • perf
  • refactor
  • style
  • test

The scope is required, but is not validated.

Example:

pkg(initial): The first commit of this package

This is the initial commit for the project scaffolding and code.

Fixes: #1

Ignored Commits

There are certain commits formats that will be ingored by the linter. These tend to be commits that are generated by known tools we use or commits that we have determined should not be linted in the sake of developer performance.

  • Commits generated by depenency managers (dependabot / renovate)
  • Commits generated by secerity tools (snyk)
  • Commits generated by versioning and release tools (versioner, semantic-release)
  • Commits that are titled doc(wiki)
  • Commits that are titled wip:
  • Dependency commits, chore(deps):, that are non-breaking

Examples:

Documentation commit only:

doc(wiki): Adding additional clarifying documentation

Adding some additional documentation that should make using this
more obvious to the casual contributor

Commits denoting something is still a work in progress

wip: this will be ignored

A minor or patch dependency update

chore(deps): Bump some-package@1.2.3

Authors

About

Commitlint configuration to enforce commit message best practices on public projects

Resources

Stars

Watchers

Forks

Packages

No packages published