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

Question

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

在由Lead dev Jordi Boggiano撰写的博客文章中,他写道:

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

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

任何明确的信息都将非常感激.谢谢.

Answer 1

依赖项本身不应该提交给源代码控制.在composer.json和composer.lock文件,在另一方面,应该.这有多种原因,其中包括:

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

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

你可以在这里阅读更多相关信息.

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