Dependency Management

Direct and transitive dependencies, update risk, API stability, versioning as a communication convention, and deprecation as a lifecycle rather than a deletion.

Dependency Management

Every package in the lockfile is code you now operate without having written it — and most of it arrived without anyone making a decision.

Q · What am I actually taking on when I add a dependency, and how do I keep that decision reversible?
Transitive Dependencies

A small package can carry a large graph you did not choose, cannot audit, and run in production with your own privileges.

Q · I added one package and my install pulled in four hundred. What is my actual relationship to the ones I never named?
Do We Need a Package for This?

Four questions decide it: how much it does for you, how hard it would be to replace, what it drags in, and who maintains it.

Q · Should this be a dependency, code we write, or code we copy — and how do I answer that in under ten minutes?
API Stability

An interface with no external users still has consumers. Changing it frequently across many of them costs coordination, and that cost is invisible in every individual diff.

Q · This module is internal and we can change it whenever we like — so why does changing it keep costing us a week?
Semantic Versioning

A communication convention, not a guarantee. The number is a claim made by a human about their own code, and humans get it wrong in both directions.

Q · If a patch release cannot break me, why did a patch release break me?
Deprecation

Introduce the new thing, migrate the consumers, warn on the old, then remove it. Skipping a step does not save time; it moves the cost onto whoever is unlucky.

Q · How do I get rid of an internal interface that other people's code still calls?