For exactly this reason, when I write software, I go out of my way to avoid using external packages. For example, I recently wrote a tool in Python to synchronize weather-statation data to a local database. [1] It took only a little more effort to use the Python standard library to manage the downloads, as opposed to using an external package such as Requests [2], but the result is that I have no dependencies beyond what already comes with Python. I like the peace of mind that comes from not having to worry about a hidden tree of dependencies that could easily some day harbor a Trojan horse.

[1] https://github.com/tmoertel/tempest-personal-weather

[2] https://pypi.org/project/requests/

There is a reason. The prevailing wisdom has thus far been: "don't re-invent the wheel", or it non-HN equivalent "there is an app for that". I am absolutely not suggesting everyone should be rolling their own crypto, but there must be a healthy middle ground between that and a library that lets you pick font color.

Isn't this the same for maven, python, ruby projects too? I don't see this as a web only problem

Or worse

   sudo curl URL | bash

The project authors probably don't even know what libraries their project requires, because many of them are transitive dependencies. There is zero chance that they have checked those libraries for supply chain attacks.

This is the best reason for letting users install from npm directly instead of bundling dependencies with the project.

Most of which can be managed with good SAST tooling and process.

Rust is like this too. Every time I open a Rust project I look at Cargo.lock and see hundreds of recursive dependencies. Compared to traditional C or C++ projects it's madness.

Nearly every package manager does this. You would never get work done if you had to inspect every package. Services like renovate and dependabot do this lifting at no cost to the js developer, and probably do it better.

> There is zero chance that they have checked those libraries for supply chain attacks.

Even if they did, unless the project locked all underlying dependencies to git hashes, all it takes is a single update to one of those and you’re toast.

That’s why things like Dependabot are great.

This is a key vulnerability of package publication without peer review plus curation. Going to have to have many more automated behavioral code coverage analysis plus human reviewers rather than allowing unlimited, instant publication from anyone and everyone.

When I'm looking for a new NPM module to do some heavy lifting, I always look for modules with zero dependencies first. If I can't find one then I look for modules with the fewest dependencies second. No preinstall or postinstall scripts in package.json, not ever. It isn't perfect, but at least we try. We also don't update modules that frequently. If it isn't broken, don't fix it. That has saved us from some recent problems with module attacks.

Why is this comment instantly grey (downvoted)? What is wrong with HN and the people who accrue enough karma (you need 500 to downvote) who go around doing this?