conventional-changelog
fix: Body line with reference like `#123` is considered footer
Steps to Reproduce
echo 'rules: {footer-leading-blank: [2, always]}' > .commitlintrc.yml
cat > commit-message.txt << EOF
fix: don't frobnicate the foobar
This commit prevents the foobar from being frobnicated
during operation, and therefore fixes #69.
EOF
npx '@commitlint/[email protected]' -e commit-message.txt
Current Behavior
Validation fails with:
⧗ input: fix: don't frobnicate the foobar
This commit prevents the foobar from being frobnicated
during operation, and therefore fixes #69.
✖ footer must have leading blank line [footer-leading-blank]
✖ found 1 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
Expected Behavior
Validation passes.
Affected packages
- [X] cli
- [ ] core
- [ ] prompt
- [ ] config-angular
Possible Solution
No response
Context
Also happens with the full reference format: user/repo#123
commitlint --version
@commitlint/[email protected]
git --version
v2.45.2
node --version
v22.4.0
It might be related, now that I've read the spec more carefully. Without having looked at any code, I think the problematic point is number 10:
A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
Maybe commitlint also looks for token/separator pairs somewhere in the middle of the line, instead of only at the beginning? The spec isn't really clear on whether that's allowed, and I guess it also depends on how commitlint wants to parse things like
Resolves #10, resolves #123, resolves octo-org/octo-repo#100
which is interpreted by Github. I can see how trying to parse this as three separate footers could easily lead to this kind of confusion in the body.
(Although now I'm not sure if #3695 is actually a bug. The way I read it, "JIRA-1234" is a valid "token", but without a separator and value afterwards, it's not a footer.)