conventional-changelog
feat: conditional subject-empty
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
- [X] core
- [ ] prompt
- [ ] config-angular
Possible Solution
No response
Context
No response
Good idea, but what to do if user has defined more types than the default ones, what to do for those?
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']]
}
'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.
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
I wonder if commitlint allows using same rule twice at the same time but with different params.
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']
// 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 ^
Ok got it, it's just the other way round. Thanks ;-)
Do you think this is something that could be implemented ?
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'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 ?
Why do you need that? I thought you were proposing the type names to be passed as a parameter to subject-empty rule.
@knocte, I wanted to make sure that the given types were matching the ones in type-enum. But you are right I can easily get rid of that and let the user alone pay attention to what he is doing.
I've submitted a PR that you can review (especially the test cases, to make sure my interpretation of the rule is correct).
Only one thing remains now: foo(bar): is working, whereas foo(bar) is not.
Due to the : missing, the parsed response gives a { type:null, scope:null }.
I guess there is an issue in how the commit message is parsed (maybe a regexp somewhere expecting the colon to exists), but this is beyond my comprehension of this library.
(maybe a regexp somewhere expecting the colon to exists)
Ah that sucks. Yes it's certainly a regexp problem which I also faced in the past (see this other bug I filed https://github.com/conventional-changelog/commitlint/issues/3404). There, you can also find a comment from someone which seems knowledgeable about that area of the code.
@knocte, I have submitted another PR based on our discussions.
Regarding the regexp issue, are you suggesting that I fix it on my own with a custom headerPattern ?
Fixing this directly in the library seems a bit tedious for me and prone to breaking changes.. 😅
Regarding the regexp issue, are you suggesting that I fix it on my own with a custom headerPattern ?
Nope, that's the workaround.
Fixing this directly in the library seems a bit tedious for me and prone to breaking changes..
Yeah well, someone has to dig, or it will never get fixed 😅 I might ask some teammate of mine to see if she can help here (she has contributed some PRs already).
That's right ^^ I would have loved to help, but I'm just not confident enough to put my hands on a core feature, especially when this issue is around since 2021 and still not fixed 😅. Thanks for your help!
