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.
I've created a proof-of-concept package dependency algorithm using the
reasonsmetadata 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:
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.