[FEAT] automatically prepend `BREAKING CHANGE: `

Is your feature request related to a problem? Please describe. While the extension explicitly prompts the user to enter any breaking changes, it expects you to prepend BREAKING CHANGE: manually. In my opinion this is a cumbersome task that should be automated.

Describe the solution you’d like A possible solution would be to simply prepend BREAKING CHANGE: automatically, if the user writes something when prompted for breaking changes.

Describe alternatives you’ve considered A simpler, but in my opinion inferior, solution would be to no longer ask for a text value for breaking changes. This could be replaced by asking whether or not there were breaking changes and then adding an exclamation mark to the description when there are.

[c-vetter]

Hello there, I came across https://www.conventionalcommits.org today and that pointed me to this extension. I like the idea very much.

When I tried out the extension, the behavior of the breaking-change-prompt appeared to me as a bug because it does not seem to follow the specs. Looking to open a bug report, I found this issue, so I will add my two cents here instead.

Firstly, as stated, the current behavior seems like a bug. The reason for that is that the prompt asks me for the breaking changes, not for an additional trailer. That really implies that the extension will take care of the structural requirements connected to breaking changes.

Regarding how this should work, I’d like to propose a different strategy than @vivaxy and @yi-Xu-0100 have discussed so far. The prompt should really have only one non-optional page asking for the description of any breaking change:

• If the user just hits enter without any content, the commit message will be saved as a non-breaking change, as is the current behavior:

  feat(parser): use TypeScript
  

• If the user enters !, the commit message will be saved as a breaking change without a description:

  feat(parser)!: use TypeScript
  

  Note the !:
• If the user enters any other text, the commit message will be saved as a breaking change with a description:

  feat(parser)!: use TypeScript
  
  BREAKING CHANGE: will not work with JavaScript anymore due to requiring types
  

This strategy reduces necessary interaction to a bare minimum:

• 1 key press (enter) for a non-breaking commit
• 2 key presses (!, enter) for a simple breaking commit
• n+1 key presses (description, enter) for a breaking commit with a description

The ! for a breaking commit with a description could be optional but should default to adding it because that maximizes visibility as @yi-Xu-0100 explained.

Whether to use BREAKING CHANGE: or BREAKING-CHANGE: should be an option defaulting to BREAKING CHANGE: because that is the main use case in the spec. The way I read the spec, BREAKING-CHANGE: is not an important use-case but really only mentioned in order to allow using the dashed style that the other footer tokens use, probably to facilitate some simpler tools.

Regarding not breaking the current behavior, my suggestion is to either accept this as a bug fix or make the whole thing opt-in and mark the current behavior as deprecated and prominently pointing to this improvement. At v2, this really should be the only way.

Looking forward to your feedback on this. @vivaxy thanks for this extension! 🙂

[yi-Xu-0100]

@vivaxy I really don’t know the situation about the BREAKING-CHANGE as the token in the footer, but I did not want to miss it when I figure out why it exists and want to use it in the future. 😋

For the reason that BREAKING CHANGE has a low usage frequency, The four options also not bother me, and the configuration with the both will not consume more time for general committing. 😀

When the pattern is BREAKING CHANGE or BREAKING-CHANGE, the selection page can be three options. When the pattern is the both, the selection page can be four options in case of future usage without setting more. 😁