What is the Conventional Commits format?

Conventional Commits structure a message as type(scope): subject, for example feat(api): add pagination. The type and optional scope make history machine-readable so tools can auto-generate changelogs and decide semver bumps.

What do the numbers in a rule like [2, always, ...] mean?

The first number is severity: 0 disables the rule, 1 warns, and 2 errors. The second value, always or never, sets whether the condition must hold or must not. The third is the rule's argument, such as the list of allowed types.

How do I require a scope on every commit?

Enable the require-a-scope option, which adds scope-empty set to [2, never]. With it on, a message like feat: add thing is rejected and you must write feat(api): add thing with a scope in parentheses.

Why limit the header length?

The header-max-length rule keeps the first line short so it reads well in git log, GitHub, and changelogs, which truncate long subjects. The common limit is 72 characters, matching git's own conventions for readable history.

Do I still need config-conventional if I add custom rules?

Yes. The generated file extends @commitlint/config-conventional, which supplies the baseline parser and standard rules. Your custom rules layer on top, overriding only the specific behaviors you set rather than replacing the whole ruleset.

commitlint.config.js Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Enforce clean commit messages

Consistent commit messages make history searchable, power automatic changelogs, and let tools like semantic-release decide version bumps. commitlint checks each message against a ruleset, and this builder generates a commitlint.config.js that extends the conventional preset with your own type list, scope rules, and length limits.

How it works

The config exports an object that extends @commitlint/config-conventional, giving you the standard Conventional Commits parser and defaults. Your custom rules then refine that baseline. Each rule is a tuple [level, applicability, value]: the level is 2 for error, 1 for warning, or 0 to disable; applicability is always or never; the value is the rule’s argument.

type-enum restricts the allowed types — feat, fix, docs, and so on. scope-enum optionally limits scopes to a fixed list, and scope-empty set to never makes a scope mandatory. subject-case enforces casing, subject-empty requires a subject, and subject-full-stop forbids a trailing period. header-max-length and body-max-line-length cap line lengths so messages stay readable in git tooling.

A message like feat(api): add pagination to search endpoint passes; Added stuff. fails on type, case, and full-stop rules.

Tips and notes

Wire this config to a Husky commit-msg hook so it runs on every commit.
Keep header-max-length at 72 to match git log conventions.
Leave scopes empty to allow any scope, or list them to standardize across a team.
Run commitlint in CI too, since local hooks can be bypassed with --no-verify.