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

6 回答

• 576

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

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

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

  回复于 2024-04-29T21:03:23+08:00
• 26

  For applications/projects ：绝对是的 .

  composer documentation就此而言（强调）：

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

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

  For libraries ：可能不是 .

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

  注意：对于库，不一定建议提交锁文件（...）

  和州here：

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

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

  回复于 2024-04-29T21:03:23+08:00
• 65

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

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

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

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

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

  Edit: 我知道这可能不是一个受欢迎的答案，但如果你投票失败，你会在评论中提供一个理由来指出答案中的缺陷吗？谢谢！

  回复于 2024-04-29T21:03:23+08:00
• 5

  • 您不应直接在Production上更新您的依赖项 .

  • 您应该对您的composer.lock文件进行版本控制 .

  • 您不应该版本控制您的实际依赖项 .

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

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

  你将看到的关于不需要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. You shouldn't version control your actual dependencies ，因为没有意义 . 使用composer.lock，您可以安装确切版本的依赖项，而不需要提交它们 . 当你不应该更新它们时，为什么要添加你的repo 10000依赖项文件 . 如果您需要更改其中一个，您应该将其分叉并在那里进行更改 . 如果您担心每次构建或发布时都必须获取实际的依赖项，那么编写器有不同的方法来缓解此问题，缓存，zip文件等 .

  回复于 2024-04-29T21:03:23+08:00
• 0

  然后，您将composer.json提交到您的项目，团队中的其他人都可以运行composer install来安装项目依赖项 . 锁定文件的要点是记录安装的确切版本，以便重新安装 . 这意味着，如果您的版本规格为1. *并且您的同事运行安装1.2.4的composer update，然后提交composer.lock文件，那么当您编写作曲家安装时，您也将获得1.2.4，甚至如果1.3.0已经发布 . 这确保了在项目上工作的每个人都具有相同的确切版本 . 这意味着如果自上次完成编写器安装以来已经提交了任何内容，那么在没有锁定文件的情况下，您将获得新的第三方代码 . 同样，如果您担心代码中断，这是一个问题 . 这也是为什么将Composer视为以composer.lock文件为中心的重要原因之一 .

  资料来源：Composer: It’s All About the Lock File .

  ---

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

  资料来源：Composer - Basic Usage .

  回复于 2024-04-29T21:03:23+08:00
• 157

  如果您担心代码中断，则应将 composer.lock 提交到版本控制系统，以确保所有项目协作者都使用相同版本的代码 . 如果没有锁定文件，您每次都会获得新的第三方代码 .

  例外情况是当您使用元应用程序时，应在安装时更新依赖项的库（如Zend Framework 2 Skeleton App） . 因此，每次想要开始开发时，目标都是获取最新的依赖项 .

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

  另见：What are the differences between composer update and composer install?

  回复于 2024-04-29T21:03:23+08:00