Proposal: Implementation of Conventional Commits and Semantic Release

[pplancq]

Description

I propose that we implement Conventional Commits for our commit messages. It's a very common convention and easy to learn.

Benefits

By adopting Conventional Commits, we can take advantage of tools such as Semantic Release, which offers the following benefits:

• Automated versioning: Semantic Release can automatically increment the version number (semver) according to validation messages.
• Change log generation: It can generate a changelog, providing a clear and concise history of changes.
• GitHub version generation: It can also generate GitHub versions, making it easier for users to see what's new in each version.

Implementation

If everyone agrees with this proposal, I can implement these tools with Commitlint to enforce commit message conventions.

I think the implementation of these tools could greatly benefit our project. I look forward to hearing from you.

[bencompton]

I have considered Semantic Release, but haven't implemented it due to lack of time. I'm also a fan of conventional commits, and my current team uses them religiously. I'd prefer that every merged PR doesn't automatically go out to everyone and introduce potentially breaking changes. My thought was maybe that every merged PR gets pushed to NPM tagged as @Next or something and then perhaps have a GitHub Action to manually release a specific version on the main channel.

As of now, there is a GitHub Action that does a release when the version in package.json is changed, but a continuous delivery setup would be preferred so folks can have quicker access to changes from NPM in the case that an official release is taking longer than expected. A PR along those lines would certainly be much appreciated.

[pplancq]

I think we could do this in several stages.

As you're already used to it, we can already use conventional commit, I can do a PR to add commitlint to the project.

As for semantic-release, I've only used it to make releases on the main branch. I know it can handle pre-releases, but it seems to me that this has to go through a branch (next or beta).
So what we could do, if you agree, is to modify the release workflow to integrate semantic-release with a manual trigger on your part. This is to avoid introducing bugs or releasing an unstable version. I can also take care of this PR.

As far as releasing a pre-release is concerned, I tend to agree, but I don't think it's a good idea to do it every PR. How about using a cron like once a week or once a month?
I'd have to test semantic-release on my side to see if it would be possible to generate pre-releases from the main branch.

[bencompton]

TL;DR - improving the automated checks is probably the next step, and then we could probably use semantic-release with its out of the box release process assuming enforcing conventional commits is a process that can work well.

So I am a fan of conventional commits, but not positive how it would work with a public repo having commitlint enabled to ensure all contributors are compliant. Maybe there are other projects already doing this and it works well? I know the Dependabot commit prefix is configurable at least.

It’s also possible I’m overcomplicating the release process by insisting on a non-stable channel. I am quite accustomed to anything merging to the main branch being released in my day job. A big part of the problem is that I still feel the need to validate manually before releasing because the integration tests in #148 only ever got halfway completed. Some additional checks might be useful as well, like something looking for warning logs and the like and also validating test coverage. Sometimes, I have merged PRs to the main branch and then done some additional tweaks, although I could merge PRs to another branch, do the tweaks, and only merge once it’s good to be released in such situations.

Once we’re more confident in the checks, Dependabot PRs could possibly automatically merge and release as well if we could automatically respect semver for updated packages, especially Jest, and that would automate a good portion of the maintenance of this package.

The changes from your last PR will be incredibly helpful in this regard as well, since there have been PRs where I’ve had to manually fix code styling issues in the past. For example, #165 is something I’d like to merge that has uncaught style issues. Again, very much appreciated!

[pplancq]

Hello,

I agree with you, if a large number of processes are automated it will make your repo management easier.

I agree with you, automating a large number of processes will make your repo management easier.

Regarding tests, yes they are needed to validate the code when merging a PR, what you can do is pin issue #148 so that it is visible and everyone can contribute to improving the tests.

As for using the conventional commit, for me, whether it's a public or private repo, from my point of view you are the project manager and/or technical lead, so if you decide you need to use that commit convention then we'll use it, and you've recently added a contributing.md which is just to explain how to contribute.

I'm going to propose a PR that adds an automatic commit convention check, personally I like this check to be done at commit time using a commit hook, so commitlint provides a sample Github action that allows you to do this check for PR commits.
Another solution would be to overwrite the commits when merging a PR, which would allow you to format the commit to your liking, but this involves a complex manual action on your part, and I understand that you don't have a lot of time.

For the semantic release part, this can be done a little later (once all the tests have been written and the commit convention has been adopted). I'll look into a solution that might suit you.

[github-actions]

🎉 This issue has been resolved in version 4.1.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