删除composer.json中的依赖项后，如何确定composer项目中未使用的包？

Question

我们有一个项目使用composer进行依赖管理；它的composer.json 由我们自己的版本控制工具进行外部更改，该工具不会保留require 的历史记录，以便能够使用composer remove 回滚。但它确实完全回滚了composer.json 文件。

当我们更新composer.json 文件时，我们希望从项目中清除现在未使用的包。我们找不到执行此操作的命令。我们有一些想法，但每个想法都有不足之处：

1. 删除vendor/、composer.lock 并运行composer install。问题：很慢；仅在没有插件的情况下工作（否则可能涉及超过目标的vendor 和状态的composer.lock）；版本将被重置

2. 使用composer show 和composer why 的组合来确定未使用的包并在它们上运行compose remove。这是我期望在内部命令中实现的，因为它是如此明显。但是，在外部实现会带来一些挑战：只有composer show 的文本输出，没有--format=json 或其他东西，难以解析，尤其是因为它还受到警告消息（如果有的话）的困扰，无法抑制（-q 关闭输出完全，即使对于列出事物的命令，恕我直言非常无用和奇怪）。

注意：我们还使用 wikimedia/composer-merge-plugin 来合并一堆 json 配置，因此我们不能轻易区分新旧 composer.json 文件以获取要成为 remove'd 的包列表，我们需要对只有composer 知道的合并包列表进行操作，并且将仁慈地让我们通过show 瞥见。

实现这一目标最痛苦的途径是什么？

关于使用update：我们不能使用它，因为它会导致以下工作周期：有人删除模块中的依赖项，该模块针对主干进行测试并通过 QA（大约 3 天），然后他们发布他们的更改；然后，为了消除他们的死开销，我必须对所有内容运行更新，这会将所有内容更新为作曲家可能决定的任何随机版本，这反过来意味着触发所有内容的测试和 QA（大约 1 周）。这种工作流程是完全不可接受的。

我只想删除死代码。删除死代码不应该意味着重新开始整个测试周期。

Answer 1

我只会运行composer update。

如果一个包不再在您的composer.json（或其依赖项之一）中声明，则在您执行update 时它将被删除

是的，它确实具有根据您的限制将您的依赖项更新到可用的最新版本的副作用；但如果你的约束足够严格（如果你的项目关心这种事情，你可以更严格地限制它们）它应该不会有问题。

似乎比为这个用例 IMO 构建特定工具/工作流程更容易。

主要问题似乎是您的团队正在从项目中删除依赖项，而不是跟踪这些删除。事后的任何其他解决方案都可以避免这一点，这是真正的问题。

通过跟踪更改，您可以执行删除 (composer remove) 这些文件的任务，而不会产生任何副作用或额外工作。

Answer 2

所以，假设您想保留现有结构（在我看来，这可能很好地解决您的需求，但也会带来问题），您可以尝试自己实现一个 Composer 插件。使用事件Composer\Installer\POST_DEPENDENCIES_SOLVING，您可能能够访问已解析的依赖项列表和composer.lock 中的包列表。

定义它可以像编写这样一个类一样简单：

<?php

class ComposerDependencyHelper
{
    public static function postDependencies(\Composer\Installer\InstallerEvent $event)
    {
        $composer = $event->getComposer();
    }
}

它在你的根目录composer.json 中通过脚本部分调用：

"post-dependencies-solving": [
            "ComposerDependencyHelper::postDependencies"
        ]

我没有时间进一步检查，但通过 $composer 对象，您应该可以访问大量信息（有关当前文档，请参阅 https://getcomposer.org/apidoc/1.6.2/Composer/Composer.html）：

• getPackage 返回您当前的包（在composer.json 中定义），而getPackage()->getRequires() 列出依赖项
• getLockedRepository 可能会返回当前存在于 composer.lock 中的软件包列表

通过一个简单的标记过程（构建“有效”已安装包的列表，将此列表与存储库中的包列表进行比较），您可以识别那些不再需要的依赖项。

为了让整个事情在未来更加干净，你应该停止从composer.json 中删除包而不运行composer remove $package。