【问题标题】:PHP packages installed by Composer - should they be in source control?Composer 安装的 PHP 包 - 它们应该在源代码管理中吗?
【发布时间】:2017-09-04 10:53:56
【问题描述】:

我正在阅读/学习 Composer,它是 PHP 的应用程序级包管理器。

在首席开发人员 Jordi Boggiano 撰写的 blog post 中,他写道:

另一方面,Composer 会强制您声明您的项目 一站式位置(根目录下的composer.json)中的依赖项。你 只需检查代码,安装依赖项,它们将位于 项目目录,不干扰机器上的其他任何东西。 另一个相关功能是生成的 composer.lock 文件 当您安装或更新依赖项时。它存储确切的版本 使用的每个依赖项。如果你提交它,任何人检查 出项目将能够安装完全相同的版本 您上次更新该文件时所做的,避免了由于 不同版本中的轻微不兼容或回归 依赖。

如果我正确理解 Composer,当我们谈论 Composer 下载/安装的包时,我们谈论的是 PHP 代码包,即 用 PHP 编写的编程代码,而不是系统级包,例如,对安装在服务器上的 PHP 运行时的扩展。因此,一旦这些 PHP 代码包被下载并添加到 PHP 项目中,我会认为这些包成为 PHP 应用程序源代码的一部分,例如,将被检入到项目使用的任何版本控制系统中。如果另一个开发人员出现并检查代码,那么他们为什么需要“安装软件包”,如博客文章中所述?当他们从源代码管理中签出代码时,他们不会得到所有代码包的副本吗?博文中的这一行让我很困惑,让我觉得我不懂 Composer。

对此的任何澄清将不胜感激。谢谢。

【问题讨论】:

标签: php composer-php


【解决方案1】:

依赖项本身应该提交到源代码管理。另一方面,composer.jsoncomposer.lock 文件应该。这有多种原因,其中包括:

  • 每次更新依赖项时,都必须提交更改。这种方式将您的代码与依赖项紧密耦合,而它本应完全相反。
  • 软件包本身已经在它们自己的存储库中,并具有自己的历史记录。为什么要在您的项目历史中重复这一点?
  • 这些存储库可能巨大,只会混淆您项目周围的水域。为什么要随身携带这么重的东西?

相反,让每个开发人员在签出项目时只运行composer install(非常重要:不是composer update)效率更高。 Composer 将从composer.lock 安装依赖项,确保运行相同提交的每个人都在完全相同的页面上。部署也是如此。

您可以阅读有关此here 的更多信息。

另一方面,在某些情况下,您必须提交您的包来解决问题,例如当您知道您将无法运行 composer install 时您的生产服务器(共享主机)

【讨论】:

    【解决方案2】:

    通常通过 composer 安装的包不会被检入源代码控制,只有你编写的代码和 composer.json 和 composer.lock 文件。

    这样,您的项目的存储库就不会因您未编写的代码而变得臃肿,而且您可能并不真正关心。

    是的,在克隆您的存储库后,开发人员需要运行“composer install”命令,这是正常的。 composer.lock 文件将确保它们获得您在创建项目时使用的相同模块和版本。

    在您的源代码管理中不包括作曲家模块也允许您轻松更新到模块以获得错误修复和新版本中的新功能。

    【讨论】:

      猜你喜欢
      • 2021-04-05
      • 2011-06-04
      • 2016-09-12
      • 1970-01-01
      • 2012-11-30
      • 1970-01-01
      • 1970-01-01
      • 2010-10-14
      • 1970-01-01
      相关资源
      最近更新 更多