Missing support of release commit syntax
Summary
It tends to be a common practice in the industry to have commits for release notes, and release commits, with the following syntax :
Release note for vX.Y.ZRelease vX.Y.Z
The <action>(<subject>): <message> syntax for commit messages does not permit to emphasize release-related commits, in fact, it hides them, which is bad for the clarity of the commit history.
Expected Behavior
commitlint to support such syntax, via configuration for example.
Current Behavior
commitlint refuses the syntax.
Affected packages
N/A
Usually you can adjust these commit-messages. You could add i.e. chore: in front of it.
If you stick to conventioanl commits in your project anyways I think this might be the easiest solution.
What do you think?
This would be sufficient if I just wanted to bypass this limitation. Here I wish I could have such non-technical commit messages not checked by the tool.
Happy for a reasonable PR if you have time and motivation. Commitlint is already handling i.e. merge- and revert-commits differently I believe. Maybe that could be a start.
@alexgille There's handling for the default output of standard-version.
If you want to ignore other formats, you can specify an ignores option:
// 3032.config.js
const semver = require('semver');
module.exports = {
extends: ['@commitlint/config-conventional'],
ignores: [
(c) => {
const version = /^Release v(\S+)/.exec(c);
return version && semver.valid(version[1]);
},
],
};
$ echo 'Release v1.2.3' | npx commitlint --verbose --config ./3032.config.js
â§— input: Release v1.2.3
✔ found 0 problems, 0 warnings
$ echo 'Release vm.e.h' | npx commitlint --verbose --config ./3032.config.js
â§— input: Release vm.e.h
✖ subject may not be empty [subject-empty]
✖ type may not be empty [type-empty]
Hello, thanks for the answers. I think that such syntax would deserve to be ignored by default as it is quite common and not a badly-formatted commit message neither. I might open a PR in that direction, let me know if it is not something you want to see. Feel free to close this issue if you don't agree with this.