4

I am reading/learning about Composer, the application-level package manager for PHP.

In this blog post written by lead dev Jordi Boggiano, he writes:

Composer on the other hand forces you to declare your project dependencies in a one-stop location (composer.json at the root). You just checkout the code, install dependencies, and they will sit in the project directory, not disturbing anything else on the machine. Another related feature is the composer.lock file that is generated when you install or update dependencies. It stores the exact version of every dependency that was used. If you commit it, anyone checking out the project will be able to install exactly the same versions as you did when you last updated that file, avoiding issues because of minor incompatibilities or regressions in different versions of a dependency.

If I understand Composer properly, when we're talking about packages downloaded/installed by Composer, we are talking about PHP code packages, ie, programming code written in PHP, and not system-level packages, eg, extensions to the PHP runtime installed on the server. So once these PHP code packages have been downloaded and added to a PHP project, I would have thought those packages become part of the PHP application source code, eg to be checked in to whichever version control system is being used for the project. If another developer comes along and checks out the code, why would they need to then "install the packages", as is stated in the blog post? Wouldn't they get a copy of all code packages when they check out the code from source control? This line in the blog post is confusing me, and making me think I don't understand Composer.

Any clarity on this would be greatly appreciated. Thanks.

Callum
  • 435
  • 1
  • 4
  • 14

2 Answers2

5

The dependencies themselves should not be commited to source control. The composer.json and composer.lock files, on the other hand, should. There's various reasons for this, amongst them:

  • Every time you update the dependency you would have to commit the changes. That kind of tightly couples your code to the dependency, when it should be exactly the other way around.
  • The packages themselves are already in their own repository with their own history. Why repeat that in your project's history?
  • Those repositories can be huge, just muddling the waters around your project. Why carry around all that weight?

Instead, having each developer just run composer install (very important: not composer update) whenever they check out the project is much more efficient. Composer will install the dependencies from composer.lock, making sure everyone running the same commit is on the exact same page. The same goes for deploying.

You can read more about this here.

On the other hand, there might be situations where you have to commit your packages to get around a problem, like for example when you know you won't be able to run composer install on your production server (shared hosting)

ishegg
  • 9,685
  • 3
  • 16
  • 31
4

Normally packages installed via composer don't get checked in to source control, only the code you write and the composer.json and composer.lock files.

This way the repository for your project does not get bloated with code you did not write and possibly don't really care that much about.

Yes its normal after cloning down your repository a developer will need to run the "composer install" command. The composer.lock file will ensure they get the same modules and versions of them you used when creating your project.

Not including the composer modules in your source control also allow you to easily update to the modules to get bug fixes and new features in new versions of them.

dougtesting.net
  • 571
  • 4
  • 9