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:

1. Open a PR on a feature branch

2. Get approvals on the PR

3. Squash all commits and write a commit message that fits the Conventional Commits specification

4. Merge PR to main branch

5. Build kicks off, reads the commit message, and calls a versioning script

6. New package version is set and build calls a publish script, which publishes a new release to the registry

7. Build completes, and code is merged to the main branch

What do you think? Have you ever used conventional commits before?

Talk soon,

Mae