CommonsChunkPlugin
がすべてのエントリポイントを調べ、それらの間に共通のパッケージ/依存関係があるかどうかを確認し、それらを独自のバンドルに分割するという一般的な要点を取得します。
だから、私は次の構成を持っていると仮定しましょう:
...
enrty : {
entry1 : 'entry1.js', //which has 'jquery' as a dependency
entry2 : 'entry2.js', //which has 'jquery as a dependency
vendors : [
'jquery',
'some_jquery_plugin' //which has 'jquery' as a dependency
]
},
output: {
path: PATHS.build,
filename: '[name].bundle.js'
}
...
CommonsChunkPlugin
を使用せずにバンドルした場合最終的に3つの新しいバンドルファイルが作成されます。
entry1.bundle.js
にはentry1.js
およびjquery
からの完全なコードが含まれ、独自のランタイムが含まれますentry2.bundle.js
にはentry2.js
およびjquery
からの完全なコードが含まれ、独自のランタイムが含まれますvendors.bundle.js
にはjquery
およびsome_jquery_plugin
からの完全なコードが含まれ、独自のランタイムが含まれますjquery
をページに3回ロードする可能性があるため、これは明らかに悪いです。したがって、それは望ましくありません。
CommonsChunkPlugin
を使用してバンドルする場合CommonsChunkPlugin
に渡す引数に応じて、次のいずれかが発生します。
ケース1:{ name : 'commons' }
を渡すと、次のバンドルファイルが作成されます。
entry1.bundle.js
は、jquery
の要件であるentry1.js
の完全なコードを含み、ランタイムは含まれませんentry2.bundle.js
は、jquery
の要件であるentry2.js
の完全なコードを含み、ランタイムは含まれませんvendors.bundle.js
は、jquery
の要件であるsome_jquery_plugin
の完全なコードを含み、ランタイムは含まれませんcommons.bundle.js
にはjquery
からの完全なコードが含まれ、ランタイムが含まれますこのようにして、全体としていくつかの小さなバンドルが作成され、ランタイムはcommons
バンドルに含まれます。かなり大丈夫ですが、理想的ではありません。
ケース2:{ name : 'vendors' }
を渡すと、次のバンドルファイルが作成されます。
entry1.bundle.js
は、jquery
の要件であるentry1.js
の完全なコードを含み、ランタイムは含まれませんentry2.bundle.js
は、jquery
の要件であるentry2.js
の完全なコードを含み、ランタイムは含まれませんvendors.bundle.js
には、jquery
およびsome_jquery_plugin
の完全なコードが含まれ、ランタイムが含まれます。この方法でも、全体としていくつかの小さなバンドルになりますが、ランタイムはvendors
バンドルに含まれるようになりました。ランタイムがvendors
バンドルに含まれているため、前のケースよりも少し悪いです。
ケース3:{ names : ['vendors', 'manifest'] }
を渡すと、次のバンドルファイルになります。
entry1.bundle.js
は、jquery
の要件であるentry1.js
の完全なコードを含み、ランタイムは含まれませんentry2.bundle.js
は、jquery
の要件であるentry2.js
の完全なコードを含み、ランタイムは含まれませんjquery
およびvendors.bundle.js
の完全なコードを含み、ランタイムを含まないsome_jquery_plugin
manifest.bundle.js
は、他のすべてのバンドルの要件を含み、ランタイムを含みますこのようにして、全体としていくつかの小さなバンドルが作成され、ランタイムはmanifest
バンドルに含まれます。これが理想的なケースです。
ケース2で、共通コード(vendors
)とjquery
エントリに残っているものの両方を含むvendors
バンドルになった理由( some_jquery_plugin
)?私の理解では、CommonsChunkPlugin
がここで行ったことは、共通コード(jquery
)を収集し、vendors
バンドルに出力するように強制したため、 vendors
バンドルに共通コードを「マージ」しました(現在はsome_jquery_plugin
のコードのみが含まれています)。 確認または説明してください。
ケースプラグインに{ names : ['vendors', 'manifest'] }
を渡したときに何が起こったのかわかりません。 vendors
が明らかに一般的な依存関係であるときに、jquery
とsome_jquery_plugin
の両方を含むjquery
バンドルがそのまま保持された理由/方法、および生成されたmanifest.bundle.js
ファイルが作成された方法で作成されました(他のすべてのバンドルが必要で、ランタイムが含まれています)?
これがCommonsChunkPlugin
の仕組みです。
共通のチャンクは、いくつかのエントリチャンクによって共有されるモジュールを「受信」します。複雑な設定の良い例は Webpackリポジトリ にあります。
CommonsChunkPlugin
は、Webpackの最適化フェーズで実行されます。つまり、チャンクがシールされてディスクに書き込まれる直前に、メモリ内で動作します。
いくつかの共通チャンクが定義されている場合、それらは順番に処理されます。ケース3では、プラグインを2回実行するようなものです。ただし、CommonsChunkPlugin
には、モジュールの移動方法に影響を与えるより複雑な構成(minSize、minChunksなど)を設定できることに注意してください。
ケース1:
entry
チャンク(entry1
、entry2
およびvendors
)。commons
チャンクを共通のチャンクとして設定します。commons
共通チャンクを処理します(チャンクが存在しないため、作成されます):entry1
、entry2
およびvendors
はjquery
を使用するため、モジュールはこれらのチャンクから削除され、commons
チャンクに追加されます。commons
チャンクにはentry
チャンクとしてフラグが付けられ、entry1
、entry2
およびvendors
チャンクは、entry
としてフラグが解除されます。commons
チャンクはentry
チャンクであるため、ランタイムとjquery
モジュールが含まれます。ケース2:
entry
チャンク(entry1
、entry2
およびvendors
)。vendors
チャンクを共通のチャンクとして設定します。vendors
共通チャンクを処理します:entry1
およびentry2
jquery
を使用して、これらのチャンクからモジュールを削除します(vendors
チャンクにはすでに含まれているため、vendors
チャンクには追加されません)。vendors
チャンクにはentry
チャンクとしてフラグが付けられ、entry1
およびentry2
チャンクはentry
としてフラグが解除されます。vendors
チャンクはentry
チャンクであるため、ランタイムとjquery
/jquery_plugin
モジュール。ケース3:
entry
チャンク(entry1
、entry2
およびvendors
)。vendors
チャンクとmanifest
チャンクを共通のチャンクとして設定します。manifest
チャンクが存在しないため作成します。vendors
共通チャンクを処理します:entry1
およびentry2
jquery
を使用して、これらのチャンクからモジュールを削除します(vendors
チャンクにはすでに含まれているため、vendors
チャンクには追加されません)。vendors
チャンクにはentry
チャンクとしてフラグが付けられ、entry1
およびentry2
チャンクはentry
としてフラグが解除されます。manifest
共通チャンクを処理します(チャンクが存在しないため、作成されます):manifest
チャンクにはentry
チャンクとしてフラグが付けられますが、entry1
、entry2
およびvendors
は、entry
としてフラグが解除されます。manifest
チャンクはentry
チャンクであるため、ランタイムが含まれています。それが役に立てば幸い。