webpack中有幾個比較難懂的變量名稱,可能對剛開始學習的人不是很友好,所以今天小鄒就整理了一下,主要是做一個總結性的概括。

1.webpack 中,module,chunk 和 bundle 的區別是什么?
首先我們來看一張圖:

看這個圖就很明白了:
- 對於一份同邏輯的代碼,當我們手寫了一個個的文件,它們無論是 ESM 還是 commonJS 或是 AMD,他們都是 module;
- 當我們寫的 module 源文件傳到 webpack 進行打包時,webpack 會根據文件引用關系生成 chunk 文件,webpack 會對這個 chunk 文件進行一些操作;
- webpack 處理好 chunk 文件后,最后會輸出 bundle 文件,這個 bundle 文件包含了經過加載和編譯的最終源文件,所以它可以直接在瀏覽器中運行。
一般來說一個 chunk 對應一個 bundle,比如上圖中的 utils.js -> chunks 1 -> utils.bundle.js;但也有例外,比如說上圖中,我就用 MiniCssExtractPlugin 從 chunks 0 中抽離出了 index.bundle.css 文件。
一句話總結:
module,chunk 和 bundle 其實就是同一份邏輯代碼在不同轉換場景下的取了三個名字:我們直接寫出來的是 module,webpack 處理時是 chunk,最后生成瀏覽器可以直接運行的 bundle。
2.filename 和 chunkFilename 的區別
filename
filename 是一個很常見的配置,就是對應於 entry 里面的輸入文件,經過webpack 打包后輸出文件的文件名。比如說經過下面的配置,生成出來的文件名為 index.min.js。
{
entry: {
index: "../src/index.js"
},
output: {
filename: "[name].min.js", // index.min.js
}
}

chunkFilename
chunkFilename 指未被列在 entry 中,卻又需要被打包出來的 chunk 文件的名稱。一般來說,這個 chunk 文件指的就是要懶加載的代碼。
比如說我們業務代碼中寫了一份懶加載 lodash 的代碼:
// 文件:index.js
// 創建一個 button
let btn = document.createElement("button");
btn.innerHTML = "click me";
document.body.appendChild(btn);
// 異步加載代碼
async function getAsyncComponent() {
var element = document.createElement('div');
const { default: _ } = await import('lodash');
element.innerHTML = _.join(['Hello!', 'dynamic', 'imports', 'async'], ' ');
return element;
}
// 點擊 button 時,懶加載 lodash,在網頁上顯示 Hello! dynamic imports async
btn.addEventListener('click', () => {
getAsyncComponent().then(component => {
document.body.appendChild(component);
})
})
我們的 webpack 不做任何配置,還是原來的配置代碼:
{
entry: {
index: "../src/index.js"
},
output: {
filename: "[name].min.js", // index.min.js
}
}
這時候的打包結果如下:

這個 1.min.js 就是異步加載的 chunk 文件。文檔里這么解釋:
output.chunkFilename 默認使用 [id].js 或從 output.filename 中推斷出的值([name] 會被預先替換為 [id] 或 [id].)
文檔寫的太抽象,我們不如結合上面的例子來看:
output.filename 的輸出文件名是 [name].min.js,[name] 根據 entry 的配置推斷為 index,所以輸出為 index.min.js;
由於 output.chunkFilename 沒有顯示指定,就會把 [name] 替換為 chunk 文件的 id 號,這里文件的 id 號是 1,所以文件名就是 1.min.js。
如果我們顯式配置 chunkFilename,就會按配置的名字生成文件:
{
entry: {
index: "../src/index.js"
},
output: {
filename: "[name].min.js", // index.min.js
chunkFilename: 'bundle.js', // bundle.js
}
}

一句話總結:
filename 指列在 entry 中,打包后輸出的文件的名稱。
chunkFilename 指未列在 entry 中,卻又需要被打包出來的文件的名稱。
3.webpackPrefetch、webpackPreload 和 webpackChunkName 到底是干什么的?
webpackChunkName
前面舉了個異步加載 lodash 的例子,我們最后把 output.chunkFilename 寫死成 bundle.js。在我們的業務代碼中,不可能只異步加載一個文件,所以寫死肯定是不行的,但是寫成 [name].bundle.js 時,打包的文件又是意義不明、辨識度不高的 chunk id。
{
entry: {
index: "../src/index.js"
},
output: {
filename: "[name].min.js", // index.min.js
chunkFilename: '[name].bundle.js', // 1.bundle.js,chunk id 為 1,辨識度不高
}
}

這時候 webpackChunkName 就可以派上用場了。我們可以在 import 文件時,在 import 里以注釋的形式為 chunk 文件取別名:
async function getAsyncComponent() {
var element = document.createElement('div');
// 在 import 的括號里 加注釋 /* webpackChunkName: "lodash" */ ,為引入的文件取別名
const { default: _ } = await import(/* webpackChunkName: "lodash" */ 'lodash');
element.innerHTML = _.join(['Hello!', 'dynamic', 'imports', 'async'], ' ');
return element;
}
這時候打包生成的文件是這樣的:

現在問題來了,lodash 是我們取的名字,按道理來說應該生成 lodash.bundle.js 啊,前面的 vendors~ 是什么玩意?
其實 webpack 懶加載是用內置的一個插件 SplitChunksPlugin 實現的,這個插件里面有些默認配置項,比如說 automaticNameDelimiter,默認的分割符就是 ~,所以最后的文件名才會出現這個符號,這塊兒內容我就不引申了,感興趣的同學可以自己研究一下。
webpackPrefetch 和 webpackPreload
這兩個配置一個叫預拉取(Prefetch),一個叫預加載(Preload),兩者有些細微的不同,我們先說說 webpackPrefetch。
在上面的懶加載代碼里,我們是點擊按鈕時,才會觸發異步加載 lodash 的動作,這時候會動態的生成一個 script 標簽,加載到 head 頭里:

