NPM Version Management Strategy

[Thels]

Currently whenever anyone makes a change to shared or cli - we need to manually update the version of the CLI being published to avoid collisions in NPM. This is a pain and something that should be addressed.

There are many tools out there that do this for us - most opting to use https://semver.org/ in some form to easier represent major/minor/patch releases.

There are a number of options available for us to choose from, so I'll list out the options and we can decide between us what to progress with at the next office hours call. The outcome of these tools are the same, just done differently with different extensibility and customization options.

• semantic-release
  • Features:
    • Fully automated versioning and package publishing.
    • Generates release notes and changelogs.
    • Integrates with CI/CD pipelines.
    • Supports plugins for customization.
  • Pros:
    • Highly automated, reducing manual intervention.
    • Comprehensive plugin ecosystem.
    • Strong community support.
  • Cons:
    • Can be complex to set up initially.
• standard-version
  • Features:
    • Automates versioning and changelog generation.
    • Follows conventional commit format.
  • Pros:
    • Simple to set up and use.
    • Lightweight and straightforward.
  • Cons:
    • Less automated compared to semantic-release.
    • Requires manual publishing.
• release-it
  • Features:
    • Versatile release tool with versioning, changelog generation, and publishing.
    • Highly configurable with plugin support.
  • Pros:
    • Flexible and customizable.
    • Supports various version control systems.
  • Cons:
    • Requires more configuration.
    • Not as automated as semantic-release.
• changesets
  • Features:
    • Manages versioning and changelogs with a focus on monorepos.
    • Allows manual control over versioning and changelog entries.
  • Pros:
    • Great for monorepos.
    • Provides manual control over releases.
  • Cons:
    • Less automated.
    • Requires more manual intervention.

Many of the above tools rely on the commit messages of what we're merging reflecting the "angular" style of commits.

• feature/feat: triggers a minor release
• fix: triggers a patch release
• breaking: triggers a major release

To enforce this, we could look at using tools like;

• Commitzen - a tool which changes the commit workflow to ensure they meet the requirements of the code-base.
• CommitLint - a pre-commit hook to enforce commits are in the format we expect.

Based on the comparison, I would recommend going with a combination of semantic-release and Commitzen for the following reasons:

• It offers a high level of automation, reducing the need for manual intervention.
• It has a comprehensive plugin ecosystem, allowing for extensive customization.
• It integrates well with CI/CD pipelines, ensuring a smooth release process.
• No need to commit and then get rejected by hooks, know at the point your commit is written that it meets the code-base standards.

Post agreement, this issue will cover the implementation too.