22 lines
1.9 KiB
Markdown
22 lines
1.9 KiB
Markdown
# 为什么 Composer 不递归加载储存库？
|
||
|
||
当你使用自定义库时，你可能会碰到问题，因为 Composer
|
||
不会递归加载你要求的储存库，所以你必须修改这些储存库中所有的 `composer.json` 文件。
|
||
|
||
在详细说明为什么是这样之前，你需要明白：使用自定义 VCS & 包储存库去尝试某些事情，或者使用你 fork 的一个分支，直到你的 pull
|
||
request
|
||
被合并，等等。你不应该使用它们来跟踪你的私人资源包，关于这点你应该看看 [setting up Satis](../articles/handling-private-packages-with-satis.md)
|
||
来为你的公司甚至自己处理私人资源包。
|
||
|
||
这里有三个途径可以使依赖解析器使用你自定义的储存库：
|
||
|
||
- 读取根包的存储库，从定义的存储库得到所有的软件包，解析依赖需求。这是目前的状态，它工作得很好，除了有“无法递归的加载储存库”这个限制。
|
||
|
||
- 读取根包的存储库，同时从定义的 repos 初始化资源包，递归的初始化，根据所有依赖包中定义的 repos，以及这些依赖包所依赖的其它包中定义的
|
||
repos，等等，然后再解析依赖需求。这可能可以工作，但会严重影响初始化的速度，因为每读取一个 VCS repos
|
||
都需要几秒钟。它可能最终执行失败，因为一个包的不同版本，可能来自一个包资源库中一个相同的包，但来至不同的 dist/source
|
||
。这样有太多的可能会出错。
|
||
|
||
- 读取根包的存储库，然后读取第一级依赖，接着读取这些依赖包所依赖的其它包，等等，然后再解析依赖需求。这样听起来更有效率，但仍然存在第二种解决方案中的问题。因为加载依赖的储存库并不像听起来那么容易。你需要加载所有可能匹配的依赖包的
|
||
repos，而这些包的定义又可能是互相冲突的。
|