11

関連するwebpack/webpack の問題。

私の経験では、実際のプロジェクトで webpack を使用すると、特定の数のコンポーネントや依存関係を重ねると速度が低下します。次のアプリケーションでこれを実証しようとするテストリポジトリがあります

  • エントリ ポイントはで、これにはとA.jsが必要です。B.jsC.js
  • B.js小さく、多くの依存関係がありません。
  • C.jsモノリシックであり、何千もの要件があります。

私の期待はwebpack-dev-server、テストプロジェクトで使用する場合、保存するたびにB.js、webpack がそれを認識しC.js、その依存関係がまったく変更されていないことです。B.js迅速に (10 ミリ秒未満で) コンパイルし、キャッシュに置き換えて、最初のコンパイルからキャッシュされたバージョンを使用してコンパイルされたものを出力する必要がありますA.jsC.js

ただし、webpack3002は を保存するたびに隠しモジュールをB.jsコンパイルするため、コンパイル時間は960ms. これ自体は悪くありませんが、react-hotやのようなローダーを追加すると制御不能になりbabelます。

私には解決策があります。同じテスト プロジェクトにdllブランチがあります。そのブランチで、 を実行してとwebpack --config webpack.dll.config.jsから 2 つの DLL を生成できます。これは、コンパイル時に利用されます。その後、 を使用すると、 を保存するたびにその DLL が再コンパイルされ、その DLL の 1 つが更新されたことに気づき、 の古い DLLと新しい DLL を取得して、それらを 1 つの迅速なハッピー バンドルに結合します。B.jsC.jsA.jswebpack-dev-serverB.jsA.jsC.jsB.js

そのブランチをさらに進めて、ディレクトリの読み取りまたは依存関係グラフのウォークを実行して、すべてのコンポーネントの DLL を生成することができます。これは、すべての webpack プロジェクトに適用できる可能性のあるアプローチです。理論的には、それは私が望むのと同じくらい速くコンパイルするはずです。しかし、その時点で、webpack のキャッシング層が独自に行うべきことを (不十分に) 再実装したように思えますが、ここで何が起こっているのでしょうか?

4

0 に答える 0