Finally wrote a new blog post! It's a solution to a problem I had running commitlint on our merge queue in GitHub. When I looked for advice I couldn't find anything about this specific problem, so maybe this will help someone.
https://kieranmcguire.uk/posts/github-merge-queue-commitlint/
@musicmatze After reviewing several tools, I currently find #commitlint the most useful for checking commit messages.
➕: flexible enough configuration that allows me to tune it to my preferences, instead of following someone else's opinions
➖: it needs npm which doesn't fit any of my projects
I use it as a GitHub Action for PRs, and locally I let vim highlight/autoformat my own commit messages.
#gitlint is pretty close too, it only misses a "subject must start uppercase" rule I care about.
Yesterday, I tried to upgrade #TypeScript to 5.0 in a number of repos and discovered that #commitlint has a direct dependency on TypeScript 4.x, ts-node and a number of other dependencies totalling close to 1 MB. We only use it to lint our commit messages, so this seems a bit overkill.
Anyway, one rabbit hole later, we've just published `@rnx-kit/commitlint-lite`. Give it a try if you care about things like this: https://www.npmjs.com/package/@rnx-kit/commitlint-lite
There is a need for a solid set of environment/language-agnostic tools for setting up #ConventionalCommits in a project (linting, prompting, changelog generation, git hook management, etc.).
Current tools like #Commitizen and #commitlint are a total circus to set up in projects that don't have npm and node_modules. 🙄
This sounds like a good read:
Zen and the art of writing good commit messages
The difference between good and bad commit messages, and how to enforce the structure with commitlint and Husky git hooks.
https://vicvijayakumar.com/blog/the-art-of-writing-good-commit-messages
Kieran McGuire
Keith (karmajunkie)
FErki
Tommy
Michael Henriksen
Ryuno-Ki