我应该把作曲家。是否在库的版本控制下锁定？[副本]

Question

在回答如何在我的私有存储库中获得包含的包的确切版本时，我声明不应该将composer.lock置于包的版本控制之下。安装包的时候，这个文件终究是不用的。

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

附带说明：这是关于包，库，不管你想怎么称呼它们。对于应用程序，这是另一回事，因为当在团队中一起工作或部署到其他系统时，您希望坚持每个依赖项的特定版本。如何处理这种不同的情况包含在composer.lock应该致力于版本控制吗？中，但它不包含我的用例的太多参数

Answer 1

我的文章不是关于纯库的，而是一种对其他库有很多依赖关系的模块。该模块是各种应用程序的一部分。例如，如果我在没有composer的情况下运行composer安装。在部署我的应用程序时，我可能会推出我没有测试过的支架。因此，我修复了模块版本对具体状态的依赖关系，当然还提交了编写器。锁因此，在我看来，与Symfony这样的框架相比有点滞后，因为这里没有部署任何东西。

Answer 2

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

然后，推理就变成了拥有执行开发任务所需的一组锁定的依赖项对库的开发人员是否有用，例如测试框架的特定版本等。在这些情况下，参数可能是编写器。json文件与常规应用程序中的作用相同——它将依赖项锁定到我们知道可以工作的依赖项。

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

Doctrine决定提交锁文件是出于他们自己的原因，这是完全有效的——实际上，他们可以归结为用于开发工作流的工具：

所有条令项目都必须提交编写器。锁定文件。像phpstan和phpcs这样的工具在补丁发布时非常脆弱，我们不希望在没有对自己的代码进行任何更改的情况下构建开始失败。每当需要升级依赖项时，composer。锁定文件应在本地更新，并通过pull请求提交更改。

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