面試必備！webpack 中那些最易混淆的 5 個知識點
原文發表於個人簡陋博客javascript
前兩天爲了優化公司的代碼打包項目，惡補了不少 webpack4 的知識。要是放在幾年前讓我學習 webpack 我確定是拒絕的，以前看過 webpack 的舊文檔，比咱們內部項目的文檔還要簡陋。css
可是最近看了一下 webpack4 的文檔，發現 webpack官網的 指南 寫的還不錯，跟着這份指南學會 webpack4 基礎配置徹底不是問題，想系統學習 webpack 的朋友能夠看一下。html
今天我主要分享的是一些 webpack 中的易混淆知識點，也是面試的常見內容。我把這些分散在文檔和教程裏的內容總結起來，目前看是全網獨一份，你們能夠加個收藏，方便之後檢索和學習。java
<br/>webpack
友情提示：本文章不是入門教程，不會費大量筆墨去描寫 webpack 的基礎配置，請讀者配合教程 源代碼食用。
<br/>git
1.webpack 中，module，chunk 和 bundle 的區別是什麼？
說實話我剛開始看 webpack 文檔的時候，對這 3 個名詞雲裏霧裏的，感受他們都在說打包文件，可是一下子 chunk 一下子 bundle 的，逐漸就迷失在細節裏了，因此咱們要跳出來，從宏觀的角度來看這幾個名詞。github
webpack 官網對 chunk 和 bundle 作出了解釋，說實話太抽象了，我這裏舉個例子，給你們形象化的解釋一下。web
首先咱們在 src 目錄下寫咱們的業務代碼，引入 index.js、utils.js、common.js 和 index.css 這 4 個文件，目錄結構以下：面試
src/ ├── index.css ├── index.html # 這個是 HTML 模板代碼 ├── index.js ├── common.js └── utils.js
index.css 寫一點兒簡單的樣式：json
body {
background-color: red;
}
utils.js 文件寫個求平方的工具函數：
export function square(x) {
return x * x;
}
common.js 文件寫個 log 工具函數：
module.exports = {
log: (msg) => {
console.log('hello ', msg)
}
}
index.js 文件作一些簡單的修改，引入 css 文件和 common.js：
import './index.css';
const { log } = require('./common');
log('webpack');
webpack 的配置以下：
{
entry: {
index: "../src/index.js",
utils: '../src/utils.js',
},
output: {
filename: "[name].bundle.js", // 輸出 index.js 和 utils.js
},
module: {
rules: [
{
test: /\.css$/,
use: [
MiniCssExtractPlugin.loader, // 建立一個 link 標籤
'css-loader', // css-loader 負責解析 CSS 代碼, 處理 CSS 中的依賴
],
},
]
}
plugins: [
// 用 MiniCssExtractPlugin 抽離出 css 文件，以 link 標籤的形式引入樣式文件
new MiniCssExtractPlugin({
filename: 'index.bundle.css' // 輸出的 css 文件名爲 index.css
}),
]
}
咱們運行一下 webpack，看一下打包的結果：
咱們能夠看出，index.css 和 common.js 在 index.js 中被引入，打包生成的 index.bundle.css 和 index.bundle.js 都屬於 chunk 0，utils.js 由於是獨立打包的，它生成的 utils.bundle.js 屬於 chunk 1。
感受還有些繞？我作了一張圖，你確定一看就懂：
看這個圖就很明白了：
- 對於一份同邏輯的代碼，當咱們手寫下一個一個的文件，它們不管是 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。
<br/>
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 中，卻又須要被打包出來的文件的名稱。
<br/>
3.webpackPrefetch、webpackPreload 和 webpackChunkName 究竟是幹什麼的？
這幾個名詞其實都是 webpack 魔法註釋（magic comments）裏的，文檔中說了 6 個配置，配置均可以組合起來用。咱們說說最經常使用的三個配置。
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），二者有些細微的不一樣，咱們先說說 webpackPreload。
在上面的懶加載代碼裏，咱們是點擊按鈕時，纔會觸發異步加載 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 加載時並行下載文件。
<br/>
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 計算與文件內容自己相關。
<br/>
5.sourse-map 中 eval、cheap、inline 和 module 各是什麼意思？
sourse-map ，裏面都有個 map 了，確定是映射的意思。sourse-map 就是一份源碼和轉換後代碼的映射文件。具體的原理內容較多，感興趣的同窗能夠自行搜索，我這裏就很少言了。
咱們先從官網上看看 sourse-map 有多少種類型：
emmmm，13 種，告辭。
若是再仔細看一下，就發現這 13 種大部分都是 eval、cheap、inline 和 module這 4 個詞排列組合的，我作了個簡單的表格，比官網上直白多了：
| 參數 | 參數解釋 |
|---|---|
| eval | 打包後的模塊都使用 eval() 執行，行映射可能不許；不產生獨立的 map 文件 |
| cheap | map 映射只顯示行不顯示列，忽略源自 loader 的 source map |
| inline | 映射文件以 base64 格式編碼，加在 bundle 文件最後，不產生獨立的 map 文件 |
| module | 增長對 loader source map 和第三方模塊的映射 |
還不明白？能夠看看 demo。
咱們對 webpack 作一些配置，devtool 是專門配置 source-map 的。
......
{
devtool: 'source-map',
}
......
index.js 文件爲了簡便，咱們只寫一行代碼，爲了得出報錯信息，咱們故意拼錯：
console.lg('hello source-map !') // log 寫成 lg
下面咱們試一試常見的幾個配置：
source-map
source-map 是最大而全的，會生成獨立 map 文件：
注意下圖光標的位置，source-map 會顯示報錯的行列信息：
cheap-sourse-map
cheap，就是廉價的意思，它不會產生列映射，相應的體積會小不少，咱們和 sourse-map 的打包結果比一下，只有原來的 1/4 。
eval-source-map
eval-source-map 會以 eval() 函數打包運行模塊，不產生獨立的 map 文件，會顯示報錯的行列信息：
// index.bundle.js 文件
!function(e) {
// ......
// 省略不重要的代碼
// ......
}([function(module, exports) {
eval("console.lg('hello source-map !');//# sourceURL=[module]\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vLi4vc3JjL2luZGV4Mi5qcz9mNmJjIl0sIm5hbWVzIjpbImNvbnNvbGUiLCJsZyJdLCJtYXBwaW5ncyI6IkFBQUFBLE9BQU8sQ0FBQ0MsRUFBUixDQUFXLG9CQUFYIiwiZmlsZSI6IjAuanMiLCJzb3VyY2VzQ29udGVudCI6WyJjb25zb2xlLmxnKCdoZWxsbyBzb3VyY2UtbWFwICEnKSJdLCJzb3VyY2VSb290IjoiIn0=\n//# sourceURL=webpack-internal:///0\n")
}
]);
inline-source-map
映射文件以 base64 格式編碼，加在 bundle 文件最後，不產生獨立的 map 文件。加入 map 文件後，咱們能夠明顯的看到包體積變大了；
// index.bundle.js 文件
!function(e) {
}([function(e, t) {
console.lg("hello source-map !")
}
]);
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vd2VicGFjay9ib290c3RyYXAiLCJ3ZWJwYWNrOi8vLy4uL3NyYy9pbmRleDIuanMiXSwibmFtZXMiOlsiaW5zdGFsbGVkTW9kdWxlcyIsIl9fd2VicGFja19yZXF1aXJ......
// base64 太長了，我刪了一部分，領會精神
經常使用配置：
上面的幾個例子都是演示，結合官網推薦)和實際經驗，經常使用的配置實際上是這幾個：
1.source-map
大而全，啥都有，就由於啥都有可能會讓 webpack 構建時間變長，看狀況使用。
2.cheap-module-eval-source-map
這個通常是開發環境（dev）推薦使用，在構建速度報錯提醒上作了比較好的均衡。
3.cheap-module-source-map
通常來講，生產環境是不配 source-map 的，若是想捕捉線上的代碼報錯，咱們能夠用這個
寫在最後
這篇文章差很少就寫到這裏了，後面我還會寫一些 webapck 打包優化的文章。
從學習 webpack 到這篇輸出差很少花了 2 個星期的時間，我的感受 webpack 說到底，也就是工具鏈的一環，不少配置內容不必像 JavaScript 的內置方法同樣須要記憶，本身寫個大而全的 demo，知道配置項大概能幹個啥，要用的時候查一下就好了。
所以我總結了這篇 webpack 易混淆知識點的文章，你們能夠點擊收藏一下，之後準備面試或者複習的時候，看一下就懂個大概了。
最後打個廣告，業餘寫一些數據可視化科普向的文章，目前一週一篇，內容非技術向，比較輕鬆，公衆號 ID 是 sky-chx，你們感興趣的話能夠關注一波。
- 1. 面試必備！webpack 中那些最易混淆的 5 個知識點
- 2. webpack 中那些最易混淆的 5 個知識點
- 3. php易混淆知識點
- 4. 【PMP】易混淆知識點
- 5. java中易混淆的知識點
- 6. [C# 基礎知識系列]C#中易混淆的知識點
- 7. c++容易混淆知識點
- 8. PMP易混淆知識點彙總
- 9. 雜記（那些我還容易混淆的c和c++知識）
- 10. 容易混淆的jquery知識點
- 更多相關文章...
- • 與傳輸層有關的基本知識 - TCP/IP教程
- • Spring中Bean的作用域 - Spring教程
- • JDK13 GA發佈：5大特性解讀
- • C# 中 foreach 遍歷的用法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 面試必備！webpack 中那些最易混淆的 5 個知識點
- 2. webpack 中那些最易混淆的 5 個知識點
- 3. php易混淆知識點
- 4. 【PMP】易混淆知識點
- 5. java中易混淆的知識點
- 6. [C# 基礎知識系列]C#中易混淆的知識點
- 7. c++容易混淆知識點
- 8. PMP易混淆知識點彙總
- 9. 雜記（那些我還容易混淆的c和c++知識）
- 10. 容易混淆的jquery知識點