🛠 Tooling: Release flow doesn't understand ! in title type

[JoshuaKGoldberg]

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

#957 was merged with feat!: in its title. It should have prompted a new minor release 0.27.0 with entries in the changelog and release notes. Instead:

• The released version was a patch 0.26.4
• https://github.com/JoshuaKGoldberg/eslint-plugin-package-json/releases/tag/v0.26.4 has no content for the version
• https://github.com/JoshuaKGoldberg/eslint-plugin-package-json/blob/7ddd7a1495c517226f6273f057716fc5adec8292/CHANGELOG.md#0264-2025-03-17 has no content for the version

Additional Info

Upstream tooling issue: JoshuaKGoldberg/create-typescript-app#1983

The PR was fine. This is a bug in the release flow, as noted by @rakleed in #752 (comment). Therefore:

Co-authored-by: @rakleed

💖

[michaelfaith]

After a quick look, I suspect this is not supported by the angular conventional-changelog preset. According to the CC spec, there are two ways of designating a change as breaking.

11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
13. If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.

However, in the angular preset documentation page, it only mentions the footer method as the way of declaring a change as breaking. And the regex in their parser would confirm that: https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/src/parser.js#L3
Personally I think it would be better to just align with the preset and just use the BREAKING CHANGE footer instead of the ! (I used both in my PR), rather than creating a new custom preset to support !. What do you think?

[JoshuaKGoldberg]

Makes sense to me. That still leaves a bug of handling the ! correctly, right? Either:

• It should be ignored -> the PR still would have been treated as a feat:
• It should be reported on as invalid -> blocking the PR merge

...I'm leaning towards the latter.

[michaelfaith]

Idk, if ! isn't recognized as an official part of the grammar, then I wouldn't really expect there to be any special handling for it. It's just another character that's attached to the type field, and feat! isn't a recognized type. So, in that sense, it would be treated the same as if someone used featy or feats, etc. Those wouldn't be treated as feat, and I don't believe it would block the PR from merging, right? Should it? That's kind of up to maintainers to ensure is correct.

[JoshuaKGoldberg]

Let's say a PR -> commit is merged with a title like feats: add some xyz feature. What would you expect to happen?

[michaelfaith]

Let's say a PR -> commit is merged with a title like feats: add some xyz feature. What would you expect to happen?

Yeah, good question. From the perspective of the release workflow, I would expect it to treat that as type feats, which doesn't match any of the groups we've configured to show in the changelog, so it would be hidden. But that may not have been the best example on my part. I think it's more similar to another non-word character. So like feat@: add some xyz feature. And that's just invalid grammar, and isn't something it should be able to parse at all.

So, I don't think the release workflow should be able to handle things that don't conform to the grammar that it supports.
With that said, should it be something that another process checks and blocks from merging? Something like commitlint could enforce that the commit syntax matches the grammar our release flow supports, but that would push that burden of correctness to contributors, and I think that could be a little heavy handed and discourage newer contributors from contributing at all. So, maybe some merge-condition that does something similar to what the PR compliance bot does. But then at that point who's behavior is it really governing? It's ours. Maintainers are the ones who are responsible for formatting that merge commit and ensuring it's compliant. At that point, I'd question the value of it, to some degree.