File sizes appear larger in visualizer than in reality

[toBeOfUse]

The file sizes shown in the visualizer are larger than the ones reported by Vite on the command line or that show up on disk after building. To see this, you can just clone vitesse, install its packages, and run vite-bundle-visualizer for it.

On the command line, a file size of 153kb is shown for the main javascript asset:

Similarly, on disk, the file appears to be 150kb:

But in the visualizer, the same file (with the same hash in the name, so it should have the same contents) is reported to be 461kb:

[KusStar]

It seems like only happen in vitesse or vite-ssg project? Looking weird, I will try to figure it out.

[KusStar]

v0.10.0 involves --sourcemap option, it will more accurate but result less detailed.

[samosad]

same problem for me!

real bundle size:

same bundle in visualizer:

with --sourcemap option:

[bfricka]

The sourcemap option is indeed less detailed, and also not more accurate, in my experience. E.g. I separated out a lodash chunk to test it, and the build (and file system) show that chunk as 34.18 kB, whereas the sourcemap options shows it as 185.66 KB (which is 190.12 kB), so it's off by 5.5x. Another chunk, however measured 2.2x off.

This hurts the functional usefulness of the tool dramatically because the relative sizes of modules and chunks are not accurate. It wouldn't be such an issue if just the numbers were inaccurate, but with the relative sizing being so dramatically off, this tool is really only useful as a module graph.

Without the sourcemap option, the numbers appear identical, but there is gzip info at least.

Edit: Appears to match this issue. Since it's downstream, and I don't see anything wrong with this Vite wrapper code, there's probably not much the author can do. This plugin is already using the latest, and it doesn't appear to help.

[KusStar]

The sourcemap option is indeed less detailed, and also not more accurate, in my experience. E.g. I separated out a lodash chunk to test it, and the build (and file system) show that chunk as 34.18 kB, whereas the sourcemap options shows it as 185.66 KB (which is 190.12 kB), so it's off by 5.5x. Another chunk, however measured 2.2x off.

This hurts the functional usefulness of the tool dramatically because the relative sizes of modules and chunks are not accurate. It wouldn't be such an issue if just the numbers were inaccurate, but with the relative sizing being so dramatically off, this tool is really only useful as a module graph.

Without the sourcemap option, the numbers appear identical, but there is gzip info at least.

Edit: Appears to match this issue. Since it's downstream, and I don't see anything wrong with this Vite wrapper code, there's probably not much the author can do. This plugin is already using the latest, and it doesn't appear to help.

Yeah, it seems the output bundles information of Vite(internal is rollup) is inaccurate, you only can get accurate final size of a module bundle, which are tree-shaken results, but only get size of a module before tree-shaken in module graph. Result in inaccurate in some cases.

[stefan-schweiger]

@KusStar seems like this issue was fixed in rollup-plugin-visualizer, would you mind updating your package to the latest version? https://github.com/btd/rollup-plugin-visualizer/issues/163

[stefan-schweiger]

Oh sorry, just saw that you are already on this version :(

[samesfahani-tuplehealth]

Any workarounds for this issue? I'm seeing the same issue. When I visualize deps, it seems like it's not honoring build.rollupOptions.treeshake where was vite build does, rendering the actual usefulness of the visualization useless.

[gavrashenko]

Are there any updates? It's too hard to analyze deps if I can't trust the data (

[SimonEast]

I've just noticed this problem too. It's not very useful if the sizes are all off.