Adding dependencies

REQUIRED BACKGROUND: the principal-engineering skill.

Overview

A dependency is a hire, not a snippet: with the feature come its defects, its release rhythm, its transitive tree, and its maintainer's attention span. Core principle: exhaust what you already have, vet what you take, pin what you took, and record why.

Exhaust what you already have

Work down the list and stop at the first level that holds; good answers often compose two levels, an existing dependency for the hard part with a few lines of your own around it:

1. The need itself. Speculative need is no need; skip it and say so in a line.
2. This codebase. A helper, type, or pattern a few files away does the job; reuse it. Writing a second copy of something the repo already contains is the same defect keeping-one-source-of-truth bans for data.
3. The standard library.
4. The platform. A database constraint over application code, a native control over a widget library, the runtime's own primitive over a wrapper.
5. A dependency the project already carries. Its transitive tree is already paid for. Two boundaries hide here: a transitive you start using is a NEW direct dependency (declare it, pin it to the already-resolved version, vet it lightly since the code already ships), and note which class the reuse crosses, because a dev-tool's transitive promoted into runtime changes who pays for it: every consumer's install, not just CI.
6. A few lines of your own. Owning twenty lines beats owning a stranger's repository, when twenty lines is truly all it takes.
7. Only past all six: a new dependency, vetted below.