Feature request: Show a table with sizes

[siddharthkp]

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.

[styfle]

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]

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]

@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-modules tool. Prior to [email protected], you could just look at the contents of the node_modules folder and see which dependency was largest.

Does that make sense?

[styfle]

@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]

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/[email protected] Here at the bottom, engine.io-client is 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 requires key 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]

similar thoughts: #124 (comment)