Use conventional-commits-parser?

[stevemao]

Both conventional-changelog and validate-commit-msg started with the angular.js project. The initial code of parsing the commit messages is almost the same. In order to scale well, I divide conventional-changelog into a few smaller modules. conventional-commits-parser then became a standalone module and received a lot of improvements. For example, the regex of parsing <type>(<scope>): <subject> can handle a few more edge cases than the original one. A lot of useful features were added to better support conventional-changelog

I don't want to over sale it. conventional-commits-parser does have a few features that validate-commit-msg may not need. EG: parsing BREAKING CHANGE, Close #issue etc. Well when writing this I also think you might want to lint these in the future 😄

I believe the biggest win would be we can join force to only maintain one parser instead of two. It take a lot of effort to maintain open source projects and we are our full time work. I can see there's some issue that might related to the parser which was already solved in conventional-commits-parser (https://github.com/kentcdodds/validate-commit-msg/issues/18).

cc @jimthedev

[jimthedev]

Hi @stevemao. Good to know. I'll have to check it out further.

Commitizen itself probably won't use it since we (selfishly / naively) don't actually care much about semantics at the moment. We're really just a wrapper for git that accepts a string.

Commitizen has lots of adapters customized for the business/organization to allow for custom fields or to modify/delete some of the conventional-changelog fields that they don't use or are confusing for their use cases. For example a business might want to add a field for what company requested the change or a billing code that this commit applies to. Some additional examples are:

1. I want to use the cz-conventional-changelog adapter but remove scope.
2. I want to use the cz-conventional-changelog adapter but want to use icons for my enums.

While teams love this feature, it can be limiting because much of the tooling outside of Commitizen is pretty strict when it comes to how your commit message string must be formatted.

Custom adapter authors may add semantics in their commit messages that are not understood by parsers/validators/semantic release. The reason for this is actually pretty clear: they're writing their own programming language (using strings to represent semantics). If they decide to go out of bounds then they have to write a parser and validator to go along with their new programming language and semantics. This begs the question, how do you have both flexibility and strictness? It is probably also a debate between configuration and convention. My suspicion is that there is a happy medium or at least we can provide some good escape hatches for people wanting to define additional semantics.

[kentcdodds]

Hi friends! I haven't taken the time to read this thread yet. But I should say that I have very little interest in maintaining this project any further, so if anyone wants to take it from me (or if we want to consolidate on another solution) that'd be awesome.

[jimthedev]

@stevemao Do you want to move this repo into conventional-changelog?

[stevemao]

@jimthedev love to 😄 I can add you guys to the org. No problem!

[Garbee]

Looking over the parser I don't see any reason to not take advantage of it. All it does is alleviate some of the parsing to keep what the message validator logic as concise as possible (and alleviate more maintenance internally.)

I'll take a look at implementing this while I work on my V2 redesign concept.

[stevemao]

The parser returns a simple object with all the information you need about the commit message. It means the validation on each part could be generic. EG: you could warn if BREAKING CHANGE is written as Breaking changes or Fixes #1 as resolves #1 etc... Types could have the same config as scope, EG:

"types": {
    required: true,
    allowed: ["feat", "fix", "docs", "style"],
    multiple: false // default
  },
  "scope": {
    required: false,
    allowed: ['button', 'card'],
    multiple: true
  },
 "references.action": {
    required: true,
    allowed: ['Fixes', 'Closes'],
    multiple: true
}

[hutson]

This package has been deprecated. Please use https://github.com/marionebl/commitlint instead.