-
-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Webpack bundle analyzer does not accurately represent effects of tree-shaking in webpack 4 #161
Comments
Hi, thanks for the detailed issue! It seems that you are looking at the "stat" size for Set |
@valscion Hello, absolutely. Here is the screenshot of webpack bundle analyzer for individual import with gzip sizes: And here's for destructuring import with gzip sizes: Parsed sizes look very similar: |
It seems that the tooltips in your example only show "stat size", which implicates that the Gzip and parsed size calculation failed for some reason. That is why you're seeing wrong sizes |
@valscion My bad, I can see the gzip and parsed sizes when I hover something outside of node_modules. I believe parsed size is accurate. If I change the code to use a few other functions imported from "ramda/es" like this: import { add, concat, compose } from "ramda/es";
document.write(compose(concat("Hello"), add(2))(3)); This makes bundle size grow from 3.22 KB to 13.4 KB as reported by webpack, and parsed size reported by webpack-bundle-analyzer changes from 3.22 KB to 13.35 KB as expected. This change however is not reflected in the grid drawn by webpack-bundle-analyzer. If I'm interpreting it correctly, it still shows as if all modules from "ramda/es" have been included into the bundle. |
Ah right, yeah this is because of the Could you try specifying |
@valscion Thank you for looking into this issue. I don't see significant change in webpack-bundle-analyzer's graph after disabling It also makes source-map-explorer show graph similar to webpack-web-analyzer, which includes all of the modules which I expected to be omitted. |
The thing is actual dead code elimination is done by This is the reason you see a lot of actually "excluded" modules under concatenated module - webpack concatenated them all but UglifyJS removed all the unused ones. As for the absence of Actually, we calculate approximate @sokra do you have any thoughts how we can improve it? |
Because of such issues in However it doesn't solve the root of the problem so I'm leaving this issue opened. |
So I don't get does WBA display all the code parts regardless tree shaking that actually take place? |
@whitecolor when toggled, WBA shows the contents of the tree-shaken modules. However, there might be modules that have been shaken away as they were not used, but webpack does not tell us which of those modules have been removed. |
@valscion Thanks) can you advice what is the best way to check if tree shaking (for particular module) actually works? |
Look at the resulting bundle code. Try running the minified code through There might be other tools for that, but I haven't had the need to check that. I'm happy that my bundle sizes are smaller and I can see that a large swath of one huge module has been tree-shaken from our application by just seeing the size differences. |
@whitecolor You can use the tool source-map-explorer to check what is inside your bundle. One of the screenshot above is generated with this tool. It's running directly on the outputted bundle so you won't have issue with code that is present or not. |
@samouss thanks, didn't know about it) |
@samouss do note that the output from Only when this checkbox is toggled, will WBA potentially show tree-shaken module contents. When that checkbox is left untoggled (which is the default), then the output will be accurate. |
@valscion Thanks for the clarifications! Is it written somewhere inside the doc? Because from a user perspective it's confusing. It took me a while to understand that output of the treemap was not completely accurate depending on the options selected. I was mainly using this view to understand which modules were tree-shaken or not. |
@valscion Its WP4, dev server, hmr. I even set |
This is why — you need to build the output files to see parsed and gzip sizes. Documentation PR for this confusing behavior would be appreciated 😜
I don't know, most likely not. Documentation contributions would be very welcome |
@valscion so I have removed from build options hmr, devserver, devtool from config and result is the same: I see, only Stats. Any advice what else should be turned on/off? |
Could you post a new issue and we can debug there? This is getting off-topic for this particular issue |
@valscion thanks, I did it, just added |
Is there an update on this issue? |
This issue has been solved with hiding the concatenated module contents by default. If you have a specific issue @davwheat please open a new issue |
Issue description
Webpack 4 enables dead code elimination from ES6 modules which declare themselves as side-effect free via
"side-effects": free
in package.json.Source
I tested this feature on an example project which I published here:
https://github.com/mpontus/tree-shaking-example
I attempted to verify that I can use destructuring import from ESM index file without significant increase in bundle size in comparison to importing modules indivudally.
In other words, the following code:
Should be equavalent to:
Judging by the bundle size, this assumption is correct:
vs
Small increase in bundle size can be attributed to webpack artifacts, and their portion in the total size will be insignificant in a real project.
I used source-map-explorer to confirm this, and it shows no significant difference:
vs
Webpack bundle analyzer, on the other hand, does not make it obious that any tree shaking has taken place.
vs
The reported stat sizes for ramda module are 2.06 KB and 311.77 KB respectively.
Is it possible to make webpack-bundle-analyzer give better representation of the effects of tree-shaking on the bundle?
Technical info
Debug info
As a plugin
webpack --mode production
none
UglifyJsWebpackPlugin
https://bpaste.net/show/311b6f843012
The text was updated successfully, but these errors were encountered: