Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 of 4 tasks
SgtPooki opened this issue Jul 18, 2019 · 4 comments
Open
1 of 4 tasks

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

SgtPooki opened this issue Jul 18, 2019 · 4 comments

Comments

@SgtPooki
Copy link

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
@marionebl
Copy link
Contributor

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.

@SgtPooki
Copy link
Author

SgtPooki commented Mar 4, 2022

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

@escapedcat
Copy link
Member

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

@SgtPooki
Copy link
Author

SgtPooki commented May 3, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants