I had a look at your library and I think git-conventional and conventional-commit-parser are both decent libraries for parsing conventional commits. (Using pest is a good idea) However, in this case, I'd like to stick with git-conventional because it has serde support and I personally think @epage is doing a good job maintaining the library. He was very responsive and helpful about the issues that popped up regarding git-cliff in the past months.

Let me know if I can help with anything else :)

@oknozor Any thoughts on collaborating?

I will admit, I've had bad experiences in the past with pest and much prefer nom. Unsure if that will be a deal breaker or not. I am working with the nom maintainers to improve its readability.

@epage I'd be glad to contribute if needed, but I have never used nom before. Also regarding your experience with pest this issue might be interesting.

When I made conventional-commit-parser I was not aware about git-conventional. I have just made a quick poc to migrate from git-conventional to conventional-commit-parser. Turns out the API is 95% similar (you can see the diff here), so like I said before I would be happy to drop conventional-commit-parser and use git-conventional.

There is one thing that puzzle me though : In the migration attempt I made the main test is failing :

Diff < left / right > :
<"# Changelog\n## Unreleased\n\n### Bug Fixes\n#### app\n- fix abc\n\n### New features\n#### app\n- add xyz\n\n### Other\n#### app\n- document zyx\n\n#### ui\n- do boring stuff\n\n## Release [v1.0.0] - 1971-08-02\n(0bc123)\n\n### Bug Fixes\n#### ui\n- fix more stuff\n\n### New features\n#### app\n- add cool features\n\n#### other\n- support unscoped commits\n\n### Other\n#### app\n- do nothing\n\n#### ui\n- make good stuff\n------------"
>"# Changelog\n## Unreleased\n\n### Bug Fixes\n#### app\n- fix abc\n\n### New features\n#### app\n- add xyz\n\n### Other\n#### app\n- document zyx\n\n#### ui\n- do boring stuff\n\n## Release [v1.0.0] - 1971-08-02\n(0bc123)\n\n### Bug Fixes\n#### ui\n- fix more stuff\n\n### New features\n#### app\n- add cool features\n\n### Other\n#### app\n- do nothing\n\n#### ui\n- make good stuff\n------------"

All commit are parsed correctly but one is not displayed in the final output, I was not able to find why. I'd be curious to know what is causing this. @orhun any idea ?

I will try switching to git-conventional on cocogitto's side and let you know how it goes.

That describes the biggest issue I have with pest (my equivalent post for nom). The slightly less important one is I'm not happy with is the compile times from being a proc-macro doing code-gen.

All commit are parsed correctly but one is not displayed in the final output, I was not able to find why. I'd be curious to know what is causing this. @orhun any idea ?

It seems like this commit is not processed:

feat: support unscoped commits

Support for these types of commits was added with #8. You can check out the implementation here. Maybe there is an API difference between two libraries.

edit: this change seems like the issue: oknozor@7088bc6#diff-fb8ea8d3a2eea059cc2540308b82d45fd5194ec545a113394ea3a75bcba3bad1R148

I think you can close this now, just so you now I tried integrating both git-conventional and the latest conventional-commit-parser in cocogitto.
Took me a while (and it was painful) to adjust lifetime bounds to make cocogitto work with git-conventional, the cocogitto code base ended less readable with almost no perf improvement, so I have decided to switch back to previous version of conventional-commit-parser that returns owned value.