pnpm vs npm vs yarn比較！速度と容量の違い

仕組みの違い：格納方式と依存関係の解決

三者の最大の差は依存包の設定方法にある。npmは平坦化したnode_modulesに複写する方式だ。重複を減らす工夫はあるが、基本は案件ごとに実体を置く。Yarn Classicも同様の設定であり、安定性と互換性を優先した設計だ。

pnpmは内容住所指定の保管域を用いる方式だ。pnpm公式文書（https://pnpm.io/motivation）が示すとおり、包の実体は全体で一か所に置く。案件側には強固な結線だけを置く。重複排除が徹底され、誤った参照を防ぐ構造だ。

Yarn BerryはPlug’n’Playと呼ばれる方式を選べる。node_modulesを作らず、圧縮書庫を直接参照する。設置物の数を抑え、解決の厳密さを高める設計だ。ただし旧来の参照を前提とした道具との不整合が生じる場合がある。

依存解決の厳しさも異なる。npmとYarn Classicは緩やかな解決で動作する符号が多い。pnpmとYarn Berryは宣言のない参照を許さない。幽霊依存の排除に役立つ一方、古い包では追加宣言が必要になる。

速度比較：初回設置と再設置の実測傾向

速度は条件で変動するが、傾向は明確だ。初回設置は回線と展開処理に左右される。pnpm公式の計測（https://pnpm.io/benchmarks）では、大規模案件でnpmより短時間の例が多い。並列取得と保管域の再利用が寄与する。

二回目以降は差が広がる。pnpmは保管域に実体があれば結線だけで済む。数秒で終わる事例も多い。npmも隠し収納の活用で速くなったが、案件ごとの複写は残る。Yarn BerryのPlug’n’Playは展開が少なく、再設置が速い部類だ。

現場での体感は継続的統合で顕著だ。npmは収納の復元が鍵になる。pnpmは保管域の共有で復元量を抑えられる。Docker構築では層の再利用と相性が良い。単一保管域ではYarn Berryの零設置運用が効く場合がある。

注意点は計測条件の統一だ。錠ファイルの有無や収納の状態で結果は変わる。並列数や計算機性能も影響する。公開値は目安とし、自案件で三回平均を取る方法が確実だ。

ディスク使用量：重複排除の効果と具体例

容量差は案件数が増えるほど拡大する。npmは案件ごとに数MBを使う場合がある。十案件で数GBに達する事例は珍しくない。Yarn Classicも同様の傾向だ。

pnpmは実体共有で使用量を抑える。React系の典型案件を十件置いた場合、npmで約3GBに対しpnpmで約1.2GBに収まったという報告が利用者層の検証にある。版違いが多いと効果は薄れるが、同系の包を使う組織では削減幅が大きい。

Yarn BerryのPlug’n’Playは展開前の圧縮書庫を置く。node_modules型より容量が小さい場合が多い。零設置では保管域を含めるため貯蔵所の容量が増える。取得時間と貯蔵容量の交換関係を考える必要がある。

運用では収納掃除も重要だ。npmはnpm cache verifyで健全性を保つ。pnpmはpnpm store pruneで不要な実体を除く。Yarnはyarn cache cleanで収納を整理する。定期的な掃除で肥大化を防ぐことだ。

互換性と移行：錠と道具連鎖の注意点

互換性ではnpmが最も無難だ。Node.jsに同梱され、ほぼ全ての道具が対応する。追加設定は不要だ。小規模な受託や教材配布では摩擦が少ない。

pnpmへの移行は錠の作り直しが必要だ。pnpm importで他形式の錠を取り込める。完全な再現にはpnpm install —frozen-lockfileの運用が欠かせない。継続的統合の設定変更も伴う。

pnpm特有の課題は厳格な同列包の扱いだ。React 18系と旧来の追加部品の組み合わせで衝突が起きる。pnpm.overridesや読込許可の設定で回避する。移行前にpnpm install —strict-peer-dependenciesで検査する方法が有効だ。

Yarn Berryは対応道具の確認が必須だ。React NativeやElectron系では展開方式との相性問題が残る。nodeLinkerをnode-modulesに戻す退避策がある。段階移行ではClassicの保守系統を選ぶ判断も合理的だ。

用途別の選び方：規模と運用体制で決める

個人開発と小規模案件ではnpmが適する。環境差が少なく、疑問の解決策が豊富だ。納品先の実行環境を問わない利点がある。学習負担を抑えたい場合の基準になる。

複数案件の並行や単一保管域ではpnpmが強い。保管域共有で容量と時間を抑える。作業域機能が内蔵され、部品分割との相性が良い。厳格な解決で品質を保ちたい組織に向く。

大規模な単一保管域と高度な統制ではYarn Berryが候補だ。制約機能で依存の版統制ができる。零設置で取得を省く運用も可能だ。設定と習熟の負担を受け入れられる体制が前提になる。

道具連鎖の観点も欠かせない。Corepackによる包管理道具の版固定は有効だ。VoltaによるNode.js版管理と併せると再現性が高まる。Dockerでは錠と定義書の複写順を整え、層の再利用を促すことだ。

編集部の見解

編集部は設置速度単体より再現性と運用負荷を重視して評価する。pnpmは厳格な依存関係解決で誤動作が少なく、複数案件の並行に強いと見る。npmは標準装備と情報量が利点であり、小規模開発の基準と評価する。

落とし穴は幽霊依存に依存した古い符号がpnpmで動かない点にある。公式文書にない設定差で継続的統合が失敗し、調査に時間を取られると見る。移行時は依存検査と結線許可設定の見直しが不可欠と評価する。

今後1〜3年はpnpm方式の効率化が主流になると見る。DenoやBunの台頭で包管理の統合が進むと言えそうだ。Yarnは大規模単一保管域での機能強化に活路があると評価する。

参考

• pnpm公式文書
• pnpm動機と基準
• pnpm速度計測
• npm文書
• Yarn文書
• Node.js公式