And that it is not even the worst I have seen.
I think the worst offenders are development tools like webpack.
I have a small project that I work on from time to time which uses 5 libraries (react, a map library and a chart library), typescript, and react-scripts (which I guess pulls in webpack and all the rest).
This is what happens when I run a npm audit (I havent' touched it for a couple of months)
> found 38934 vulnerabilities (38916 low, 18 moderate) in 906346 scanned packages
> run `npm audit fix` to fix 38620 of them.
> 314 vulnerabilities require manual review. See the full report for details.
While the real numbers are probably lower because there is a lot of duplication inside the node_modules folder, I find this ... astounding.
Javascript doesn't have a standard library (something a lot of languages provide), and nodejs's built-in functions library are... lacking. Also, the culture of providing small packages, being around for longer, and so on and so forth...
I have a project I haven't even started yet in Rust. Three dependencies in Cargo.toml. They download and install 34 dependencies.
I've now added three more (from kube-rs readme). It's now 197 dependencies. And so on.
There are bad packages in rust, go, python (1), even C. The worst of these are closer to the norm for JavaScript though. Personally I don’t feel comfortable running JavaScript packages outside of some kind of sandbox (usually a VM) on my personal computers.
(1) in fact, seeing some of the worst kept me away from python for far too long until I realized plenty of python software doesn’t even need pypi and most only need it for a couple things with no transitive dependencies
Yes. Using third-party code is not a binary decision between “write everything yourself” and “use all the things”, it is part of the ongoing conversation about optimization: Development time, deployable size, build time, tool support, community support, training, documentation, etc.
I agree that this isn't totally specific to JavaScript. It's just that the ecosystem is very extensive and so there are a lot of packages, because you don't need to write your own code for a lot of existing problems.
There is perhaps a something about the JavaScript audience tending to attract less advanced implementers. So you end up with a lot of otherwise considered trivial and low-quality utilities being published and pulled down from the registry.
Rust and Go tend to be for more advanced scenarios where things like performance, security and support matters tremendously.
If you mean that javascript gets a disproportional amount of hate, that might be because of how much more it is being used. It is true that rust seems to be ignoring the sins of the past and diving right in to having lots of dependencies, with the solution being to manage them instead of weeding them out in some way.
I’m not sure whataboutism is the way to fix the well-known issues the JS ecosystem has in package management. When I’ve installed a Go package or Python package I haven’t ended up with sometimes hundreds or thousands of sub-dependencies. Some packages can be ridiculous, but nothing like I have seen running “npm i” for something that seems like it should be simple. I apologize for not having an example off-hand but this keeps coming up precisely because it is an issue unique to JS in this case, even if other languages have it to a degree.
Try Feathers, a "lightweight web-framework for creating real-time applications and REST APIs" clocking in at about 600 transitive dependencies. How do you audit this?
I took a look, this sounds more unique to Rust than Go or Python, but they all can do it to some degree. I have no hands on experience with Rust to really have any reasonable input on this so I don’t want to make an uninformed statement.
Try installing a package for Rust. Or Go. Or ... any language, really.