commitlint: subject-case rule breaks ConventionalCommits spec

For me, the issue is that we don’t want to bikeshed the rules within the team, we want to just adopt the ones from conventional-commits. It would be nice if we can do that by using an existing config. So, we found the @commitlint/config-conventional package.

However, that package implements the conventional commits rules, plus some extra ones.

Pragmatically, as you point out, we can override those bits, but this means it’s less easy to have the same config everywhere (unless we publish actually-config-conventional, which feels unnecessary, since the “best” package name is the exisiting one).

It’s also concerning as a user- because if the rules here are the spec plus some modifications, where else do the rules differ, and how do we know?

It’s much easier to trust a lint package named after a specification if it only implements the rules from that specification.

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.

My team recently adopted this and are finding pain that the package doesn’t follow conventional commits specification. We will be adding overrides. As this package advertises itself as following the spec, it probably shouldn’t get opinionated about these things. Specifically casing and length were the issues for us.

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.

An obvious use case that confirms to the spec, but is rejected by this implementation:

type(scope): JIRAISSUE-123: short description of change that resolves JIRAISSUE-123

I fully agree with previous commenters that while commitlint has every right to provide an opinionated stance, such as via a config called @commitlint/config-conventional-recommended, it’s important that there is a config that applies the spec and only the spec, and an ordinary person’s assumption would be that @commitlint/config-conventional is the config that enforces the spec.

@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.

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?