git composer.lock 应该致力于版本控制吗？

Should composer.lock be committed to version control?

提问by Pierre de LESPINAY

I'm a little confused with composer.lockused in an application with a repository.

我对composer.lock在带有存储库的应用程序中使用感到有些困惑。

I saw many people saying that we should not .gitignorecomposer.lockfrom the repository.

我看到很多人说我们不应该.gitignorecomposer.lock从存储库中提取。

If I update my libraries in my dev environment, I will have a new composer.lockbut I will not be able to update them into production, will I ?

如果我在我的开发环境中更新我的库，我会有一个新的composer.lock但我将无法将它们更新到生产中，是吗？

Won't it generate conflicts on this file ?

它不会在这个文件上产生冲突吗？

回答by meza

If you update your libs, you want to commit the lockfile too. It basically states that your project is locked to those specific versions of the libs you are using.

如果你更新你的库，你也想提交锁文件。它基本上表明您的项目已锁定到您正在使用的那些特定版本的库。

If you commit your changes, and someone pulls your code and updates the dependencies, the lockfile should be unmodified. If it is modified, it means that you have a new version of something.

如果您提交了更改，并且有人拉取了您的代码并更新了依赖项，那么锁文件应该是未修改的。如果它被修改了，这意味着你有一个新版本的东西。

Having it in the repository assures you that each developer is using the same versions.

将它放在存储库中可以确保每个开发人员都使用相同的版本。

回答by Jeroen Fiege

For applications/projects: Definitely yes.

对于应用程序/项目：绝对是。

The composer documentationstates on this (with emphasis):

该作曲家文档在此（重点）规定：

Commit your application's composer.lock (along with composer.json) into version control.

将应用程序的 composer.lock（连同 composer.json）提交到版本控制中。

Like @meza said: You should commit the lock file so you and your collaborators are working on the same set of versions and prevent you from sayings like "But it worked on my computer". ;-)

就像@meza 说的：你应该提交锁定文件，这样你和你的合作者就可以在同一组版本上工作，并防止你说“但它在我的电脑上工作”。;-)

For libraries: Probably not.

对于图书馆：可能不是。

The composer documentation notes on this matter:

作曲家文档对此问题的说明：

Note: For libraries it is not necessarily recommended to commit the lock file (...)

注意：对于库，不一定建议提交锁定文件 (...)

And states here:

并在此声明：

For your library you may commit the composer.lock file if you want to. This can help your team to always test against the same dependency versions. However, this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project.

对于您的库，您可以根据需要提交 composer.lock 文件。这可以帮助您的团队始终针对相同的依赖项版本进行测试。但是，这个锁定文件不会对依赖它的其他项目产生任何影响。它只对主项目有影响。

For libraries I agree with @Josh Johnson's answer.

对于图书馆，我同意@Josh Johnson 的回答。

回答by Josh Johnson

After doing it both ways for a few projects my stance is that composer.lockshould not be committed as part of the project.

在对一些项目进行双向操作后，我的立场是composer.lock不应该作为项目的一部分进行提交。

composer.lockis build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

composer.lock是不属于项目的构建元数据。依赖项的状态应该通过您如何对它们进行版本控制（手动或作为自动构建过程的一部分）来控制，而不是由最后一个开发人员随意更新它们并提交锁定文件。

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

如果您担心在 Composer 更新之间的依赖关系发生变化，那么您对版本控制方案缺乏信心。版本（1.0、1.1、1.2 等）应该是不可变的，并且您应该避免在初始功能开发之外使用“dev-”和“X.*”通配符。

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicitly defined.

提交锁定文件是依赖管理系统的回归，因为依赖版本现在已经恢复为隐式定义。

Also, your project should never have to be rebuilt or have its dependencies reacquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing.

此外，您的项目不应该在每个环境中重新构建或重新获取其依赖项，尤其是 prod。您的可交付成果（tar、zip、phar、目录等）应该是不可变的，并且可以在不改变的情况下通过环境进行推广。

回答by lebobbi

1. You shouldn't update your dependencies directly on Production.
2. You should version control your composer.lockfile.
3. You shouldn't version control your actual dependencies.

1. 您不应该直接在 Production 上更新您的依赖项。
2. 您应该对composer.lock文件进行版本控制。
3. 您不应该对实际依赖项进行版本控制。

