我应该将 composer.lock 置于库的版本控制之下吗？ [复制]

Question

在对How to get the exact version of included packages in my private repository 的答复中，我声明不应将composer.lock 置于包 的版本控制之下。安装包的时候，这个文件根本用不到。

我查看了一组流行的存储库，其中大多数都不包含锁定文件（如 Symfony、Laravel、Guzzle、Monolog）。另一方面，Doctrine 存储库包含该文件，我想知道是否有充分的理由这样做，或者省略该文件。

---

旁注：这是关于包、库，但是你想调用它们。对于应用程序来说，这是另一回事，因为在团队合作或部署到其他系统时，您希望坚持每个依赖项的特定版本。 Should composer.lock be committed to version control? 中介绍了如何处理这种不同的情况，但对于我的用例，它没有包含太多参数

Answer 1

由于在安装包时文件没有以任何有用的方式使用，作为库本身对最终用户的功能，它至少与库的用户无关。

然后推理变成对于库的开发人员来说，拥有一组锁定的依赖项是否有用，他们需要执行开发任务，例如测试框架的特定版本等。在这些情况下，参数可以是 @ 987654322@ 文件的作用与常规应用程序中的相同 - 它将依赖项锁定到我们知道有效的那些。

但是，这里有一个警告 - 在开发库时，您真的希望用例与库的用户在安装它时的体验相同。考虑到这一点，锁定composer.json 中的显式版本通常更有意义，而不是依赖锁定文件来提供相同的功能。这使得任何 CI 解决方案在运行测试时都安装了正确的依赖集（与用户将获得的相同）。但是，您可以让该进程在运行测试之前在本地更新锁定文件以拥有多个测试用例 - 一个具有锁定的依赖项，一个具有最新版本（用户将获得）。

Doctrine 出于自己的原因做出了lock files should be committed 的决定，这是完全正确的 - 实际上他们归结为用于其开发工作流程的工具：

所有 Doctrine 项目都必须提交 composer.lock 文件。 phpstan 和 phpcs 之类的工具在补丁版本中非常脆弱，我们不希望在没有对自己的代码进行任何更改的情况下构建开始失败。每当需要升级依赖项时，应在本地更新 composer.lock 文件并通过拉取请求提交更改。

两种情况都可以进行论证；这将取决于项目本身及其开发人员的偏好。我倾向于不提交它，因为它更接近地复制了用户在安装库时的体验。但是，每个开发人员仍然存在本地锁定文件，这意味着每个开发人员在开发库时在他们自己的计算机上拥有的内容可能会有所不同。提交锁定文件将使所有开发人员的整体体验更加相似，但需要格外小心才能为用户复制体验（然后，我们又回到了最初的论点......）。

Answer 2

我的帖子不是关于纯库，而是一种对其他库有很多依赖关系的模块。该模块是各种应用程序的一部分。例如，如果我在部署我的应用程序时运行没有 composer.lock 的 composer install，我可能会推出我没有测试过的支架。因此，我将模块版本的依赖关系固定在具体状态上，当然还提交了 composer.lock。因此，在我看来，与 Symfony 等框架的比较有点滞后，因为这里没有部署任何东西。