[internal] Prevent unstable chunks in size snapshot#23181
Conversation
|
@material-ui/core: parsed: -11.45% 😍, gzip: -8.01% 😍 |
probably not tested thoroughly sine cache is off by default in prod mode
Didn't know it supports multi-config
oliviertassinari
left a comment
There was a problem hiding this comment.
For easier debugging of the bundle size you can now run yarn size:snapshot --analyze which creates static reports for each bundle that can be inspected. We're not using the server since that would open >100 ports.
Nice, I have tried it, I wanted to understand why the createMuiTheme() is large:
I wonder if there is a way to have more granular information than the "concatenated" rectangle.
@oliviertassinari In the left side bar enable I also added a $ node scripts/sizeSnapshot/create --help
create
Saves a size snapshot in size-snapshot.json
Options:
--help Show help [boolean]
--analyze Creates a webpack-bundle-analyzer report for each
bundle. [boolean] [default: false]
--accurateBundles Displays used bundles accurately at the cost of
accurate bundle size. [boolean] [default: false] |
stable chunks
Previously we ran
webpackonce with each package being an entry. This means that webpack creates chunks that are shared by different packages. For example,@material-ui/coreand@material-ui/labcould share some part of@material-ui/styles. This results in the reported size of@material-ui/corebeing affected by changes in
@material-ui/lab.We're now running separate webpack compiler instances for each package to prevent shared chunks. We didn't do this previously because of perf considerations. However, perf shouldn't affect results. Caching the terser results improves perf while not changing results. Runs with cache hits are as fast as previously versions of this scripts but cache misses result in considerably slower runs in CI (local should be fine unless you have a single core machine) but are still faster then the full pipeline (argos completes). The slowness isn't as big of a problem for the initial run anymore since the time until the comment is reserved stays the same.
The reported sizes should be a lot more stable and accurate. We should get this in before #21761 since the reported size in that PR is weird.
size:snapshot --analyze
For easier debugging of the bundle size you can now run
yarn size:snapshot --analyzewhich creates static reports for each bundle that can be inspected. We're not using the server since that would open >100 ports.