adding-dependencies

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. A second copy of something the repo already contains is the defect keeping-one-source-of-truth bans for data.
3. The standard library. Read its index before installing a package that duplicates it.
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. A transitive you start using is a NEW direct dependency: declare it, pin it to the already-resolved version, and vet it lightly since the code already ships. Check the class the reuse crosses: a dev-tool's transitive promoted into runtime shifts the cost to 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.