Choose fewer, better dependencies

A dependency can save months of work. It can also add a permanent update and incident obligation.

Every package you add joins your trusted computing base: the set of code that can compromise your product if it misbehaves. It brings a maintainer account, a registry release path, and an update stream. Those stay attached to your product for as long as the package does.

A team considers adding a package to test whether a number is even. The package saves one line today. It is not hypothetical: is-even exists on npm, and it depends on is-odd, which depends on is-number. One trivial check imports three maintainer accounts into your supply chain.

Evaluate before you install

Before adding a package, spend two minutes on evidence:

npm view fastify time.modified maintainers
npm view fastify dependencies

The first command shows when the package was last published and who controls it. The second shows how many packages it drags in. A package last published four years ago with one maintainer and thirty dependencies is a different proposition than an actively maintained package with two dependencies.

Ask these questions and write down the answers:

• Does it solve a substantial, difficult problem, or duplicate a platform feature?
• Is there a credible maintenance path — releases, issue triage, more than one owner?
• What would replacing it cost in six months?

Prefer mature packages that solve hard problems. Avoid abandoned wrappers around things the language already does. Object.keys(), fetch, and structuredClone replaced whole families of utility packages.

Writing it yourself is not automatically safer

The goal is not zero dependencies. A mature parser or cryptographic library is difficult to replace correctly, and your hand-rolled version will not get security patches from anyone. Compare implementation risk with continuing dependency risk instead of counting packages.

Record why a sensitive dependency was chosen and how it could be replaced. That one paragraph turns a future incident from archaeology into a lookup.

Write a one-page decision for one proposed dependency: add it, implement the feature locally, or defer it. Include the code size, maintenance activity, install behavior, replacement cost, and security impact. Test the decision against an edge case where the local implementation would be difficult to get right.