feat: conditional subject-empty

[Badisi]

Expected Behavior

It would be great to have conditional subject-empty (not just always or never).

Because some types might not always require a subject:

# Here, subjects are required to understand the context (ie. what happened in the fix or feature)
fix(foo): bar
feat(foo): bar

# Here, subjects could be optionals as the scope is enough to understand the context (ie. no need to explain what I changed in the README)
docs(README)
chore(deps)
refactor(foo)
style(bar)

Current Behavior

subject-empty is either always or never, not conditional.

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

No response

Context

No response

[knocte]

Good idea, but what to do if user has defined more types than the default ones, what to do for those?

[Badisi]

I was thinking about making the rule configurable like so:

rules: {
    /**
     * subject-empty
     *   condition: subject is empty
     *   rule: always | never
     *   value: array of type defined in type-enum
     */
    'subject-empty': [2, 'always', ['docs', 'chore', 'refactor', 'style']]
}

[knocte]

'subject-empty': [2, 'always', ['docs', 'chore', 'refactor', 'style']]

That's still using always :) which then contradicts with your previous request:

subject-empty is either always or never, not conditional.

[Badisi]

Yeah, I questioned myself too when writing it as I'm not too familiar with how the rules are working ^^'

I was reading it that way:

---

'subject-empty': [2, 'always', ['docs', 'chore', 'refactor', 'style']]

Subject can always be empty for types in [docs,chore,refactor,style] or throw error

---

'subject-empty': [1, 'never', ['foo', 'bar']]

Subject can never be empty for types in [foo,bar] or display warning

[knocte]

I wonder if commitlint allows using same rule twice at the same time but with different params.

[Badisi]

I don't know but it was not my intention here.
I just shared my interpretation of how the rule could be used.

Users could use it in two ways by deciding to include or exclude types (because it's sometimes easier to do one or the other).

'type-enum': [2, 'always', ['foo', 'bar', 'baz']]

// Case 1: subject can be empty as long as type equals foo
'subject-empty': [2, 'always', ['foo']]
-> foo() -> OK
-> foo(): subject -> OK
-> bar() -> KO
-> bar(): subject -> OK

// Case 2: subject can never be empty if type equals foo
'subject-empty': [2, 'never', ['foo']]
-> foo() -> KO
-> foo(): subject -> OK
-> bar() -> OK
-> bar(): subject -> OK

// Case 3: subject can be empty or not, disregarding the types (= current behavior)
'subject-empty': [2, 'always']
'subject-empty': [2, 'never']

[knocte]

// Case 1: subject can be empty as long as type equals foo
'subject-empty': [2, 'always', ['foo']]

IMO the interpretation of this case should not be that way. You have to use the word 'always' to interpret it. So: subject has to be always empty if type = foo.

-> foo() -> OK
-> foo(): subject -> OK

So the KO should be here ^

[Badisi]

Ok got it, it's just the other way round. Thanks ;-)

Do you think this is something that could be implemented ?

[knocte]

Do you think this is something that could be implemented ?

I don't see why not, but I'm not the maintainer so if I were you, I would ping him before working on a PR.

[escapedcat]

I guess this can work. @Badisi would you be able to provide a PR?

[Badisi]

@escapedcat, I've had a look at the code but there seems to be no context shared between rules.

I need to get the types (declared by the type-enum) in the subject-empty rule.
Do you have any idea how I can achieve this ?

[knocte]

Why do you need that? I thought you were proposing the type names to be passed as a parameter to subject-empty rule.