Dependencies & Package Managers

Almost no software is written entirely from scratch. Developers build on top of existing code that other people wrote and maintain — date handling, image processing, encryption, and thousands of other solved problems. Pulled into a project, that reused code is a dependency, and it's the single biggest productivity multiplier in software.

Bringing in and keeping track of all that borrowed code is handled by a package manager. The whole arrangement is enormously powerful — and a real source of risk, which is why it's worth understanding even at a concept level.

An analogy: cooking with quality store-bought ingredients instead of milling your own flour and pressing your own oil. It's faster and usually better — but you're trusting the suppliers, and a bad ingredient becomes your problem.

Libraries and Dependencies

A library is a reusable bundle of code that solves a common problem, published for others to use. When your project relies on one, that library becomes a dependency — your code now depends on it to work. Using libraries is standard and wise: re-solving a problem that thousands have already solved well is usually a waste, and often less correct than the battle-tested version.

Package Managers

A package manager is a tool that fetches, installs, and tracks a project's dependencies — and, crucially, pins their exact versions so every developer and every server builds with the same code. You name the libraries you want; the package manager downloads them and records precisely which versions are in use. npm (for JavaScript) and pip (for Python) are common examples. It's the difference between a managed list and a chaotic pile of borrowed code.

Transitive Dependencies

Here's the catch that surprises beginners: your dependencies have dependencies of their own, and those have more. Pull in one library and you may quietly pull in fifty others it relies on — these indirect ones are called transitive dependencies. A modern project's dependency tree can run thousands deep, almost none of it written by your team. The package manager keeps that whole tree organized.

The Risks

All that borrowed code carries real risks. Dependencies add bloat (code you ship but barely use), can break when you upgrade them, and — most seriously — can contain security holes that become your security holes. A flaw in a library deep in your tree is a flaw in your product. This "supply chain" risk is so important it gets its own treatment in the security chapter; for now, just know that every dependency is a convenience and a liability at once.

Cadence uses a well-known date-handling library rather than writing tricky streak-and-calendar math from scratch — a sensible reuse. Its package manager pins that library to an exact version, so Marcus's machine, Lena's machine, and the production server all build with identical code. And when a security advisory later lands for that library, the team knows it's in their tree and patches it — borrowed code, borrowed responsibility.