choose-dependencylisted

# Choosing a dependency Every dependency is a trade, and the obvious heuristics pull in opposite directions. Balance them deliberately. - **Force A — fewer dependencies is better.** Each third-party library is attack surface, a supply-chain risk, transitive bloat, a thing that can break or go unmaintained, and a version to track. The standard library is always the first choice; a pile of micro-dependencies is a smell. - **Force B — don't reinvent the wheel.** A library delegates a whole problem's maintenance to its owner. Hand-rolled helpers for solved, non-trivial problems are _our_ bug surface and _our_ maintenance burden forever, so **prefer a good external library to an internal reimplementation** of something already well-solved. These resolve into one rule: > **Import rarely; when you do, pick the broad, trusted, well-maintained option and consolidate on > it.** A batteries-included library from a reputable source that covers a whole domain beats a thin > wrapper that you'll have to supplement with three more libraries later. Fewer, better, broader > dependencies — not more, smaller ones. **Illustration.** Prefer an ORM like `bun` (struct decoding, query building, migrations, hooks all native, one maintainer) over a lower-level driver like `pgx` that needs extra third-party packages bolted on for the same ergonomics: one broad, well-maintained dependency replaces several narrow ones, fewer versions to track and one place to learn. Follow the _reasoning pa