material-ui
material-ui copied to clipboard
mui
[code-infra] Add canary release scripts
Created scripts in infra packages that can be used to publish them after each PR to the main (master or next) branch.
The workflow looks like this:
- Check if there are any uncommitted changes. Fail if there are.
- Set up .npmrc to look for an access token in an enviroment variable.
- Figure out which packages changed between this and the previous commit.
- Update package.json of the changed packages, adding the
-dev.[yyMMddHHmmss]suffix. - Publish the changed packages.
- Restore package.json files to the original state.
Runnning pnpm canary:release executes all these steps.
It requires an npm access token present in the NPM_TOKEN environment variable.
I'll create a GitHub action running the script in a separate PR, once this one is merged.
Netlify deploy preview
https://deploy-preview-41949--material-ui.netlify.app/
Bundle size report
No bundle size changes (Toolpad) No bundle size changes
Generated by :no_entry_sign: dangerJS against c7d71907cb8c78b8e5e57c4f413e82295d0c0c4c
I'm not 100% sure, but I think there is a problem with only publishing changed packages in this scenario
suppose A has a dependency on B start situation: A@v1=>B@v1 + B@v1 commit 1: only A changes => publish only A, new situation: A@v2=>B@v1 + B@v1, ✅ commit 2: only B changes => publish only B, new situation: A@v1=>B@v1 + B@v2, ❌ => don't have a version of A that points to B@v2
And even if you also publish everything with a dependency on B, then you get
commit 2: only B changes => publish B and dependants, new situation: A@v2=>B@v2 + B@v2, ✅
but now:
commit 3: only A changes => publish only A, new situation: A@v3=>B@v1 + B@v1, ❌ => doesn't know about B@v2 because repo always resets versions after publishing
Only correct way is to always publish everything, changes or not
commit 3: only A changes => publish everything, new situation: A@v3=>B@v3 + B@v3, ✅ => now B@v2 is incorporated in B@v3
Or am I misunderstanding how this works? If we can't rely on semver resolution then shouldn't the whole dependency tree reflect the desired situation, regardless of changes?
I'm also touching on this in https://www.notion.so/mui-org/code-infra-Release-process-299a2fb7fe93441b8e345af0b2fc4fb4?pvs=4#7ba482d1725147bc8f312b6836f64b5e
I see. The script publishes changed packages and all the packages that depend on it, but "=> doesn't know about B@v2 because repo always resets versions after publishing" is indeed a problem.
Only correct way is to always publish everything, changes or not
This will create a massive number of packages that are essentially the same (especially considering that we don't change the infra code very often). How about we check for changes between the last commit and the last stable release instead?
How about we check for changes between the last commit and the last stable release instead?
That could also work, if that's what we already do for stable releases anyway, I don't see an immediate problem with it. I'm changing https://www.notion.so/mui-org/code-infra-Release-process-299a2fb7fe93441b8e345af0b2fc4fb4?pvs=4#7ba482d1725147bc8f312b6836f64b5e
I ended up actually implementing both: first, the script checks if there are any changes in public packages between this and the previous commit (there is no point in releasing packages if nothing changed). Then we look for differences between this commit and the latest tag (or any other commit - this is configurable).
I did a test run - the resulting packages were published to npm with the -dev.240424162023-9968b4889d suffix:
- @mui/codemod
- @mui/core-downloads-tracker
- @mui/joy
- @mui/material
- @mui/docs
- @mui/icons-material
- @mui/lab
- @mui/material-nextjs
- @mui/styles
- @mui/system
Updated the version number to reflect the commit date and changed the format to -dev.yyyyMMdd-hhmmss-sha (for example @mui/[email protected])
One more addition I made - the ability to ignore certain packages. I thought it could be useful to prevent uploading the huge @mui/icons-material after each commit.