Open Wuestengecko opened 1 month ago
Does this duplicate or relate to #3695?
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.)
Steps to Reproduce
Current Behavior
Validation fails with:
Expected Behavior
Validation passes.
Affected packages
Possible Solution
No response
Context
Also happens with the full reference format:
user/repo#123
commitlint --version
@commitlint/cli@19.3.0
git --version
v2.45.2
node --version
v22.4.0