What is a. lock file?

Asked

Viewed 2,598 times

4

I’m using git to convert a project and noticed when checking for modifications, that some files . json have a file with the same name, but with different extension and content.

Example: Composer.lock, Yarn.lock.

  1. What are?
  2. What are they for?
  3. Must Versionar or put in . gitignore?
  • see if that’s the case: https://githubengineering.com/git-concurrency-in-github-desktop/

  • 1

    and: https://yarnpkg.com/docs/yarn-lock/

1 answer

5


The archives .lock in these two cases are automatically generated by the package manager (Composer or Yarn) to ensure the exact version your code is using.

In the archives .json correspondent, you usually have a Constraint version, which when you update (using the composer update for example) will download the latest version of that dependency and then a file will be generated .lock with the versions he downloaded.

If there is a file .lock and you execute the command composer install, you will receive the exact version that is in your .lock and no longer the latest version.

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

Example:

  • You downloaded your project on Github and ran composer install, without an archive .lock and has the dependency 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 sent to Github your file .lock that’s in your machine
  • The person who maintains the batata/db fixed a bug and decided to generate a patch altering the version for 5.1.5
  • Now, if you install your project on another machine, with this file .lock, the version you will receive is the 5.1.4. Dependency will only be updated when running composer update.

Must Versionar or put in . gitignore?

This is a very common question. The advantage of viewing the file .lock ensures that exact version, already tested will be downloaded, for example, on your production server. Thus you allow deploys automated where a script download the remote repository on your Github for example and run the commands for install 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 certain dependency, which can generate several conflicts in these files .lock. In such cases keep a file .lock is not very interesting and have only the .json is enough, trusting in the Semver of its premises.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.