Set commit message convention for chainlit and literal

[clementsirieix]

Changes

• Add basic commitlint support to enforce conventional commit

How to test?

• pnpm install
• Add a dummy change
• Test a commit git commit -m "foo"
• Notice that you get an error
• Test a valid commit git commit -m "chore: test dummy commit"
• Notice that it works

[tpatel]

Thanks for the clean PR @clementsirieix. I love this convention, however I'm afraid this won't work for this repository.

Usually the development flow is:

1. A contributor creates a PR with a bunch of commits (they don't need to follow the convention because of point 2).
2. The PR is squashed into one commit. This commit can't be checked with the husky automation.

[clementsirieix]

@tpatel thanks for the review, you are right to point that the husky automation can not enforce the rule on squashed commits.
That said I do not think this is an issue, our contributors may or may not follow the convention but what matters is the ability for the maintainer to review the history. Here is what the documentation has to say about this topic.
Wdyt?

[tpatel]

I'm not sure to understand your reply. When I read the link you've shared, I've found that conventional commit aren't required in our squash-based workflow.

If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they’re merged—adding no workload to casual committers.

I think merging this PR will force all committers to use conventional commits in their PR which adds friction to contributing, right?

[clementsirieix]

Closing to prevent friction.