composer why和composer why-not命令的使用

31次阅读

composer why 和 composer why-not 用于分析依赖关系：why 查看某包被哪些依赖引入，why-not 诊断版本无法安装的原因，帮助清理冗余、解决冲突、优化版本约束，提升项目可维护性。

composer why

和

composer why-not

是 Composer 提供的两个极其有用的命令，它们的核心功能都是为了帮助开发者深入理解项目中的依赖关系。简单来说，

why

命令可以告诉你为什么一个特定的包会被安装到你的项目中，即谁依赖了它；而

why-not

命令则解释了为什么某个包的特定版本无法被安装或更新，通常是由于版本冲突导致的。这两个命令是诊断和解决 Composer 依赖问题的利器，能让你在复杂的依赖网格中找到清晰的路径。

解决方案

在使用 Composer 管理 PHP 项目依赖时，我们常常会遇到各种疑问和挑战：某个包是从哪里来的？为什么我不能升级到最新版本？这些问题如果只凭肉眼去翻阅

composer.json

和

composer.lock

文件，效率会非常低下，甚至可能遗漏关键信息。

composer why

和

composer why-not

正是为了解决这些痛点而生。

composer why <package-name>

这个命令会列出所有直接或间接依赖

<package-name>

的包。它的输出会清晰地展示一条从你的项目或某个直接依赖，到你查询的这个包的依赖链。这对于理解包的来源、排查冗余依赖、或者确认某个包是否仍然被需要，都非常有帮助。

例如，如果你想知道为什么

monolog/monolog

会出现在你的项目中：

composer why monolog/monolog

输出可能看起来像这样：

your-vendor/your-project requires monolog/monolog ^2.0

或者，如果它是一个间接依赖：

symfony/http-kernel v5.4.0 requires monolog/monolog ^2.0 your-vendor/your-project requires symfony/http-kernel ^5.4

这表明

monolog/monolog

是因为

symfony/http-kernel

需要它，而你的项目又需要

symfony/http-kernel

。

composer why-not <package-name> <version-constraint>

这个命令则是在你尝试安装或更新一个包到特定版本失败时，提供诊断信息。它会详细说明为什么你指定的

<version-constraint>

无法满足，通常是因为项目中的其他依赖对该包有冲突的版本要求。

比如，你尝试将

guzzlehttp/guzzle

升级到

7.0

版本，但 Composer 报错了：

composer why-not guzzlehttp/guzzle 7.0

输出可能会是这样：

guzzlehttp/guzzle 7.0.0 conflicts with guzzlehttp/psr7 1.8.0 (requires guzzlehttp/guzzle ^6.5) your-vendor/your-project requires guzzlehttp/psr7 ^1.8

这个输出明确告诉你，

guzzlehttp/guzzle

的

7.0.0

版本与

guzzlehttp/psr7

的

1.8.0

版本存在冲突，因为

guzzlehttp/psr7 1.8.0

自身要求

guzzlehttp/guzzle

必须是

^6.5

版本。而你的项目又依赖了

guzzlehttp/psr7 ^1.8

。这一下就把问题根源找到了。

composer why

命令如何揭示项目中的隐藏依赖？

在日常开发中，我们往往只关注

composer.json

中直接声明的那些依赖，但一个项目真正的依赖图谱远比这复杂。很多时候，一个你从未直接安装过的包，却悄无声息地出现在了

vendor

目录里。这就是所谓的“隐藏依赖”或者说“传递性依赖”。

composer why

命令就是一把手术刀，能精确地剖析出这些包的来龙去脉。

Upscalepics

在线图片放大工具

44

查看详情

我记得有一次，我在一个老项目中发现了一个我完全不认识的 HTTP 客户端库，我确定我没在

composer.json

里写过它。当时就一头雾水，想把它移除又怕影响到什么。用

composer why mysterious/http-client

一查，结果显示是另一个我项目里常用的日志库间接依赖了它。那一刻，感觉就像拨开了迷雾。

这个命令的价值在于：

追踪溯源：它能帮你找出某个特定包是被哪个上游依赖所引入的。这对于理解你的
```
vendor
```
目录为什么这么大，或者某个你没直接声明的包为什么会存在，至关重要。
识别冗余：如果你发现一个你直接声明的依赖，其实只是某个更高级别依赖的传递性依赖，那么你可能就不需要直接声明它了。这有助于保持
```
composer.json
```
的简洁。
调试问题：当某个包的行为异常，或者版本不符合预期时，
```
why
```
可以帮助你快速定位是哪个上游依赖引入了它，进而检查上游依赖的版本约束是否合理。
清理项目：当你想移除一个包时，
```
why
```
可以告诉你还有哪些包依赖它。如果这个包是其他包的传递性依赖，你可能需要先移除那些上游包，或者修改它们的版本约束。

例如，你想知道你的项目中为什么会有

doctrine/annotations

这个包：

composer why doctrine/annotations