1. You shouldn't update your dependencies directly on Production, because you don't know how this will affect the stability of your code. There could be bugs introduced with the new dependencies, it might change the way the code behaves affecting your own, it could be incompatible with other dependencies, etc. You should do this in a dev environment, following by proper QA and regression testing, etc.

1. 您不应该直接在 Production 上更新您的依赖项，因为您不知道这将如何影响您代码的稳定性。新依赖项可能会引入错误，它可能会改变影响您自己的代码行为方式，它可能与其他依赖项不兼容等。您应该在开发环境中执行此操作，然后进行适当的 QA 和回归测试等.

2. You should version control your composer.lockfile, because this stores information about your dependencies and about the dependencies of your dependencies that will allow you to replicate the current state of the code. This is important, because, all your testing and development has been done against specific code. Not caring about the actual version of the code that you have is similar to uploading code changes to your application and not testing them. If you are upgrading your dependencies versions, this should be a willingly act, and you should take the necessary care to make sure everything still works. Losing one or two hours of up time reverting to a previous release version might cost you a lot of money.

2. 你应该对你的composer.lock文件进行版本控制，因为它存储了关于你的依赖项以及你的依赖项的依赖项的信息，这些信息将允许你复制代码的当前状态。这很重要，因为您的所有测试和开发都是针对特定代码完成的。不关心您拥有的代码的实际版本类似于将代码更改上传到您的应用程序而不对其进行测试。如果您正在升级您的依赖项版本，这应该是一种自愿的行为，您应该采取必要的措施以确保一切仍然有效。失去一两个小时的正常运行时间以恢复到以前的发布版本可能会花费您很多钱。

One of the arguments that you will see about not needing the composer.lockis that you can set the exact version that you need in your composer.jsonfile, and that in this way, every time someone runs composer install, it will install them the same code. This is not true, because, your dependencies have their own dependencies, and their configuration might be specified in a format that it allows updates to subversions, or maybe even entire versions.

您将看到的关于不需要composer.lock的论点之一是您可以在composer.json文件中设置您需要的确切版本，这样，每次有人运行时composer install，它都会安装相同的版本代码。这是不正确的，因为您的依赖项有自己的依赖项，并且它们的配置可能以允许更新子版本甚至整个版本的格式指定。

This means that even when you specify that you want Laravel 4.1.31 in your composer.json, Laravel in its composer.jsonfile might have its own dependencies required as Symfony event-dispatcher: 2.*. With this kind of config, you could end up with Laravel 4.1.31 with Symfony event-dispatcher 2.4.1, and someone else on your team could have Laravel 4.1.31 with event-dispatcher 2.6.5, it would all depend on when was the last time you ran the composer install.

这意味着即使你在composer.json 中指定你想要 Laravel 4.1.31，它的composer.json文件中的Laravel也可能有它自己的依赖项，如 Symfony event-dispatcher: 2.*。使用这种配置，您最终可以使用带有 Symfony event-dispatcher 2.4.1 的 Laravel 4.1.31，而您团队中的其他人可以使用带有 event-dispatcher 2.6.5 的 Laravel 4.1.31，这完全取决于何时是您最后一次运行 composer install 。

So, having your composer.lockfile in the version system will store the exact version of this sub-dependencies, so, when you and your teammate does a composer install (this is the way that you will install your dependencies based on a composer.lock) you both will get the same versions.

因此，在版本系统中拥有您的composer.lock文件将存储此子依赖项的确切版本，因此，当您和您的队友安装 composer 时（这是您将基于composer.lock安装依赖项的方式）。 lock) 你们都将获得相同的版本。

What if you wanna update? Then in your dev environment run: composer update, this will generate a new composer.lockfile (if there is something new) and after you test it, and QA test and regression test it and stuff. You can push it for everyone else to download the new composer.lock, since its safe to upgrade.

如果你想更新怎么办？然后在你的开发环境中运行：composer update，这将生成一个新的composer.lock文件（如果有新的东西），在你测试它之后，QA 测试和回归测试它等等。您可以将其推送给其他人以下载新的composer.lock，因为它可以安全升级。

