序文
主な記事
v1 - v3 単一ダイアグラムアーキテクチャ
Webpackは、イメージの公式ホームページが示すように、すべてがパッケージ化することができることをスローガンの初めに生まれた、それはWebpackの初めから、フロントエンドエンジニアリングは、バンドルの本当の意味を持っていると言うことができる、過去の助成金では、gulpは、プロセスの問題を解決したが、どのようにパッケージにリソースを解決していない、これは最も単純な問題は、Webpackは、フロントエンドエンジニアリングのこの欠点を補うために、同時に、フロントエンドエンジニアリングは、新しいフィールドに。Webpackはフロントエンドエンジニアリングのこの欠点を補うと同時に、フロントエンドエンジニアリングを全く新しい分野に押し上げます。
この期間は、ほぼv1です - v3これらの3つのバージョンの、私の記憶では、v1から - v3 Webpackのアップグレードはあまりにも大きな変更ではありませんが、まだ比較的滑らかで、安定性の設計のコアアーキテクチャの背後にあるこの滑らかな、見てみましょう、Webpackのこの期間は、いくつかの主要な概念をもたらすために
- entry
- output
- Module
- chunk
初期のコア・アーキテクチャでは、これら4つのコンセプトは次のような図にまとめられていました。
このイメージの意味を説明すると、Webpackは、解析のためのエントリファイルによって指定されたエントリを介して、解析プロセス？、長い話、とにかく、あなたはただ、Webpackは、モジュールのインポート構文のすべての種類をサポートする必要がありますインポートなどを要求するために、知っている、ここでWebpackは主に使用します。
acorn.jsはJavaScriptで書かれた、JavaScriptコードを抽象構文木に変換する非常に高速で高性能なインタプリタですが、なぜbabelを使わないのでしょうか？ まず、babelはやはり様々なバージョンのJavaScriptを変換するのがメインですが、実はbabelはモジュールのパース問題を解決していないので、Webpackには重すぎます。 問題を解決しているわけでもないし、v1でbabelが問題になったわけでもないし。
上の図に戻り、ここではチャンクモジュールとそれを繋ぐ線に注目します。Webpackのコアアーキテクチャにおいて、核となるコンテンツはチャンクであり、チャンクの概念、およびチャンクを中心とした一連の設計は、Webpack全体の核となるコア、土台の土台であると言えます。チャンクがなければチャンクなくしてWebpackに魂はありません。 次にモジュールですが、Webpackの設計では、モジュールはファイルの抽象的なマッピングであり、ローダーと一緒になってバンドルの実体内容を形成します。
この話は何度もしていますが、まだ本題に入っていません。 タイトルでは 単一グラフのアーキテクチャについて 書きました。 この単一グラフとは、チャンクで構築されたグラフ構造である ChunkGraph を指し、チャンクの中にモジュールを包み込みます。Webpack の依存性分析、CommonsChunkPlugin のパブリック コード最適化、パッケージングなどは、すべてこのコア アーキテクチャに基づいていました。
その後、なぜ後にv4に変更され、経験豊富なv3からv4の学生が感覚を持っている必要があり、Webpackのv4のアップグレードは非常にスムーズですが、プラグインの多くは互換性がない、移行コストが非常に大きく、ここでは、実際にこのCommonsChunkPluginの最適化にある中核的な理由は、需要のアンパックのためのフロントエンドエンジニアリングに適応することはできませんので、あります。主要な変更のv4は、後でSplitChunksPluginを導入しました
v3 - v4 シングルグラフからデュアルグラフアーキテクチャへ
技術の発展に伴い、Webpackのチームは徐々にCommonsChunkPluginは、もはや最適化のための多くの部屋を持っていないことを発見し、公式サイトでは、理由を最適化し続けることができない理由を説明する記事があり、理由と最適化戦略の一つは、ChunkGraphでは、すべてのチャンクは、親情報を持っていることを単純な事実に関連しているマーキングそして、Chunk の親が満杯であるモジュールがあるとすると、このモジュールは共通化されたモジュールです。Chunkにこれらの共通モジュールを保存して、それから？ そして、それを ChunkGraph に追加します。すべての Chunk は親の情報を持つ必要があるため、Webpack は CommonsChunk を親チャンクとすることをデフォルトとしています。
- CommonsChunk にはたくさんのパブリックな依存関係がありますが、順不同なので、非同期にロードするのは難しく、できるだけ同期させる必要があります。
- もうひとつは、あなたが望もうが望むまいが、あなたの中にあるモジュールが望もうが望むまいが、とにかくこの塊は一度ロードされるとずっとやってくるので、家族にとっては非常に不親切だということです。
さらに、チャンクは抽象化として設計されていますが、暗黙のモジュール依存性があり、この2つの抽象化の次元が同じでないため、理解しにくいことがあります。
つまり、v4ではデュアル・グラフ・アーキテクチャが採用され、デュアル・グラフは元のChunkGraphで、もう一方はModuleGraphです。 そして、CommonsChunkはSplitChunkになり、親チャンクと子チャンクの関係は、親チャンクグループと子チャンクグループの関係になります。子チャンクグループの関係、ここでチャンクグループも新しい概念です、実際、チャンクを純粋にするために、親子関係はチャンクグループに抽象化されます、Webpackはこのヒューリスティックと呼ばれ、Reactもヒューリスティックを持っています、感覚はより似ています、デュアルグラフアーキテクチャの利点は明らかです、それは2つのネットが分割するために一緒にかき混ぜることと同等です。デュアルグラフアーキテクチャの利点は明らかです、それは分割するために一緒に2つのネットの混合に相当し、Chunkはまだモジュールを含んでいますが、依存関係の分析では、ModuleGraphは、独自のプレー、Chunkは純粋に抽象的な概念となっています
チャンクの分析が独立し、親子構造がないため、フラット、チャンクの分割と非同期の組み合わせは非常に簡単になり、どのように組み合わせたいか、非同期として非同期にしたい、チャンク自体が分類を行う限り、例えば、イニシャルチャンクと非イニシャルチャンクがあり、後者は非同期に従事するために使用され、前者はエントリによって形成されたチャンクです。前者は、エントリによって形成されたチャンクです。
だからv3からv4にWebpackの開梱機能が大幅に改善され、SplitChunkは非常に柔軟で、制御性もはるかに強力ですが、フロントエンドエンジニアリングの開発も非常に高速であり、v4から今まで2年以上、 マイクロフロントエンドは 、新しいフロントエンドエンジニアリングの要件を提唱捨て、当然のことながら、Webpackのチームの時代に取り残されることはできませんので、v5があり、新しいホットな機能Module Federationは、同じv5はまた、新しいアーキテクチャ設計をもたらします。だからv5があり、ホットな機能 モジュール連盟の 新鮮な、同じv5はまた、新しいアーキテクチャ設計をもたらします
v5 - コンテナベースのアーキテクチャ
v5はまだベータ版のため、ここに書かれているコンセプトの一部は後に変更される可能性があります！
実際には、v5がある理由は、v4 ModuleGraphアーキテクチャのアップグレードを行うことはできませんが、モジュールフェデレーションを見て、モジュールに基づいているため、それはまだ単一のグラフアーキテクチャのv3であれば、パッケージは、組合について話をしない分割することはできません、せいぜい独裁 なので、アーキテクチャは進化であり、ジャンプアーキテクチャはありません、各進化は 、トレース であり 、相互接続されているので、モジュールフェデレーションは、どのような問題を解決するために？ ジャンプアーキテクチャはありません、すべての進化は、トレース可能で相互接続されて いるので、モジュール連盟は、どのような問題を解決しようとしているのですか？
そのために、もともとの建築デザインだけでは不十分で、 コンテナという新しいコンセプトを開発したの です。
Containerは、fileNameを持って、エイリアスの出力であり、その後、Containerはまた、エントリの独自の設定にマップする名前を通して、独自のエントリを持って、Containerはまた、重要な概念を持っているインターフェイスとしてモジュールを取ることです、はい、あなたはそれを正しく読んで、あなたはContainerになります。そうです、正しく読みましたね、あなたはContainerをサービスとして考え、apiはモジュールの中にあるものなので、モジュールは非常にシンプルで、Containerを要求するために行くので、Containerは、リクエストのソースを識別するために使用されるremotes属性を持っています。
しかし、v5がまだリリースされていないので、その後の変更があるかどうかを言うのは難しいので、現在の観点から、アーキテクチャ設計のこのセットの概念のいくつかはまだ比較的漠然としているので、私はいくつかの変更があるだろうことを意味し、最適化のための多くの余地がまだあると思います、少なくとも先月に私は関連するコンテンツを読んで、今月は同じではないいくつかありますが、あなたが興味を持っている場合は、例を含む関連するドキュメントを参照することができ、公式の与えるあなたが興味を持っている場合は、正式に利用可能な例を含むドキュメントをチェックアウトすることができ、Webpackのv5に目を離さないでください。
あとがき
Webpackのアーキテクチャ設計は非常に興味深く、学ぶ価値があり、フロントエンドエンジニアリングの理解のために、学習と探求を通じて、非常に有用であるだけでなく、私は多くの利益を得ることができ、また、アーキテクチャとデザインの探求にあなたの興味を喚起するために、この記事を使用することを願っています。
