Should composer.lock be committed to version control?

Question

I\'m a little confused with composer.lock used in an application with a repository.

I saw many people saying that we should not .gitignore

Answer 1

For applications/projects: Definitely yes.

The composer documentation states on this (with emphasis):

Commit your application's composer.lock (along with composer.json) into version control.

Like @meza said: You should commit the lock file so you and your collaborators are working on the same set of versions and prevent you from sayings like "But it worked on my computer". ;-)

For libraries: Probably not.

The composer documentation notes on this matter:

Note: For libraries it is not necessarily recommended to commit the lock file (...)

And states here:

For your library you may commit the composer.lock file if you want to. This can help your team to always test against the same dependency versions. However, this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project.

For libraries I agree with @Josh Johnson's answer.

Answer 2

If you’re concerned about your code breaking, you should commit the composer.lock to your version control system to ensure all your project collaborators are using the same version of the code. Without a lock file, you will get new third-party code being pulled down each time.

The exception is when you use a meta apps, libraries where the dependencies should be updated on install (like the Zend Framework 2 Skeleton App). So the aim is to grab the latest dependencies each time when you want to start developing.

^{Source: Composer: It’s All About the Lock File}

See also: What are the differences between composer update and composer install?