@theholocron/commitlint-config NPM

CommitLint Config

A CommitLint configuration for writing properly formatted Git commits within the Galaxy.

Installation

npm install --save-dev @theholocron/commitlint-config

Usage

In your project package.json add the following:

{
  "commitlint": {
    "extends": "@theholocron"
  }
}

How We Write Commits

Problems

The following rules are considered problems for @theholocron/commitlint-config and will yield a non-zero exit code when not met.

Consult docs/rules for a list of available rules.

type-enum

condition: type is found in value
rule: always

value

[
  'build',
  'ci',
  'chore',
  'docs',
  'feat',
  'fix',
  'perf',
  'refactor',
  'revert',
  'style',
  'test'
]

echo "foo: some message" # fails
echo "fix: some message" # passes

type-case

description: type is in case value
rule: always
value
```
  'lowerCase'
```

echo "FIX: some message" # fails
echo "fix: some message" # passes

type-empty

condition: type is empty
rule: never

echo ": some message" # fails
echo "fix: some message" # passes

scope-case

condition: scope is in case value
rule: always

  'lowerCase'

echo "fix(SCOPE): some message" # fails
echo "fix(scope): some message" # passes

subject-case

condition: subject is in one of the cases ['sentence-case', 'start-case', 'pascal-case', 'upper-case']
rule: never

echo "fix(SCOPE): Some message" # fails
echo "fix(SCOPE): Some Message" # fails
echo "fix(SCOPE): SomeMessage" # fails
echo "fix(SCOPE): SOMEMESSAGE" # fails
echo "fix(scope): some message" # passes
echo "fix(scope): some Message" # passes

subject-empty

condition: subject is empty
rule: never

echo "fix:" # fails
echo "fix: some message" # passes

subject-full-stop

condition: subject ends with value
rule: never
value

'.'

echo "fix: some message." # fails
echo "fix: some message" # passes

header-max-length

condition: header has value or less characters
rule: always
value

echo "fix: some message that is way too long and breaks the line max-length by several characters" # fails
echo "fix: some message" # passes

How We Track Changes

This project uses a CHANGELOG and GitHub releases which contains a curated, chronologically ordered list of notable changes for each version of a project. Read more about changelogs.

How We Version

We use SemVer for its versioning providing us an opt-in approach to releases. This means we add a version number according to the spec, as you see below. So rather than force developers to consume the latest and greatest, they can choose which version to consume and test any newer ones before upgrading. Please the read the spec as it goes into further detail.

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes.
MINOR version when you add functionality in a backward-compatible manner.
PATCH version when you make backward-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

How to Contribute

Have a bug or a feature request? Looking to contribute to advance the project? Read our contribution guide or maintenance guide first in order to understand how we do things around here. Or you could look at some of our other guides below: