Releasing prerelease versions without modifying package.json files

Affected Packages

Problem

Let’s say we have a UI library that is actively developed and releases are happening multiple times from different branches. The releases from branches are happening for testing or experimentation. These releases should happen with prerelease version numbers.

There’s active development on master and on the different branches, so the versions are being modified all the time. As a result, merges and/or rebases are extremely hard due to the conflicts in the version numbers.

Proposed solution

There should be a way to publish prerelease versions without modifications to package.json files. This way, only the regular publishes on master will modify the versions in manifests and conflicts will never happen.

[emmatown]

We definitely want to do something like this. We documented what we wanted this to look like when we first implemented prereleases in our dictionary but we haven’t got around to actually implementing it.

snapshot prerelease - A snapshot prerelease is intended to make it easy to test all changes at a particular git commit. It is published at 0.0.0 and uses the git hash as the tag. This should be used as a less formal method than a release candidate to make it easy to install and test changes. An example, if we have a package at 1.0.0, and have a changeset for it to be major bumpred, a snapshot release will be at 0.0.0-ABCDEFGH (the last github hash). If we add more commits, the next snapshot would be 0.0.0-HIJKLMNOP.

IIRC, the command we wanted was changeset pre snapshot <tag>. It would set all the versions to 0.0.0-tag-hash and update that in all the dependents, publish all the packages to the dist tag that was specified and then undo the changes.

[Noviny]

❤️ Thanks @ajaymathur