Composer安装的PHP包 - 它们应该在源代码管理中吗？

Question

我正在阅读/了解Composer，PHP的应用程序级包管理器。

在由领导开发人员Jordi Boggiano撰写的blog post中，他写道：

  

另一方面，Composer强制您声明项目   一站式位置的依赖关系（根的composer.json）。您   只需检查代码，安装依赖项，它们就会出现在   项目目录，不会打扰机器上的任何其他内容。   另一个相关功能是生成的composer.lock文件   安装或更新依赖项时。它存储确切的版本   使用的每个依赖项。如果您提交，任何人检查   该项目将能够安装完全相同的版本   你上次更新该文件时做了，避免了因为问题而导致的问题   a。不同版本中的轻微不兼容性或回归   依赖性。

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

对此的任何明确性将不胜感激。感谢。

Answer 1

依赖项本身应不提交给源代码管理。另一方面，composer.json和composer.lock文件应该是。这有很多原因，其中包括：

• 每次更新依赖关系时，都必须提交更改。这种紧密地将你的代码与依赖关系紧密地联系在一起，而它应该完全相反。
• 包本身已经拥有自己的历史记录。为什么在项目的历史中重复这一点？
• 这些存储库可能巨大，只是混淆了项目周围的水域。为什么要随身携带所有重量？

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

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

另一方面，可能存在 提交包以解决问题的情况，例如当您知道无法运行{{1}时在您的生产服务器（共享主机）上

Answer 2

通常，通过composer安装的软件包不会检入源代码控制，只会检入您编写的代码以及composer.json和composer.lock文件。

这样，您的项目的存储库不会因为您没有编写的代码而变得臃肿，并且可能并不那么关心。

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

在源代码管理中不包含编写器模块，还允许您轻松更新到模块，以便在新版本中修复错误和新功能。