DEV Community

Cover image for Versioning or not the composer.lock file?

Versioning or not the composer.lock file?

rafaelcg profile image Rafael Corrêa Gomes Originally published at Updated on ・2 min read

Many developers ignore the composer.lock into their .gitignore, it because it's an auto-generated file. By analyzing the .gitignore's purpose this theory is correct, however, is a good practice managing the version control of this file, and using the composer install command to prepare an environment, not composer update, let's check basis that sustains that idea in order to apply this change on your projects.

Using or not the composer.lock file

- You can find in the Composer documentation saying:

"You should commit the composer.lock file to your project repo so that all people working on the project are locked to the same versions of dependencies."

- Having the composer.lock file, it will become the installation of composer dependencies 2x faster.

- You can let it more optimised using the parameters to optimize the autoload, to prefer the packages via source and avoiding getting the dev dependencies in a production environment.

- As each install will use the composer.lock file, it will install the same package distribution version for each developer, avoiding the famous sentence "It's working in my machine".

- This practice is not recommended for libraries according to the Composer Documentation.

"For your library, you may commit the composer.lock file if you want to."

- Never use composer update in your production, it might update packages which you didn't update in UAT yet, so, UAT environment loses its purpose.

Are you versioning you composer.lock? let me know in the comments below!

Discussion (3)

Editor guide
szymach profile image
Piotr Szymaszek • Edited

In a non-library repository? Always, that is the main purpose of having it, to be able to install a working set of packages anytime, anywhere. It also prevents breaking changes being introduced in a vendor library and provides a smoother way of upgrading to newer versions of these - you only update when you want to.

For a library or something meant to be used in other people's code? No, it does not really make a whole lot of sense. You would usually provide a range of versions for each package for which your code works and let the user deal with sorting out the dependency map. Since you have to be able to support that range via testing through some CI anyway, a lock file would get constantly changed, which seems quite redundant. Also, it bloats the repository with a big file that never gets used in the target project, since only the top level lock file defines which version gets installed.

rafaelcg profile image
Rafael Corrêa Gomes Author

Excellent arguments Piotr, I'll update my opinion about it.

chyn_km profile image

Thanks for the valuable insights regarding composer :)