タイトル：Vite vs Webpack
日付：2022 年 06 月 06 日 10:28:00
目次：false
index_img：https://puep.qpic.cn/coral/Q3auHgzwzM4fgQ41VTF2rF1YCFdibQ9cyYktsNibicoKDA3PQPcYXddjA/0
カテゴリ：
- フロントエンド
タグ： - プロジェクト
- ファイル
- ユーザー
- サービス
- 解決
- 発生
- 印刷
Vite の速さの理由#
皆さんはwebpackを使用してプロジェクトをビルドする際に、次のような状況に遭遇したことがあるかもしれません。
プロジェクトに A と B の 2 つのページがあると仮定します。
A ページはプロジェクトのホームページであり、コードは正常に動作しています。
B ページはリダイレクトが必要なページであり、いくつかのエラーが存在します。例えば、存在しないファイル
a.jsをインポートしてaを印刷するなどです。このプロジェクトをビルドする際、私たちは明らかに B ページにはアクセスしていないのにもかかわらず、webpack は依然として対応するエラー
Can't resolve './a.js' in xxxをスローします。
この問題の原因は、webpackのビルドメカニズムによるものです。
開発時の webpack のビルドでは、デフォルトでアプリケーション全体をキャプチャしてビルドし、サービスを提供するため、プロジェクト内のどのページにエラーが存在しても（ユーザーがアクセスしていないページであっても）、プロジェクト全体のビルドに影響を与えます。
このため、プロジェクトが大きくなるほど、ビルド時間が長くなり、プロジェクトの起動速度が遅くなります。
しかし、viteの場合、同じテストを行うと興味深いことがわかります。
同じ
Can't resolve './a.js' in xxxエラーは、B ページにアクセスしない限り表示されず、B ページにアクセスすると突然このようなエラーが表示されます。
これが起こる理由は、viteは最初からプロジェクト全体をビルドしないためです。代わりに、アプリケーションのモジュールを依存関係とソースコード（プロジェクトコード）の 2 つに分け、ソースコードの部分はルートに基づいてコードモジュールを分割し、最初にビルドする必要があるコンテンツのみをビルドします。
同時に、viteはブラウザに対してソースコードをネイティブ ESMの形式で提供し、ブラウザにパッケージングの一部を引き継がせます。
このようなメカニズムのため、プロジェクトのサイズに関係なく、最初にビルドする必要があるコンテンツのみをビルドするため、viteのビルド速度が大幅に向上します。
これがviteが高速な理由の核心です。
Vite のこのメカニズムには問題があるのでしょうか？#
もしESMのビルドメカニズムについて理解がある場合、次の問題に気付くことができるでしょう。
それは、viteがネイティブ ESMの形式でソースコードをブラウザに提供し、ブラウザにパッケージングの一部を引き継がせるため、プロジェクトにcommonJSのコンテンツが存在する場合、解析できないことを意味するのではないかということです。
そうです！
viteの初期バージョンでは、この問題が実際に存在し、多くの依存関係が使用できなくなるという非常に深刻な問題が発生しました。
例えば、axiosはaxios内で多くのcommonJSの規格を使用しているため、viteは対応するコンテンツを解析できず（関連するissue）、エラーが発生します。この問題については、vite の issueで激しい議論が行われました。
尤大（Evan You）もこの問題について発言しています：
では、このような問題は最終的にどのように解決されたのでしょうか？
公式はこの問題をどのように解決しているのでしょうか？#
この問題は非常に深刻なため、viteは後期に依存関係の事前ビルド機能を提供しました。これは、CommonJS と UMD の互換性の問題を解決するための非常に重要な目的の 1 つです。現在、viteはCommonJSまたはUMDで公開された依存関係をESMに変換し、再コンパイルします。これはまた、速度がビジネスに対する妥協であるとも理解できます。