Display gzipped size

[thom4parisot]

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/[email protected] (compared to https://packagephobia.now.sh/[email protected]).

What do you think?

[styfle]

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]

@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.tgz is 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]

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]

Let me try to answer with one picture 😄

[styfle]

Nice mockup 👍

How can we effectively measure the "transferred" data?

[thom4parisot]

It seems to be advertised in the HTTP response headers:

$ curl --head https://registry.npmjs.org/webpack/-/webpack-4.11.1.tgz
HTTP/2 200
date: Wed, 06 Jun 2018 09:38:54 GMT
content-type: application/octet-stream
content-length: 246611

Unpacked size is 1.2MB according to npm metadata (npm view webpack dist.unpackedSize) and 247KB according 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]

The dist.unpackedSize from npm is almost identical to the publishSize that Package Phobia reports. See https://packagephobia.now.sh/[email protected]

There is some discussion going on in an RFC which got moved to here.

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.

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]

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]

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

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]

FYI, there is a tool that accomplishes what you are looking for: https://arve0.github.io/npm-download-size/