Rules based on commit message

[jdbruijn]

This is a question/improvement. One issue I'm facing recently is with automated dependency updating and the long commit messages those can create. One example of such a message is chore(deps): update dependency https://github.com/homebrew/brew to v2.2.17 (#37), which is 80 characters long. I know that we can use the rules to statically change the header-max-length in this case using something like this in our commitlint.config.js.

  "rules": {
    "header-max-length": [0, "always", 100],
  }

One downside, IMHO, with this is that it obviously changes it for all commits. I thought it would be nice if we can change header-max-length, but only for certain commits. In this case those commits would have to start with chore(deps): update dependency. By searching the issues I've found #303 and #397, which are somewhat related.

Expected Behavior

This sections describes how the rules functions would work with this improvement.

In this issue I want to suggest that the commit message is passed to rules that use a function. That would look something like shown below.

  rules: {
    'header-max-length': (commitMessage) => {
      // commitMessage could be used to do whatever and return accordingly.
      return [2, 'always', 100];
    },
  },

Using this, users should be able to create rules, based on commit messages. In the snippet below I've shown how this would look like for the issue I'm facing as described above.

  rules: {
    'header-max-length': (commitMessage) => {
      if (commitMessage.startsWith('chore(deps): update dependency')) {
        return [2, 'always', 100];
      }

      return [2, 'always', 72];
    },
  },

I think this improvement would also support the use-case described in #397 and in general give users more flexibility in defining rules.

Current Behavior

The difference from the current behaviour would be that the commit message is passed to rules functions.

Context

I'd be happy to help work on this with some pointers to where in the code-base the these changes would be.

Your Environment

Executable	Version
commitlint --version	8.3.5
git --version	2.26.0
node --version	13.13.0

[escapedcat]

Hey @jdbruijn , maybe this can be achieved by creating your own plugin? You could turn of the header-max-length rule and use your own maybe. Have a look if that makes sense.

[jdbruijn]

This could definitively work with a plugin but I'm wondering how versatile that would be. For example, I could create a plugin that adds my own header-max-length rule and then could turn off the commitlint rule for that and turn on the rule from my plugin. That would work for this specific use-case but when there is a slightly different use-case there would need to be a different rule and there would be an environment with a whole bunch of plugins that are slightly different. I feel like allowing functions would make commitlint itself more versatile.

I've played around with a plugin very briefly and think I could easily make a plugin (e.g. commitlint-plugin-func-rules) that takes functions as rules.

Then the rules could be something like this.

  rules: {
    'header-max-length': (parsed) => {
      if (parsed.header.startsWith('chore(deps): update dependency')) {
        return [2, 'always', 100];
      }

      return [2, 'always', 72];
    },
  },

And my plugin could simply call that function.

module.exports = function(parsed, when, value) {
  value(parsed);
}

This is just an idea ATM so likely not like how it exactly would be, but should give a general idea. If there is little chance functions will be supported in commitlint then I'l probably work on a plugin with behaviour something like described above.

@escapedcat Could you please let me know what you think of the topic of functions in commitlint vs a plugin like I described here? And also whether a plugin like this would be something that could work and/or any major downsides to such a approach for a plugin?

[escapedcat]

@byCedric might be able to give more useful feedback to this than me.
Make it easier to tackle the things you mentioned or which are mentioned in #397 would be nice I guess but not sure if this should be done in core.

[jdbruijn]

@byCedric Could you please have a look at my comment (#1698 (comment)) and provide feedback on adding function arguments in commitlint vs the plugin I described there? If you also think that the plugin is the way to go I can move forward and create a plugin.

[jdbruijn]

Took a while 😝 but created a plugin to specify rules as functions. Using that resolved my specific issue.

https://github.com/vidavidorra/commitlint-plugin-function-rules

@escapedcat I think some open tickets here could benefit/be resolved by using my plugin, is it okay if I comment to those issues that using my plugin might be a solution for those cases and people? I don't want to 'promote'/spam those topics unsolicited ;).
I didn't go through all issues so there might be more that would benefit from it, these are just tickets I ran into earlier when creating this ticket.

• Github/Gitlab issue ID support (in subject) #397
• [Question]How to write rules with regex #2051
• type-enum does NOT work with scoped package names #2108
• [Help/Question] How to add scope dynamically? #1996

[escapedcat]

@jdbruijn no worries, feel free to comment on those issues and suggest to try your plugin.
I'm not completely sure, but maybe it would make sense to list plugins somewhere i.e. in this section.