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

我们有一个使用composer进行依赖关系管理的项目；它的

composer.json

是由我们自己的一个版本控制工具在外部更改的，该工具不保存

需要的时间和内容的历史，以便能够使用
composer remove
回滚。但它确实会完全回滚
composer.json
文件

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

删除
vendor/
，
composer.lock
并运行
composer安装
。问题：速度很慢；仅在没有插件的情况下工作（否则，可能会涉及超过目标的
供应商
，以及状态的
编写器.锁
）；版本将被重置

结合使用
composer show
和
composer why
来确定未使用的包，并对其运行
compose remove
。这是我期望在内部命令中实现的，因为它非常明显。但是，外部实现带来了一些挑战：只有
composer show
的文本输出，没有
--format=json
或其他东西，很难解析，特别是因为它还存在无法抑制的警告消息（如果有的话）（
-q
完全关闭输出，即使对于列出内容的命令，也是非常无用和奇怪的IMHO）

注意：我们还使用了
wikimedia/composer合并插件
来合并一组json配置，这样我们就不能轻易区分新旧
composer.json
文件来获得要删除的包列表，我们需要对合并包列表进行操作，只有
composer
知道并会让我们高兴地看到pse at通过
显示

实现这一目标，哪条路最不痛苦

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

我只想删除死代码。删除死代码并不意味着重新启动整个测试周期。
我只想运行
编写器更新

如果包不再在
composer.json
（或其依赖项之一）中声明，则在执行
update

是的，它确实会产生副作用，根据您的约束将依赖项更新到最新的可用版本；但是如果您的约束足够严格（如果您的项目关注这种事情，您可以更严格地约束），那么就不会有问题

看起来比为这个用例构建一个特定的工具/工作流程要简单，IMO

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

通过跟踪更改，您可以在没有任何副作用或额外工作的情况下删除（
composer remove
）这些文件。
因此，假设您希望保留现有结构（在我看来，这可能会很好地解决您的需求，但也会带来问题），您可以尝试自己实现Composer插件。使用事件
Composer\Installer\POST\u DEPENDENCIES\u SOLVING
，您可能可以访问
Composer.lock
中已解析的依赖项列表和包列表

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

<?php

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

我没有时间进一步检查这一点，但通过
$composer
对象，您应该可以访问大量信息（请参阅当前文档）：


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


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

为了使整个过程在将来更加干净，您应该停止从
composer.json
中删除包，而不运行
composer remove$package
如果在
composer.json
中设置了适当的版本约束，为什么不使用第一种方法呢？“非常慢”具体是什么意思？应该多久执行一次？对于第二种方法：您所说的“未使用的包”是什么意思？安装的软件包既不能直接在
composer.json中列出，也不能通过dependencies@NicoHasse：第一点，我们确实需要担心这一点，因为它已经够麻烦的了。仍然需要的包可以通过这个操作进行更改，这一事实也是我们不能考虑的立即评估其后果。对于第二种方法：
composer
除了通过
remove
之外，没有其他方法删除包。
composer.json
文件可以通过多种方法进行更新，包括手动更新或使用我们的版本控制工具更新。因此，
vendor
和
composer.lock
以及任何其他
"post-dependencies-solving": [
            "ComposerDependencyHelper::postDependencies"
        ]