node_modules 戦争：死んだサイドプロジェクトからギガバイトを奪還する

ディスク上の死んだサイドプロジェクトは、それぞれ自分の記念碑を立てています。Windows のインストールより多いファイル数、ときには数 GB を抱えた node_modules フォルダーです。朗報は、削除しても安全などころか、それこそが本来の設計だということ。まだ大切にしているものを壊さずに容量を取り戻す手順を紹介します。

フォルダー1つがOSより重くなる理由

npm は依存関係をすべてプロジェクトごとのローカルな node_modules にインストールします。プロジェクト間での共有も重複排除も、デフォルトではありません。こじんまりした Web アプリでも 1,000 パッケージで 800 MB～2 GB を軽く引き込み、本当の殺し屋はファイル数です。Windows Defender がスキャンし、バックアップツールが這い回り、プロジェクトを同期フォルダーに置いていれば OneDrive が永遠に窒息する、数万個の細かいファイル。Windows でインストールに数分かかり Linux では数秒なのも同じ理由です。小さなファイル生成のオーバーヘッドは凄まじい。放置した実験が5つ積もれば、誰も使っていない 10～15 GB の完成です。

恐れず削除：lockfile が保証

取り決めは単純です。package.json は何が必要か、package-lock.json は正確にどのバージョンを使っていたかを示し、node_modules はその2つを展開した結果にすぎません。node_modules を削除して npm ci を実行すれば、数分で同一のツリーが戻ります。これは復旧テクニックではなく、想定されたワークフローです。許されない唯一の過ちは、lockfile を消すこと、あるいは lockfile をコミットしないままプロジェクトを腐らせることです。フォルダーの検索には npx npkill。すべてのドライブを走査し、各 node_modules のサイズと最終更新日を一覧表示し、マークしたものを削除します。全体像が欲しければ WizTree が汎用ディスクマップとして同じ仕事をします。

削除するのは node_modules — package.json や lockfile は決して
再インストールは npm ci で：npm install と違い lockfile に正確に従います
npx npkill を実行して全ドライブの node_modules を見つけて処分
アクティブなプロジェクトは OneDrive や Dropbox の外へ — ファイル数は同期を殺す
プロジェクトが死んだら？ node_modules を除いて zip にしてからフォルダーを削除
新規プロジェクトには pnpm を：単一のグローバルストアにプロジェクトがリンク

フォルダーの背後にあるキャッシュ

すべての node_modules が消えても、npm は第2の貯蔵庫を抱えています。%LOCALAPPDATA%\npm-cache のキャッシュで、インストールしたことのあるすべてのパッケージバージョンのコピーを保管し、何年も単調に増え続ける数 GB です。npm cache verify が安全に掃除し、同じ理屈はそれぞれのストアに対する pnpm store prune と yarn cache clean にも当てはまります。npm のキャッシュ自体は有効のままにすべきです。空のキャッシュでの再インストールが「遅い道」であって「普通」でなくなるのは、このキャッシュのおかげだからです。Kleaner PRO の定期ゴミ掃除は、こうした開発者キャッシュを通常の一時ファイルと一緒に回収します。複数のツールが同じマシンで静かに貯め込んでいたときに便利です。