Support parsed module size and gzip module size

[whirlp00l]

Thanks very much for building this and it is really useful to track our bundle status.

One thing we noticed was that the webpack stats file only contains the original size of modules, which do provide some level of information but are not that useful for understanding the production code.

Some other projects do have such kind of support: https://github.com/webpack-contrib/webpack-bundle-analyzer/issues/61 https://github.com/webpack-contrib/webpack-bundle-analyzer/issues/6

Wondering if we could do something similar with bundle-stats?

[vio]

thanks for opening the issue @whirlp00l !

The problem of only showing stat size (webpack stats) appeared couple times, but since the focus was on comparison and differences over time, the request did not make it to the board.

I am already having in my backlog to investigate if we can use webpack-bundle-anlyzer or source-map-explorer JSON reports.

If bundle-stats will be able to consume multiple data sources(webpack stats, webpack-bundle-analyzer/source-map-explorer reports), will you expect to see multiple bundle-stats reports for each source or one report with merged data?

[whirlp00l]

Thanks @vio for the quick response, yup I think the major focus on the comparison and diff already gives an awesome insight with the change data, and glad to know you already considering adding some additional support data in the following iteration.

My two-cent here is the merged report will be more useful, the report could let the user select the main size which used for compare, and provides additional data with a mouseover/click on the size data (similar to what we have for the module-chunk belonging). How do you feel about that?

[vio]

the report could let the user select the main size which used for compare, and provides additional data with a mouseover/click on the size data (similar to what we have for the module-chunk belonging). How do you feel about that?

I think that could work, though not sure how will that look in combination with the assets. webpack-bundle-analyzer is providing the gzip data only for javascript files, while the assets can have other resources that do not have a gzip size and they are used in computing global metrics (eg: total bundle size).

I am planning to explore a bit the problem in ~ 1 month

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[LucasMatuszewski]

Hey @vio - first, many thanks for building Relative CI - thanks to you I have just noticed that next-intl package I've installed has some dependencies (according to Bundlephobia it should not have any). This information was so well visible in your report, it's awesome!

But... we always use gzip values with other tools, like Bundle Analyzer or BundlePhobia, etc.

It would be great to have the option to enable at least some estimations next to normal numbers, how big the asset will probably be after gzipping (you can add a tooltip to inform, that it's only an estimation).

Of course, it would be best to see real parsed/minified and gzipped values, but I guess we would have to provide a different stats.json file?

Maybe it's already possible and I can just change my settings to provide different json data?

I use your default @relative-ci/agent in Next.js app. I have the Next Bundle Analyzes configured separately.

If it's not possible, maybe you have some plans to add this option in the future?

[vio]

hi @LucasMatuszewski, that's great to hear! 🙇

Currently, we are consuming only the webpack stats. For modules, webpack reports the size before any production optimizations (minification, tree shaking). We are considering possible ways to get the resulting size of the modules, but nothing has been planned yet.

While a solution will need to work across all the agents/setups/ingestion, it is currently possible to POC a solution by altering the stats file before sending it to the service:

1. export webpack stats JSON file
2. process the file and replace sizes with data from sourcemaps or another tool(bundle-analyzer)
3. send the resulting JSON to the service using the agent CLI

The issue is high on the backlog, I hope to start investigating it in the next 2-3 months. In the meantime, I am open to user-land proposals using a transformer on the webpack stats JSON file.