search

mui / material-ui

Material UI: Ready-to-use foundational React components, free forever. It includes Material UI, which implements Google's Material Design.
https://mui.com/material-ui/
MIT License
91.86k stars 31.57k forks source link

[code-infra] Add canary release scripts #41949

Closed michaldudak closed 1 week ago

michaldudak commented 1 month ago

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:

  1. Check if there are any uncommitted changes. Fail if there are.
  2. Set up .npmrc to look for an access token in an enviroment variable.
  3. Figure out which packages changed between this and the previous commit.
  4. Update package.json of the changed packages, adding the -dev.[yyMMddHHmmss] suffix.
  5. Publish the changed packages.
  6. 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.

mui-bot commented 1 month ago

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

Janpot commented 1 month ago

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

michaldudak commented 1 month ago

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?

Janpot commented 1 month ago

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

michaldudak commented 3 weeks ago

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).

michaldudak commented 3 weeks ago

I did a test run - the resulting packages were published to npm with the -dev.240424162023-9968b4889d suffix:

michaldudak commented 1 week ago

Updated the version number to reflect the commit date and changed the format to -dev.yyyyMMdd-hhmmss-sha (for example @mui/material@6.0.0-dev.20240507-080616-4ea4f9e382)

michaldudak commented 1 week ago

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.