Installing a dependency takes ten seconds. That’s the whole appeal, and it’s the whole problem. Ten seconds buys you code you didn’t read, written by people you can’t name, pulled from a registry that trusts them because you did.
In March 2024 the xz-utils compression library shipped two versions, 5.6.0 and 5.6.1, with malicious code inside them. CISA’s alert told everyone to downgrade and go looking for signs of compromise. Almost nobody who had it installed had chosen it. It came in under something else, several layers down. That’s the shape of the risk. The package you pick is the tip. The tree under it is what you install.
Anyone who’s opened a node_modules folder a hundred times larger than the app it serves already knows this. The question is what to do about it.
Question every dependency before it goes in. Does what it does justify one more package to keep current, or is it twenty lines you could write and read once? I’ve done the twenty lines at a day job, for a small utility the registry had a package for, and it held up. Most of the time it’s the twenty lines.
When a package does earn its place, it has to earn all of it. Not the package, the tree. npm ls --all, go mod graph or cargo tree shows what you’re adding before you add it, and a small library with a large tree is a large library.
Then look at the repository, the boring way. Is it maintained? How many open issues and pull requests sit unanswered? Does it have tests? How many people contribute, and how many dependencies does it carry itself?
Once it’s in, lock the version, update on a schedule, and read the changelog of every major version before you take it. Skipping updates is its own cost. A week of upgrades put off for two years becomes a rewrite.
You don’t need zero dependencies. You need to have read the ones you have, and to say no more often than feels polite.