conversionxl / lint-staged-config

CXL lint-staged configuration
0 stars 2 forks source link

refactor: customize commitlint rules #4

Closed pawelkmpt closed 2 years ago

pawelkmpt commented 2 years ago

Adjust commitlint rules to follow semantic commit messages and good practices.

Base commitlint config @commitlint/config-conventional follows https://www.conventionalcommits.org/en/v1.0.0/ but what we do is slightly different.

lkraav commented 2 years ago

Are we somehow able to run this ruleset vs all repo commit messages, and find out how it reacts, what will it complain about?

That could be the best available way to determine the rules that actually make sense.

For example, 80 char width is a relic from ancient times, although, it might still make sense for paragraph readability, just like web page. But occasionally, scope descriptions are lengthy. I personally don't like multi-line commit messages at all, but maybe need to grow into them.

pawelkmpt commented 2 years ago

Are we somehow able to run this ruleset vs all repo commit messages, and find out how it reacts, what will it complain about?

Yes. Run following command in the repo main directory (with ruleset present).

 npx commitlint --from HEAD~30 --to HEAD --verbose

For example, 80 char width is a relic from ancient times, although, it might still make sense for paragraph readability, just like web page. But occasionally, scope descriptions are lengthy. I personally don't like multi-line commit messages at all, but maybe need to grow into them.

Maybe we can make body 100 but keep header 72.

pawelkmpt commented 2 years ago

@lkraav could you look at it again? I'd like to merge it.

saas786 commented 2 years ago

I personally like: tweak & enhancement as types, have to think about using refactor or fix otherwise. Which doesn't make sense to me at least to use as an alternatives to tweak & enhancement.

pawelkmpt commented 2 years ago

I personally like: tweak & enhancement as types, have to think about using refactor or fix otherwise. Which doesn't make sense to me at least to use as an alternatives to tweak & enhancement.

fix is quite obvious for me, but I agree that tweak would be useful in some cases instead of using refactor.

But there's a risk of log ending up with tweak for everything.

@saas786 do you know any good repositories which we could look at?

lkraav commented 2 years ago

fix is quite obvious for me, but I agree that tweak would be useful in some cases instead of using refactor.

No. Less choices and decisions load === better.

Refactor - something just works differently, or better Fix - shit was crashing, or completely broken in some other way

saas786 commented 2 years ago

I personally like: tweak & enhancement as types, have to think about using refactor or fix otherwise. Which doesn't make sense to me at least to use as an alternatives to tweak & enhancement.

fix is quite obvious for me, but I agree that tweak would be useful in some cases instead of using refactor.

But there's a risk of log ending up with tweak for everything.

@saas786 do you know any good repositories which we could look at?

I will have to look for such repos, as v. few utilize commitlint. But if find one, will let you know.