1. 導入：依存関係の「謎」を即座に解明する
開発を進めていると、package.jsonに記述していないはずのパッケージがnode_modulesに存在し、ビルドサイズを肥大化させたり、予期せぬ脆弱性警告の原因になったりすることがあります。これらは「依存の依存（推移的依存）」として自動インストールされるものですが、その経路を自力で追うのは困難です。yarn whyやpnpm whyコマンドは、この「なぜインストールされたのか」という疑問を解決し、不要なパッケージの削減や依存関係の整理を強力にサポートしてくれます。
2. 基礎知識：依存関係ツリーとは
Node.jsのプロジェクトでは、Aというライブラリを使うためにBが必要で、さらにBを使うためにCが必要……というように、パッケージが階層状に連結されています。これを「依存関係ツリー」と呼びます。
推移的依存（Transitive Dependencies）とは、自分が直接インストールしたわけではないが、依存先が利用しているために間接的にインストールされるパッケージのことです。これらが肥大化すると、ビルド時間の増加やセキュリティリスクの増大を招くため、定期的な棚卸しが重要となります。
3. 実装/解決策：調査コマンドの活用法
まずは、特定のパッケージがどのライブラリから引き込まれているのかを確認します。
yarnの場合:
yarn why [パッケージ名]
pnpmの場合:
pnpm why [パッケージ名]
このコマンドを実行すると、誰がそのパッケージを要求しているのかがツリー形式で出力されます。特定のパッケージを名指しすることで、「どの依存関係からこのパッケージが芋づる式にインストールされているのか」を視覚的に把握できます。
4. サンプルプログラム：調査フローの実践
以下の手順で、不要な巨大ライブラリが混入していないか調査するワークフローを試してください。
1. まず、怪しいパッケージ（例: lodash）がどこから来ているかを確認
yarn why lodash
2. 結果が以下のように返ってきた場合:
command “lodash”
– “my-app” -> “some-library” -> “lodash”
– “my-app” -> “another-utility” -> “lodash”
3. 解説:
上記の結果から、”some-library” と “another-utility” がそれぞれ lodash を要求していることが判明します。
もし lodash が不要なら、”some-library” のバージョンを下げるか、別の軽量なライブラリへの移行を検討します。
4. pnpmの場合はこちら
pnpm why lodash –recursive # プロジェクト全体で検索する場合
5. 応用・注意点：現場で陥りやすい罠
・バージョン不一致の罠
whyコマンドの結果に複数のバージョンが表示されることがあります。これは「依存先のライブラリごとに異なるバージョンの依存を要求している」状態です。無理に手動でバージョンを固定すると、依存先ライブラリが壊れる可能性があるため注意してください。
・脆弱性対応の優先順位
セキュリティスキャンで脆弱性が報告された際、その原因が直接インストールしたものではない場合、なぜ入っているのかをwhyで特定し、依存元のライブラリをアップデートする（あるいは依存元ごと置き換える）のが定石です。
・不要なパッケージの削除
「使われていないはずなのに残っている」場合は、npm-check-unusedのようなツールを併用し、whyコマンドで依存関係の正当性を確認してから削除するフローを推奨します。いきなり削除せず、まずはwhyコマンドで「誰が必要としているのか」を明確にすることが、ビルドトラブルを防ぐ最大の近道です。
コメント