タイトル: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に変換
し、再コンパイルします。これはまた、速度がビジネスに対する妥協であるとも理解できます。