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.

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.

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.