feat(ensure): modify enum to support regular expression

[dc3671]

Description

Implement support for scope items of regular expression, such as [/ensure\/*/, /cli\/*/] to match feat(ensure/enum): some descriptions here . If scope-enum is not RegExp, this feature will not be enabled.

Motivation and Context

to explicitly tell which module is related in this commit.

Usage examples

// commitlint.config.js
module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "scope-enum": [2, "always", [/ensure\/*/, /cli\/*/]],
    "scope-empty": [2, "never"]
  }
};
echo "chore(ensure/enum)" | commitlint #passes
echo "chore(unknown/unknown)" | commitlint #fails

How Has This Been Tested?

Extended the tests in scope-enum.test.ts

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[escapedcat]

@armano2 what do you think about this?

[escapedcat]

@AdeAttwood you wanna have a look at this? Looks fine to me tbh

[AdeAttwood]

I have been looking into this one. I have rebased on master, and it's all good. There is one issue with the new @commitlint/cz-commitlint package. I will put this one next on my list to get this merged.

[AdeAttwood]

After looking into this, I'm not sure whether this is the correct place for this rule.

The rule name scope-enum is used in interactive commit tooling to provide a prompt with available scope values. Some examples of this are our own cz-commitlint and vscode-conventional-commits. I am sure there are many others out there that require this functionality. If we added this functionality,
users who have a regex in their rules would no longer be able to use interactive tooling without upstream changes.

I am proposing that we split this out into a new rule called scope-enum-regex. This will not clash with any existing tooling and if try would like to support it other than giving a free text field they can.

@escapedcat what do you think?

[yi-Xu-0100]

I am proposing that we split this out into a new rule called scope-enum-regex. This will not clash with any existing tooling and if try would like to support it other than giving a free text field they can.

I think the new rules are good for configuration. The previous rule has a potential type definition, that is, scope-enum is a string type. If the regex type is added, I personally think that this will be a destructive change rather than a simple new feature.

[escapedcat]

So he we are a year later :P
@dc3671 are you interested to switch this into a new rule? I think both comments make valid points.

[escapedcat]

Closing this. Please reopen if you want to continue. Thanks for your efforts!