feat: Align with conventional-commits

[jorenbroekema]

Cool project!

Perhaps it would be nice to align with https://www.conventionalcommits.org/en/v1.0.0/#specification This specification is basically an industry standard, and lots of tooling and standards are built on top of it.

I know that it would require some changes and to remove the emojis in front of the commit type in the message, but it will really help with your commit history being read out and analyzed properly by external tooling that assume conventionalcommits used as the convention. One such example are automatically generated changelogs based on your commit history.

[devpolo]

Hi @jorenbroekema, Thank you for your contribution. I strongly agree with you! I wonder about the shortcuts:

• fe = feat:
• fi = fix:
• ch = chore:
• ci = ci:

It doesn’t look so valuable. What do you think of a simple gac <message> variant?

[jorenbroekema]

I guess my suggestion is more to do a breaking change and change the current commit message conventions to align with conventional commits. Everyone can create a shell alias for doing their own commit conventions, I think the power in this tool is to align on a commonly used convention so that developers don't have to create such aliases themselves, but for that, the tool should follow the most common convention(s), the current messages with the emojis seem to be quite arbitrarily chosen. I love emojis, but surely some people in my team would frown upon them.

[devpolo]

👋 Hi

I'll have time in the next weeks to improve this project and make some breaking changes to align with conventional commits.

For now, we have those commands:

commands	result
b	🐛 BUG FIX:
c	📦 CHORE:
d	📖 DOCS:
n	🚀 NEW RELEASE:
i	👌 IMPROVE:
r	🪚 REFACTOR:
s	🎨 STYLE:
t	🧪 TEST:
w	🛠 WORKING ON:
f	✅ FEAT:

What about?

commands	result
x	fix:
f	feat:
b	fix(🐛 bug):
c	feat(📦 chore):
d	feat(📚 docs):
i	feat(👌 improve):
n	feat(🚀 new release):
r	feat(🪚 refactor):
s	feat(🎨 style):
t	feat(🧪 test):
any message	any message

[jorenbroekema]

The tricky thing with things like fix(🐛 bug):

Is that conventional commits sees the () part as the scope, so basically:

chore(button): add docs

type --> chore scope --> button message --> add docs

Putting the type as feat and then a different type in the scope is quite confusing to me.

Furthermore, a chore is explicitly not a feature, we usually use that type if we want to commit work that is not a fix or a feature, which means it doesn't mandate a release of the thing.

For example, if you look at release orchestration tools, they sometimes take the commit type in order to generate changelog entries. Or they optionally use the scope to group changelog entries, decide which package needs a bump within a monorepository of multiple packages (scope = package there) etc.

commands	result
x	fix:
f	feat:
c	chore:
d	docs:
r	refactor:

is what I would go with. And yeah that's also because I don't see the point in emojis, they just clutter commit history and reduce readability in my personal opinion :P

[devpolo]

Ok :) Thanks for sharing your point of view.

I would love to create something like below. What is your opinion? Do you believe it is too verbose? Or useless?

command

gac f update button props -s button -b this button was uncompatible with a certain context -bc remove color props 

-s for --scope
-b for --body
-bc for --breaking-change

real command

git add -A 
git commit -m "feat(button)!: update button style" -m "this button was uncompatible with a certain context" -m "BREAKING CHANGE: remove color props"

result

feat(button)!: update button style

this button was uncompatible with a certain context

BREAKING CHANGE: remove color props

[jorenbroekema]

Yeah I think that makes sense.

It looks verbose on first sight but -s, -b and -bc are optional, so it's mostly verbose because you're creating a commit with additional body to the main message, and additional breaking change information.