WSL ビルドが遅いのは npm のせいでした – 実際の修正には 5 分かかりました

何年も開発環境を構成してきましたが、WSL2 内の最近のプロジェクトが私を完全に謙虚にさせたのを見て驚きました。ビルド時間が非常に遅いように見えたので、プロジェクトが肥大化しているのではないかと思い、問題を解決するためにキャッシュをクリアしたりソフトウェアを更新したりするのに数時間を無駄にしました。

しかし、私はこの問題を誤って診断していました。私のツールとハードウェアはすべて正常でしたが、唯一の問題はドライブ上のファイルの保存場所でした。プロジェクトを適切な場所に移動することでビルド速度を 4 倍にし、この改善には 5 分もかかりませんでした。

私は間違ったことを責めた

npmは問題ではなかった

WSL ビルドが遅いのは npm のせいでした – 実際の修正には 5 分かかりました — アファム・オニマドゥ/MUO

私の完全に正常な Next.js アプリが問題を明らかにしたプロジェクトでした。数週間にわたって取り組んできましたが、これに関しては何もユニークなことはありません。標準の依存関係リストとビルドパイプラインを使用します。どちらも以前に何度も利用したことがあります。しかし、私は走るたびに常に失望を覚悟していました。 npm ビルドを実行する。これは依存関係をインストールしたときに感じたのと同じで、通常は問題なく実行できるはずのコマンドでさえ遅延が発生し始めました。

何かがクロールしているときは常にターミナルにこのコマンドを入れていたので、私は当然 npm のせいにしました。そこで、npm キャッシュをクリアし、ノードを最新の LTS リリースに更新することで問題を修正することにしました。何も変化がなかったので、より高速なインストーラーで問題を解決しようと、しばらくの間 PNPM に切り替えてみましたが、それもうまくいきませんでした。

ずっと、重要な手がかりを見逃していました。遅いプロジェクトはすべて実行されていたのです /mnt/c/Users/... 。同じ遅延を示さなかった小さなリポジトリがいくつかありました。それらを直接 WSL にクローンしたところ、問題が何であるかを知る手がかりが得られました。これらを問題のあるビルドと比較すると、パターンを見逃すのは困難でした。

ただし、この発見により、プロジェクトフォルダーがその中で実行されているツールよりも重要なのはなぜなのかという重要な疑問が生じました。

ファイルシステムの問題

ここから不況が始まる

Windows 11 で WSL を有効にする — アファム・オニマドゥ/MUO

WSL を有効にすると、2 種類のファイルシステムが得られます。 1 つ目は Linux のネイティブファイルシステムで、多くの場合ホームディレクトリに存在します。 ~/プロジェクト。 2 つ目は Windows ファイルシステムで、Linux 内にマウントされます。それは起こったかもしれない /mnt/c、 /mnt/d等

Linux が Windows にマウントされたドライブ上のタッチファイルを処理するときに、2 つのシステム間に必要な変換層を通過する必要があります。これは、単一ファイルの場合には無視できるオーバーヘッドです。ただし、単一の npmci 小規模なプロジェクトでは、何千もの個別のファイル操作が発生する可能性があり、それぞれが変換レイヤーを横断します。

npm が完全に責任があるわけではないことは注目に値します。多くのファイル操作を実行する多くのツール (Git、pnpm、Yarn、Vite など) は、ファイルシステムが遅いと速度が低下します。装置自体が効率的かどうかは関係ありません。

ワークフロー	プロジェクトに最適な場所
WSL の Node.js、Vite、Next.js、Git、Docker	ネイティブLinuxファイルシステム
Windows ネイティブ開発ツール	Windowsファイルシステム

使用 DF-T 探すファイルシステムタイプ: Windows にマウントされたドライブの場合は drvfs、ネイティブ Linux の場合は ext4 (または類似のもの)。

5分で直りました

パッケージマネージャーは無実だった

推測したくなかったので、他のすべての要素を同じにしてテストすることにしました。これは、同じハードウェア、ノード、npm バージョン、同じプロジェクトを意味します。私が変更した唯一の要因は場所でした。ここからプロジェクトを移動しました /mnt/c/...Linux ホームディレクトリ内。プロジェクトを正常に編集できることを確認するために、VS Code Remote – WSL 拡張機能を使用しました。

同じコマンドを再度実行すると、前後で次のようになります。

仕事	/mnt/c	Linuxファイルシステム
npm ビルドを実行する	45～75秒	15時から25時まで
npmci	65～100秒	12-20
git ステータス	2.5～5.0秒	0.05～0.1秒

施工・設置数は満足のいくものでしたが、唯一納得できたのは、 git ステータス。この命令はほとんど影響しませんが、 ノードモジュールEnterを押すと数秒も待たずに戻ってきました。 npm に問題がある場合、Git はこれ以上高速ではありません。その素早い対応が何よりの贈り物でした。問題はパッケージマネージャーではなく、基盤となるファイルシステムにありました。

これらの新しい結果を得るためにツールを変更したり構成を書き直したりすることはありませんでした。唯一の変更はプロジェクトの場所でした。 Linux プロジェクトは、まさに Linux が期待していた場所でした。これが、私がキャッシュクリアコマンドに頼るのをやめたポイントです。ここで最初に行うことは、プロジェクトがどこにあるかを確認することです。

これは普遍的な解決策ではありません

私は、すべてのプロジェクトを WSL Linux ファイルシステムに置く必要があるかどうか、まだ確信が持てません。 Windows ネイティブ IDE、Photoshop などのクリエイティブアプリ、または単純な Windows 同期ツールでは、いくつかの情報を直接読み取る必要がある場合がありますが、それらのリソースを Windows 側に置くことでメリットが得られます。実際、これらの特定のリソースを移動すると、ある種類の摩擦を別の種類の摩擦と交換するだけになります。

しかし、振り返ってみると、それは恥ずかしいほど明白な解決策でした。故故宮は目に見えて減速しており、それが長期間苦しむ原因となった。本当の問題は、npm を間違ったファイルシステム上で辛抱強く待機させていたことでした。このファイルシステムは、迅速にサービスを提供するように設計されていませんでした。この変更は、パッケージマネージャーを変更するよりも効果的でした。