Add commitizen to make it easier to follow the Commit Message Guidelines

[rikhall1515]

Description

This change makes it easier to follow the conventional commits standard by automatically using the commitizen CLI whenever you execute git commit (no -m flag).

Validation

I ran git commit, used the CLI, and commitizen worked as it should.

Related Issues

Check List

• [x] I have read the Contributing Guidelines and made commit messages that follow the guideline.
• [x] I have run npx turbo format to ensure the code follows the style guide.
• [x] I have run npx turbo test to check if all tests are passing.
• [x] I have run npx turbo build to check if the website builds without errors.
• [x] I've covered new added functionality with unit tests if necessary.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Jun 18, 2024 7:23pm

[rikhall1515]

I'm honestly debating if I should even keep commitlint in this change.

I've changed the config so that it's not terribly strict about the rules. It will allow sentence case, lower case, and anything in-between (in case of accidental typos).

More strictness just leads to a terrible developer experience because there is no easy way of integrating linting into the commit message file (that works on all IDEs). If you close the file, have it be linted, and then it fails; now you must redo the whole thing. I've checked and there isn't an easy way around that.

Also, you get 80% of the result anyway if you just use git commit and let commitizen do most of the work. Commitlint at this point only exists to prevent cases where the user intentionally avoids commitizen.

[ovflowd]

lso, you get 80% of the result anyway if you just use git commit and let commitizen do most of the work. Commitlint at this point only exi

I feel that if we are so permissive for commit messages, we lose the reasoning behind CommitLint, no?

I do believe adding Semantic Versioning would be great tho!!

[rikhall1515]

lso, you get 80% of the result anyway if you just use git commit and let commitizen do most of the work. Commitlint at this point only exi

I feel that if we are so permissive for commit messages, we lose the reasoning behind CommitLint, no?

I do believe adding Semantic Versioning would be great tho!!

Yeah you're right, I'll update the PR so it's just commitizen in that case.

[aymen94]

LGTM, @rikhall1515 thanks for contribution.

[rikhall1515]

I realize my most recent commit was perhaps unnecessary after reading the CONTRIBUTING.md a bit closer when it comes to rebasing/merging recent changes.

I assume there's nothing else I need to do right now in order for this PR to be merged?

[bmuenzenmeyer]

I assume there's nothing else I need to do right now in order for this PR to be merged?

I want to test it locally - also, there is a merge conflict that you cool look into

[rikhall1515]

Could someone check what the details are for the deployment? What I did is I copied the current upstream/main package-lock.json and package.json - then I did npm ci followed by adding the commitizen and cz-conventional-commits dependencies.

It should just work because I have not modified any files relating to the actual source code.

Definitely need to squash the changes on this PR 😅

[github-actions[bot]]

Running Lighthouse audit...

[github-actions[bot]]

Unit Test Coverage Report

Lines	Statements	Branches	Functions
	90.67% (593/654)	76.08% (175/230)	94.57% (122/129)

Unit Test Report

Tests	Skipped	Failures	Errors	Time
131	0 :zzz:	0 :x:	0 :fire:	6.419s :stopwatch:

[ovflowd]

Vercel is not happy with the changes :thinking:

Can we get a rebase here? That might (?) help

[rikhall1515]

Vercel is not happy with the changes 🤔

Can we get a rebase here? That might (?) help

@ovflowd I've re-opened the same PR so now it only has one commit.