PCの容量が。。。
Nodeを使ったプログラムを単品でアホほど作ってるとnode_modules地獄になるよね。
お陰でPCの容量がアホほどカツカツになってしまうことって有るよね。
※モノレポで作ったとしても、プロジェクト変わったりしてまた1から構築とかしてると結局チリツモだよね
どうも、PCデブなえ～すけさんですよ。
npm vs pnpm — まだnpmで消耗してるの？
Nodeを使ったシステムを作る場合に「とりあえずnpmつかってやるか」は、
もはや思考停止かなってココ最近思った次第です。
いや、別にnpmが悪いわけじゃないんだけど、“デフォルトだから・紹介記事に書いてあるから使う”は技術選定じゃない という、当たり前を疑え 的なことを話したい。
とりあえず、npmとpnpmの違いを「ちゃんと理解した上で選べる状態」になるためのお手伝いになればいいかなと思ってます。
そもそもnpmとpnpmって何が違うの？
どっちも「パッケージマネージャ」です。役割は同じ。
- 依存関係をインストールする
- バージョン管理する
- スクリプトを実行する
つまりやってることは同じ。
じゃあ何が違うのか？
「依存パッケージの持ち方」 です。
npm：とりあえず全部コピーするマン
npmはシンプルです。
- プロジェクトごとに
node_modulesを作る - 依存パッケージを全部コピーする
つまりこういうこと↓
projectA/node_modules/react
projectB/node_modules/react
projectC/node_modules/react
同じReactでも、プロジェクトごとに複製される。
その結果どうなるか？
- ディスクが無駄に肥大化
- インストールが遅くなる
- node_modulesが地獄
これは設計としてそうなってるので、npmが悪いというより「そういう思想」だから。
pnpm：賢く使い回すマン
pnpmは発想が違う。
- パッケージはグローバルに1回だけ保存
- 各プロジェクトにはリンクだけ貼る
~/.pnpm-store/react (実体)
projectA/node_modules/react -> link
projectB/node_modules/react -> link
つまり 「同じものは1回しか持たない」 (なんてステキ
これによって何が起きるか？
- インストールが速い（2〜3倍になるケースも）
- ディスク使用量が激減（~60%削減とか普通にある）
- ダウンロードも効率化される
正直、やってることは普通に正しい。
一番デカい違い：依存関係の「厳しさ」
ここ、初心者とかは意識しない部分だけど。。。
npm（ゆるい）
- package.jsonに書いてなくても動くことがある
- いわゆる「幽霊依存（phantom dependency）」が発生
動くけど、壊れやすい
pnpm（厳しい）
- package.jsonに書いたものしか使えない
- 不正な依存は即エラー
バグを未然に潰す設計
まとめ：違いを雑に言うとこう
| 観点 | npm | pnpm |
|---|---|---|
| インストール方式 | コピー | リンク |
| 速度 | 遅め | 速い |
| ディスク効率 | 悪い | 良い |
| 依存の厳格さ | ゆるい | 厳しい |
| 互換性 | 最強 | たまにハマる |
「で、どっち使えばいいの？」
結論を逃げずに言います。
npmを使う理由
- とにかく互換性重視
- 既存プロジェクトがnpm前提
- チーム全員が何も考えずに使える
👉 “無難”を選びたい人向け
pnpmを使う理由
- インストール遅いのにイライラしてる
- ディスク容量が気になる
- 依存関係のバグに疲れた
- モノレポやってる
“ちゃんと開発したい人向け”
正直な話
pnpmは「魔法のツール」ではないです。
- たまに互換性でハマる
- チームに説明コストがかかる
- CI設定で詰むこともある
でも、それ込みでも
「npmの構造的な非効率」をちゃんと解決してるのはpnpmだけです。
結論
- npm = 標準装備の安心感
- pnpm = 設計として正しい進化系
そして一番ダメなのは
「違い知らずにnpm使ってる状態」
それ、ただの思考停止です。
おまけ：雑な判断基準
とりあえず動けばいい → npm
開発体験を改善したい → pnpm
モノレポ・大規模 → pnpm
何も考えたくない → npm
最後に
技術選定で「デフォルトだから」は卒業しましょう。
npmを選ぶにしても、pnpmを選ぶにしても
理由を持って選べる状態が大正義です。