是否应该将composer.lock置于库的版本控制下? [英] Should I put composer.lock under version control for a library?

问题描述

在对如何在我的私有存储库中获取包含的软件包的确切版本的答案中，我做了以下声明:> composer.lock 不应置于程序包的版本控制之下.安装软件包时，根本不会使用此文件.

In an answer to How to get the exact version of included packages in my private repository, I made the statement that composer.lock should not be put under version control for a package. When installing a package, this file is not used after all.

我偷看了一组受欢迎的存储库，其中大多数不包含锁定文件(例如Symfony，Laravel，Guzzle，Monolog).另一方面，Doctrine存储库包含该文件，我想知道是否有充分的理由这样做或忽略该文件.

I've peeked in a set of popular repositories, and most of them do not contain a lock file (like Symfony, Laravel, Guzzle, Monolog). On the other hand, the Doctrine repositories contain that file, and I'd like to know if there is any good reason to do so, or to omit the file.

侧面说明:这是关于软件包，库的，但是您要调用它们.对于应用程序，这是另一回事，因为当您在团队中一起工作或部署到其他系统时，您希望坚持每个依赖项的特定版本.应将composer.lock致力于如何处理这种不同情况版本控制?，但是对于我的用例而言，它不包含太多参数

Side note: this is about packages, libraries, however you want to call them. For applications, this is a different thing, as you want to stick to specific versions of each dependency when working together in a team or deploying to other systems. How to handle this different situation is covered in Should composer.lock be committed to version control?, but it does not contain too much arguments for my use case

推荐答案

由于在安装软件包时未以任何有用的方式使用该文件，因此作为最终用户库本身的功能，它至少与库的用户.

Since the file is not used in any useful manner when installing the package, as a functionality of the library itself for the end user, it's at least not relevant to the user of the library.

然后，推理就变成了对于库开发人员来说，拥有一组执行开发任务所需的锁定依赖关系(例如测试框架的特定版本等)是否有用.在这些情况下，参数可以是 composer.json 文件起着与常规应用程序相同的作用-将依赖项锁定到我们知道的工作范围内.

Then the reasoning becomes whether it's useful to the developers of the library to have a locked set of dependencies that they need to perform development tasks, such as specific versions of testing frameworks etc. In those cases the argument can be that the composer.json file fulfils the same role as in a regular application - it locks down the dependencies to those that we know work.

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

However, there's a caveat here - when developing a library you really want the use case to be the same as what the user of the library experiences when he/she installs it. Considering this it usually makes more sense to lock down the explicit version in composer.json instead of relying on the lock file to provide the same functionality. That makes any CI solution install the correct set (the same as what a user would get) of dependencies when for running the tests. You can however make that process update the lock file locally before running the tests to have multiple test cases - one with the locked dependencies and one with the most recent versions (as the user would get).

Doctrine已决定出于自身原因而应提交锁定文件，这是完全有效的-实际上，它们归结为用于其开发工作流程的工具:

Doctrine has made the decision that lock files should be committed for their own reasons, which are perfectly valid - in effect they come down to the tools used for their development workflows:

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

All Doctrine projects must commit the composer.lock file. Tools like phpstan and phpcs are quite fragile on patch releases and we don't want builds to start failing without us having made any changes to our own code. Whenever a dependency needs to be upgraded, the composer.lock file should be updated locally and the change submitted via pull request.

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

An argument can be made for both cases; it'll be up to the preferences of the project itself and its developers. I'm leaning towards it not being committed, since that more closely replicates what a user would experience when installing the library. However, there would still be local lock files present for each developer, meaning that what each developer has on their own computer when developing the library could differ. Committing the lock file would make that more similar across the board for all developers, but would require extra care to replicate the experience for users (and then, we're back to our original arguments again..).

这篇关于是否应该将composer.lock置于库的版本控制下?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！