conventional-changelog
Rule does not work with #ids
I was trying this utility in my project as we are planning to enforce conventional commit messages. It works nicely but I was pleasantly surprised when it started failing miserably. When I tried to commit with messages like git commit -m "#123 - test commit" it does not throw any error. However when I run commitlint --from=HEAD~1 it shows error.
This is causing issues as the team is accustomed to #ticket-id - message pattern.
This is causing issues as the team is accustomed to
#ticket-id - messagepattern.
This isn't the conventional-commits structure though, so it fails correctly.
You might be able to achieve your structure by adjusting the configuration. Please have a look at https://commitlint.js.org and the issues in this repo.
@escapedcat my issue is commitlint is not throwing any error and accepts it as valid commit message :(
Ah sorry, sounds like your husky setup might have issues.
This works for us:
/.husky/commit-msg
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
yarn commitlint --edit
How does yours look like? Have a look at the issues. We recently had some issues on how to configure husky correctly.
I can confirm there is no issue with husky as it fires correctly before commit. We even have a pre-commit hook for linting staged files. Even commitlint works in most of the scenarios it fails only when I use commit message in above format.
Husky setup is as below
it fails only when I use commit message in above format.
Ooohhhh, I see. I assume commitlint thinks this is a commented out sentence as does not lint it.
Oh that was not expected :( is there a work around or will this be treated as bug? The same rule works when we run commitlint --from=HEAD~1 weird though.
Uhm, nor sure. I remember there were some adjustments regarding comments in the commit-body. Would be good to have a look what was done there and if this also caused this. In general this might be a bug I guess.
Thank you @escapedcat for your quick replies. I will continue with current setup hopefully we get a fix for this in near future :)
hopefully we get a fix for this in near future
Only if someone is motivated to take care of it :P
I'll try to find the PR I mentioned.
hopefully we get a fix for this in near future
Only if someone is motivated to take care of it :P I'll try to find the PR I mentioned.
May I offer my assistance with this Git issue, despite being new to open source? I have recently reviewed this codebase to implement custom issue prefixes. I think i might be able to help with some guidance.
@kamathgopal which commitlint version are you using? According to this issue it's fixed: #3208
I just tried this with current master
echo "#123 - test commit" | ./@commitlint/cli/cli.js
⧗ input: #123 - test commit
✖ subject may not be empty [subject-empty]
✖ type may not be empty [type-empty]
✖ found 2 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
Update:
-m '#123 - test commit' is leading to the bug.
@HoLiSchitz have a look if you have some time.
#3208 might be related.
#2827 as well.
Would be nice to have the same behaviour when running -m or echo "#123 - test commit" | ./@commitlint/cli/cli.js or other ways of linting.