vscode-conventional-commits: [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.

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 1
Comments: 24 (9 by maintainers)

Commits related to this issue

feat(prompt)!: :sparkles: add prepend breaking change add a prompt for the breaking news BREAKING CHANGE: Add a new prompt for the breaking change before the footer. Close #39 — committed to yi-Xu-0100/vscode-conventional-commits by yi-Xu-0100 3 years ago
feat(prompt)!: :sparkles: add prepend breaking change add a prompt for the breaking news BREAKING CHANGE: Add a new prompt for the breaking change before the footer. Close #39 — committed to yi-Xu-0100/vscode-conventional-commits by yi-Xu-0100 3 years ago
feat(breakingchange): :sparkles: add detectBreakingChange option Ref #39 — committed to yi-Xu-0100/vscode-conventional-commits by yi-Xu-0100 3 years ago
feat(breakingchange): ✨ add breaking change configuration 1. add `detectBreakingChange` option. 2. add `promptBreakingChange` option. 3. add `breakingChangeFormat` option. Close #39 — committed to yi-Xu-0100/vscode-conventional-commits by yi-Xu-0100 3 years ago

Most upvoted comments

👋 @emiliosheinz, Thank you for your concern, but due to a lack of available development time, this feature has been temporarily put on hold. I would greatly appreciate it if someone could contribute a pull request for it.

yi-Xu-0100 on May 26, 2023

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! 🙂

c-vetter on May 13, 2021

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

yi-Xu-0100 on Mar 23, 2021