Repository navigation
Display gzipped size #87
Description
Hello!
I find this project super useful. Thank you so much for making it real 🙂
I was wondering what is the cost to add the gzipped value of a module (and its dependencies)? It might be more realistic if most of the I/O to the npm registry happens to be compressed (I have no idea about the stats).
I quite liked this info on https://bundlephobia.com/result?p=webpack@4.11.0 (compared to https://packagephobia.now.sh/result?p=webpack@4.11.0).
What do you think?
Activity
styfle commentedon Jun 5, 2018
Hi Thomas!
I'm glad you like Package Phobia 😄
I'm not sure I understand your request.
Are you suggesting that Package Phobia should display the same information that Bundle Phobia displays?
In the example you linked to (webpack), I don't think the results that Bundle Phobia displays actually mean anything, since webpack doesn't bundle itself.
Can you elaborate?
thom4parisot commentedon Jun 5, 2018
@styfle eh eh 🙂 Sorry if I was unclear and thanks for encouraging me to rephrase the idea 👍
I can see on Package Phobia the cost of downloading webpack is 14MB (during
npm install).I took for granted the 14MB figure is uncompressed, on disk (after
https://registry.npmjs.org/webpack/-/webpack-14.11.0.tgzis unpacked).I found out the I/O cost to be interesting too—how much a package weighs on the bandwidth before hitting the disk. Therefore I was wondering if the transfer size was a difficult information to display for both publish and install size… if that's considered useful?
That's the bit I liked in Bundle Phobia (knowing the very end result, what's supposedly transfered over the wire).
Let me know if there is some more details to add to make it more understandable 😅
styfle commentedon Jun 5, 2018
I understand now.
Do you think displaying the size of the tarball (the unpacked size) would be sufficient?
Or do you think it would be better to actually attempt to calculate the bits transferred on the network (I would image there is more than one HTTP request)?
thom4parisot commentedon Jun 5, 2018
Let me try to answer with one picture 😄
styfle commentedon Jun 5, 2018
Nice mockup 👍
How can we effectively measure the "transferred" data?
thom4parisot commentedon Jun 6, 2018
It seems to be advertised in the HTTP response headers:
Unpacked size is
1.2MBaccording to npm metadata (npm view webpack dist.unpackedSize) and247KBaccording the HTTP header. The first figure is interesting disk-wise whereas the second is interesting I/O wise. The latter reflects the performance cost of retrieving that stuff from the Internet.I guess the total transfer size would be the module content-length + all the dependencies of dependencies content-length as well. It looks like the easiest starting point from my standing point.
What do you think?
styfle commentedon Jun 6, 2018
The
dist.unpackedSizefrom npm is almost identical to thepublishSizethat Package Phobia reports. See https://packagephobia.now.sh/api.json?p=webpack@4.11.1There is some discussion going on in an RFC which got moved to here.
That makes sense, I'm not sure if there are other HTTP requests made besides tar balls so that might be worth further investigation.
My other concern is how to display this data point in the bar chart.
Do we add a third color? It might feel a bit busy.
thom4parisot commentedon Jun 6, 2018
From what I read on the other two issues, it seems the space on disk and the bytes transfered are two different levels of reading (and expectations).
The first thing which comes to my mind is a toggle
Disk Space (o ) Transfered Data(on top of the left hand side column ?). Which means it should imply no change to the layout aside of sourcing a different data store to populate the charts and the readable figures.styfle commentedon Sep 7, 2018
@oncletom Sorry for the delay.
I think the toggle is a good idea to show a different chart!
However, I think it's best to implement #124 first and then come back to this feature. I believe file count will be much easier to implement when compared to "transferred" data. Once that gets nailed down, we can revisit this feature.
I hope you don't mind waiting a bit longer 😄
thom4parisot commentedon Sep 7, 2018
No worries, and there is no issue waiting.
I like #124 in how it shows an additional way of measuring package install performance hit.
Thank you for your work 🙂
styfle commentedon Dec 14, 2018
FYI, there is a tool that accomplishes what you are looking for: https://arve0.github.io/npm-download-size/