Code your project leans on
Very few projects are built entirely from scratch. A web app might rely on a framework for routing, a library for dates, and a driver for talking to its database. Each of those outside pieces is a dependency: remove it and your project stops working. It's similar to a recipe that calls for store-bought puff pastry. You didn't make the pastry, but the dish fails without it.
Projects record their dependencies in a manifest file so anyone can rebuild the same setup: package.json for Node.js, requirements.txt or pyproject.toml for Python, composer.json for PHP. Alongside it, a lock file (package-lock.json, composer.lock) pins the exact versions that were installed, so a teammate or a server gets identical copies.
Declaring a dependency with Composer
composer require monolog/monolog # adds it to composer.json and composer.lock
composer install # installs exactly what the lock file lists
A constraint such as ^3.0 in composer.json or package.json means "any compatible 3.x release," following semantic versioning.
Direct vs transitive dependencies
Things you install on purpose are direct dependencies. But each package you add may have dependencies of its own, and those have theirs. These indirect ones are called transitive dependencies, and a modest project can end up with hundreds of them.
That matters for two reasons. First, a bug or security hole deep in the tree affects you even though you never chose that package. Running npm audit or composer audit checks for known vulnerabilities. Second, two packages might need incompatible versions of the same shared dependency, a situation usually called a version conflict. Package managers try to resolve this, and the lock file freezes the result once they succeed.
Keep the list lean: every dependency is code you trust but didn't write.
Learn more
Last updated