commitlint icon indicating copy to clipboard operation
commitlint copied to clipboard

Feature Request(rules): Multiple/escalating rule levels

Open SgtPooki opened this issue 5 years ago • 4 comments

I would like to be able to set escalating limitations of values for particular rules. For example, setting a warning at header-max-length>=50 but an error at header-max-length>72.

We should be able to either

  1. Have rule functions that are passed the commit message's attribute value so they can conditionally return the appropriate rule level, applicability, and value.
  2. Allow specifying multiple rule levels at once (an array of rule conditions, only one rule condition(i.e. value+applicability) per level)

I set a function for each of the rules, and they don't seem to be passed any values at all. I can't seem to find an existing issue or anything on the roadmap that talks about this feature.

Thanks for your consideration!

Expected Behavior

{
  "header-max-length": [[2, "always", 72], [1, "always", 50]] 
}
// currently throws Error: level for rule header-max-length must be number, received [ 2, 'always', 72 ] of type object

// or
{
  "header-max-length": (value) => value >= 50 ? [[2, "always", 72] : [1, "always", 50]]
}
// or
{
  "header-max-length": async (value) => value >= 50 ? [[2, "always", 72] : [1, "always", 50]]
}
// or
{
  "header-max-length": (value) => Promise.resolve(value >= 50 ? [[2, "always", 72] : [1, "always", 50]])
}

Current Behavior

The current docs say that we can do the following:

{
  "header-max-length": [0, "always", 72]
}
// or
{
  "header-max-length": () => [0, "always", 72]
}
// or
{
  "header-max-length": async () => [0, "always", 72]
}
// or
{
  "header-max-length": () => Promise.resolve([0, "always", 72])
}

Affected packages

  • [ ] cli
  • [x] core
  • [ ] prompt
  • [ ] config-angular

Possible Solution

Change the rules map/object Map<ruleName, ruleConditions> to Map<ruleName, Map<ruleLevel, ruleConditions> where ruleConditions removes the level index in the latter config.

I believe the actual work running all the rules (runtime commit msg adding to the built rules) is done here. I think we need to make loaded.rules a function instead of an object.

Steps to Reproduce (for bugs)

N/A

Context

Obviously this is a breaking change, so we should be cautious. I think the most important part is agreeing that this functionality is desired.

I liked that the rules config accepted functions for the conditions, but I was really surprised that the functions aren't passed any information at all. It seems like the execution of the rules is supposed to be a build-time execution and not a run-time execution, so it would be a non-trivial undertaking to add this functionality.

Am I understanding the code correctly?

Your Environment

Executable Version
commitlint --version 8.1.0
git --version 2.22.0
node --version v12.6.0

SgtPooki avatar Jul 18 '19 07:07 SgtPooki

Thanks for the detailed proposal and the analysis, it is correct! I'll consult with the other maintainers and let you know around the Mon. 22th.

marionebl avatar Jul 18 '19 17:07 marionebl

@marionebl this issue has been open a while, any update?

SgtPooki avatar Mar 04 '22 17:03 SgtPooki

@SgtPooki no progress here. Happy for any support on this.

escapedcat avatar Mar 05 '22 01:03 escapedcat

I will stay subscribed here and try to help out when I get some time =D

SgtPooki avatar May 03 '22 22:05 SgtPooki