Many developers ignore the composer.lock into their .gitignore, because it’s an auto-generated file. By analyzing the .gitignore’s purpose this theory is correct, however, is a good practice to manage the version control of this file and use the composer install command to prepare an environment. Avoid composer update, let’s check the basis that sustains that idea in order to apply this change to your projects.
– 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 lock file, will become the installation of dependencies 2x faster.
– You can let it more optimized using the parameters to optimize the autoload. Prefer the packages via source, and avoiding getting the dev dependencies in a production.
– As each install will use the lock file, it will install the same package distribution version for each developer. Avoid 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 production. It might update packages that you didn’t update in staging yet, the staging environment might lose its purpose.
Are you versioning your lock file? let me know in the comments below! If you need consulting for your company or project, let me know here.
