UI - treemap charts

[vio]

Rel: #624 Ref: https://github.com/webpack-contrib/webpack-bundle-analyzer/issues/187

[jflayhart]

I think this should be rather trivial since we're already generating the stats.json file from webpack, simply generate the HTML file along with it using webpack-bundle-analyzer and link to it.

[jflayhart]

Which webpack file(s) need to be updated to add webpack-bundle-analyzer and then where would we need to send the html HTML file to the host server, so we can generate a link to it on the corresponding relative-ci page?

I was thinking it would be nice to have a simple link to the foam tree graph on the summary pages:

[vio]

@jflayhart the webpack-bundle-analyzer is a great tool and I believe they are doing their own parsing of the sources. Will be really complicated if not impossible to pack it in bundle-stats.

bundle-stats is already extracting and normalising the modules data from the webpack stats, so this issue is more about taking that data and displaying it in a tree map chart. The user can switch between the table and the chart view. It will display only the stat size, but from my experience that's a good enough metric to identify the biggest parts of a chunk.

The tree map library has been the main blocker for me, since the idea was to have the bundle-stats.html as light as possible (all the assets are inlined). The ones depending on D3 are great but they can be quite large. I think there are 2 options to unblock this:

1. load the charting lib from a cdn
2. look for a lighter treemap option - for example bundlephobia is using something custom

[vio]

Here is a quick wireframe of the way i see this feature - https://excalidraw.com/#json=6277084896821248,1i-vE6IxVrVGQH8bt8Et-A. Let me know what do you think ;)

[jflayhart]

the webpack-bundle-analyzer is a great tool and I believe they are doing their own parsing of the sources. Will be really complicated if not impossible to pack it in bundle-stats.

I dont know how your tool works per se, but all these analyzer tools need one thing: the webpack stats.json output file. You should already be generating that with your tool but webpack-bundle-analyser could have an orthogonal relationship with what YOUR tool spits out and simply be used to generate the separate module tree map. The rest is automatically generated by WBA into an HTML file that you host and link to. Which part are you saying is not possible?

I like the dedicated modules tab that's good.

Also, I get you want a lighter lib so that's fair, but webpack-bundle-analyzer is the OFFICIAL one for webpack therefore guaranteed to use all the same inputs you should already be generating as the stats output webpack created. Have you tried this w/ your tool and found that's not the case? I use both ur tool and WBA at Shipt.

I was thinking your tool does what it needs and in parallel you could process the same build (if you can't reuse the same stats file for both) with WBA to simply output the HTML file to some CDN:

bundle-stats -> process -> output
WBA -> process -> output html (would need uuid as file name and something to create relationship with the file to PR/build).

[jflayhart]

P.S. I guess what I am saying for this UI bit you don't need to necessarily pack WBA into bundle-stats lib itself, you just want it as a means to an end to generate the module graph for RelativeCI GUI, so bundle-stats shouldn't be affected by this unless you want it to be packaged as part of your tool.

[vio]

@jflayhart both of the packages are working in a similary way:

1. extract data (webpack-plugin, stats.json file)
2. manipulate
3. report

What i was trying to convey is that bundle-stats is already having the modules data available, it only needs the chart visualisation. We might not need to bring another full reporting tool just for that(not very knowledgeable of the visualisation lib they are using, at a quick glance is looking like it is not open source).

Here is a high level diagram on how everything is working together:

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

[vio]

Available for testing and for feedback on v4.13.0-beta.2:

https://github.com/relative-ci/bundle-stats/assets/13300/5ca9726e-8762-4aa6-9fb4-49c26b2e2226

Related tasks:

• https://github.com/relative-ci/bundle-stats/issues/4316
• https://github.com/relative-ci/bundle-stats/issues/4317