What about checking commit message style with commitplease?

ESLint follows this commit message style. If I am not mistaken, it is checked by the following code from Makefile.js when the developer manually runs npm run check-commit as instructed at step 5. If the check fails, the developer has to go back and slightly rewrite some local git history, rinse and repeat.

Would you like this commit message style check to happen automatically when you type git commit? That is what the npm module commitplease does. If the commit message style check fails, the commit aborts and you do not have to rewrite any history. Just read the failure reason and try to git commit again with a new message. This is a shorter cycle!

Secondly, you have had problems (#3706 and #6109) with in-house scripts that check commit messages before. If you use commitplease, you outsource those problems to us. And we do not have many 😃

Finally, if you would like to give commitplease a go, here is the real issue that needs discussing. Your style guide is very close to jQuery commit message style. The only big difference is that you require the first line of the commit message to end with a reference to the issue, while jQuery style does not.

Would you consider loosening that requirement and moving the issue reference to the bottom of the commit message? What problems do you think that will cause? I am happy to solve any of those if you are willing to give commitplease a go.

Commitplease is:

1. used by jQuery Core, jQuery UI, jQuery Mobile, Globalize and QUnit
2. considered by angular (angular/angular.js#14888 and angular/angular#9953)

[nzakas]

We actually check the commit message format in only one place right now, which is by our bot on pull requests. The check-commit task is no longer run automatically because we can always fix the commit message in the PR directly. Plus, as we can now squash commits in PRs, we don’t need to check every commit, just the first one.

So, I don’t see a lot of value in switching to something else. I’m very much of the mind that we shouldn’t be spending time fixing things that aren’t broken, and this part of our process works just fine right now.

[platinumazure]

Thanks for the thorough reply.

I don’t believe I was advocating for a context-free grammar-- I was really advocating for a regular language parser, where tokens (e.g., {tag} in my examples) would essentially be parsed by a regex (tokenized I guess?), then the value is run through some simple predicates.

I did look at the Angular.js commit guidelines and I admit that perhaps, in order to describe their commit message grammar, a CFG would be easier. So I will need to rethink my suggested approach. In any case, you deserve a fully thought out proposal, so I will take the time to work on that and then perhaps create an issue in the commitplease repo. I agree that it would not be ideal to create another preset style, but at the same time I doubt we will be dropping our issue fix requirement either.