All commits are like 3 things

I’ve come around to the idea of keeping your commits clean, probably too far late in life. Automated linting helped a lot with that. Since most of my projects are Node.js based, I’ve landed on commitlint as my tool of choice.

Now, commitlint out of the box gives you a lot of options for the commit types (this is the part usually at the beginning, like feat, test, etc.:

1. feat
2. fix
3. build
4. chore
5. ci
6. docs
7. perf
8. refactor
9. revert
10. style
11. test

Clarity is good, but when authoring a commit message I want to limit the amount of decision that I have to make. Some choices are clear, but it can get messy quick. If my commit includes both tests and a feature, what do I do? “Those should be different commit” could be an answer, but I tend to lean on the side of everythting for a new feature being bundled in a single commit, which often means that things like tests, styles, and the feature itself are getting grouped in one commit.

Ultimately, I don’t want to have to make a lot of decisions when I’m authoring a commit, and so I’ve simplified it down to the three possible things I believe I could possibly be commiting:

1. for commits that are authoring new features: feat
2. for commits that are fixing a broken part of the codebase: fix
3. for basically everything else: chore

I also allow wip for when I’m working on something in smaller chunks that are going to be squashed later (at which point, I’ll pick one of the above three).

The commitlint config I typically start projects out with looks like this:

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
        'type-enum': [2, 'always', ['chore', 'feat', 'fix', 'wip']],
    },
};