在回答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?涵盖了如何处理这种不同的情况，但是对于我的用例而言，它并不包含过多的参数
答案 0 :(得分：3)
由于在安装软件包时未以任何有用的方式使用文件，因此作为库本身对最终用户的功能，它至少与库的用户无关。 / p>
然后，推理就变成了对于库开发人员来说，拥有一组执行开发任务所需的锁定依赖关系（例如特定版本的测试框架等）是否有用。在这种情况下，参数可以是{ {1}}文件的作用与常规应用程序相同-将依赖项锁定为我们已知的工作。
但是，这里有一个警告-开发库时，您真的希望用例与库用户在安装时所经历的相同。考虑到这一点，通常更有意义的是锁定composer.json中的显式版本，而不是依靠锁定文件来提供相同的功能。这使得任何CI解决方案在运行测试时都安装正确的依赖项集（与用户获得的依赖项集相同）。但是，您可以在运行测试以使它具有多个测试用例之前，使该进程在本地更新锁定文件-一个带有锁定的依赖项，另一个带有最新版本（如用户所愿）。
Doctrine决定lock files should be committed出于其自身的原因，这是完全有效的-实际上，它们归结为用于其开发工作流的工具：
所有Doctrine项目都必须提交
composer.json文件。composer.lock和phpstan之类的工具在补丁程序发行版中相当脆弱，我们不希望在不对自己的代码进行任何更改的情况下构建就开始失败。每当需要升级依赖项时，phpcs文件应在本地更新，并通过拉取请求提交更改。
两种情况都可以争论。这将取决于项目本身及其开发人员的偏好。我倾向于不提交，因为它可以更紧密地复制用户在安装库时的体验。但是，每个开发人员仍将存在本地锁定文件，这意味着每个开发人员在开发库时在其自己的计算机上拥有的内容可能会有所不同。提交锁定文件会使所有开发人员在总体上都更加相似，但是需要格外小心才能为用户复制体验（然后，我们再次回到原始论点..）。
答案 1 :(得分：-2)
我的文章不是关于纯库的，而是一种与其他库有很多依赖性的模块。该模块是各种应用程序的一部分。例如，如果在部署应用程序时运行没有composer.lock的composer安装，则可能会推出尚未测试的机架。因此，我将模块发布的依赖关系固定在一个具体的状态，当然要提交composer.lock。因此，在我看来，与Symfony之类的框架进行比较有点滞后，因为这里没有部署任何东西。