プロジェクト内の各モジュールの依存関係がツリーとみなされる場合、エントリは依存関係ツリーのルートになります。
これらの依存モジュールは、パッケージ化時にチャンクにカプセル化されます。では、チャンクとは何でしょうか？
チャンクは文字通りコード ブロックを意味し、Webpack では抽象化されパッケージ化されたいくつかのモジュールとして理解できます。これは、多数のファイルを含むファイル バッグのようなもので、Webpack は外側にパッケージングの層を追加してチャンクを形成します。
特定の構成に応じて、プロジェクトがパッケージ化されるときに 1 つ以上のチャンクが生成される場合があります。
プロジェクトには複数のエントリを定義でき、各エントリは結果リソースを生成します。
たとえば、プロジェクトにはsrc/index.jsとsrc/lib.js dist/index.js 2 つのエントリがあります。 dist/lib.js 。
一部の特殊なケースでは、1 つのエントリが複数のチャンクを生成し、最終的には複数のバンドル
パラメータ: エントリ
module.exports = {
エントリ:'./src/index.js', //エントリファイルを示します、つまり、index.jsからプロジェクトに入る}; ①エントリタイプ
| を意味する | タイプの | 例 |
|---|---|---|
| ' | ./app/entry' | エントリのファイルパスmodule (相対パス配列 ['./app/entry1', './app/entry2'] にすることができます |
| ) | エントリ | モジュールのファイル パス (相対パス |
| オブジェクト | にすることができます){ a: './app/entry- a', b: ['./app/entry-b1', './app/entry-b2']} | 複数のエントリを設定すると、 |
配列型の場合、出力で使用されるときに
各エントリがチャンクを生成します。ライブラリ設定項目、配列内の最後のもののみ エントリ ファイルのモジュールがエクスポートされます
。② チャンク名
Webpack は、生成された各チャンクに名前を付けます。チャンクの名前はエントリの設定に関連します。
構成ダイナミクス。
プロジェクトに複数のページがある場合、各ページにエントリを構成する必要がありますが、これらのページの数は増加し続ける可能性があります。他の要因の影響を受けるため、静的な値として書き込むことはできません。解決策は、関数に Entry を設定して、上記の設定を動的に返すことです。コードは次のとおりです。
// 同期関数エントリ: () => {
戻る {
a:'./ページ/a'、
b:'./ページ/b',
}
};
// 非同期関数のエントリ: () => {
return new Promise((resolve)=>{
解決する（{
a:'./ページ/a'、
b:'./ページ/b',
});
});
パラメータ: context
Webpack は、相対パスを持つファイルを検索するときに、ルート ディレクトリとして context を使用します。Context のデフォルトは、Webpack が起動される現在の作業ディレクトリです。 コンテキストのデフォルト設定を変更したい場合は、設定ファイルで次のように設定できます。
module.exports = {
コンテキスト: path.resolve(__dirname, 'app')
context は絶対パス文字列である必要があることに注意してください
。
さらに、
Webpack の起動時にパラメータ webpack --context を指定することで、
コンテキストの使用法: entry:string|Array<string>
1. 省略された構文
webpack.config.js
//単一であるため、次のように省略できます。
module.exports = {
エントリ: './main.js'
上記のエントリ構成は、
実際には次の略語として記述されます
module.exports = {
エントリ: {
メイン: './main.js'
}
2.配列構文
module.exports = {
エントリ: {
main:['./main.js','./main2.js']
}
配列を渡す機能は、
パッケージ化するときに、文字列または配列を使用して単一のエントリを定義する場合、配列内の最後の要素を事前にマージすること
です
。チャンク名を変更する方法は、デフォルトの「main」のみです。
使用法: entry: {[entryChunkName: string]: string|Array}
オブジェクト構文
module.exports = {
エントリ: {
アプリ: './src/app.js',
ベンダー: './src/vendors.js'
}
これはさらに面倒になります。ただし、これはアプリケーション内のエントリ ポイントを定義する最も拡張可能な方法です。
「拡張可能な Webpack 構成」 : 再利用可能で、他の構成と組み合わせることができます。これは、環境、ビルド ターゲット、およびランタイムから懸念事項を分離するための一般的な手法です。次に、webpack-merge などの特殊なツールを使用してそれらをマージします。
1. シングルページ アプリケーションは
、各ページのフレームワーク、ライブラリ、モジュールのいずれであっても、 app.jsの単一のエントリ ポイントによって参照されます。この利点は、JS ファイルが 1 つだけ生成され、依存関係が明確になることです。
module.exports = {
エントリ: './src/app.js'
このアプローチには欠点もあります。つまり
、アプリケーションの規模がある程度大きくなると、生成されるリソースの量が大きくなりすぎて、
デフォルトではユーザーのページのレンダリング速度が低下します。 Webpack の構成でバンドルが 250kB (圧縮前) より大きい場合、バンドルは大きすぎるとみなされ、図に示すようにパッケージ化中に警告が表示されます。
2. サードパーティ ライブラリ (ベンダー) を分離する
ために、
Webpack では、ベンダーは通常、ライブラリなどのサードパーティを指します。およびプロジェクトで使用されるフレームワークをバンドルします
module.exports = {
エントリ: {
アプリ: './src/app.js',
ベンダー: ['react','react-dom','react-router'],
}
アプリケーションの例に基づいて、
vendorのチャンク名を持つ新しいエントランスを追加し、プロジェクトが依存するサードパーティ モジュールを配列の形式で配置しました。
ベンダーのエントリ パスは設定しませんでした
。. Webpack はどうすればよいでしょうか?
現時点では、 CommonsChunkPlugin (CommonsChunkPlugin は Webpack 4 以降廃止されました。optimization.splitChunks を使用できます) を使用して、アプリとベンダーの 2 つのチャンク内の共通モジュールを抽出できます。
この構成では、app.js によって生成されたバンドルのみが作成されます。ビジネス モジュールとそれが依存するサードパーティ モジュールが抽出されて新しいバンドルが生成されます。これにより、ベンダーを抽出するという目標も達成されます。
ベンダーにはサードパーティ モジュールのみが含まれるため、この部分は頻繁に変更されません。したがって、クライアント側のキャッシュを効果的に利用でき、その後ユーザーがページをリクエストしたときの全体的なレンダリング速度が向上します。
CommonsChunkPlugin は主に、最初の画面に読み込まれるバンドル ファイルやオンデマンドで読み込まれるバンドル ファイルが大きすぎて読み込み時間が長くなるのを防ぐために、サードパーティのライブラリとパブリック モジュールを抽出するために使用されます。
3. マルチページ アプリケーション
マルチページ アプリケーションのシナリオでは、リソースのサイズをできる限り削減するために、すべてのページを同じバンドルにパッケージ化するのではなく、各ページが独自の必要なロジックのみをロードすることを望みます。したがって、各ページには独立したバンドルが必要です。この場合、これを実現するために複数のエントリを使用します。次の例を参照してください:
module.exports = {
エントリ: {
pageOne: './src/pageOne/index.js',
pageTwo: './src/pageTwo/index.js',
pageThree: './src/pageThree/index.js'
}
この時点で、エントリとページは 1 対 1 に対応しているため、各 HTML が導入する限り必要なモジュールを読み込むことができます
。
独自の JS。