Size of an npm package

[pastelsky]

It's quite common that developers want to find out the size of a framework/library before dropping it into their own project. While there's already a badge for displaying file and repo sizes, most library authors don't check in dist files into their repo.
I made a heroku app that lets you know the gzipped + minified size of any npm package after bundling - https://cost-of-modules.herokuapp.com

Was wondering if a badge for the same would be useful?

[espadrine]

Thanks for the suggestion!

For now, the API available through api.npmjs.org does not include that information.

https://cost-of-modules.herokuapp.com/package?name=express has a size field in bytes.
However, it takes 1.8s to load.

Could you provide more information in what it does behind the scene? Do you cache size information for all packages, regularly updated by a batch job? Does it perform a download of the library on each request? Do you perform a call to npmjs.org every time?

[pastelsky]

So, I'm not really sure badges work. Does every page load result in the API being hit? Or is there an internal caching of some kind?
The current approach taken by cost of modules is :

1. If it's seeing a package for the first time, fetch the package, build it, minify and gzip. This can be a long operation and can take several seconds.

2. Since the above process is costly, I use two levels of caching - a short term in-memory cache and a permanent firebase cache to store the results.

[espadrine]

There is a non-persistent cache, but it does not scale with the load, and it isn't large. It would be difficult for me, given the resources I have, to become a cache store for all projects. I rely on the APIs I call to make sure that they can survive the load (scaling their cache if necessary). I use a user-agent HTTP header if you need to block me at some point.

If you feel good about this, let's go for that badge!

[pastelsky]

On one hand, I'm sure that this solves a popular use case, on the other I doubt my free heroku tier and firebase would be able to handle the traffic of hundreds of users hitting the service at a time.

Do you have an idea how much cache hit % does your temporary cache take for a popular badge? Also, what kind of traffic should I be ready for? (assuming the badge is a tiny bit popular)

[paulmelnikow]

I'm marking all the needs-upstream-help issues closed.

If there's new information from the upstream service, please post in the thread. If they're actionable by Shields, a maintainer will reopen the issue.

If anyone wants to follow up with these vendors, feel free to do that! Even though the unresolved issues are closed, they are easy to find:

https://github.com/badges/shields/issues?q=label%3Aneeds-upstream-help+is%3Aclosed

[pastelsky]

@espadrine We have better hosting and caching solutions for bundlephobia now, and I think we can handle traffic from sheilds. Could you please reopen this issue and let me know what's required to make a sheild for the same ?

[paulmelnikow]

Hi! Glad to hear it. We have a great tutorial, and there are some guidelines here. Let us know in this issue if you need help, and someone knowledgeable will be happy to respond.

[paulmelnikow]

Closed in #1481! Thanks @pastelsky and @tlaziuk!