bug: footer-leading-blank complains with the number sign in the commit body

Expected Behavior

The following commit message should pass the footer-leading-blank rule:

test: footer-leading-blank bug

hello
see issue #1234

Current Behavior

The above commit message, however, fails with the following:

⧗   input: test: footer-leading-blank bug
⚠   footer must have leading blank line [footer-leading-blank]

⚠   found 0 problems, 1 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

This happens when the following conditions are true:

1. The # symbol is present in the commit body
2. It is immediately followed by a number
3. It is not at the beginning of a line
4. It doesn’t appear in the first line of the commit body

For instance, the following example, taken from the spec, also triggers this bug:

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

Affected packages

• cli
• core
• prompt
• config-angular

Steps to Reproduce

1. Create a repo with the below config file
2. In this repo, create a commit such as the above examples
3. Run commitlint --edit
4. An error such as the above appears

commitlint.config.js

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      1,
      'always',
      [
        'build',
        'chore',
        'ci',
        'docs',
        'feat',
        'fix',
        'perf',
        'refactor',
        'revert',
        'style',
        'test'
      ]
    ]
  }
}

Context

I was referencing a GitHub issue in the standard GitHub format, which is #1234. This was inside a very detailed commit message with multiple lines.

Your Environment

Executable	Version
commitlint --version	8.3.4
git --version	2.20.1
node --version	10.17.0

[melink14]

I think this would need to be fixed in https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-commits-parser but they’ve not been that open about matching the conventional commit spec.

I had forgotten but looked into this as part of https://github.com/conventional-changelog/conventional-changelog/issues/415#issuecomment-881862836

If commitlint passes through a config to the parser then the work around there would work though ideally the parser would be updated to implement the spec as written (or maybe that’s the job of an extension?)

[ProbstDJakob]

Maybe the following ANTLR grammar can be used to parse the commit message. ANTLR can generate code to parse the commit message. JavaScript is officially supported and a community driven generator for TypeScript also exists. The grammar below is strongly based upon the conventional commits specification.

grammar ConventionalCommits;

// needed to allow carriage returns not followed by a line feed
CARRIAGE_RETURN
  : '\r'
  ;

NEWLINE
  : CARRIAGE_RETURN? '\n'
  ;

BREAKING_CHANGE_HEADER_INDICATOR
  : '!'
  ;

// needed to allow hyphen which follows word(s) but has no trailing word (e.g. abc-def-)
INCOMPLETE_FOOTER_TOKEN
  : (WORD '-')+
  ;

FOOTER_TOKEN
  : INCOMPLETE_FOOTER_TOKEN WORD
  | BREAKING_CHANGE_TOKEN
  ;

BREAKING_CHANGE_TOKEN
  : 'BREAKING' (' ' | '-') 'CHANGE'
  ;

WORD
  : [a-zA-Z][a-zA-Z0-9]*
  ;

// needed to allow colons not followed by a space
COLON
  : ':'
  ;

// needed to allow spaces not followed by a hashtag
SPACE
  : ' '
  ;

COLON_SPACE
  : COLON SPACE
  ;

SPACE_HASHTAG
  : SPACE '#'
  ;

commit
  : header (NEWLINE body)? (NEWLINE footer)? EOF
  ;

header
  : type enclosedScope? BREAKING_CHANGE_HEADER_INDICATOR? COLON_SPACE summary
  ;

type
  : WORD
  ;

scope
  : WORD
  ;

enclosedScope
  : '(' scope ')'
  ;

summary
  : nonEmptyLine
  ;

body
  : nonEmptyNonFooterLine (NEWLINE* nonEmptyNonFooterLine)*?
  ;

line
  : (~NEWLINE)*? NEWLINE
  ;

nonEmptyLine
  : ~NEWLINE line
  ;

// a line which does not match a footer line (line != footer-token + footer-separator + footer-value)
nonEmptyNonFooterLine
  : ~(FOOTER_TOKEN | WORD | NEWLINE) line
  | (FOOTER_TOKEN | WORD) NEWLINE
  | (FOOTER_TOKEN | WORD) ~(COLON_SPACE | SPACE_HASHTAG | NEWLINE) line
  | (FOOTER_TOKEN | WORD) (COLON_SPACE | SPACE_HASHTAG) NEWLINE
  ;

footer
  : footerEntry+?
  ;

footerEntry
  : (FOOTER_TOKEN | WORD) (COLON_SPACE | SPACE_HASHTAG) footerValue
  ;

footerValue
  :  nonEmptyLine (NEWLINE* nonEmptyNonFooterLine)*?
  ;