Commitlint Configuration
A shareable configuration for Commitlint for projects maintained by the Ethima organization. The configuration is based on the conventional commits configuration, with some minor adjustments as detailed below.
Differences from the config-conventional configuration
More lenient rules regarding long lines in bodies and footers
When referencing URIs in commit messages it is trivial to trigger the
{body,footer}-max-line-length rules. This is a common scenario when
referencing code, commits, etc. on source hosting platforms.
One scenario in which long URIs in a commit message are common are release
commits of the semantic release process. Specifically linking to source commits
for changelog entries, see the initial release of this configuration for an
example. These commits,
assumed to have a header of the form build|chore(release): v<x.y.z>, are
exempt from any checks.
Other long URI references can be included in commit messages by writing them as
Markdown footnotes, e.g. [^1]: <long URI>, [^named-footnote]: <long URI> at
the end of the commit message and referencing them from the body. Most hosting
platforms will render these footnotes with proper links, etc. in various places
in their UI. To support this functionality, this configuration replaces the
{body,footer}-max-line-length rules with the
{body,footer}-max-line-length-with-footnote-exemption rules. Apart from the
exemption, these rules behave the same as the original rules and accept the
same configuration. Both the body- and footer- rules are replaced as some
URIs may trigger the footer detection in the commit message parser,
particularly when a URI includes a #.
Stricter rules on merge and fixup!/squash! commits
The desired workflow for projects using this configuration is to use feature
branches that are continuously rebased on top of (pre)release branches. This
includes the use of fixup! and squash! commits, which should all be rebased
out prior to merging into a (pre)release branch. However, by default, these
types of commits are allowed by the is-ignored
configuration, resulting in merge/pull
requests not being blocked when they should be by Commitlint.
Additionally, the default is-ignored
configuration allows different types of
merge commits which do not align well with the process set out here, e.g.
merging into a feature branch or pulling updates using a merge strategy. All
of these commits should also be rebased out prior to merging into a
(pre)release branch.
The only acceptable commits that are ignored by default are those related to "reverts", which may be used to update/undo conventionally documented changes prior to a release and merge commits that result from merging feature branches into (pre)release branches.