chore(ci): create v2 alpha release workflow

[dreamorosi]

Description of your changes

This PR introduces a new workflow that allows to publish pre-releases of our Powertools utilities to the npm registry.

The workflow is expected to last for the duration of the pre-release period and for this reason it takes some important shortcuts that make it deviate from the original release workflow. Contrary to most of the PRs related to v2 this one must be merged to main otherwise GitHub won't show the workflow as available.

Nevertheless, the workflow is expected to run always using the feat/v2 branch and never on main.

No persistence

The workflow doesn't generate git tags, change logs, nor version increment commit.

Since the workflow is expected to run on the v2 branch, which might have been rebased with main more or less recently, it always assumes that the version present in the lerna.json file or any of the package.json files is the current one.

From this assumption it always creates a major version which will always default to 2.0.0. Once that's done it'll query the npm registry and check the version of the latest pre-release available (i.e. 2.0.0-alpha.0) and will use that number to determine the next increment (i.e. 2.0.0-alpha.0 -> 2.0.0-alpha.1).

It will then add this suffix out of band right before publishing the packages to npm.

Automatic UA string increment

This is a change that technically speaking was not essential nor necessary, however given the lower stakes a pre-release I opted for sneaking in this behavior so that we can test it and eventually back-port it to main.

The workflow will use the release version determined in the previous step to update the contents of the packages/commons/src/version.ts file so that the full release won't require any manual intervention.

Build

The workflow uses a new method of building that will be introduced in a future PR and that allows us to generate double builds for CJS/ESM.

At the moment it will call a placeholder script (build:prod), the actual script will be implemented in each utility in dedicated PRs.

Pack & Publish

The workflow then packs the utility (aka creates tarballs for each one of them) and then publishes them under the next tag.

Using the next tag will allow customers to

Others

As part of the versioning process the workflow will also run a script that injects a postinstall script in each utility. This script will log a warning every time a utility is installed informing customers that the version they're using is a prerelease and should not be used in production.

The script is not part of this PR but can be found here. We want the script to be on the v2 branch instead of this one (main) so that it's run only when publishing pre-releases.

Related issues, RFCs

Issue number: closes #1717

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information