Commitlint: Feature Request (@commitlint/parse): Support parsing information for breaking changes

[akphi]

Hi,

I just took a quick look at the type definition for Commit used in @commitlint/parse, I don't see information related to breaking changes present. Could we support this?

I think either by seeing BREAKING CHANGE in the footer or by spotting the exclamation point ! in the header.

Thank you so much!

[escapedcat]

Hey, what command did you try to execute?

In general this is working in commitlint:

git commit -m 'feat!: this should be supported already
quote>
quote> BREAKING CHANGE
quote>
quote> '
husky > commit-msg (node v14.15.0)

This works.

Or do you mean something specific to the parse-package?
Maybe provide some more info we understand your issue better :) Thanks

[akphi]

@escapedcat oh no no, I don't mean @commitlint/lint, I'm trying to use the parse package. A little bit of context though, I'm trying to create a little script to get commits from a PR and then base on the commits (which follow conventional-commit) in that PR, create changelog markdown text, so it would be helpful for me to know if a commit contains ! notifying that there are breaking change(s).

I looked at https://github.com/conventional-changelog/commitlint/blob/8c41651cd59f4b53057ca92ff32f0ab8dfb3d165/%40commitlint/types/src/parse.ts#L1-L14 and I don't see any field for breaking change, so I just wonder if we can add that when we parse the commit message.

[escapedcat]

Thanks for the further context and explanation! Got it.

I'm still not too familiar with TS. I would assume that i.e. the ! would just be part of type and BREAKING CHANGE just within the footer. Should/can this be extra reflected in the types? If so, how?

If you know what you would expect we're happy about a PR :)

[akphi]

@escapedcat not a problem!
This requires some actual JS logic change though, but yes the type needs to be changed as well to reflect. Would you be ok if we add 2 fields:

hasBreakingChange: boolean; // when we spot `!` in the type part or `BREAKING CHANGE:` in the footer
breakingChange: string | null // the actual breaking change message (I actually prefer undefined if possible)

Or we can do a field

breakingChange?: BreakingChange

interface BreakingChange {
  text: string;
}

[akphi]

@escapedcat oh! I see what you mean now, we call conventional-commits-parser anyway. Maybe I should actually file an issue over there. Let me take a look and let you know!

[akphi]

Looks like for people with my needs, we can just use conventional-commits-parser and note this answer https://github.com/conventional-changelog/conventional-changelog/issues/648#issuecomment-704867077

@escapedcat As for the typings, I suppose you can just use @types/conventional-commits-parser perhaps.

I'm closing this issue now. Thanks!