3. You shouldn't version control your actual dependencies, because it makes no sense. With the composer.lockyou can install the exact version of the dependencies and you wouldn't need to commit them. Why would you add to your repo 10000 files of dependencies, when you are not supposed to be updating them. If you require to change one of this, you should fork it and make your changes there. And if you are worried about having to fetch the actual dependencies each time of a build or release, composer has different ways to alleviate this issue, cache, zip files, etc.

3. 你不应该版本控制你的实际依赖，因为它没有意义。使用composer.lock您可以安装依赖项的确切版本，而无需提交它们。当您不应该更新它们时，为什么要将 10000 个依赖项文件添加到您的 repo 中。如果您需要更改其中之一，您应该分叉它并在那里进行更改。如果您担心每次构建或发布时都必须获取实际依赖项，composer 有不同的方法来缓解这个问题，缓存、zip 文件等。

回答by waanders

You then commit the composer.jsonto your project and everyone else on your team can run composer install to install your project dependencies.

The point of the lock file is to record the exact versions that are installed so they can be re-installed. This means that if you have a version spec of 1.* and your co-worker runs composer update which installs 1.2.4, and then commits the composer.lock file, when you composer install, you will also get 1.2.4, even if 1.3.0 has been released. This ensures everybody working on the project has the same exact version.

This means that if anything has been committed since the last time a composer install was done, then, without a lock file, you will get new third-party code being pulled down.

Again, this is a problem if you're concerned about your code breaking. And it's one of the reasons why it's important to think about Composer as being centered around the composer.lock file.

然后，您将 提交composer.json到您的项目，您团队中的其他人都可以运行 composer install 来安装您的项目依赖项。

锁定文件的目的是记录已安装的确切版本，以便可以重新安装。这意味着如果你的版本规范是 1.* 并且你的同事运行 composer update 安装 1.2.4，然后提交 composer.lock 文件，当你安装 composer 时，你也会得到 1.2.4，即使如果 1.3.0 已经发布。这可确保参与该项目的每个人都具有相同的确切版本。

这意味着，如果自上次 Composer 安装完成以来已提交任何内容，那么，如果没有锁定文件，您将获得新的第三方代码被拉下。

同样，如果您担心代码破坏，这将是一个问题。这也是将 Composer 视为以 composer.lock 文件为中心很重要的原因之一。

Source: Composer: It's All About the Lock File.

来源：作曲家：一切都与锁定文件有关。

---

---

Commit your application's composer.lock (along with composer.json) into version control. This is important because the install command checks if a lock file is present, and if it is, it downloads the versions specified there (regardless of what composer.json says). This means that anyone who sets up the project will download the exact same version of the dependencies. Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then.

将应用程序的 composer.lock（连同 composer.json）提交到版本控制中。这很重要，因为安装命令会检查锁定文件是否存在，如果存在，它会下载那里指定的版本（不管 composer.json 怎么说）。这意味着设置项目的任何人都将下载完全相同版本的依赖项。您的 CI 服务器、生产机器、您团队中的其他开发人员，所有事物和每个人都在相同的依赖项上运行，这减少了仅影响部署的某些部分的错误的可能性。即使您单独开发，在六个月内重新安装项目时，您仍然可以确信安装的依赖项仍然有效，即使您的依赖项从那时起发布了许多新版本。

Source: Composer - Basic Usage.

来源：作曲家 - 基本用法。

回答by kenorb

If you're concerned about your code breaking, you should commit the composer.lockto your version control system to ensure all your project collaborators are using the same version of the code. Without a lock file, you will get new third-party code being pulled down each time.

如果您担心代码被破坏，您应该将其提交composer.lock给您的版本控制系统，以确保您的所有项目合作者都使用相同版本的代码。如果没有锁定文件，您每次都会得到新的第三方代码。

The exception is when you use a meta apps, libraries where the dependencies should be updated on install (like the Zend Framework 2 Skeleton App). So the aim is to grab the latest dependencies each time when you want to start developing.

例外情况是当您使用元应用程序时，应在安装时更新依赖项的库（如Zend Framework 2 Skeleton App）。因此，目的是每次要开始开发时获取最新的依赖项。

