In what world does cost mean file size and not consider financial cost, patching, security auditing, debugging, and the cost of finally ripping it out when everyone agrees retrospectively that it was a mistake to include in the first place.
Come to think of it, the shortcoming of the description explains a lot of things about the current state of the JavaScript ecosystem.
Big systems have big surfaces, no matter what quality they are.
Dependency chains may be more of an issue. I think several of the last few big exploits have been compromises in fairly small packages, that were incorporated into larger ones.
Then, there's the "Bro Coefficient." Who wrote the package should count for a lot.
I'd trust a package written by "linus.torvalds," a lot more than one written by "L33tCoder420LOL," even if the Web site is super-sexy, and it has a gazillion GH stars.
...explains a lot of things about the current state of the JavaScript, Python, Rust and Go ecosystems.
Here, FTFY.
IOW, having a package manager in your programming language is a boon and a curse, but more of a latter. People just add a single line to their dependency list, and pull in the literal world. As long as their code runs the way it should, nobody, I mean, nobody cares.
"...explains a lot of things about the current state of the JavaScript, Python, Rust and Go ecosystems."
The difference is that with Go or Python you can, if you decide to, do quite a lot without either pulling random stuff from the internet or making your own implementation from scratch, due to extensive standard libraries.
I find this problem much easier to talk about face-to-face - my catchphrase on th subject involves gestures:
"All we've done is trade this kind of complexity <holds hands about two feet apart, vertically> for this kind of complexity <holds hand about four feet apart horizontally>.
At least with python you can get away with an awful lot without pulling in random packages. I use python repl and scripts daily, and seldom use pip (apt repos I’m fine with)
If you code mindfully, Python stdlib can do tons and tons of things (I love logging and argparse, for example). But I have seen the other end of the spectrum, too. Somebody imported whole Pandas just to read a couple of columns from an Excel file, to create a simple URL list, and some folders.
To download the free Springer books during COVID.
I mean, ouch.
P.S.: If you like your eyes, please don't look at AI stacks.
> People just add a single line to their dependency list, and pull in the literal world.
So do you prefer the situation in c++ where you just add one dependency, like "boost" or "Qt" and it still pulls in 15M lines of code but now it's just "one" dependency instead of 150?
No, I prefer to find and vendor in single libraries which do not come with 15M lines of code. Like Eigen.
On the other hand, you can introduce Qt modularly, so you don't have to import all of them. Same for Boost, though I don't use either.
I write Go and use Uber's zap for logging. It pulls in uncomfortable amount of code, too. Until I can find something better, I'll continue using it, but I'm not comfortable with it.
However, in C++ land, I was able to use standalone libraries like Catch or Eigen which were big, but not unwieldy, and Eigen is also as modular as Boost. So you know what you include and what you do at the end of the day.
I'm a big fan of standalone source code repositories which vendor minimum number of libraries (which I strive to develop, too). You need GCC and glibc only. Just make it, use it. "No hidden fees, no games", I may say.
Even ignoring the fact that no one forces you to add whole Qt to your project, do not compare Qt, which is a battle-tested, long-lived framework, developed and maintained for decades by the company that also provides commercial support for it, with a bucket of intermingled crap sourced from random repositories across the internet.
Which also shows the issue with using size as the only metric.
Boost and Qt are very solid systems. They have well-deserved, excellent reputations. In order for this tool to be useful, it would need to have a “reputation score,” that relies on more than GH stars and social media buzz.
That said, I am not a fan of doing something like adding 1MB to a page load, so you can animate a button press; even if the dependency is reputable.
Sometimes, it makes more sense to reinvent the wheel, as opposed to bringing in an 18-wheeler.
I appreciate the concept, but there are additional costs that would be great to consider. How frequently do you need to parch the package to address CVEs? How many downstream dependencies does this package have? How often do they make breaking changes?
Tried uploading my package.json, but I got a 404, because of a local package, which is part of my monorepo. Would be good if it would ignore dependencies, where the version is: `"workspace:^"`
I like how the graph shows the change in size per version.
"Publish size" is a little misleading though. I thought that meant the size that would be included in my bundle when I publish my app, and was wondering how you were calculating that. Maybe "w/ deps" "w/o deps"?
I'd appreciate you not hiding information below the fold. Really hate that design trend. Remove the `min-height: 100vh` and see how much better it looks (with a bit of padding). At least make it 90vh.
They says sponsored by Vercel and Upstash, but in the repo, it just says hosting and database "sponsored" by them. Are they just using the free tier???
Both offer a free plan but Package Phobia is sponsored meaning its on the paid plan but getting it for free.
Kinda like a skateboarder might be sponsored and get a skateboard for free even though others pay for the same item.
Package Phobia started out on the free plan but it turns out its quite popular, serving over 5 million requests per month. A cache miss (which is frequent given the cardinality of packages + versions), it can take 30 seconds to install a package and measure its size.
There's also a public API which tools like Socket use to check the size of every npm package.
In what world does cost mean file size and not consider financial cost, patching, security auditing, debugging, and the cost of finally ripping it out when everyone agrees retrospectively that it was a mistake to include in the first place.
Come to think of it, the shortcoming of the description explains a lot of things about the current state of the JavaScript ecosystem.
I would have thought it would show how big the dependency tree was.
And a count of historical CVEs in its transitive graph.
CVEs might not be the best metric, alone.
Many large, mature, and solid packages could have long histories of resolved CVEs.
It's still a good measure of how much security risk you are taking from the increased attack surface.
Yes but that would indicate deeply rooted issues in many cases.
I would say "might," as opposed to "would."
Big systems have big surfaces, no matter what quality they are.
Dependency chains may be more of an issue. I think several of the last few big exploits have been compromises in fairly small packages, that were incorporated into larger ones.
Then, there's the "Bro Coefficient." Who wrote the package should count for a lot.
I'd trust a package written by "linus.torvalds," a lot more than one written by "L33tCoder420LOL," even if the Web site is super-sexy, and it has a gazillion GH stars.
There's no way to automatically establish those costs, considering that if you want some of that functionality, you take that cost on yourself too.
> In what world
the land of spherical cows...
reminds me of https://www.folklore.org/Negative_2000_Lines_Of_Code.html
...explains a lot of things about the current state of the JavaScript, Python, Rust and Go ecosystems.
Here, FTFY.
IOW, having a package manager in your programming language is a boon and a curse, but more of a latter. People just add a single line to their dependency list, and pull in the literal world. As long as their code runs the way it should, nobody, I mean, nobody cares.
This is a huge problem.
"...explains a lot of things about the current state of the JavaScript, Python, Rust and Go ecosystems."
The difference is that with Go or Python you can, if you decide to, do quite a lot without either pulling random stuff from the internet or making your own implementation from scratch, due to extensive standard libraries.
I find this problem much easier to talk about face-to-face - my catchphrase on th subject involves gestures: "All we've done is trade this kind of complexity <holds hands about two feet apart, vertically> for this kind of complexity <holds hand about four feet apart horizontally>.
At least with python you can get away with an awful lot without pulling in random packages. I use python repl and scripts daily, and seldom use pip (apt repos I’m fine with)
True, Python has a larger std lib, but Node.js has increased a lot in the last two years.
Although it’s not so much Python that’s influencing Node.js but more like Deno and Bun that try to include everything but the kitchen sink.
If you code mindfully, Python stdlib can do tons and tons of things (I love logging and argparse, for example). But I have seen the other end of the spectrum, too. Somebody imported whole Pandas just to read a couple of columns from an Excel file, to create a simple URL list, and some folders.
To download the free Springer books during COVID.
I mean, ouch.
P.S.: If you like your eyes, please don't look at AI stacks.
> People just add a single line to their dependency list, and pull in the literal world.
So do you prefer the situation in c++ where you just add one dependency, like "boost" or "Qt" and it still pulls in 15M lines of code but now it's just "one" dependency instead of 150?
No, I prefer to find and vendor in single libraries which do not come with 15M lines of code. Like Eigen.
On the other hand, you can introduce Qt modularly, so you don't have to import all of them. Same for Boost, though I don't use either.
I write Go and use Uber's zap for logging. It pulls in uncomfortable amount of code, too. Until I can find something better, I'll continue using it, but I'm not comfortable with it.
However, in C++ land, I was able to use standalone libraries like Catch or Eigen which were big, but not unwieldy, and Eigen is also as modular as Boost. So you know what you include and what you do at the end of the day.
I'm a big fan of standalone source code repositories which vendor minimum number of libraries (which I strive to develop, too). You need GCC and glibc only. Just make it, use it. "No hidden fees, no games", I may say.
Yes.
Even ignoring the fact that no one forces you to add whole Qt to your project, do not compare Qt, which is a battle-tested, long-lived framework, developed and maintained for decades by the company that also provides commercial support for it, with a bucket of intermingled crap sourced from random repositories across the internet.
Which also shows the issue with using size as the only metric.
Boost and Qt are very solid systems. They have well-deserved, excellent reputations. In order for this tool to be useful, it would need to have a “reputation score,” that relies on more than GH stars and social media buzz.
That said, I am not a fan of doing something like adding 1MB to a page load, so you can animate a button press; even if the dependency is reputable.
Sometimes, it makes more sense to reinvent the wheel, as opposed to bringing in an 18-wheeler.
BTW: Most compiled languages have good linkers and postprocessors. They strip out unused executable.
The compile might take a while, but the resulting binary may not be as big as you think.
This does not apply, however, to interpreted languages, like JS.
Not sure about "JIT" languages, though, like Python and PHP.
It does apply to JS if you use a bundler that has “tree-shaking” also known as “dead code elimination”.
What a surprise!
I’m the author of Package Phobia and it’s been largely unchanged since 2018.
If you’re looking for more details, checkout the readme on GitHub.
Let me know if you have questions, thanks!
https://github.com/styfle/packagephobia
Based on this talk by TkDodo (TanStack Query maintainer): https://youtu.be/8-RTNnn9GR8?t=255 https://bundlejs.com/ is the better alternative to check your dependency sizes with
They are orthogonal tools.
Checkout the readme for a comparison against other tools.
https://github.com/styfle/packagephobia
Ah got it! Thanks for the README
I appreciate the concept, but there are additional costs that would be great to consider. How frequently do you need to parch the package to address CVEs? How many downstream dependencies does this package have? How often do they make breaking changes?
Tried uploading my package.json, but I got a 404, because of a local package, which is part of my monorepo. Would be good if it would ignore dependencies, where the version is: `"workspace:^"`
I thought this was language agnostic. Should probably make it more clear that it's for JS.
I agree 100% - this needs to be renamed if it is not agnostic.
I like how the graph shows the change in size per version.
"Publish size" is a little misleading though. I thought that meant the size that would be included in my bundle when I publish my app, and was wondering how you were calculating that. Maybe "w/ deps" "w/o deps"?
I'd appreciate you not hiding information below the fold. Really hate that design trend. Remove the `min-height: 100vh` and see how much better it looks (with a bit of padding). At least make it 90vh.
The word "publish" is from "npm publish" and I don't think there is a better term to switch to.
https://docs.npmjs.com/cli/v8/commands/npm-publish
I like your idea about showing the information below the fold so I fixed it, thanks!
https://github.com/styfle/packagephobia/pull/1069
I prefer https://pkg-size.dev/
Looking at some packages that I maintain, I think the sizes might be off, but I'll have to dig in more later.
I wonder if it's handing export conditions properly? We have browser, node, developer, and types exports. Are the files behind quadruple counted?
If you find a bug, please report the issue on GitHub and I’ll take a look, thanks!
They says sponsored by Vercel and Upstash, but in the repo, it just says hosting and database "sponsored" by them. Are they just using the free tier???
Both offer a free plan but Package Phobia is sponsored meaning its on the paid plan but getting it for free.
Kinda like a skateboarder might be sponsored and get a skateboard for free even though others pay for the same item.
Package Phobia started out on the free plan but it turns out its quite popular, serving over 5 million requests per month. A cache miss (which is frequent given the cardinality of packages + versions), it can take 30 seconds to install a package and measure its size.
There's also a public API which tools like Socket use to check the size of every npm package.
https://x.com/styfle/status/1826296197566644497
Frankly bundlephobia gives me more information that I care about... "How much is the end user going to have to download, parse and execute".
How is this different from bundlephobia?
See the readme on github for a full comparison
bundlephobia counts loaded code size, this counts total package size.
This is somehow slower and worse than bundlephobia. Was bundlephobia an improvement on this concept or is packagephobia just a cheap knockoff?
See this issue:
https://github.com/pastelsky/bundlephobia/issues/40
Does anyone know something like this, but for other languages like Python?
Useless, doesn't even know what glibc is.