我已经花了几个小时寻找问题的答案，但仍然没有找到合适的答案。
基本上，我接手了一个PHP项目，该项目使用composer来引入第三方库/依赖项。然而，许多依赖项不再被管理，作者可能随时从github中完全删除它们。
我现在想我应该检查一下整个供应商文件夹，这样即使composer不再提供库，我也会随身携带。
或者，我可以将这些库分支到repo，并让composer从我的帐户中提取。这可以接受吗？
我真的希望能得到一些关于处理这个问题的最佳方法的建议。
提前感谢！
我是否应该签入整个供应商文件夹，这样即使composer不再提供库，我也会随身携带它们？
我的建议是创建一个备份分支，其中包含所有供应商的应用程序。只需执行git checkout -b {VERSION}-backup，然后执行composer install（将composer.lock和所有依赖项放入定义的供应商文件夹中），然后再执行git push origin {VERSION}-backup。
这允许依赖动态包管理，只要包可以通过Packagist获得并从其源代码（Github等）下载。现在，如果一个依赖项被删除并变得不可用，您可以将其从composer.json中删除，并将最后一个{VERSION}-backup分支中的代码合并到主分支中。=您用备份中的静态依赖项替换了动态依赖项。
顺便问一下：有没有想过对你的代码进行安全审计？对于动态拉取的依赖项，这将不起作用。安全审计是针对特定的版本——针对一组静态的依赖项。在这种情况下，推送一个具有所有依赖关系的完整应用程序是常见的，也是最佳实践。但是我们有什么：Composer在后台安装新的主题，而Composer安装——没有开发——优化生产框上的自动加载以"安装"软件。现代；）
我可以把这些库从repo中分叉，然后让composer从我的帐户中提取吗。这可以接受吗？
是的！你也可以要求Packagist的人删除不再维护的包，或者将它们替换或别名为新的个人分叉。
这实际上取决于您的项目是否需要针对可移植性进行优化。尽管如此，违反最佳实践比遗憾地使用不可用的依赖关系更安全，因为你必须花时间替换和重构。。。
从她的包装学家那里——理论上这是可能的，但不太可能。从实践来看，包直接连接到CVS的主要问题。但如果是实时项目，您可以找到另一个代码副本来恢复功能。