Текст и данные · Инструкция
pnpm why почему установлен пакет
`pnpm why <package>` строит обратное дерево зависимостей и показывает, какие пакеты привели выбранную зависимость в проект. Это первая команда для ситуации «пакета нет в моём package.json, но он установлен»: по выводу можно отличить прямую зависимость от транзитивной и найти реального владельца цепочки.
Короткий ответ
`pnpm why <package>` показывает обратное дерево зависимостей и помогает найти прямой пакет или workspace, из-за которого транзитивная зависимость появилась в проекте.
Почему важны транзитивная зависимость и workspaces
Команда полезна, когда пакет есть в lock/store или security-отчёте, но отсутствует среди прямых зависимостей текущего `package.json`. Для monorepo одна и та же зависимость может иметь несколько независимых цепочек; глубину и формат вывода можно менять, включая JSON. Исправлять нужно родительскую зависимость или её диапазон, а не вручную удалять транзитивную запись из lock-файла.
Совет: Читайте дерево до собственного manifest — это быстрее поиска по `node_modules`.
Как проверить изменение через pnpm lock
- Шаг 1: В корне нужного проекта выполните `pnpm why <package>` и найдите ближайшего родителя.
- Шаг 2: Определите workspace и тип ветки: production, dev или optional.
- Шаг 3: Если дерево большое, используйте фильтрацию workspace, глубину, `--long` или JSON-вывод.
- Шаг 4: Обновите или замените реального родителя, снова выполните install и повторите `pnpm why` для проверки.
Как читать цепочку зависимостей
- Запрошено точное имя пакета, которое реально присутствует в графе зависимостей.
- Каждая ветка доведена до прямой зависимости или workspace, который её создаёт.
- Если путей несколько, они рассматриваются отдельно, а не сводятся к одному «виновнику».
- После изменения `package.json` или lock-файла `pnpm why` запущен повторно.
- Вывод подтверждает ожидаемую цепочку без удаления зависимостей наугад.
Предупреждение: Один пакет может приходить несколькими путями; не удаляйте первую найденную зависимость автоматически.
Как читать дерево `pnpm why` в monorepo
Начинайте с точного имени пакета и смотрите вверх по каждой ветке до зависимостей, объявленных вашим проектом. Несколько веток означают, что один пакет может приходить по разным путям и даже в разных версиях; удаление одной прямой зависимости в таком случае не гарантирует исчезновение пакета. В workspace-репозитории запускайте проверку в нужном контексте или используйте рекурсивный режим, если нужно увидеть несколько проектов. После изменения manifest повторите `pnpm why`: изменившаяся ветка полезнее простого поиска папки в store.
Когда вывод pnpm why можно понять неверно
Не удаляйте транзитивный пакет вручную из `pnpm-lock.yaml`: следующий install восстановит граф по manifests, а ручной diff усложнит диагностику.
Как убедиться, откуда пришёл пакет
Диагностика закончена, когда вы можете назвать конкретную зависимость или workspace, из-за которого пакет попал в граф, и повторный `pnpm why` подтверждает изменение после правки. Если пакет остаётся, ищите вторую ветку дерева; ручное удаление его каталога не меняет граф зависимостей и не решает причину.
Важно: Контрольный запуск после правки должен изменить именно ту ветку, которую вы собирались убрать.
Что учитывать
Команда полезна, когда пакет есть в lock/store или security-отчёте, но отсутствует среди прямых зависимостей текущего `package.json`. Для monorepo одна и та же зависимость может иметь несколько независимых цепочек; глубину и формат вывода можно менять, включая JSON. Исправлять нужно родительскую зависимость или её диапазон, а не вручную удалять транзитивную запись из lock-файла.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. pnpm why). Пример и формулировки — редакция N1RO на 2026-09-23.