Conventional Commits
Builds commit messages that follow the Conventional Commits specification.
Select the type that best describes this change
The component or area of the project affected by the change
Short phrase, imperative mood, always lowercase, no trailing period
Commit message
Footers (optional)
One footer per reference or metadata — e.g. token "Closes", value "#123"
What Conventional Commits is
Conventional Commits is a lightweight convention for writing commit messages — a simple format (type, optional scope, description) that makes the repository's history readable by both humans and machines. From that format, tooling can generate a changelog automatically, compute the next semantic version, and even trigger releases without manual intervention.
The types, and when to use each one
The formal specification only requires feat (new feature) and fix (bug fix) — every other type is optional, left to each project's own choice. In practice, nearly everyone uses the same 11-type list published by @commitlint/config-conventional (based on the Angular convention, the most widely adopted one, and the one the official site itself cites as an example): build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test. This tool uses exactly that list — Nexinon itself follows it in every commit of the project.
The two ways to declare a breaking change
A backwards-incompatible change can be signaled two ways, and the spec allows using both at once: a "!" right before the header's colon (e.g. feat!: drop Node 14 support) and/or a BREAKING CHANGE: footer describing what breaks. This tool always generates both together when the toggle is checked — maximum compatibility with any changelog/CI tooling that only scans one of the two signals, and no extra choice to get wrong.
Footers are git trailers
A footer follows the same format as a git trailer: a token (e.g. Closes, Reviewed-by, Refs) followed by a colon and a space, followed by the value (e.g. Closes: #123). A space inside the token automatically becomes a hyphen (Reviewed by → Reviewed-by) — the specification itself requires this. The BREAKING CHANGE footer is reserved for the breaking change toggle; trying to add it manually here has no effect.
From commit message to changelog and version
The real payoff of following the convention shows up after the commit: tooling like semantic-release/commitlint reads the history and decides the next version on its own — fix becomes PATCH, feat becomes MINOR, any breaking change ("!" or a BREAKING CHANGE footer) becomes MAJOR — and builds the changelog by grouping commits by type, with no one writing the release notes by hand. Nexinon itself versions this way: every dev-to-main PR declares the version bump as its own chore(release) commit.
What this tool doesn't do
It builds and validates the message's format, but it can't know whether the chosen type actually reflects the commit's content (feat: bug fix is still a validly formatted message, just semantically wrong) — that part stays a judgment call for whoever commits. It's also not a commit-msg hook: nothing here stops an out-of-format commit in your own repository; tools like commitlint + Husky are still what enforce that inside a project.
Frequently asked questions
Yes — every commit in this project uses exactly the format and type list this tool generates, no exceptions (the convention is registered in the product's own unversioned behavior-rules file). It was literally tested against the very process it documents.
It's not a rule from the formal specification itself — it comes from the convention most adopted in practice (the same source as the type list, @commitlint/config-conventional), meant to keep the header working well as a single-line title in log/changelog tooling. That's why the warning never blocks copying, it only warns.
The same source as the type list (@commitlint/config-conventional) specifically forbids four styles in the description — "Sentence case", "Title Case", PascalCase and ALL CAPS —, so instead of just warning afterwards, the tool corrects it right away: the header's description is always lowercase, guaranteed by construction. This only applies to the header's description — the Body (optional) is free-form text by the specification's own definition, with no casing rule at all, so it preserves exactly what you type (useful for naming a function, e.g. `testFunction`, or an acronym like JWT).
The formal specification allows it — only feat and fix are technically required, every other type is optional and up to each project. This tool fixes the 11-type list because it's the most widely adopted de facto convention (the same one the official site cites as an example), not because the spec requires it.
The specification accepts all three forms — just "!", just the footer, or both together. This tool always generates both together when the toggle is checked, to guarantee compatibility with any changelog tooling that only reads one of the two signals.
It becomes a hyphen automatically as you type (e.g. "Reviewed by" → "Reviewed-by") — the specification itself requires this (a footer's token can never contain a space).
No — building and validating the message happens entirely in your browser, with no network calls at all. Nothing you type ever leaves your machine.
That token is reserved for the breaking change toggle (check the corresponding checkbox instead) — allowing both paths at once would create a real risk of duplicating or contradicting the same information in the final message.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.