Commit messages

Vinicunca repositories expect Conventional Commits: a type, an optional scope, then a short description. Tools can generate changelogs and SemVer bumps from that history (fix → patch, feat → minor, BREAKING CHANGE / ! → major).

This page is a short summary of the Conventional Commits 1.0.0 specification, which is licensed under CC BY 3.0. Read the spec for the full rules.

Format

<type>[optional scope][optional !]: <description>

[optional body]

[optional footer(s)]

• feat: a new feature (minor).
• fix: a bug fix (patch).
• ! after the type/scope, or a BREAKING CHANGE: footer: a breaking change (major). Either is enough.
• Other types (docs, refactor, test, chore, …) have no SemVer meaning unless they also mark a breaking change.
• A scope in parentheses narrows the area, for example feat(parser):.

feat: add pnpm workspace filter for docs

fix(wsl): keep projects off /mnt/c

feat(api)!: remove legacy v1 routes

docs: correct spelling of CHANGELOG

Body and footers are optional. Put a blank line before each. Footers look like Git trailers (Reviewed-by:, Refs: #123). A breaking-change footer must be the uppercase token BREAKING CHANGE:.

Vinicunca commitlint

@vinicunca/commitlint-config extends @commitlint/config-conventional. In Taman and other Vinicunca workspaces it also:

• Allows scopes from workspace package names (full @vinicunca/foo and short foo) plus project, style, lint, ci, dev, deploy, other.
• Allows extra types types and release (the cz-git prompt also offers workflow).
• Caps the header at 108 characters.

If the repo has pnpm commit (cz-git / czg), use that instead of free-form git commit so the prompt fills a valid message. Casual contributors can still write raw messages; maintainers often squash-and-edit on merge.