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.
see if that’s the case: https://githubengineering.com/git-concurrency-in-github-desktop/
– rmagalhaess
and: https://yarnpkg.com/docs/yarn-lock/
– rmagalhaess