Add a "semver" field for each emoji

Summary

I would like to see a doc (ideally part of website, but maybe just something checked into the repo) that lays out how various emojis should map to conventional-commits.

Why?

There are many tools today that can parse conventional commits. I often would like to propose to authors of these tools to support conventional commits or gitmoji, but how to do so is pretty wishy-washy (compared to the very formal definition of conventional-commits).

For example, I’d probably suggest “💥 Drop node v8 support” be parsed equivalently to “feat!: Drop node v8 support”, “✨ Add a new button” be parsed equivalently to “feat: Add a new button”, “🐛 Fix something” be parsed as “fix: Fix something”, and then everything else just also gets “fix:”.

(This isn’t ideal, because there are a lot of obvious mappings, like “📝 Add a new paragraph” is clearly intended to be “doc: Add a new paragraph”. If we mapped out that relationship, it would be easier to propose support to tool authors.)

Why bother if you can just use both conventional-commits and gitmoji?

I’ve seen this, but I don’t like it. A good example is the https://github.com/vivaxy/gacp project, which creates commit messages that follow conventional-commits standard and contain gitmoji emojis.

I have two issues with this:

1. It’s double-accounting. Commits like feat: :sparkles: add a feature and BREAKING CHANGE: :boom: make a change are just saying the exact same thing twice in different ways, defeating the whole purpose of using the emojis.

2. It looks really bad. If the emoji can’t be the very first character, it ruins the effect of an all-gitmoji repo (where the commits are lined up and easily parseable). If combining gitmoji and conventional-commits resulted in :sparkles: feat: add a feature, I guess that would be better, but look at the gacp project link above to see how hard it is to even find the emoji when it is not lined up in the commit message.

Could conventional-commit change to support gitmoji?

Maybe. I find it very doubtful, but could conventional-commit make a change to their rules that says:

You can prefix any <type> with a phrase surrounded by colons.

This would let :boom: feat!: Big API change be a valid conventional-commit message, and fixes my Complaint (2). But it’s still double-accounting.

For this reason, I think that even if conventional-commits would be willing to bend to accomodate prefixed emojis, it’s not the best case. The best case would be to craft a formalized way to interpret gitmoji, so that asking a tool author to support gitmoji is just like asking a tool to output YAML as well as JSON, etc.

Any thoughts? Pros/cons?

[nkmr-jp]

Hello ! I wrote a script that adds a semver field to gitmojis.json. Until the semver field is officially added, I think this will be useful. It’s easy to edit with a yaml file.

# semver.yml
semver:
  major: [ boom ]
  minor: [ sparkles ]
  patch: [ bug, ambulance ]

genelate gitmojis.json file with semver field

$ cat build/dist/gitmojis.json | jq '.gitmojis[] | select(.name=="sparkles")'
{
  "emoji": "✨",
  "entity": "✨",
  "code": ":sparkles:",
  "description": "Introduce new features.",
  "name": "sparkles",
  "semver": "minor"
}

https://github.com/nkmr-jp/gitmoji-semver

[frinyvonnick]

On gitmoji-changelog we grouped the commits using emojies into categories like added, breaking changes, … Here is our configuration file. It could be useful to have this semver property to put commits into some categories. For example emojies of type major should go into breaking changes category. But it won’t replace totally our configuration file.