What is a .lock file?

The .lock files in these two cases are automatically generated by the package manager (composer or yarn) to guarantee what exact version your code is using.

In the corresponding .json files, you usually have a version constraint , which when you upgrade (using composer update for example) will download the latest version of that dependency and then generated a .lock file with the versions that it downloaded.

If there is a .lock file and you run the command composer install , you will get the exact version that is in your .lock and not the most recent version.

In the absence of a .lock file, the install command has the same behavior as update .

Example:

• You have downloaded your project in GitHub and executed composer install , without a .lock file and has batata/db: 5.1.* as constraint
• At the end of the command, the .lock file is generated and you find the following version: batata/db: 5.1.4
• You continued with your work and uploaded to GitHub your .lock file on your machine
• The person holding batata/db fixed a bug and decided to generate a patch by changing the version to 5.1.5
• Now, if you install your project on another machine, with this file .lock , the version you will receive is 5.1.4 . The dependency will only be updated when running composer update .

  

Should I version or put in .gitignore?

This is a very common question. The advantage of versioning the .lock file is that it ensures that that exact version , already tested will be downloaded, for example, on your production server. This allows you to automate deploys where a script drops the remote repository in your GitHub for example and runs the install commands to download the dependencies.

On the other hand, if you are developing a package that will be used in other projects, it is difficult to ensure that all project contributors have the same version of a particular dependency, which can lead to multiple conflicts in these .lock files. In these cases keeping a .lock file is not very interesting and having only .json is enough, relying on the SemVer of your dependencies.