Php 如何在庞大的代码库中使用composer？

我们有一个巨大的PHP代码库（我的意思是巨大的，大约2百万行以上）。我想知道你们是如何在这种情况下整合作曲家的

特别是当代码由于复杂性（甚至与遗留代码混合）而无法在小项目（现在）中解耦，并且它被保存在同一个SVN存储库中时

• 为什么我应该对composer/packagist库的质量充满信心
• 如果packagist倒下了怎么办
• 如果我的供应商存储库宕机（Github/Bitbucket/Whatever），我该怎么办
• 如果我的一些供应商决定删除他们的库，会发生什么
• 如果他们被黑客攻击并将下一个版本标签设置为空，该怎么办

我知道这些可能的问题可能会以某种方式被忽略。但事实上，很多人的生活都依赖于此，这让我对这种决定感到有点疯狂

---

你觉得怎么样？我的最佳选择是什么？

关于第一点-如果您有遗留的、2M+紧密耦合的代码库，那么公共开源项目的质量不应该困扰您；）

对于其余部分，您可以使用staging与依赖项一起构建项目，然后在那里构建完整的包（我指的是所有下载的依赖项和捆绑包）。当然，在您的开发周期中，您仍然依赖于外部软件包，但在部署/生产中则不依赖。无论什么时候，只要包裹坏了，你们就有时间和可能更换它

Composer是将您的项目与依赖项捆绑在一起的一个非常好的工具，因此它既是“如何使用外部依赖项”问题的答案，也是“如何独立于外部依赖项”问题的答案，您只需要指定一个点，在这个点上，您希望将这种独立性引入到您的项目中

我认为开发时应该考虑到外部依赖性，尽可能降低代码基础，不要把这些问题推到开发人员的肩上，他们希望使用代码、库、使用tiem。。。然后，在部署过程中的某个地方，将其捆绑在一起（登台是一个好地方）。即使您的依赖项将消失，并且您将不得不花费开发时间来替换它们：

---

它可能仍然比您自己处理所有这些文件花费更少。

在生产中，提交

composer.lock

文件。这将确保它构建每个依赖项的相同版本，这样您就可以知道它已经过测试并且可以正常工作。您只需要在进行新构建时构建依赖项，这样我就不会担心Packagist宕机（我遇到了一些问题，因为GitHub、Packagist、NPM等宕机，我无法在30分钟内部署）。如果依赖项来自公共存储库，并且如果您认为它们可能会被供应商删除，那么没有什么可以阻止您分叉依赖项。感谢这个答案，我设法找到了某种中间点，我打算使用私人回购（Satis）中的composerwich有一个缓存外部库的选项。