Repository navigation
Feature request: Show a table with sizes #11
Description
I tested this with @auth0/babel-preset-cosmos and got a scary result, but couldn't pin point why
By running cost-of-modules on my machine, I found it was because of one specific dependency: babel-plugin-transform-class-properties
┌───────────────────────────────────────────┬─────────────┬───────┐
│ name │ children │ size │
├───────────────────────────────────────────┼─────────────┼───────┤
│ babel-plugin-transform-class-properties │ 45 │ 8.05M │
├───────────────────────────────────────────┼─────────────┼───────┤
│ babel-plugin-transform-object-rest-spread │ 2 │ 0.06M │
├───────────────────────────────────────────┼─────────────┼───────┤
│ babel-preset-react │ 20 │ 0.46M │
└───────────────────────────────────────────┴─────────────┴───────┘
Feel free to close this if it is out of scope.
Activity
styfle commentedon Apr 9, 2018
Thanks for the request!
I realize that the way you described this is how cost-of-modules works and the initial reason for this tool diffs slightly as seen in the readme
I will think through this problem a little more and see if I can come up with something. 👍
mohsen1 commentedon Jun 17, 2018
You know the dependencies and their install sizes. It would be nice to list them in each package page. A pie chart would be excellent
styfle commentedon Jun 17, 2018
@mohsen1 Kind of 🤔
We know the dependencies and their publish sizes, not their install sizes (unless we run Package Phobia for each dependency which could be very very slow).
This is because of the way npm flattens dependencies after an install which is why @siddharthkp created the
cost-of-modulestool. Prior to npm@3.0.0, you could just look at the contents of thenode_modulesfolder and see which dependency was largest.Does that make sense?
styfle commentedon Jul 25, 2018
@siddharthkp @mohsen1 I have a PR in another project that might be what you're looking for:
anvaka/npmgraph.an#27
It would be great if you could give it a look through, thanks! 👍
goto-bus-stop commentedon Sep 5, 2018
I think just having the package size of each dependency would help a lot, and it's also what bundlephobia does for its graph: https://bundlephobia.com/result?p=@uppy/transloadit@0.27.2 Here at the bottom,
engine.io-clientis a transitive dependency, but it's listed along with everything else. The ideal situation IMO would be to have a graph like that, that also listed the dependency paths on hover (or elsewhere), so you can see whether a very heavy transitive dependency could be removed by changing just one dependency or if it needs more work.Trying to estimate the install sizes of each package could be done in a single install by looking at the
requireskey in package-lock.json, but shared transitive dependencies would add up to more than they're actually worth (eg. lodash being depended on by two different dependencies should not be counted twice).leeoniya commentedon Sep 5, 2018
similar thoughts: #124 (comment)