[BUG] Massive size mismatch for minified code

[thoughtspile]

We're facing a similar problem to #96 — the module / chunk sizes reported by plugin-visualizer are overestimated by 2-3x. I built a reproduction with a 5x overestimation when bundling date-fns

I'm pretty sure this is caused by using non-minified modules for size computation — reported size is very close to the bundle size without terser. This is very problematic for several reasons:

• Such massive overestimation can cause useless optimization. In our production app, the reported date-fns size was around 30kB gzip, while the real size was around 3.5kB.
• Most production bundles are minified. Accounting for it is a necessity, not a bonus.
• The relative sizes of different modules (especially libraries) are skewed, depending on whether the dist is minified and commented. Using only percents, as suggested in Add fileSize option #98, won't work.
• For ESM bundles where a lot of dead code is eliminated during tree-shaking, the overestimation can be even bigger.

sourcemap plugin option has no major effect (~45 bytes) — both the original module in the FS and the sourcemap version are non-minified.

Using renderedLength as reported by rollup in plugin/index.js gives a much better result. From what I hear, this method underestimates the size of unicode strings, and the reported size is indeed a bit smaller for our production app with cyrillic texts, but nowhere close to 5x.

I'd suggest adding a renderedLength: boolean option to report more realistic sizes under minification. Unicode-adjusted estimation can be added later.

For now, we'll work around the issue using patch-package on plugin-visualizer to use raw renderedLength.

[thoughtspile]

Actually, sourcemap: true correctly computes renderedLength, but later it's dismissed in ModuleLengths.

This computation can be better adjusted for unicode by this change in getBytesPerFileUsingSourceMap:

- modules[id].renderedLength += 1;
+ modules[id].renderedLength +=  Buffer.byteLength(code[i], "utf-8");`

Ran additional tests on date-fns/locale (a lot of unicode), here are the results:

1. Actual bundle size: 597kB
2. Reported: 990kB (166% actual), regardless of sourcemap option.
3. Reported using rollup's renderedLength and sourcemap: false: 915kB (153% actual)
4. Reported using renderedLength from current sourcemap: true: 521kB (87% actual)
5. Reported using renderedLength with unicode-adjusted sourcemap: 597kB (matches actual)

How would you feel about using renderedLength when sourcemap option is enabled, and adding unicode adjustment I propose?

[btd]

Hi. First of all Thanks for every detailed issue.
Yes reportered size always different from actual one. Closest you can get to reality with sourcemap option set to true.
I should say i never tried to use non ascii chracters.
It would be nice if you will make PR and i will take a look. Otherwise no ETA.
Also i am curious if we should use codePointAt or anything that correctly traverse code points. Random index could point in the middle of surrogate pair

[btd]

I have published 5.9.2. Take a look pls if it improves size reporting with sourcemap.

[r-thomson]

I have published 5.9.2. Take a look pls if it improves size reporting with sourcemap.

Heads up, 5.9.2 seems to be missing from the changelog

[jasonaden]

I have published 5.9.2. Take a look pls if it improves size reporting with sourcemap.

Heads up, 5.9.2 seems to be missing from the changelog

I think it was supposed to say 5.9.1 since that was published 4 days ago and sounds like it matches this issue.

[r-thomson]

Heads up, 5.9.2 seems to be missing from the changelog

I think it was supposed to say 5.9.1 since that was published 4 days ago and sounds like it matches this issue.

Except there was a 5.9.2 published

[btd]

The difference between 5.9.2 and 5.9.1 is that i dropped 14.x from test matrix

[HummingMind]

This doesn't report the correct sizes.
vite-bundle-analyzer does not have this problem (although it's a Vite plugin, not a rollup plugin).

Would be nice to see a fix.

Thank you! 🍻

[Haroenv]

For anyone that wants a quick workaround to have mostly useful numbers, it seems like sourcemap: true uses sizes post minification