Show non-bundled size (total size on disk)

[styfle]

Type

Feature Request

Request

Some npm packages are not meant to be bundled, such as test tools like ava or tape.

It would be great if bundlephobia could show the size on disk before bundling.

For example, ava and should show 24 MB but it shows 941 kB minified.

I created an issue in siddharthkp/cost-of-modules#50 since it might be out of scope for bundlephobia.

[Arttse]

For example, the same with the vnu-jar package. It shows 3.7 kB minified, but on the disk it takes ~25.7 Mb.

[styfle]

Now that I have thought through this.
I truly think bundlephobia is the correct place for this feature.

Afterall, bundlephobia already has to run npm install to get the package before running webpack to bundle it. All that is missing is a du -sh to get the size of the files on disk before running webpack and of course, store it in the database.

[pastelsky]

As of now, we do not flush the node_modules folder across build requests. This means that a package's dependencies might be installed in a flat hierarchy, where a typical du -sh would fail.

Besides, there are already packages that can help with package sizes - https://www.npmjs.com/search?q=npm%20package%20size&page=1&ranking=optimal

How would this be helpful for an average developer ? I don't find this information very actionable.

[styfle]

@pastelsky

How would this be helpful for an average developer?

I'm glad you asked! 😃

This information is helpful to an average developer the same way that bundlephobia is helpful to an average front-end developer.

Now I don't see a "WHY" section to explain the purpose of bundlephobia, but the GitHub subtitle says "Find out the cost of adding a new frontend dependency to your project".

So my assumption is that bundlephobia is a tool to allow a front-end developer to do a quick comparison of npm package sizes which might affect which dependency you choose to put into your web app. For example, you would want to pick the 1 KB package over that 100 KB package if you had the choice (obviously there are other attributes you would want to look at to make this decision, not just size).

Currently, bundlephobia assumes that npm packages are destined for the browser and shows the size after bundling with webpack.

But that assumption is incorrect. Many packages (in fact node's original purpose) is meant for back-end developers. It's also increasingly becoming more popular to use npm packages for your build & test tools.

Now an astute back-end developer or dev ops would want to compare two unit test tools such as ava vs tape and see that ava is 10x larger.

Or how about a micro framework that is larger than it's competitor zeit micro.

I'll quote myself from that issue here:

If you add micro as a dependency to a 1000MB mono-repo, then it's only a 1% increase.
If you add micro as a dependency to 500 individual microservices, that's a 5000MB (5GB) increase in size.

So you see, size matters even for dependencies that are not going to be served to the front-end 😄

[styfle]

Here's what I came up with: https://github.com/styfle/packagephobia

[pastelsky]

Closing this, since I don't think there's anything else left to discuss here.