左に古い lockfile、右に新しい lockfile を貼り付けます。プルリクエストでは base ブランチと head ブランチのファイルをそれぞれ開くか、git show main:package-lock.json と git show HEAD:package-lock.json を使います。ローカルのインストールで lockfile が変わった場合は、git show HEAD:package-lock.json が変更前、作業ツリーのファイルが変更後です。両側は同じ種類の lockfile である必要があります。npm には npm、pnpm には pnpm です。

直接依存は package.json で宣言したものです。間接依存は lockfile にあるそれ以外のすべてで、直接依存やその依存が必要とするために存在します。lockfile の大半は間接依存なので、package.json の 1 行の変更が数百行の変更を生むことがあります。表の direct ラベルは自分で宣言したパッケージを示し、ラベルのないものはいずれかのチェーンを通じて入ってきたもので、チェーン表示がどれかを示します。

npm の package-lock.json（lockfileVersion 1、2、3）と pnpm-lock.yaml（lockfileVersion 5、6、9）に対応しています。npm-shrinkwrap.json は package-lock.json と同じ形式なので利用できます。yarn.lock（旧来の v1 テキスト形式と Berry の YAML 形式のどちらも）は検出されますが未対応で、推測せずにその旨を表示します。なお npm lockfileVersion 1 にはルートの依存リストがないため、direct ラベルは package.json ではなくトップレベルの位置から推定しています。

git diff はパッケージではなく行を見ます。1 つのパッケージの更新は version、resolved、integrity の各行と、それを参照するすべてのエントリに触れるため、同じ変更がファイル全体に散らばります。GitHub の依存関係ビューは追加・削除・変更されたパッケージを列挙しますが、GitHub 上でしか使えず、平坦な一覧に過ぎません。rimraf の更新が原因で minimatch が major を跨いだ、といったことは教えてくれません。このツールは貼り付けられる任意の 2 つの lockfile に対して、変更をパッケージ単位にまとめ、変更幅を分類し、それを説明するチェーンを表示します。

変更された各パッケージについて、変更後の lockfile（削除の場合は変更前）をルートから外側に向かって探索し、そのパッケージに到達する最短チェーンを保持します。次に最短チェーンをルートから辿り、もう一方の lockfile とバージョンが異なる最初のノードで止まります。そのノードが原因として報告されます。例えば「rimraf が 3.0.2 から 6.0.1 に変わったことによる」といった具合です。パッケージが直接宣言されている場合、原因は package.json そのものです。どのノードも変わっていなければ、リゾルバの再解決や重複排除による配置変更の可能性が高く、ツールは原因を作り出さずにその旨を表示します。

それ自体はバグではありません。2 つの依存が要求する範囲を単一のバージョンで満たせない場合、パッケージマネージャは両方をインストールし、一方をネストして配置します。lockfile は各コピーを個別に記録し、このツールはそれを「N バージョン共存」として表示します。これは正常で、多くの場合無害です。そのパッケージが共有状態を持つ、instanceof で検査されるクラスをエクスポートする、あるいは重複がバンドルサイズに影響するほど大きい場合には対処する価値があります。チェーンを見れば、どの依存が古い範囲を要求しているか分かります。