For me, it’s not about reaching zero dependencies. But having dependencies that we cautiously agreed upon.
The following section about SBOMs covers what I’m about to say, but I want to add to it. Most (all?) major ecosystems include lockfiles that let you control exact dependency versions and look at them. Always be explicit when updating the lockfile.
I also want to add that Nix gives you the ability to do this at the tooling level. While I’m not going to say everyone should go install Nix, do seriously consider that or devcontainers or some other kind of solution to ensure that you don’t get hit by tools you rely on becoming compromised suddenly (PSA: if you use AUR, seriously read that thread). As long as you can pin a specific version of each tool you use, whether by creating a shared image, by pinning a nixpkgs commit, or whatever, you shouldn’t have anything suddenly change on you.
There was an excellent point somewhere by some youtuber-coder. I don’t remember off the top of my head.
If you ever find yourself at the point where you are deciding on whether to fork a huge project or update to the latest version, you maybe just experiencing the consequence of deciding to have your core product have external dependencies at inception.
I am paraphrasing of course.
Sure you can, you just gotta wait for it to be orphaned and then you can do unimaginably horrible things with it. Of course, that doesn’t constitute legal ownership, but still.
Agree most with the audit-fatigue point. A signal that is always red trains everyone to ignore red, and the same failure kills lint warnings and flaky test suites. The other line that stuck was taking a dependency without deciding to. We started listing direct dependencies in review for exactly that reason, adding one became a decision someone makes rather than a side effect of npm install, and the conversation it forces is usually short but occasionally stops a bad one.