^{Source: Composer: It's All About the Lock File}

^{来源：作曲家：一切都与锁定文件有关}

See also: What are the differences between composer update and composer install?

另请参阅：composer update 和 composer install 之间有什么区别？

回答by jgmjgm

There's no exact answer to this.

对此没有确切的答案。

Generally speaking, composer shouldn't be doing what the build system is meant to be doing and you shouldn't be putting composer.lock in VCS. Composer might strangely have it backwards. End users rather than produces shouldn't be using lock files. Usually your build system keeps snapshots, reusable dirs, etc rather than an empty dir each time. People checkout out a lib from composer might want that lib to use a lock so that the dependencies that lib loads have been tested against.

一般来说，composer 不应该做构建系统应该做的事情，也不应该将 composer.lock 放在 VCS 中。作曲家可能奇怪地把它倒过来了。最终用户而不是生产者不应使用锁定文件。通常，您的构建系统每次都会保留快照、可重用目录等，而不是一个空目录。人们从 composer 签出一个库可能希望该库使用锁，以便库加载的依赖项已经过测试。

On the other hand that significantly increases the burden of version management, where you'd almost certainly want multiple versions of every library as dependencies will be strictly locked. If every library is likely to have a slightly different version then you need some multiple library version support and you can also quickly see the size of dependencies needed flair out, hence the advise to keep it on the leaf.

另一方面，这显着增加了版本管理的负担，您几乎肯定希望每个库都有多个版本，因为依赖项将被严格锁定。如果每个库的版本可能略有不同，那么您需要一些多库版本支持，并且您还可以快速查看所需依赖项的大小，因此建议将其保留在叶子上。

Taking that on board, I really don't find lock files to be useful either libraries or your own workdirs. It's only use for me is in my build/testing platform which persists any externally acquired assets only updating them when requested, providing repeatable builds for testing, build and deploy. While that can be kept in VCS it's not always kept with the source tree, the build trees will either be elsewhere in the VCS structure or managed by another system somewhere else. If it's stored in a VCS it's debatable whether or not to keep it in the same repo as source trees because otherwise every pull can bring in a mass of build assets. I quite like having things all in a well arranged repo with the exception of production/sensitive credentials and bloat.

考虑到这一点，我真的不认为锁定文件对库或您自己的工作目录有用。它仅用于我的构建/测试平台，该平台保留任何外部获取的资产，仅在请求时更新它们，为测试、构建和部署提供可重复的构建。虽然它可以保存在 VCS 中，但它并不总是与源代码树一起保存，构建树要么位于 VCS 结构中的其他地方，要么由其他地方的另一个系统管理。如果它存储在 VCS 中，是否将它保存在与源树相同的存储库中是有争议的，否则每次拉取都会带来大量构建资产。除了生产/敏感凭证和膨胀之外，我非常喜欢将所有东西都放在一个精心安排的回购中。

SVN can do it better than git as it doesn't force you to acquire the entire repo (though I suspect that's not actually strictly needed for git either but support for that is limited and it's not commonly used). Simple build repos are usually just an overlay branch you merge/export the build tree into. Some people combine exernal resources in their source tree or separate further, external, build and source trees. It usually serves two purposes, build caching and repeatable builds but sometimes keeping it separate on at least some level also permits fresh/blank builds and multiple builds easily.

SVN 可以比 git 做得更好，因为它不会强迫您获取整个 repo（尽管我怀疑这实际上也不是 git 所必需的，但对它的支持是有限的，并且不常用）。简单的构建存储库通常只是您将构建树合并/导出到的覆盖分支。有些人在他们的源树中组合外部资源，或者进一步分离外部资源、构建树和源树。它通常有两个目的，构建缓存和可重复构建，但有时至少在某个级别上将其分开也可以轻松地进行新鲜/空白构建和多个构建。

There are a number of strategies for this and none of them particularly work well with persisting the sources list unless you're keeping external source in your source tree.

对此有许多策略，除非您将外部源保留在源树中，否则它们中没有一个特别适用于持久化源列表。

They also have things like hashes in of the file, how do that merge when two people update packages? That alone should make you think maybe this is misconstrued.

他们也有文件中的哈希之类的东西，当两个人更新包时如何合并？仅此一点就应该让您认为这可能被误解了。

The arguments people are putting forward for lock files are cases where they've taken a very specific and restrictive view of the problem. Want repeatable builds and consistent builds? Include the vendor folder in VCS. Then you also speed up fetching assets as well as not having to depend on potentially broken external resources during build. None of the build and deploy pipelines I create require external access unless absolutely necessary. If you do have to update an external resource it's once and only once. What composer is trying to achieve makes sense for a distributed system except as mentioned before it makes no sense because it would end up with library dependency hell for library updates with common clashes and updates being as slow as the slowest to update package.

人们为锁定文件提出的论点是他们对问题采取了非常具体和限制性的观点。想要可重复的构建和一致的构建？在 VCS 中包含供应商文件夹。然后，您还可以加快获取资产的速度，并且不必在构建过程中依赖可能损坏的外部资源。除非绝对必要，否则我创建的任何构建和部署管道都不需要外部访问。如果您确实必须更新外部资源，则只有一次。作曲家试图实现的对于分布式系统来说是有意义的，除非如前所述它没有意义，因为它最终会导致库更新的库依赖地狱，常见冲突和更新与最慢的更新包一样慢。

Additionally I update ferociously. Every time I develop I update and test everything. There's a very very tiny window for significant version drift to sneak in. Realistically as well, when semantic versioning is upheld, which is tends to be for composer, you're not suppose to have that many compatibility issues or breakages.

另外我更新的很凶。每次开发时，我都会更新和测试所有内容。有一个非常非常小的窗口可以让显着的版本漂移潜入。实际上，当语义版本控制被支持时，这往往是为作曲家，你不应该有那么多的兼容性问题或损坏。

In composer.json you put the packages you require and their versions. You can lock the versions there. However those packages also have dependencies with dynamic versions that wont be locked by composer.json (though I don't see why your couldn't also put them there yourself if you do want them to be version locked) so someone else running composer install gets something different without the lock. You might not care a great deal about that or you might care, it depends. Should you care? Probably at least a little, enough to ensure you're aware of it in any situation and potential impact, but it might not be a problem either if you always have the time to just DRY run first and fix anything that got updated.

在 composer.json 中放置所需的包及其版本。您可以在那里锁定版本。然而，这些包也具有不会被 composer.json 锁定的动态版本的依赖项（尽管我不明白为什么如果你确实希望它们被版本锁定，你不能自己也把它们放在那里）所以其他人运行 composer install没有锁就会得到不同的东西。你可能不太关心这个，或者你可能关心，这取决于。你应该关心吗？可能至少有一点，足以确保您在任何情况和潜在影响下都知道它，但如果您总是有时间先 DRY 运行并修复任何更新的内容，那么这可能也不是问题。

The hassle composer is trying to avoid sometimes just isn't there and the hassle having composer lock files can make is significant. They have absolutely no right to tell users what they should or shouldn't do regarding build versus source assets (whether to join of separate in VCS) as that's none of their business, they're not the boss of you or me. "Composer says" isn't an authority, they're not your superior officer nor do they give anyone any superiority on this subject. Only you know your real situation and what's best for that. However, they might advise a default course of action for users that don't understand how things work in which case you might want to follow that but personally I don't think that's a real substitute for knowing how things work and being able to properly workout your requirements. Ultimately, their answer to that question is a best guess. The people who make composer do not know where you should keep your composer.lock nor should they. Their only responsibility is to tell you what it is and what it does. Outside of that you need to decide what's best for you.

作曲家试图避免的麻烦有时只是不存在，而让作曲家锁定文件可能造成的麻烦很重要。他们绝对没有权利告诉用户他们应该或不应该做什么关于构建与源资产（是否在 VCS 中单独加入），因为这不关他们的事，他们不是你我的老板。“作曲家说”不是权威，他们不是你的上级，也不会在这个问题上给任何人任何优势。只有你知道你的真实情况以及什么是最好的。但是，他们可能会建议不了解事情如何运作的用户采用默认的行动方案，在这种情况下，您可能希望遵循该方案，但我个人认为不会” 真正替代了解事物如何运作并能够正确满足您的要求。最终，他们对这个问题的回答是最好的猜测。制作 composer 的人不知道你应该把你的 composer.lock 放在哪里，他们也不知道。他们唯一的责任是告诉您它是什么以及它有什么作用。除此之外，您需要决定什么最适合您。

Keeping the lock file in is problematic for usability because composer is very secretive about whether it uses lock or JSON and doesn't always to well to use both together. If you run install it only uses the lock file it would appear so if you add something to composer.json then it wont be installed because it's not in your lock. It's not intuitive at all what operations really do and what they're doing in regards to the json/lock file and sometimes don't appear to even make sense (help says install takes a package name but on trying to use it it says no).

将锁定文件保留在可用性方面是有问题的，因为 composer 对于它是使用锁定还是 JSON 非常保密，并且并不总是很好地将两者一起使用。如果你运行 install 它只使用它会出现的锁文件，所以如果你向 composer.json 添加一些东西，那么它不会被安装，因为它不在你的锁中。对于 json/lock 文件，操作真正执行的操作以及它们正在执行的操作根本不直观，有时甚至似乎没有意义（帮助说安装需要一个包名，但在尝试使用它时说不）。

To update the lock or basically apply changes from the json you have to use update and you might not want to update everything. The lock takes precedence for choosing what should be installed. If there's a lock file, it's what's used. You can restrict update somewhat but the system is still just a mess.

要更新锁或基本上应用来自 json 的更改，您必须使用 update 并且您可能不想更新所有内容。锁定优先选择应安装的内容。如果有锁定文件，那就是使用的文件。您可以稍微限制更新，但系统仍然只是一团糟。

Updating takes an age, gigs of RAM. I suspect as well if you pick up a project that's not been touched for a while that it looked from the versions it has up, which there will be more of over time and it probably doesn't do that efficiently which just strangles it.

更新需要很长时间，内存的演出。我也怀疑，如果你拿起一个有一段时间没有接触过的项目，它会从它的版本中看到它，随着时间的推移会有更多的版本，而且它可能不会有效地完成它，只会扼杀它。

They're very very sneaky when it comes to having secret composite commands you couldn't expect to be composite. By default the composer remove command appears to maps to composer update and composer remove for example.

当涉及到您无法期望复合的秘密复合命令时，它们非常非常狡猾。默认情况下， composer remove 命令显示为映射到 composer update 和 composer remove 例如。

The question you really need to be asking is not if you should keep the lock in your source tree or alternatively whether you should persist it somewhere in some fashion or not but rather you should be asking what it actually does, then you can decide for yourself when you need to persist it and where.

您真正需要问的问题不是您是否应该将锁保留在源代码树中，或者是否应该以某种方式将其持久化，而是您应该询问它实际做了什么，然后您可以自己决定当你需要坚持它以及在哪里。

I will point out that having the ability to have the lock is a great convenience when you have a robust external dependency persistence strategy as it keeps track of you the information useful for tracking that (the origins) and updating it but if you don't then it's neither here not there. It's not useful when it's forced down your throat as a mandatory option to have it polluting your source trees. It's a very common thing to find in legacy codebases where people have made lots of changes to composer.json which haven't really been applied and are broken when people try to use composer. No composer.lock, no desync problem.

我会指出，当您拥有强大的外部依赖持久性策略时，拥有锁定的能力会非常方便，因为它会跟踪您对跟踪（来源）和更新它有用的信息，但如果您不这样做那么它既不在这里也不在那里。当它被强制压入您的喉咙时，它是没有用的，因为它会污染您的源树。在遗留代码库中发现人们对 composer.json 进行了大量更改，这些更改尚未真正应用并且在人们尝试使用 composer 时被破坏是很常见的事情。没有 composer.lock，没有不同步问题。

回答by Dinesh Suthar

Yes obviously.

是的，很明显。

That's because a locally installed composer will give first preference to composer.lock file over composer.json.

这是因为本地安装的 composer 会优先使用 composer.lock 文件而不是 composer.json。

If lock file is not available in vcs the composer will point to composer.json file to install latest dependencies or versions.

如果 vcs 中没有锁定文件，composer 将指向 composer.json 文件以安装最新的依赖项或版本。

The file composer.lock maintains dependency in more depth i.e it points to the actual commit of the version of the package we include in our software, hence this is one of the most important files which handles the dependency more finely.

文件 composer.lock 更深入地维护依赖关系，即它指向我们包含在软件中的包版本的实际提交，因此这是最重要的文件之一，可以更精细地处理依赖关系。