sourceMappingURL comment included in unmapped size
erykpiast opened this issue · comments
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
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.
Let's remove comments first. I don't know a case when it can be useful to know the size of the source map.
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.
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
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?
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.
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
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
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.