OC-301d · Module 1

Dependency Management

3 min read

Every dependency is a liability. Every npm package, every external API, every shared utility is a surface area for breakage. A module with 40 dependencies is a module with 40 reasons to break when nothing in your code changed. Dependency management is the discipline of minimizing dependencies, isolating the ones you keep, and having a plan for when they break.

The dependency audit asks three questions for each dependency. First: is this necessary, or can the functionality be achieved with standard library features? A date formatting library is unnecessary if Intl.DateTimeFormat handles the use case. Second: is this maintained? Check the last commit date, open issue count, and maintainer activity. A dependency abandoned in 2024 is a time bomb. Third: is this isolated? If the dependency is used directly in 15 files, removing or replacing it is a 15-file surgery. If it is wrapped in an adapter that 15 files import, removing it is a one-file change.

Do This

  • Wrap every external dependency in an adapter — one file to change if the dependency breaks or is replaced
  • Audit dependencies quarterly: is it maintained? Is it necessary? Can a lighter alternative replace it?
  • Pin dependency versions in production — automatic updates break production at the worst possible time

Avoid This

  • Import external packages directly in business logic — coupling makes replacement expensive
  • Add dependencies for trivial functionality — left-pad taught the industry this lesson
  • Use the latest version in production without testing — "latest" is a moving target that moves at inconvenient times