Feature suggestion: Package Dependency Tree

[eirikurn]

I've created a proof-of-concept package dependency algorithm using the reasons metadata which might make this tool even more useful.

Instead of creating a tree of modules based on their location in the file system, it creates a tree where leafs are modules but non-leaf (folder) nodes are packages and connections are module/package dependencies. This shows more clearly the complete size of installed packages and how they relate.

For shared code, if a package is used in multiple places, it becomes a "shared" package node higher in the tree. If a package contains optional modules used in different places, then it could appear in multiple places in the tree. Example:

react: 103.8 KB - shared by <root>, react-dom & 6 more
react-addons-css-transition-group: 30.7 KB
  react: 30.64 KB (99.8%)
  <self>: 62 B (0.197%)

This example shows 103,8KB of "shared" react code used by two or more packages. However, react-addons-css-transition-group is loading an additional 30,64KB of react code, making the "sum cost" of css-transition-group 30,7KB instead of 62B. This is difficult to figure out with existing analyzers and might make other animation libraries more appealing.

I honestly think this is a life saver when evaluating new project dependencies or when looking for fat dependencies to trim. Some might have a small tree of huge dependencies, others might have a large tree of tiny dependencies, yet others might depend on packages already being used, making the difference a smaller one.

I'm going to try and integrate the algorithm into this project/viewer. At least as a fork for my use, but I think it is very useful to others.

EDIT: Feel free to try the POC running in a fork of webpack-bundle-size-analyzer.

[eirikurn]

I imagine this would work well with the split analyzer and ui code, a la #32 and #40. It might also be useful for #41.

[basicdays]

This would be amazing. Just tried out the webpack-bundle-analyzer today and this tool made it immediately obvious some dependency is pulling in all of lodash. We'll have to go code spelunking to figure out which one is doing that or find another tool to report on that. It'd be amazing to have all of that within one tool.

[wmertens]

you can feed the stats file to webpack.io/analyze and then you can see the dependency that pulled it in.

…

On Wed, Apr 5, 2017 at 10:17 PM Paul Sanchez ***@***.***> wrote: This would be amazing. Just tried out the webpack-bundle-analyzer today and this tool made it immediately obvious some dependency is pulling in all of lodash. We'll have to go code spelunking to figure out which one is doing that or find another tool to report on that. It'd be amazing to have all of that within one tool. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlhKg4IWeJw_PaOIH0vlM7QMTlDDzks5rs_bUgaJpZM4MDtKH> .

[valscion]

Yeah an use case such as this one is definitely a thing I want to make possible with #32 and #40.

Too bad that your fork is an entirely different project, so comparing the diff makes no sense.

[Frondor]

I don't know if I get the idea, but does it tries to display where is a dependency coming from? I'm trying to tree-shake lodash properly, and I'm using a few lodash/fn functions, but in the analyzer I see a lot of small lodash functions imported... I'd like to know which other packages are importing them. Is that possible with this approach?

[eirikurn]

Yes. That is the idea. This kind of clustered dependency resolution is quite complicated, however. I gave this a stab last year and hit some obstacle, and I haven't had time to work on it since. This is probably even more difficult now with webpack3+ and ModuleConcatenationPlugin. :)

…

-- Sent from Missive ( https://missiveapp.com/?ref=signature ) - Email, Chat & Tasks for Productive Teams On April 30, 2018 at 5:12 PM, Federico Vázquez ([email protected]) wrote: I don't know if I get the idea, but does it tries to display where is a dependency coming from? I'm trying to tree-shake lodash properly, and I'm using a few lodash/fn functions, but in the analyzer I see a lot of small lodash functions imported... I'd like to know which other packages are importing them. Is that possible with this approach? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub ( #53 (comment) ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/AAHBlswvQxSs-8sucuKd1mHKbMohwwM_ks5tt0YJgaJpZM4MDtKH ) .

[yvele]

Any workaround or external tool to get the dependency tree of a Webpack bundle? 🤔

[wmertens]

@yvele you can use http://webpack.github.io/analyse/

[yvele]

@yvele you can use http://webpack.github.io/analyse/

It's not working with my stats.json 🤔

web.js:1 Uncaught TypeError: Cannot read property 'sort' of undefined
    at web.js:1
    at Object.n.load (web.js:1)
    at FileReader.l.onload (15f6448ec2a08f35395d.js:1)