fix: Body line with reference like #123 is considered footer

[Wuestengecko]

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/cli@19.3.0' -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

• cli
• core
• prompt
• config-angular

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

[escapedcat]

Does this duplicate or relate to #3695?

[Wuestengecko]

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.)