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

15. 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?