输出可能会告诉你，

doctrine/orm

依赖了它，而你的项目又依赖了

doctrine/orm

。这样你就明白了它的来历，也就能更好地评估是否需要它。

当

composer update

失败时，

composer why-not

如何帮助你诊断版本冲突？

composer update

失败是每个 PHP 开发者都可能遇到的“噩梦”。当 Composer 抛出一大堆关于版本冲突的错误信息时，那种无力感是真切的。这时候，

composer why-not

简直就是救命稻草。它不像

update

命令那样只告诉你“不行”，而是会详细解释“为什么不行”。

想象一下，你尝试更新项目中的所有依赖，但 Composer 突然报错，说

package-A

的

v2.0

版本与

package-B

的

v1.5

版本冲突。这种错误信息往往很长，而且不直接指向解决方案。这时，

composer why-not package-A 2.0

就能提供更具操作性的洞察。

它会清晰地列出所有阻止

package-A

升级到

v2.0

的依赖项及其版本约束。这通常意味着：

某个直接依赖：你的
```
composer.json
```
中某个包（比如
```
package-C
```
）明确要求
```
package-A
```
必须是
```
^1.0
```
，而不是
```
^2.0
```
。
某个传递性依赖：你项目中的某个包
```
package-D
```
依赖了
```
package-E
```
，而
```
package-E
```
又要求
```
package-A
```
必须是旧版本。

通过

why-not

的输出，你可以：

定位冲突源：它会明确指出哪个包是冲突的根源，以及它对目标包的版本要求是什么。
理解约束：你可以看到是哪个
```
require
```
或
```
conflict
```
声明导致了问题。
制定解决方案：
- 如果冲突是由于你项目中的直接依赖引起的，你可以考虑升级该直接依赖，或者调整其版本约束。
- 如果冲突是由于传递性依赖引起的，你可能需要检查那个传递性依赖的上游包，看是否有更新版本可以解决冲突，或者是否可以替换掉那个传递性依赖。
- 实在不行，你可能需要暂时放弃升级到目标版本，等待其他包的兼容性更新。

例如，你尝试将

symfony/console

升级到

6.0

，但 Composer 抱怨：

composer why-not symfony/console 6.0

输出可能会显示，

symfony/framework-bundle

在

5.4

版本中要求

symfony/console ^5.4

，而你的项目依赖了

symfony/framework-bundle ^5.4

。这就很清楚了，你需要先升级

symfony/framework-bundle

到兼容

symfony/console 6.0

的版本，或者干脆将

symfony/console

的目标版本调整到

5.x

系列。

优化

composer.json

文件时，

why

和

why-not

能提供哪些决策支持？

composer.json

文件是项目的核心依赖清单，它的整洁和准确性直接影响到项目的可维护性和构建效率。我的经验是，定期用这两个命令审视一下依赖，能让项目少走很多弯路，尤其是那些老项目，依赖链条简直是盘根错节。

why

和

why-not

不仅仅是调试工具，更是优化

composer.json

的强大辅助。

composer why

在优化

composer.json

中的作用：

清理冗余的直接依赖：有时我们会直接在
```
composer.json
```
中添加一个包，后来发现它其实已经被另一个核心依赖间接引入了。用
```
composer why <package-name>
```
检查，如果发现它总是作为传递性依赖存在，那么你就可以考虑从
```
require
```
中移除它，让 Composer 自己去管理。这能让你的
```
composer.json
```
更精简，只包含真正必要的直接依赖。
理解移除包的影响：当你考虑移除一个不再使用的包时，
```
why
```
命令可以告诉你还有哪些包直接或间接依赖了它。这能帮助你评估移除该包可能带来的“连锁反应”，避免意外破坏其他功能。
审计依赖来源：定期运行
```
composer why *
```
（或者针对你怀疑的包）可以帮助你理解每个包的真正来源，确保没有不必要的或不安全的包被引入。

composer why-not

在优化

composer.json

中的作用：

规划版本升级：在决定将某个核心依赖升级到主要版本（例如从
```
v5
```
到
```
v6
```
）之前，你可以先用
```
why-not
```
命令模拟这次升级。
```
composer why-not <package-name> <new-major-version>
```
会告诉你，如果升级，会有哪些现有依赖会产生冲突。这让你能在实际操作前，预判并解决潜在问题，避免了盲目升级导致项目崩溃的风险。
确定兼容性边界：当你需要引入一个新包，但它对其他现有包有严格的版本要求时，
```
why-not
```
可以帮助你理解当前项目环境是否满足这些要求，或者需要调整哪些现有依赖的版本才能兼容。
优化版本约束：通过
```
why-not
```
的反馈，你可能会发现某个依赖的版本约束过于宽松或过于严格，导致了不必要的冲突。你可以根据这些信息，更精准地调整
```
composer.json
```
中的版本约束，例如从
```
^1.0
```
调整到
```
~1.5
```
，以平衡兼容性和稳定性。