Skip to content

Feature Request(rules): Multiple/escalating rule levels #746

Open
@SgtPooki

Description

@SgtPooki

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
  • 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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions