Commitlint: Github/Gitlab issue ID support (in subject)

[jimzhan]

Expected Behavior

Github/Gitlab issue ID (e.g. #123, #6778) can be added as references into subject.

Current Behavior

subject-case now only allows characters

  [
    'lower-case', // default
    'upper-case', // UPPERCASE
    'camel-case', // camelCase
    'kebab-case', // kebab-case
    'pascal-case', // PascalCase
    'sentence-case', // Sentence case
    'snake-case', // snake_case
    'start-case', // Start Case
  ]

Affected packages

• [X] cli
• [X] core
• [X] prompt

Possible Solution

Add regex pattern supports to subject-case, for now, I have to disable subject-case which doesn't make sense.

commitlint.config.js

{
  "commitlint": {
    "extends": [
      "@commitlint/config-conventional"
    ],
    "parserPreset": {
      "parserOpts": {
        "issuePrefixes": [
          "#"
        ]
      }
    },
    "rules": {
      "references-empty": [2,"never"],
      "subject-case": [0,"never"],
      "subject-empty": [2, "never"]
    }
  }
}

Context

Your Environment

| Executable | Version |
| ---: | :--- |
| commitlint --version | v7.0.0 |
| git --version | v2.15.2 |
| node --version | v10.6.0 |

[marionebl]

Please provide also the error output created by commitlint.

[heavybeard]

This feature can be very useful and it's value is very high, imho.

I suggest to extend it to header, body and footer too in order to give to commitlint user every customization

In my company we need to check the Jira task ID link in body e we are looking for a feature like the suggested one

[therealklanni]

Being able to do this by allowing regular expressions seems like a good solution. Alternately, being able to provide a function (instead of array/string) to the value part of the config...

'some-config': [2, 'always', (commit) => validateThing(commit)]

[byCedric]

Hi guys! That does seem like a good solution. But if it can be created with a rule, why not add it too 😄 I would love to try and see if we can create a dedicated rule for such a thing! But for that, I need some use cases and examples. What commits do you want to validate and what should or shouldn't pass?

Are you talking about commits with something like this?

feature: my awesome new feature #1337
fix(auth): allow users to log in #2337

And to validate based on the existence of #xxx?

[therealklanni]

This is why I think it's simpler to allow for regular expressions or functions, because in my case it's a letter-code followed by numerical identifier. Other people could also have varied cases.

[byCedric]

Ah ok, so commitlint is using the conventional commit parser. This parser includes a reference regex. It's a bit buried deep down in the code, but that's why I was thinking about creating a rule. Sounds like it could be interesting to create a rule which uses that parsed value, but that requires you to "extend" the parser config when using forms like:

ISS1337
7777777

[ankurloriya]

Hi guys! That does seem like a good solution. But if it can be created with a rule, why not add it too I would love to try and see if we can create a dedicated rule for such a thing! But for that, I need some use cases and examples. What commits do you want to validate and what should or shouldn't pass?

Are you talking about commits with something like this?

feature: my awesome new feature #1337
fix(auth): allow users to log in #2337

And to validate based on the existence of #xxx?

Yes, If this kind of rule or user can create custom rules for their use that would be good.

[jdbruijn]

I've created a plugin commitlint-plugin-function-rules, which can be used to write functions for rule values, allowing you to use a regex to specify the allowed values, and much more. I think the issue potentially could be resolved with a function rule and a regex for the subject-case rule (named function-rules/subject-case using the plugin).

I hope this helps!