Add Changesets and update release actions #56
Conversation
|
You are of course welcome to do what you think is best for this project, but I do think the canary stuff adds a level of complexity that's solved very well by CodeSandbox CI. This allows any contributor to get a "canary" build from their PR, which is the ideal DX in my opinion. Every PR gets a comment with a link to builds that can be |
|
I see. From what I can gather, I like the idea of giving individual PR's a Sandbox where the library can be immediately tested and installed as a dependency from the registry. I don't know if CodeSandbox CI allows you to actually publish those changes to the NPM registry, but if this is not the case, I think we're trying to solve for two different problems here:
The main point here being that Let me know if you'd recommend me going trough with both approaches, or just dropping the canary release workflow and sticking with the CodeSandbox CI releases, both approaches are okay for me. |
|
@ernestoresende yeah - they're not mutually exclusive, so if you like the canary workflow don't let me stop you. As always, this is more your project than mine; I'm just here to guide. The codesandbox builds are This is also a pretty reversible decision, so feel free to go forward with both and see if you prefer one workflow over the other 👍 |
| "changedFilePatterns": ["src/**"], | ||
| "snapshot": { | ||
| "useCalculatedVersion": true, | ||
| "prereleaseTemplate": "{tag}.{commit}" |
There was a problem hiding this comment.
Not a blocker - but if you wanted to release a normal alpha, rc, etc, you'd be stuck with the commit hash on the version as well?
| const [major, minor, patch] = oldVersion.split('.').map(Number); | ||
| const newVersion = `${major}.${minor}.${patch + 1}-canary.${commitHash}`; | ||
| pkg.version = newVersion; | ||
| const content = JSON.stringify(pkg, null, '\t') + '\n'; |
There was a problem hiding this comment.
Never actually seen a \t used here, typically it's a 2. I guess this depends on if the project uses tabs or spaces? Haven't thought about that in a long time :)
| const content = JSON.stringify(pkg, null, '\t') + '\n'; | |
| const content = JSON.stringify(pkg, null, 2) + '\n'; |
| // ORIGINALLY FROM CLOUDFLARE WRANGLER: | ||
| // https://github.com/cloudflare/wrangler2/blob/main/.github/changeset-version.js | ||
|
|
||
| import { exec } from 'child_process'; | ||
| // This script is used by the `release.yml` workflow to update the version of the packages being released. | ||
| // The standard step is only to run `changeset version` but this does not update the package-lock.json file. | ||
| // So we also run `npm install`, which does this update. | ||
| // This is a workaround until this is handled automatically by `changeset version`. | ||
| // See https://github.com/changesets/changesets/issues/421. | ||
| exec('npx changeset version'); | ||
| exec('npm install'); |
There was a problem hiding this comment.
This can just be an npm script, fine as is too. We do the same thing in Apollo Server.
This introduces Changesets as part of the publishing pipeline and sets up the actions necessary to handle
canaryreleases.With this setup, any new commits to
canarybranch will automatically create a new release with the tagx.x.x-canary.{commitHash}. Canary releases will not show up in the Releases page from GitHub (let me know if this is not the wanted behavior).Beware that in this setup,
canaryreleases are not using the snapshot release feature from Changesets, as the idea is to automatically generatecanaryreleases off the corresponding branch. We can still manually use the Snapshot feature and alter the template in"prereleaseTemplate": "{tag}.{commit}"if we need to trigger other kinds of manual and/or CI releases.