If you’ve looked through any open-source repositories recently, you’ve likely seen commits that look like this:
The commit messages are prefixed with a “tag” like fix or feat . This commit message specification is called Conventional Commits, and it’s a powerful way to write commit messages that are human and machine-readable.
Conventional commits are a powerful specification that makes it possible to automate some of the more annoying parts of your versioning and publishing workflow. For example, you can use conventional commits to auto-version new releases of your library.
Because conventional commits are machine-readable, plenty of open source tools leverage them. For example, lerna has a --conventional-commits flag that checks your commit messages and recommends a semantic version for you.
I’d recommend this tool for library authors and maintainers who want to automate their versioning and publishing flow using tools like CI or Github Actions. A common workflow might look like this:
Open a PR on a feature branch
Get approvals on the PR
Squash all commits and write a commit message that fits the Conventional Commits specification
Merge PR to main branch
Build kicks off, reads the commit message, and calls a versioning script
New package version is set and build calls a publish script, which publishes a new release to the registry
Build completes, and code is merged to the main branch
What do you think? Have you ever used conventional commits before?
If you liked this post, please consider sharing it!