wbepackのoutput.filenameとoutput.chunkFilename



Output Filename Output



webpack構成でのfilenameとchunkFilenameの使用に関して、使用法で理解されていないいくつかの事柄は、調査後に次のように記録されます。

filename: string | function



このオプションは、各出力バンドルの名前を決定します。これらのバンドルは、output.pathオプションで指定されたディレクトリに書き込まれます。

単一のエントリポイントの場合、filenameは静的な名前になります。



chunkFilename: string

このオプションは、非エントリチャンクファイルの名前を決定します。

上記はfilenameとchunkFilenameの公式な説明です。



まず、入り口は何ですか?

現在、入力フィールドは提供されたアプリケーションの入力ファイルであることが理解できます。 (この説明は包括的ではありません)

次の試行を開始します。

ディレクトリ構造:

nodule_modules /

距離/

src /

--index.js

--a.js

webpack.config.js

ファイルwebpack.config.js

var path = require('path') module.exports = { mode: 'development', entry: './src/index.js', output: { path: path.resolve(__dirname, '../dist'), filename: '[name].[contenthash:6].js', chunkFilename: '[name].[contenthash:4].js' } }

上記の構成では、アプリケーション全体のエントリはファイル/src/index.jsです。

ファイルsrc / index.js

import('./a.js') console.log('index')

ファイルsrc / a.js

console.log('a')

画像
パッケージ化後、index.jsに対応するmain.conenthash.jsは6ビットであり、a.jsに対応する1.contenthash.jsは4ビットであることがわかります。

これは私たちが期待したのと同じ結果です。 Filenameはエントリファイルのファイル名を設定し、chunkFilenameは非エントリファイルのファイル名を設定します。動的にロードされるファイルa.jsはエントリファイルではありません。

webpackによってパッケージ化されたファイルは3つのモジュールに分割されていることがわかっています。 1つはサードパーティのライブラリです。この部分は比較的安定しており、キャッシュを容易にするために一緒にパッケージ化できます。 1つはビジネスコードで、基本的にバージョンがリリースされるたびに変更されます。最後の1つは、webpackによって生成されるランタイムとマニフェストであり、パックするたびに変更されます。

現在、コードには独自のビジネスコードのみが含まれており、サードパーティのライブラリコードはありません。それでも、webpackを分離してランタイムとマニフェストを生成できます。

次のように構成を変更します。

var path = require('path') module.exports = { mode: 'development', entry: './src/index.js', output: { path: path.resolve(__dirname, '../dist'), filename: '[name].[contenthash:6].js', chunkFilename: '[name].[contenthash:4].js' }, optimization: { runtimeChunk: { name: 'manifest' } } }

画像

エントリによって生成されたmain.jsファイルのハッシュが4桁になっていることがわかりますが、エントリはアプリケーションのエントリファイルを明確に指定しています。対応するファイル名の構成はファイル名であり、対応するハッシュの数字は6桁である必要があります。 。

しかし実際には4ビットです。

そして、新しく分離されたmanifest.jsのハッシュが6ビットであることがわかります。

これは実際には、webpackパッケージアプリケーションのエントリが入力フィールドによって提供されたファイルではないことを示しています。アプリケーションのエントリは、webpack自体によって生成されたランタイムです。コードとサードパーティライブラリが正常に編成および実行されるのは、ランタイム+マニフェストを通じてです。

したがって、webpackによってパッケージ化されたアプリケーションの入り口は、ランタイム+マニフェストによって生成されます。

マニフェストが抽出されていない場合、エントリによって生成された対応するmain.jsのハッシュ番号は正しいです。マニフェストとランタイムがmainとjsから分離されていないため、この場合、参照エントリ全体がmain.jsであるため、これは実際には単なる偶然です。したがって、エントリファイルはmain.jsに対応し、ファイル名の設定はmain.jsに正しく適用されます。

上記の分析から、マニフェスト+ランタイムをHTMLファイルにインライン化すると、エントリjsファイルが生成されないため、6ビットのハッシュファイルは生成されないことが推測できます。構成ファイルを次のように変更します。

var path = require('path') var HtmlWebpackPlugin = require('html-webpack-plugin') var ScriptExtHtmlWebpackPlugin = require('script-ext-html-webpack-plugin') module.exports = { mode: 'development', entry: './src/index.js', output: { path: path.resolve(__dirname, './dist'), filename: '[name].[contenthash:6].js', chunkFilename: '[name].[contenthash:4].js' }, optimization: { runtimeChunk: { name: 'manifest', }, }, plugins: [ new HtmlWebpackPlugin({ template: './src/index.html' }), new ScriptExtHtmlWebpackPlugin({ inline: /manifest..*.js$/ }) ] }

画像
上の図から、実際には6桁のハッシュファイルが生成されていないことがわかります。

総括する:

output.filenameはアプリケーションエントリファイルの名前を指定し、output.entryはwebpackによってパッケージ化されたエントリを提供します。特定の状況下では、これら2つの入り口は統合されています。

webpackによってパッケージ化されたアプリケーションの入り口は、webpackによって生成されたマニフェスト+ランタイムです。マニフェストとランタイムの分離がない場合、この部分の生成されたコンテンツは入力フィールドによって提供されます

  1. 出力
  2. マニフェスト