Shareable configuration for `commitlint` used by Faithlife / Logos Bible Software.
npm install commitlint-config-faithlifeThis is a shared configuration for commitlint used by Faithlife / Logos Bible Software.
This package aims to be dependency-free: there is little to gain from depending on another config and then overriding it with our own customizations, and there are real costs (keeping dependencies up-to-date, properly handling breaking changes, etc.).
The rules in this shared config focus on requiring what is important for tooling and automated versioning. They avoid enforcing stylistic concerns that are not meaningful for automation.
We follow the Conventional Commits specification, and the docs are useful to consult. (The open source @commitlint/config-conventional shared config enforces stylistic preferences beyond the scope of what's in the spec and isn't suitable for our needs.)
> Note: the following is not only a terrible commit message, it's also technically invalid—"type" is not a valid type—but it's a helpful illustration of the format using the token names in context.
``
type(scope): A subject or description.
This is body content.
BREAKING CHANGE: this is a footer.
`
#### type
type is required, must be lowercase, and must be one of the following types:
`
feat
fix
perf
build
chore
ci
docs
refactor
revert
style
test
`
By default, only feat, fix, and perf will trigger a release with release notes.[^1] (BREAKING CHANGE: ... will always trigger a release, regardless of the type.)
[^1]: This is controlled by your project's semantic-release config and is outside the scope of this repo.
#### scope
scope is required. Sometimes scopes refer to sub-projects within a monorepo; sometimes they refer to feature areas within a single project. Enforcement of specific scope values is outside the _scope_ of this shared config.
#### subject
subject—also called description in the Conventional Commits spec—is required.
There are intentionally no enforced requirements on casing or ending punctuation.
#### body
body—an optional free-form supplementary description accompanying the commit message—must be preceded by one blank line. This is specified in the Conventional Commits spec.
#### footer
footer—may include BREAKING CHANGE: or Co-authored-by:` or other supplemental footer information—must be preceded by one blank line. This is specified in the Conventional Commits spec.