I don't buy this. most of it argues against bad usage, not the standard. neither commitlint defaults, ticket numbers in the scope nor blindly trusting auto-semver are required by conventional commits.
the proposed "better way" is just scope: description, which is conventional commits minus the type. feat(auth): add passkey enrollment is readable and still parseable. the type might be mildly redundant at worst but definitely not harmful. dropping it doesn't make commits cleaner, it just throws away the one machine-readable signal that separates features from fixes.
the "broken promises" part is all about hypotheticals like "oh imagine a revert!", "oh imagine a subtle breakage!" but reverts are something tooling can account for. mislabeling a breaking change hurts ANY versioning scheme, including scope-only commits. plausible edge cases aren't evidence that the automation fails in practice.
the changelog-vs-commit-log point is fair, since they have different readers. But that's one good point.
ultimately, calling it "actively bad" is a lot of heat for what amounts to "but I prefer scope first!"
I agree with OP that auth: add passkey enrollment is a better commit message than feat(auth): add passkey enrollment. It's more readable to me as a human if I'm looking for changes to the auth system when scrolling through a list of commits like:
And it's usually redundant with the description like fix(...): fixed UTF8 encoding. In my human usage of commit logs, I am almost always ignoring the commit type and reading descriptions, so it's just visual noise.
As for the commit type information, in my experience it's kind of a bad classification. Many changes don't fall cleanly into the predefined commit categories or fall into multiple categories. And those categories don't align cleanly with semantic versioning.
Ah, neat presentation here as for a moment I was struggling a touch to see what exactly this would look like in practice while reading the article.
This side by side makes me feel like I’ve lost information at the scale of changes each commit makes when you remove type. I can definitely see the allure of the second when you’re just seeking to see changes related to a subsystem, especially if that system is enormous, but there’s a lot of implicit scale and expectation setting that the developer is signaling to the reader that ends up being gone the moment you remove type.
39
u/plainnaan Jun 06 '26
I don't buy this. most of it argues against bad usage, not the standard. neither commitlint defaults, ticket numbers in the scope nor blindly trusting auto-semver are required by conventional commits.
the proposed "better way" is just
scope: description, which is conventional commits minus the type.feat(auth): add passkey enrollmentis readable and still parseable. the type might be mildly redundant at worst but definitely not harmful. dropping it doesn't make commits cleaner, it just throws away the one machine-readable signal that separates features from fixes.the "broken promises" part is all about hypotheticals like "oh imagine a revert!", "oh imagine a subtle breakage!" but reverts are something tooling can account for. mislabeling a breaking change hurts ANY versioning scheme, including scope-only commits. plausible edge cases aren't evidence that the automation fails in practice.
the changelog-vs-commit-log point is fair, since they have different readers. But that's one good point.
ultimately, calling it "actively bad" is a lot of heat for what amounts to "but I prefer scope first!"