我应该将composer.lock置于库的版本控制之下吗?

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

然后,推理就变成了对库的开发人员来说,拥有一组执行开发任务所需的锁定依赖关系是否有用,例如测试框架的特定版本等。在这些情况下,论点可能是 composer.json 文件的作用与常规应用程序中的作用相同,它锁定了我们知道有效的依赖关系。

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

Doctrine已经做出决定 lock files should be committed 出于他们自己的原因,这是完全合理的——实际上,他们归结为用于开发工作流程的工具:

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

这两种情况都可以提出论点;这将取决于项目本身及其开发人员的偏好。我倾向于不承诺,因为这更接近于用户在安装库时的体验。然而,每个开发人员仍然会有本地锁文件,这意味着每个开发人员在开发库时在自己的计算机上拥有的文件可能会有所不同。提交锁文件将使所有开发人员的体验更加相似,但需要格外小心才能为用户复制体验(然后,我们又回到了最初的论点……)。

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