This is an interesting question I have been asked about a few times now and it appears many developers are confused what the answer is. Long story short: Yes, you should commit your composer.lock file.
The composer.lock file is a build metadata file that specifies exact versions of dependencies in your Composer project. It means if someone else in the team pulls down your code, they will get the exact same versions specified.
In the official Composer documentation, it actually says to commit the file in bold.
Commit your application’s composer.lock (along with composer.json) into version control.
This does mean if there are updates and you first pull down the project, you won’t get them. You will need to run a “composer update” to get any updates to a dependency.
Please note, you should commit the composer.lock file only for projects and you should NEVER commit this file for a library someone else is installing, just projects.
What about in a situation such as this:
A laravel project being worked on by a few guys. We like to keep up to date with the various libraries that a fresh laravel install comes with as well as a few added libraries we use for functionality in the project.
We’ve noticed that if one of us runs “composer update” it updates all the versions in the composer.lock file. If this person pushes and someone else pulls, subsequently running “composer update” will bring errors and ultimately force a fresh composer install.
For this reason we removed compser.lock for our repo, and we just make sure everyone runs “composer update” regularly. Is this bad practice?
Newton, I wouldn’t say that is bad practice. Each scenario is unique and you have to decide what works best for your team.