Semantic releases

[danilowoz]

Goals

Over time as the project grows, it's important to keep the project as easy as possible to maintain and publish new versions without the publishers' role, leaving them to work on what matters and saving time. That said, we might consider for this very first step the following requirements to consider it as a successful process of releasing a new version:

Must-have:

• Bump version on package.json;
• Create git-tag and push it;
• Create git-release and push it;
• Generate different version for each workspace/package;
• Push this new version to npm-registry;

Nice to have:

• Generate beta versions;
• Changelog file;
• Commenting on the mentioned issue;

Solution

Semantic-release is the most popular and go-to solution for automated version management and package publishing, using the semver convention. Plus, it provides many plugins (from npm, GitHub to changelogs), and it has a great community around it.

Also, it takes advantage of the commit message conventions to determine the intended version to be released, which is very interesting but lead us to others concerns, like how strict we are willing to be to contribute to the project? Besides that, it'd require some kind of checking to make sure every message is following that format.

So, we have some open questions:

• How to manage releases in a monorepo environment?
  There are a few discussion around it, like here

• How strict we want to be? Should we enforce using the commit convention?
  If so, there are a few tools to make it easier, such as commitlint, and commitzen.

• Is there any kind of alternative or tool that does the same thing?
  Of course, we could explore and create an internal solution, but does it worth it?

• Who will assign the commits and releases to npm?
  All those steps require an account on GitHub and Npm, so I believe it would be a good idea to create a new account only for publishing tasks, like a codesandbox-bot account.

[smhutch]

I agree with using the semantic-release tools to help with this 👍

Some thoughts:

• Personally I think using commitlint is a better choice than commitzen. The problem with commitizen is that it runs before the linting/prettier checks we have, and isn't to everyones liking (i would prefer to just write my commits, not use a CLI). With commitlint, we run lint checks first, then write commit, then lint it. Commitlint is also easier to integrate into CI if needed.
• For open source projects, enforcing a commit convention creates a bit of friction for contributors. Perhaps we should make these rules less strict (a warning in CI), and the maintainer who merges the PR would be expected to squash and re-write the commit to match our conventions. For internal projects, I would be fine with enforcing a convention.
• I don't know of any better alternatives than the semantic-release ecosystem.

[alexnm]

From a discussion I had with Ives, it might be that there will be multiple packages brought into this monorepo as the sandpack open source ecosystem. Therefore, I would suggest we first do the things that are not impacted the monorepo vs single repos decision:

• commitlint or comitizen to ensure a standard
• github actions for publishing the packages when a new tag is created (this might be impacted by the decision to use lerna later and treat each package as an independent version or not)

[danilowoz]

Recently I've started to explorer more these ideas and how to make them work out in a monorepo scenario. Unfortunately, it seems that semantic-release still doesn't support multiples package, there this long and old thread giving the reasons and challenges to support it.

So I considered using Lerna for that since they support independent versions and conventional commits. As a result of this, I've made a POC to play around with these concepts. Here are a few points I learned in this exploration:

Basically, Lerna covers all points we considered in the first place:

• Bump independent versions for each package;
• Create conventional tag/release and push to git;
• Generate independents changelogs;
• Publish to npm;
• Commitlint package scope: custom rule to only accept a package name as the scope of commit message;
• And better: alpha/beta releases 🎉 ;

But unfortunately, there are a nice-have that Lerna still doesn't support:

• Release note;
• Comments on mention issues and pull-request;

However, as @alexnm said above, regardless of the approach we follow, we're already able to implement the commitlint/commitzen and the actions to publishing the tags in the npm.

[JayaKrishnaNamburu]

Hey, you can take a little inspiration from here - https://github.com/teleporthq/teleport-code-generators

• Repo uses a Monorepo setup using lerna
• Releases with GitHub Actions, whenever we have a version bump
• Changelog management using lerna-changelog

We did a little research before adopting options for the repo, you can check more of our findings here if it can help any
teleporthq/teleport-code-generators#77

We had a little write up here on using lerna - https://medium.com/@askjkrishna/scaffolding-a-project-using-lerna-and-lerna-changelog-cad6156f6f36