Dependency

A dependency is an external code library or package that a project relies on to work. When developers build a website or application, they rarely write every function themselves. Instead they lean on existing, tested code for common needs, such as handling dates, processing payments, rendering interfaces, or making network requests. Each of those external pieces the project pulls in is a dependency, so named because the project depends on it: if the library changed or disappeared, the project would break or fail to build.

Mechanically, dependencies are declared in a project's manifest file, which lists each required package and the acceptable range of versions. A package manager reads that list, downloads the packages, and installs them. Crucially, dependencies have dependencies of their own. A single library a developer adds may itself rely on a dozen others, and those on still more, forming a dependency tree that can grow surprisingly deep. This is why adding one seemingly small package can quietly bring a great deal of code into a project. Developers also distinguish between dependencies needed to run the finished product and those needed only while building or testing it, keeping the shipped code as lean as possible. A lock file records the exact versions installed so the same tree can be reproduced elsewhere.

The word comes from depend, rooted in the Latin dependere, meaning to hang from, combined with the suffix that forms a noun. The image is apt: in software, one piece of code hangs from another, unable to stand on its own. The term predates modern web development but became central to it as ecosystems of shareable, open-source packages made building on others' work the normal way to develop software.

For a business, dependencies are what make fast, cost-effective development possible. Reusing mature, well-tested libraries means teams do not spend time and money rebuilding solved problems, and they benefit from improvements and security fixes that the wider community contributes. A modern application is, in large part, an assembly of dependencies stitched together with the team's own code. Managed well, this leverage is a major advantage; managed poorly, it becomes a liability.

The common mistakes center on taking dependencies for granted. Every dependency is code the business now relies on but did not write and may not fully understand, so casually adding many of them bloats the project and expands the surface where bugs and security vulnerabilities can hide. A widely publicized risk is that a single compromised or abandoned package can affect countless projects that depend on it, which is why keeping dependencies updated, removing unused ones, and monitoring security advisories are essential habits. Pinning versions through a lock file guards against a surprise update silently changing behavior. When an update does cause a problem, the ability to roll back to a known-good set of versions is what limits the damage, which ties dependency management closely to version control and disciplined release practices. Understood clearly, a dependency is both a powerful shortcut and an ongoing responsibility, and treating it as the latter is what keeps a project stable over time.