composer.lock应该提交版本控制吗？

Question

我对composer.lock使用存储库的应用程序感到困惑.

我看到很多人说我们不应该.gitignore composer.lock从存储库中.

如果我在我的开发环境中更新我的库,我将有一个新的,composer.lock但我将无法将它们更新到生产中,是吗？

它不会在这个文件上产生冲突吗？

Answer 1

如果更新lib,则也要提交锁文件.它基本上表明您的项目已锁定到您正在使用的库的特定版本.

如果您提交更改,并且有人提取您的代码并更新依赖项,则应该不修改lockfile.如果它被修改,则意味着你有一个新版本的东西.

将它放在存储库中可以确保每个开发人员使用相同的版本.

Answer 2

对于应用程序/项目:绝对是的.

该作曲家文档在此(重点)规定:

将应用程序的composer.lock(以及composer.json)提交到版本控制中.

就像@meza所说的那样:你应该提交锁定文件,这样你和你的合作者就可以使用同一套版本,并阻止你说"但它在我的电脑上工作"这样的说法.;-)

对于图书馆:可能不是.

作曲家文档记录了这件事:

注意:对于库,不一定建议提交锁文件(...)

在这里陈述:

对于您的库,如果您愿意,可以提交composer.lock文件.这可以帮助您的团队始终针对相同的依赖项版本进行测试.但是,此锁定文件不会对依赖它的其他项目产生任何影响.它只对主项目产生影响.

对于图书馆,我同意@Josh Johnson的回答.

Answer 3

在为一些项目做两种方式后,我的立场是composer.lock不应该作为项目的一部分提交.我知道这样做比较容易,但在我为此提出诉讼时请耐心等待.

composer.lock是构建元数据,它不是项目的一部分.依赖关系的状态应该通过如何对它们进行版本控制(手动或作为自动构建过程的一部分)来控制,而不是由最后一个开发人员任意更新它们并提交锁定文件.

如果您担心作曲家更新之间的依赖关系发生变化,那么您对版本控制方案缺乏信心.版本(1.0,1.1,1.2等)应该是不可变的,您应该避免在初始功能开发之外使用"dev-"和"X.*"通配符.

提交锁定文件是依赖关系管理系统的回归,因为依赖关系版本现在已经回归到隐含定义.

此外,您的项目永远不需要重建或在每个环境中都需要它的依赖项,尤其是prod.您的可交付成果(tar,zip,phar,目录等)应该是不可变的,并且在不改变状态的情况下通过环境进行推广.

编辑:我知道这可能不是一个受欢迎的答案,但如果你拒绝投票,你会非常友好地在评论中提供一个指出答案缺陷的理由吗？谢谢!

Answer 4

1. 您不应直接在Production上更新依赖项.
2. 您应该对composer.lock文件进行版本控制.
3. 您不应该版本控制您的实际依赖项.

1.您不应直接在Production上更新依赖项,因为您不知道这将如何影响代码的稳定性.可能存在新依赖项引入的错误,它可能会改变代码行为影响您自己的方式,它可能与其他依赖项等不兼容.您应该在开发环境中执行此操作,然后执行适当的QA和回归测试等.

2.您应该对composer.lock文件进行版本控制,因为它会存储有关依赖项的信息以及依赖项的依赖项,这些依赖项将允许您复制代码的当前状态.这很重要,因为您的所有测试和开发都是针对特定代码完成的.不关心您所拥有的代码的实际版本类似于将代码更改上载到您的应用程序而不是测试它们.如果你要升级你的依赖版本,这应该是一个自愿的行为,你应该采取必要的谨慎,以确保一切仍然有效.丢失一到两个小时的正常运行时间将恢复到之前的发布版本可能会花费您很多钱.

您将看到不需要composer.lock的一个论点是您可以在composer.json文件中设置所需的确切版本,并且这样,每次有人运行时composer install,它都会安装它们码.事实并非如此,因为您的依赖项具有自己的依赖项,并且它们的配置可能以允许更新颠覆或甚至整个版本的格式指定.

这意味着即使您在composer.json中指定要Laravel 4.1.31,其composer.json文件中的Laravel 也可能具有自己的依赖关系作为Symfony事件调度程序:2.*.使用这种配置,您最终可以使用Symfony事件调度程序2.4.1来使用Laravel 4.1.31,并且您团队中的其他人可以使用事件调度程序2.6.5来使用Laravel 4.1.31,这将取决于何时是你最后一次运行作曲家安装.

因此,在版本系统中使用composer.lock文件将存储此子依赖项的确切版本,因此,当您和您的队友进行作曲家安装时(这是您基于作曲家安装依赖项的方式).锁)你们两个都会得到相同的版本.

如果你想更新怎么办？然后在你的开发环境中运行:composer update,这将生成一个新的composer.lock文件(如果有新的东西)并在你测试之后,并进行QA测试和回归测试它和东西.您可以将其推送给其他人下载新的composer.lock,因为它可以安全升级.

3.你不应该版本控制你的实际依赖,因为它没有意义.使用composer.lock,您可以安装确切版本的依赖项,而不需要提交它们.当你不应该更新它们时,为什么要添加你的repo 10000依赖项文件.如果您需要更改其中一个,您应该将其分叉并在那里进行更改.如果您担心每次构建或发布时都必须获取实际的依赖项,那么编写器有不同的方法来缓解此问题,缓存,zip文件等.

Answer 5

然后,您将提交composer.json到项目,团队中的其他人都可以运行composer install来安装项目依赖项.

锁定文件的要点是记录安装的确切版本,以便重新安装.这意味着,如果您的版本规格为1.*并且您的同事运行安装1.2.4的composer update,然后提交composer.lock文件,那么当您编写作曲家安装时,您也将获得1.2.4,甚至如果1.3.0已经发布.这确保了在项目上工作的每个人都具有相同的确切版本.

这意味着如果自上次完成编写器安装以来已经提交了任何内容,那么在没有锁定文件的情况下,您将获得新的第三方代码.

同样,如果您担心代码中断,这是一个问题.这也是为什么将Composer视为以composer.lock文件为中心的重要原因之一.

来源:作曲家:关于锁文件的全部内容.

将应用程序的composer.lock(以及composer.json)提交到版本控制中.这很重要,因为install命令检查是否存在锁文件,如果存在,则下载其中指定的版本(无论composer.json是什么).这意味着设置项目的任何人都将下载相同版本的依赖项.您的CI服务器,生产计算机,团队中的其他开发人员,所有人和每个人都运行相同的依赖关系,这减少了仅影响部署的某些部分的错误的可能性.即使您单独开发,在重新安装项目的六个月内,即使您的依赖项从那时起发布了许多新版本,您仍然可以确信所安装的依赖项仍然有效.

来源:作曲家 - 基本用法.