What does @commitlint/config-conventional already enforce?

It enforces the Conventional Commits format itself (type(scope): subject), sentence-case/lowercase rules for the subject, a maximum header length, and a broad default list of allowed types (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert). This tool's type-enum rule narrows that default list to only the types your team actually wants to allow.

What's the "2" in [2, "always", [...]] for?

That's the rule's severity level in commitlint's rule-config array: 0 disables the rule, 1 makes it a warning, and 2 makes it an error that fails the commit. Both generated rules use 2 so an invalid type or scope blocks the commit rather than merely warning.

Is scope-enum required, or can commits omit a scope?

This generator omits the scope-enum rule entirely when you don't provide any allowed scopes, leaving scopes unrestricted (and, per config-conventional's own defaults, optional). If you do provide scopes, only those exact scope values become allowed, e.g. `fix(api): ...` passes only if "api" is in your list.

How does this connect to a git hook?

This config alone doesn't run anything, it needs to be read by the `commitlint` CLI, invoked from a Husky commit-msg hook (`npx --no -- commitlint --edit "$1"`) so it lints every commit message automatically.

Commitlint Config Generator - commitlint.config.js Builder

Overview

Introduction

@commitlint/config-conventional gives a project the Conventional Commits format for free, but its default list of allowed commit types is broader than what most teams actually want enforced, and restricting it to your team's own list means writing a type-enum rule override by hand.

This tool generates a commitlint.config.js extending config-conventional with your own type-enum and (optionally) scope-enum overrides, from simple lists of allowed types and scopes.

What Is Commitlint Config Generator?

A commitlint.config.js generator that always extends @commitlint/config-conventional as its base, then adds a type-enum rule restricted to your chosen commit types, and a scope-enum rule restricted to your chosen scopes when you provide any.

Both rules are set to severity 2 (error), matching config-conventional's own severity convention, so an out-of-list type or scope fails the commit rather than just producing a warning.

How Commitlint Config Generator Works

Your allowed-types list is validated (lowercase letters, numbers, hyphens only) and written into a `type-enum` rule as `[2, "always", [...]]`, the array-based rule-config shape commitlint's own rule system expects.

If you supply any allowed scopes, a matching `scope-enum` rule is added the same way; if the scopes list is empty, the rule is omitted entirely so commits with any scope (or none) remain valid under config-conventional's own defaults.

When To Use Commitlint Config Generator

Use it when adding commit message linting to a project and you want to restrict Conventional Commits' type list to only what your team actually uses (e.g. dropping "revert" or adding a project-specific type).

It's also useful for enforcing a fixed set of scopes (matching your monorepo's package names, or your app's feature areas) so commit history stays searchable by scope.

Often used alongside Husky Git Hooks Generator and lint-staged Config Generator.

Features

Advantages

Always extends config-conventional rather than reinventing Conventional Commits' base rules, so you only need to override what's actually different for your team.
Validates commit type names against a safe pattern before generating the config, preventing a typo from silently producing an unenforceable rule.
Omits the scope-enum rule entirely when no scopes are provided, avoiding an empty enum that would reject every scoped commit.

Limitations

Only covers the type-enum and scope-enum overrides; other commitlint rules (subject-case, header-max-length, etc.) fall back to config-conventional's defaults and need manual overrides if you want to change them.
Doesn't wire itself into a git hook; it needs to be paired with a Husky (or equivalent) commit-msg hook that actually invokes the commitlint CLI.

Examples

Restricting types and scopes for a small team

Input

allowedTypes: ["feat", "fix", "chore", "docs"], allowedScopes: ["api", "web", "docs"]

Output

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "type-enum": [2, "always", ["feat", "fix", "chore", "docs"]],
    "scope-enum": [2, "always", ["api", "web", "docs"]],
  },
};

Best Practices & Notes

Best Practices

Keep the allowed-types list close to Conventional Commits' own defaults (feat, fix, docs, chore, refactor, test) unless your team has a specific reason to diverge, since tooling like semantic-release keys off these exact type names.
If you enforce scope-enum in a monorepo, keep the scope list in sync with actual package/workspace names so it doesn't drift out of date as packages are added or renamed.
Pair this config with the Husky Config Generator's commit-msg hook so violations are caught locally before push, not just in CI.

Developer Notes

Commitlint's rule-config format is a 3-tuple: severity (0/1/2), applicability ("always" or "never"), and a rule-specific value, here an array of allowed strings for both type-enum and scope-enum. Both generated rules use severity 2 to match config-conventional's own convention of treating type/format violations as hard errors rather than warnings, so a misformatted commit message actually blocks the commit under a wired-up hook rather than just printing a warning that's easy to ignore.

Commitlint Config Generator Use Cases

Restricting Conventional Commits' type list to a smaller, team-agreed set
Enforcing a fixed list of scopes matching a monorepo's package names or an app's feature areas
Standardizing commit message rules across multiple repositories on a team

Common Mistakes

Adding a scope-enum rule with an incomplete scope list, causing valid commits scoped to a legitimate area (like a newly added package) to fail linting until the config is updated.
Forgetting to also extend @commitlint/config-conventional (or removing it while customizing), losing the base Conventional Commits formatting rules the type/scope overrides are meant to sit on top of.

Tips

Use the Husky Config Generator to wire this config into a commit-msg hook, since commitlint.config.js alone doesn't run on any commit by itself.

Commitlint Config Generator