"scope" and "type" rules fail when those fields are empty

[cengels]

Describe the bug

1. I defined a custom configuration file (see below) that ignores an empty type, but fails when a type other than "chore" is supplied.
2. I ran commitlint --from HEAD~1 --to HEAD~1 on a commit that only had a description, no type or scope.
3. Validation failed with the message: type is not allowed. Only ["cli"] are allowed

The same also happens with the scope and scope-empty rules.

Curiously, the same also still happens if you explicitly set options: [""] to say that the only valid types/scopes are an empty string.

Config

rules:
  type:
    level: error
    options: ["chore"]
  type-empty:
    level: ignore

Error message

N/A

Expected behavior

The type-empty and scope-empty rules already validate an empty type or scope, so the type and scope rules shouldn't do this again. From what I can see, this problem currently makes it impossible to define the ruleset that supplying a type/scope should generally be optional, but that if it is supplied, only certain types/scopes are accepted.

Version

# Run the following command
$ commitlint --version
commitlint-rs 0.1.6

Additional context

As an additional wish, I would like for it to be valid to define options in the type/scope rules as an empty array. That way it would be possible to, for instance, set up a repository in which supplying a scope is never allowed (only a type + description, for instance).

[KeisukeYamashita]

Thank you very much for your report!
Let me take a look soon 🙏

As an additional wish, I would like for it to be valid to define options in the type/scope rules as an empty array. That way it would be possible to, for instance, set up a repository in which supplying a scope is never allowed (only a type + description, for instance).

That makes sense!
Let me consider it 🏃

[KeisukeYamashita]

I think this is fixed in this PR → #269

Regarding this YAML

rules:
  type:
    level: error
    options: [] or [""]
  type-empty:
    level: ignore

$ echo "feat: desc" | cargo run --bin commitlint 
type feat is not allowed. Only [] are allowed

$ echo "desc" | cargo run --bin commitlint
type  is not allowed. Only [] are allowed

Thank you for your report!

I'm currently considering your additional wish, if you have any ideas, how the rule name should be, please let me know.
From Conventional Commits point of view, only the scope is omittable, thus, it can be something like requireScope, disableScope, etc... For instance,

https://github.com/amannn/action-semantic-pull-request/blob/67cbd7a15a6eeea0c3a0dffff4768fa5653de05c/action.yml#L17-L21

[cengels]

Personally I'm not sure I'd even want a new rule for this. If the fix works the configuration

rules:
  scope:
    level: error
    options: []
  scope-empty:
    level: ignore

should be able to easily model this requirement. It's up to you, of course, but maybe you could simply print a different validation error when an empty options array is provided and make a note of this in the corresponding docs pages? Something like scopes are disallowed or similar.

[KeisukeYamashita]

Something like scopes are disallowed or similar.

Super, I was thinking the same thing!
I'll update the message and the documentations, thanks!