bundle-stats

bundle-stats copied to clipboard

Hey @vio,

It would be nice to set initial: true for chunks directly exposed with module federation. WebpackModuleFederation injects a remote entry chunk that is all auto-generated and only loosely related to app code/the exposed module's size. Subsequently, the remote entry chunk is the only chunk stats list as initial and entry.

While tracking the initial size of the auto-generated code is useful, I'd ideally like to know the size of chunks loaded right after the auto-generated remote entry.

1. One approach would be to support exposes and sharedModules in stats.json.
2. Or a general approach capturing and filtering reports by module depth.

I'm a fan of the second approach, where we'd track depth in a build-agnostic way. Depth is also an interesting facet for synchronous and async modules outside of module federation.

To help narrow in on exacts, I created an example test case highlighting a common async app scenario that I'd expect to report initial bundle stats for. The example test and approach 2) don't touch on shared modules, another aspect of module federation currently triggering duplicate dependency reports, requiring stats: { excludeModules: Object.keys(shared) } to suppress.

Hi @amccloud, thank you for opening the issue!

Not sure if I understood your case correctly, but are you interested in counting the module federated chunks as initial for the container or consumer package?

@vio possibly, but one way to approach this is in a way that is agnostic to module federation.

I'd like to understand the size of my modules at every depth of my bundle/assets. I'd like you to expand on your initial entry size concept to show size at 2nd, 3rd, etc. entries.

• 2nd entries are all async modules referenced from initial entries.
• 3rd entries are all async modules referenced from 2nd entries.

This is useful for module federation case where it allows teams to focus on 2nd entry. The second entry is where application code starts vs. the initial entry, which is always the module federation runtime and not much you can optimize.

Overall bundle size and initial size are not great measures of our initial async loading. Each team is passively aware of the code-split levels they create to optimize bundles. Adding module depth tracking would give a glimpse into the possible impact of size at runtime.

That sounds like something we can build on top of module resolutions - https://github.com/relative-ci/bundle-stats/issues/1449.

How do you see the presentation part, specific metrics or a way to filter the modules by the level or by a common parent?

@vio sorry for the delay, I was out last week on holiday.

I completely missed module resolutions, and I agree it looks like the data you need to drive depth.

On the UI side, Ideally whichever route, we could aggregate the filtered sizes into a graph over time like initial js.

I've only considered filtering by level as that seemed like an evolution of the existing initial filter, as I believe it would be comparable to depth/level: 0. IMO, only the first ~5 or so levels would be interesting as modules loaded later have less of an impact on the initial async loading.

Tracking size under a common parent could be useful here too as we know we want to focus on the size after initial js, in my case "remoteEntry.js".

Hi @amccloud, hope you had a good time! ;)

On the UI side, Ideally whichever route, we could aggregate the filtered sizes into a graph over time like initial js.

The presentation i had in mind was a dependency graph, similar to https://observablehq.com/@d3/tree/2. We should be able to see the total size for a part of the tree, though not sure if we can extract a metric.

The plan is to finish the changes required for v5 and then handle the module issuer for 5.1. I don't have a date yet, but would love to hear your thoughts regarding possible metrics / graphs.

💯 on tree visualization. The radial view is really interesting, It seems to fit all on one screen. Ideally we could also report a metric for the sum of each level in the visualization or at least use a level's overall size as a check rule.

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

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

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