Commitlint: subject-case rule breaks ConventionalCommits spec

[mrmartan]

@commitlint/config-conventional subject-case rule breaks ConventionalCommits spec

Expected Behavior

From https://www.conventionalcommits.org/en/v1.0.0/#specification

1. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.

Current Behavior

⧗   input: fix: Gitlab CI pipeline fixed
See the TP for details
Refs #131167
✖   subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]
✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Affected packages

• [ ] commitlint

Possible Solution

Remove the casing rule

[escapedcat]

Looks like this should be updated: https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#subject-case

For now you could change the subject-case rule in your own config.

[iamscottcab]

I this true also of type-case and scope-case? They are both currently set to lowerCase but in theory TYPE(scope): sUbJeCt is a valid commit?

Is the wording implying that type, scope and subject are all individual _units_ within the overall commit, or are units referring to elements in the subject and body respectively?

[escapedcat]

[...] in theory TYPE(scope): sUbJeCt is a valid commit?

I guess so? Although all their examples are showing non-mixed-cases. Would it be possible to allow Subject and subject but not sUbJeCt with the current existing rules? Need to check.

Is the wording implying that type, scope and subject are all individual units within the overall commit, or are units referring to elements in the subject and body respectively?

If it's referring to this part I think it means everything? type, scope, subject, body and footer?

[iamscottcab]

I guess my point being that (ignoring the silly spongebob case) should we be enforcing lowerCase on type and scope or should the rule just be ignored to let the user input the case however they want?

[escapedcat]

The units of information that make up Conventional Commits MUST NOT be treated as case sensitive

I guess that's a yes for "the user input the case however they want".
But then showing lower-case only examples only..... . .. . . . ....

I feel like we should enforce some sort of consistency otherwise people will end up with changelogs saying, i.e.:

• Fix(button): Changed color
• feat(Select): changed padding
  
  
  
  • Docs(settings): ChangED All tHE seTTinGS
  
  

That can't be what people would expect from commitlint, right?
@mrmartan what do you think/expect?

[iamscottcab]

Agreed, I think the default config should set some standard, as you mentioned above you can tailor the plugins to behave in a certain way. I think we should enforce lowerCase on type and scope at the very least. But I figure this issue raises a sort of meta discussion so might be worth deciding how much of the config we change if / before we do :)

[escapedcat]

@mrmartan we tend to close this.
commitlint should enforce certain cases. 100% according to spec would lead to inconsistent messages. If people want to be 100% according to spec when it comes to cases they can use their own commitlint-config.

[mrmartan]

I tend to disagree. I see your point but raise that with the spec itself. All implementors are expected to conform to it. Otherwise problems arise in heterogenous environments. That's in fact how we arrived here. One tool in one part of the system would be ok with fix(button): Changed color and another tool (this one) would not. Now you have to start matching configuration of multiple tools that only sort of conform to a standard.

At least make the casing rules opt-in instead of opt-out.

As for consistency, the spec itself argues for consistency but does not presume what that should be. https://www.conventionalcommits.org/en/v1.0.0/#are-the-types-in-the-commit-title-uppercase-or-lowercase

There is a more demanding solution. You could pickup the preferred style from the commits themselves and make them self-consistent on contrary to all lower-case. I can imagine the inconsistencies, in type and scope in particular, could cause trouble down the line if other plugins/tool are not case-insensitive, e.g. release notes generators.

[mrmartan]

So I have tried disabling the case-sensitvity rules. The type-enum rule (evaluation implementation) itself is also case-sensitive. Can you see the issue?

[iamscottcab]

We've been having a bit of a discussion about this one in Slack and can appreciate where you are coming from. I think (internally) there is a consensus for us to provide some basic and generally adopted opinionated defaults, as we do now, based on the conventional changelog format.

However we do appreciate that some users might want something that matches the spec but is less opinionated. I'm not sure how this will turn out in practice yet.

One suggestion was relaxing the rules on the current configuration and also supplying a commitlint configuration which keeps the values we ship currently. I'm partial to this idea because the commitlint config would be for those who want a simple out-of-the-box solution with some rules built in for them that we think are commonly used. Alternatively the conventional config could be adopted for those who want to match the spec 100%.

I guess we would have to discuss how that affects documentation and onboarding because we already get questions about trying to streamline setup and two configs might be confusing for users.

EDIT: @escapedcat a change like this would also be considered a breaking change I guess if we loosen or change config values as current users may expect lowerCase enforcement on type and scope for example?

Thoughts @mrmartan?

[mrmartan]

Well, from my POV @commitlint/config-conventional was from the start about setting up rules conforming to the standard. So when it does not, I see it as a bug and any change to make it conform does not break the original contract. Which strictly speaking means also removing the type-enum rule. I can understand your dilemma but there are many configs available and if one wanted an opinionated one, he could have chosen so. Here you have taken one that refers itself to a standard and made it opinionated.