sourceMappingURL comment included in unmapped size

Question

sourceMappingURL comment included in unmapped size

erykpiast opened this issue 5 years ago · comments

Eryk Napierała commented 5 years ago

Description
The number of unmapped bytes changes with the filename of the source map file.

Steps to reproduce

Build any bundle with a source map
Load source-map-explorer, save the number of unmapped bytes
Change the name of the source map itself and the name inside sourceMappingURL comment inside the bundle
Load source-map-explorer
See a different number of unmapped bytes

Files to reproduce
It's a TAR archive, despite the name.
dist.zip

Expected behavior
Unmapped bytes number does not depend on the name length of the source map file.

Environment

OS: MacOS X 10.14.6, node 11.15.0
source-map-explorer 2.0.1

Eryk Napierała · Answer 1 · Tue Sep 03 2019 04:05:27 GMT+0800 (China Standard Time)

Maybe even the whole sourceMappingURL comment shouldn't be taken into account when calculating unmapped bytes count? It has fixed size (except the URL itself), it's usually added to the bundle after in the final step, so it has nothing to do with the source code, it's not even a code...

On the other hand, such exception would distort the real size of the file, so maybe the comment may be presented in the tool separately, as some kind of virtual module? Simply like sourceMappingURL comment, placed next to unmapped bytes of unknown origin.

Nikolay Borzov · Answer 2 · Wed Nov 13 2019 03:40:47 GMT+0800 (China Standard Time)

Let's remove comments first. I don't know a case when it can be useful to know the size of the source map.

Dan Vanderkam · Answer 3 · Wed Nov 13 2019 03:51:28 GMT+0800 (China Standard Time)

I think the reason we included this originally was that it's also confusing to run SME over a 5MB JS file but only see 1MB accounted for in the top level of the visualization.

Nikolay Borzov · Answer 4 · Wed Nov 13 2019 03:55:51 GMT+0800 (China Standard Time)

So, do you think it's better to include source map comment size as a separate block? What should we call it on treemap then?
Or we should do it as webpack-bundle-analyzer does it

Dan Vanderkam · Answer 5 · Wed Nov 13 2019 04:08:01 GMT+0800 (China Standard Time)

Maybe we should say something more precise in the console, something like "foo.js contains a 5MB inline source map which will be ignored for space analysis."

How does webpack-bundle-analyzer do it?

Eryk Napierała · Answer 6 · Wed Nov 13 2019 04:18:54 GMT+0800 (China Standard Time)

They operate on a different level. The output bundle is used just for obtaining a parsed size of modules taken from the compilation stats. The source map comment is ignored as it's not a module.

Nikolay Borzov · Answer 7 · Wed Nov 13 2019 04:19:49 GMT+0800 (China Standard Time)

Maybe we should say something more precise in the console, something like "foo.js contains a
5MB inline source map which will be ignored for space analysis."

SME not always can output message to console (e.g. when the output format is specified). Also, API doesn't have info messages list ATM

How does webpack-bundle-analyzer do it?

I don't know yet

Nikolay Borzov · Answer 8 · Wed Nov 13 2019 11:29:02 GMT+0800 (China Standard Time)

On second thought, I think we should include source map comment into size analysis. One of key use cases of SME - figure out what takes most space in the bundle size. Seeing that bundle contains an inline source map might help to reduce the bundle size

Nikolay Borzov · Answer 9 · Thu Nov 14 2019 01:33:43 GMT+0800 (China Standard Time)

But we should also add an option to exclude source map comments from size calculation. This way the user decides and aware that the result size might be smaller.
@danvk, regarding message in the console - I'm not sure we should add one. Look at the deluge of confusion caused by "Your source map only contains one source" message.