如果我們 import 的時候添加 webpackPrefetch:
const { default: _ } = await import(/* webpackChunkName: "lodash" */ /* webpackPrefetch: true */ 'lodash');
就會以 <link rel="prefetch" as="script"> 的形式預拉取 lodash 代碼:

這個異步加載的代碼不需要手動點擊 button 觸發,webpack 會在父 chunk 完成加載后,閑時加載 lodash 文件。
webpackPreload 是預加載當前導航下可能需要資源,他和 webpackPrefetch 的主要區別是:
- preload chunk 會在父 chunk 加載時,以並行方式開始加載。prefetch chunk 會在父 chunk 加載結束后開始加載。
- preload chunk 具有中等優先級,並立即下載。prefetch chunk 在瀏覽器閑置時下載。
- preload chunk 會在父 chunk 中立即請求,用於當下時刻。prefetch chunk 會用於未來的某個時刻
一句話總結:
webpackChunkName 是為預加載的文件取別名,webpackPrefetch 會在瀏覽器閑置下載文件,webpackPreload 會在父 chunk 加載時並行下載文件。
4.hash、chunkhash、contenthash 有什么不同?
首先來個背景介紹,哈希一般是結合 CDN 緩存來使用的。如果文件內容改變的話,那么對應文件哈希值也會改變,對應的 HTML 引用的 URL 地址也會改變,觸發 CDN 服務器從源服務器上拉取對應數據,進而更新本地緩存。
hash
hash 計算是跟整個項目的構建相關,我們做一個簡單的 demo。
沿用案例 1 的 demo 代碼,文件目錄如下:
src/
├── index.css
├── index.html
├── index.js
└── utils.js
webpack 的核心配置如下(省略了一些 module 配置信息):
{
entry: {
index: "../src/index.js",
utils: '../src/utils.js',
},
output: {
filename: "[name].[hash].js", // 改為 hash
},
......
plugins: [
new MiniCssExtractPlugin({
filename: 'index.[hash].css' // 改為 hash
}),
]
}
生成的文件名如下:

我們可以發現,生成文件的 hash 和項目的構建 hash 都是一模一樣的。
chunkhash
因為 hash 是項目構建的哈希值,項目中如果有些變動,hash 一定會變,比如說我改動了 utils.js 的代碼,index.js 里的代碼雖然沒有改變,但是大家都是用的同一份 hash。hash 一變,緩存一定失效了,這樣子是沒辦法實現 CDN 和瀏覽器緩存的。
chunkhash 就是解決這個問題的,它根據不同的入口文件(Entry)進行依賴文件解析、構建對應的 chunk,生成對應的哈希值。
我們再舉個例子,我們對 utils.js 里文件進行改動:
export function square(x) {
return x * x;
}
// 增加 cube() 求立方函數
export function cube(x) {
return x * x * x;
}
然后把 webpack 里的所有 hash 改為 chunkhash:
{
entry: {
index: "../src/index.js",
utils: '../src/utils.js',
},
output: {
filename: "[name].[chunkhash].js", // 改為 chunkhash
},
......
plugins: [
new MiniCssExtractPlugin({
filename: 'index.[chunkhash].css' // // 改為 chunkhash
}),
]
}
構建結果如下:

我們可以看出,chunk 0 的 hash 都是一樣的,chunk 1 的 hash 和上面的不一樣。
假設我又把 utils.js 里的 cube() 函數去掉,再打包:

對比可以發現,只有 chunk 1 的 hash 發生變化,chunk 0 的 hash 還是原來的。
contenthash
我們更近一步,index.js 和 index.css 同為一個 chunk,如果 index.js 內容發生變化,但是 index.css 沒有變化,打包后他們的 hash 都發生變化,這對 css 文件來說是一種浪費。如何解決這個問題呢?
contenthash 將根據資源內容創建出唯一 hash,也就是說文件內容不變,hash 就不變。
我們修改一下 webpack 的配置:
{
entry: {
index: "../src/index.js",
utils: '../src/utils.js',
},
output: {
filename: "[name].[chunkhash].js",
},
......
plugins: [
new MiniCssExtractPlugin({
filename: 'index.[contenthash].css' // 這里改為 contenthash
}),
]
}
我們對 index.js 文件做了 3 次修改(就是改了改 log 函數的輸出內容,過於簡單就先不寫了),然后分別構建,結果截圖如下:



我們可以發現,css 文件的 hash 都沒有發生改變。
一句話總結:
hash 計算與整個項目的構建相關;
chunkhash 計算與同一 chunk 內容相關;
contenthash 計算與文件內容本身相關。
5.sourse-map 中 eval、cheap、inline 和 module 各是什么意思?
開發常用配置:
1.source-map
大而全,啥都有,就因為啥都有可能會讓 webpack 構建時間變長,看情況使用。
2.cheap-module-eval-source-map
這個一般是開發環境(dev)推薦使用,在構建速度報錯提醒上做了比較好的均衡。
3.cheap-module-source-map
一般來說,生產環境是不配 source-map 的,如果想捕捉線上的代碼報錯,我們可以用這個。