Implementing Commitlint with Conventional Commit Configuration

[pplancq]

Hello,

This PR introduces commitlint configured with the conventional commit standard. The aim is to ensure that all commits adhere to a consistent style for better code management and readability, as indicated in issue #195.

Two levels of verification have been added:

1. Local verification through husky commit-msg, which checks each commit made locally.
2. A build workflow verification that checks all commits within a PR (only on a PR).

The build workflow has been revised for easier review, separating different stages (lint, test, build) into distinct steps. A package-lock verification stage has also been added. This was motivated by noticing frequent discrepancies between package.json and package-lock.json in several projects I've worked on.

The documentation has been updated to indicate that the project uses the conventional commit standard (pending approval of this PR).

Your review and feedback are appreciated.

Best.

[bencompton]

Nice! One concern I have at the moment is the release workflow expects a commit like Release v4.0.2, which I don't think will pass linting after this PR, right?

[pplancq]

Hello, my configuration excludes the commit annalize if it includes the word release

so normally this shouldn't be a problem.

[pplancq]

Oops, my current configuration is case-sensitive, so I'm going to do an update to fix that.

I'll take this opportunity to resolve any conflicts.

[pplancq]

I've corrected the conflicts.
You can see in the github action logs the commit validation with the convential commit.

Contributors will automatically see failed actions and can then correct their commit message.
However, this case will only arise if the contributor commits with the --no-verify option.

[bencompton]

Merged! 🥳

[github-actions]

🎉 This PR is included in version 4.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