As I'm sure anyone reading this knows, the default behavior for npm is to install sub-dependencies within their respective sub-dependency directories themselves (in a new node_modules directory). The default behavior for composer, on the other hand, simply puts all dependencies, including sub-dependencies, into a single vendor directory. As best I can currently surmise, this seems like poor design, since it could cause conflicts if two different dependencies were to use two different specific versions of the same sub-dependency.

But, of course, I think one ought to assume that the designers of composer must have had some good reasons for this deviation from the npm design. What might some of these reasons be?


First of all, I don't think Composer is trying too hard to be a PHP version of NPM - there may be similarities, but differences are to be expected. It may not be the best way to understand it to think of the tool as NPM, Maven, Rake or whatever, but translated into PHP.

Secondly, understand that Composer solves 'problem' of autoloading in PHP. Having two different versions of a given library in your vendor/ directory is not a state of affairs that Composer strives for here, and perhaps that is a good thing. Everything in your vendor/ directory is accessible in your user-land code via the same autoloader. Why would you want more that one class with the same fully-qualified classname? What should happen if you refer to that classname in your own code - which one do you want? I'm not sure we should even want PHP to know what to do when confronted with two different pieces of code each trying to interact with subtly different versions of the same dependency.

Composer replaces told like Pear and Pecl in PHP, and was partly inspired by the PSR-0/4 standards for PHP autoloading. It gives you all your dependencies in one place. It makes dependencies part of your project, not part of its documentation. It uses the semantic versioning that is becoming standard in PHP libraries to find versions of your dependencies that play nicely together, and if there aren't any, it tells you as much.

We've never had a tool like this in PHP before, and the change it has helped precipitate is much greater awareness on the parts of library and framework authors on how their tools work or don't work together. Much is being duke in the community to address these challenges. Composer may not be exactly like NPM, but its handling of PHP package management is ideally suited to the language, and really fills a gap which made deploying a large PHP application a pain in the neck before.

Not the answer you're looking for? Browse other questions tagged or ask your own question.