Support for canary releases based on changesets?

Hi there!

We at The Guild are working with changesets extensively. One of the solution we implement on top of the current implementation of changesets is the ability to easily connect canary/alpha releases, based on active changesets.

To do that, we are applying a minimal patch file to changesets code, in order to allow flexibility in the release flow.

I’m sharing an overview of the technical changes we are doing today, and I can also create a PR if this makes sense. I was thinking of a workflow of changesets version canary in the CLI.

The canary / alpha workflows

1. To release a canary based on changesets, we are scanning and reading all relevant changesets that are currently available in the repo.
2. Then, we run assembleReleasePlan and builds the complete plan as changesets plan to release it (on the next release planned)
3. Then, we modify the version to be {plannedVersion}-canary.{COMMIT_ID}
4. Run applyReleasePlan to apply the change temporarily
5. Run changesets publishing script with --tag canary

Here’s the script we are using: https://github.com/B2o5T/graphql-eslint/blob/master/scripts/canary-release.ts

This way - changesets are used as the source of truth to the packages that actually was changed and needs to be released - and we apply an empheral change to the versioning before publishing it to npm.

Allowing non-ranged publishing

As part of the canary release workflows, we want to make sure to get rid of all possible ranges (^ / ~) in the internal packages dependencies, to make sure to get the exact versions of the canary changes.

To do that, we added a new argument to versionPackage function, called ignoreRange

Reference: https://github.com/B2o5T/graphql-eslint/blob/master/patches/%40changesets%2Bapply-release-plan%2B6.0.0.patch#L19

[Andarist]

It might actually be somewhat nice to have those generated because you might always easily check in the package itself what kind of a change has been published in a given snapshot release.

[emmatown]

This sounds like snapshot releases (or at least the intent behind them).

{plannedVersion}-canary.{COMMIT_ID}

Using plannedVersion instead of 0.0.0 can be done with ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.useCalculatedVersionForSnapshots though you can’t currently use a commit.

@Andarist I’m kinda thinking we should have a “snapshot version template” config option,

So you could make have some variables that we provide like:

• tag
• commit
• timestamp
• plannedVersion (v not sure about this name)

and the default would be 0.0.0-{tag}-{timestamp} to align with the current behavior and you could express whatever and it would replace ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.useCalculatedVersionForSnapshots and #830.

Allowing non-ranged publishing

Snapshot releases should definitely use exact versions for dependencies (I’m surprised that’s not already true tbh). Do you want to create a PR for that?