深入理解 webpack 檔案打包機制

發表於2018-01-15

前言

最近在重拾 webpack 一些知識點,希望對前端模組化有更多的理解,以前對 webpack 打包機制有所好奇,沒有理解深入,淺嘗則止,最近通過對 webpack 打包後的檔案進行查閱,對其如何打包 JS 檔案有了更深的理解,希望通過這篇文章,能夠幫助讀者你理解:

  1. webpack 單檔案如何進行打包?
  2. webpack 多檔案如何進行程式碼切割?
  3. webpack1 和 webpack2 在檔案打包上有什麼區別?
  4. webpack2 如何做到 tree shaking?
  5. webpack3 如何做到 scope hoisting?

本文所有示例程式碼全部放在我的 Github 上,看興趣的可以看看:

webpack 單檔案如何打包?

首先現在 webpack 作為當前主流的前端模組化工具,在 webpack 剛開始流行的時候,我們經常通過 webpack 將所有處理檔案全部打包成一個 bundle 檔案, 先通過一個簡單的例子來看:

通過 npm run build:single 可看到打包效果,打包內容大致如下(經過精簡):

將相對無關的程式碼剔除掉後,剩下主要的程式碼:

  1. 首先 webpack 將所有模組(可以簡單理解成檔案)包裹於一個函式中,並傳入預設引數,這裡有三個檔案再加上一個入口模組一共四個模組,將它們放入一個陣列中,取名為 modules,並通過陣列的下標來作為 moduleId。
  2. 將 modules 傳入一個自執行函式中,自執行函式中包含一個 installedModules 已經載入過的模組和一個模組載入函式,最後載入入口模組並返回。
  3. __webpack_require__ 模組載入,先判斷 installedModules 是否已載入,載入過了就直接返回 exports 資料,沒有載入過該模組就通過 modules[moduleId].call(module.exports, module, module.exports, __webpack_require__) 執行模組並且將 module.exports 給返回。

很簡單是不是,有些點需要注意的是:

  1. 每個模組 webpack 只會載入一次,所以重複載入的模組只會執行一次,載入過的模組會放到 installedModules,下次需要需要該模組的值就直接從裡面拿了。
  2. 模組的 id 直接通過陣列下標去一一對應的,這樣能保證簡單且唯一,通過其它方式比如檔名或檔案路徑的方式就比較麻煩,因為檔名可能出現重名,不唯一,檔案路徑則會增大檔案體積,並且將路徑暴露給前端,不夠安全。
  3. modules[moduleId].call(module.exports, module, module.exports, __webpack_require__) 保證了模組載入時 this 的指向 module.exports 並且傳入預設引數,很簡單,不過多解釋。

webpack 多檔案如何進行程式碼切割?

webpack 單檔案打包的方式應付一些簡單場景就足夠了,但是我們在開發一些複雜的應用,如果沒有對程式碼進行切割,將第三方庫(jQuery)或框架(React) 和業務程式碼全部打包在一起,就會導致使用者訪問頁面速度很慢,不能有效利用快取,你的老闆可能就要找你談話了。

那麼 webpack 多檔案入口如何進行程式碼切割,讓我先寫一個簡單的例子:

這裡我們定義了兩個入口 pageA 和 pageB 和三個庫 util,我們希望程式碼切割做到:

  1. 因為兩入口都是用到了 utilB,我們希望把它抽離成單獨檔案,並且當使用者訪問 pageA 和 pageB 的時候都能去載入 utilB 這個公共模組,而不是存在於各自的入口檔案中。
  2. pageB 中 utilC 不是頁面一開始載入時候就需要的內容,假如 utilC 很大,我們不希望頁面載入時就直接載入 utilC,而是當使用者達到某種條件(如:點選按鈕)才去非同步載入 utilC,這時候我們需要將 utilC 抽離成單獨檔案,當使用者需要的時候再去載入該檔案。

那麼 webpack 需要怎麼配置呢?

單單配置多 entry 是不夠的,這樣只會生成兩個 bundle 檔案,將 pageA 和 pageB 所需要的內容全部放入,跟單入口檔案並沒有區別,要做到程式碼切割,我們需要藉助 webpack 內建的外掛 CommonsChunkPlugin。

首先 webpack 執行存在一部分執行時程式碼,即一部分初始化的工作,就像之前單檔案中的 __webpack_require__,這部分程式碼需要載入於所有檔案之前,相當於初始化工作,少了這部分初始化程式碼,後面載入過來的程式碼就無法識別並工作了。

這段程式碼的含義是,在這些入口檔案中,找到那些引用兩次的模組(如:utilB),幫我抽離成一個叫 vendor 檔案,此時那部分初始化工作的程式碼會被抽離到 vendor 檔案中。

這段程式碼的含義是在 vendor 檔案中幫我把初始化程式碼抽離到 mainifest 檔案中,此時 vendor 檔案中就只剩下 utilB 這個模組了。你可能會好奇為什麼要這麼做?

因為這樣可以給 vendor 生成穩定的 hash 值,每次修改業務程式碼(pageA),這段初始化時程式碼就會發生變化,那麼如果將這段初始化程式碼放在 vendor 檔案中的話,每次都會生成新的 vendor.xxxx.js,這樣不利於持久化快取,如果不理解也沒關係,下次我會另外寫一篇文章來講述這部分內容。

另外 webpack 預設會抽離非同步載入的程式碼,這個不需要你做額外的配置,pageB 中非同步載入的 utilC 檔案會直接抽離為 chunk.xxxx.js 檔案。

所以這時候我們頁面載入檔案的順序就會變成:

執行 npm run build:multiple 即可檢視打包內容,首先來看下 manifest 如何做初始化工作(精簡版)?

與單檔案內容一致,定義了一個自執行函式,因為它不包含任何模組,所以傳入一個空陣列。除了定義了 __webpack_require__,還另外定義了兩個函式用來進行載入模組。

首先講解程式碼前需要理解兩個概念,分別是 module 和 chunk

  1. chunk 代表生成後 js 檔案,一個 chunkId 對應一個打包好的 js 檔案(一共五個),從這段程式碼可以看出,manifest 的 chunkId 為 4,並且從程式碼中還可以看到:0-3 分別對應 pageA, pageB, 非同步 utilC, vendor 公共模組檔案,這也就是我們為什麼不能將這段程式碼放在 vendor 的原因,因為檔案的 hash 值會變。內容變了,vendor 生成的 hash 值也就變了。
  2. module 對應著模組,可以簡單理解為打包前每個 js 檔案對應一個模組,也就是之前 __webpack_require__ 載入的模組,同樣的使用陣列下標作為 moduleId 且是唯一不重複的。

那麼為什麼要區分 chunk 和 module 呢?

首先使用 installedChunks 來儲存每個 chunkId 是否被載入過,如果被載入過,則說明該 chunk 中所包含的模組已經被放到了 modules 中,注意是 modules 而不是 installedModules。我們先來簡單看一下 vendor chunk 打包出來的內容。

在執行完 manifest 後就會先執行 vendor 檔案,結合上面 webpackJsonp 的定義,我們可以知道 [3, 4] 代表 chunkId,當載入到 vendor 檔案後,installedChunks[3] 和 installedChunks[4] 將會被置為 0,這表明 chunk3,chunk4 已經被載入過了。

webpackJsonpCallback 一共有兩個引數,chuckIds 一般包含該 chunk 檔案依賴的 chunkId 以及自身 chunkId,moreModules 代表該 chunk 檔案帶來新的模組。

簡單說說 webpackJsonpCallback 做了哪些事,首先判斷 chunkIds 在 installedChunks 裡有沒有回撥函式函式未執行完,有的話則放到 callbacks 裡,並且等下統一執行,並將 chunkIds 在 installedChunks 中全部置為 0, 然後將 moreModules 合併到 modules。

這裡面只有 modules[0] 是不固定的,其它 modules 下標都是唯一的,在打包的時候 webpack 已經為它們統一編號,而 0 則為入口檔案即 pageA,pageB 各有一個 module[0]。

然後將 callbacks 執行並清空,保證了該模組載入開始前所以前置依賴內容已經載入完畢,最後判斷 moreModules[0], 有值說明該檔案為入口檔案,則開始執行入口模組 0。

上面解釋了一大堆,但是像 pageA 這種同步載入 manifest, vendor 以及 pageA 檔案來說,每次載入的時候 callbacks 都是為空的,因為它們在 installedChunks 中的值要嘛為 undefined(未載入), 要嘛為 0(已被載入)。installedChunks[chunkId] 的值永遠為 false,所以在這種情況下 callbacks 里根本不會出現函式,如果僅僅是考慮這樣的場景,上面的 webpackJsonpCallback 完全可以寫成下面這樣:

但是考慮到非同步載入 js 檔案的時候(比如 pageB 非同步載入 utilC 檔案),就沒那麼簡單,我們先來看下 webpack 是如何載入非同步指令碼的:

大致分為三種情況,(已經載入過,正在載入中以及從未載入過)

  1. 已經載入過該 chunk 檔案,那就不用再重新載入該 chunk 了,直接執行回撥函式即可,可以理解為假如頁面有兩種操作需要載入載入非同步指令碼,但是兩個指令碼都依賴於公共模組,那麼第二次載入的時候發現之前第一次操作已經載入過了該 chunk,則不用再去獲取非同步指令碼了,因為該公共模組已經被執行過了。
  2. 從未載入過,則動態地去插入 script 指令碼去請求 js 檔案,這也就為什麼取名 webpackJsonpCallback,因為跟 jsonp 的思想很類似,所以這種非同步載入指令碼在做指令碼錯誤監控時經常出現 Script error,具體原因可以檢視我之前寫的文章:前端程式碼異常監控實戰
  3. 正在載入中代表該 chunk 檔案已經在載入中了,比如說點選按鈕觸發非同步指令碼,使用者點太快了,連點兩次就可能出現這種情況,此時將回撥函式放入 installedChunks。

我們通過 utilC 生成的 chunk 來進行講解:

pageB 需要非同步載入這個 chunk:

當 pageB 進行某種操作需要載入 utilC 時就會執行 __webpack_require__.e(2, callback) 2,代表需要載入的模組 chunkId(utilC),非同步載入 utilC 並將 callback 新增到 installedChunks[2] 中,然後當 utilC 的 chunk 檔案載入完畢後,chunkIds 包含 2,發現 installedChunks[2] 是個陣列,裡面還有之前還未執行的 callback 函式。

既然這樣,那我就將我自己帶來的模組先放到 modules 中,然後再統一執行之前未執行完的 callbacks 函式,這裡指的是存放於 installedChunks[2] 中的回撥函式 (可能存在多個),這也就是說明這裡的先後順序:

webpack1 和 webpack2 在檔案打包上有什麼區別?

經過我對打包檔案的觀察,從 webpack1 到 webpack2 在打包檔案上有下面這些主要的改變:

首先,moduleId[0] 不再為入口執行函式做保留,所以說不用傻傻看到 moduleId[0] 就認為是打包檔案的入口模組,取而代之的是 window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules, executeModules) {} 傳入了第三個引數 executeModules,是個陣列,如果引數存在則說明它是入口模組,然後就去執行該模組。

其次,webpack2 中會預設載入 OccurrenceOrderPlugin 這個外掛,即你不用 plugins 中新增這個配置它也會預設執行,那它有什麼用途呢?主要是在 webpack1 中 moduleId 的不確定性導致的,在 webpack1 中 moduleId 取決於引入檔案的順序,這就會導致這個 moduleId 可能會時常發生變化, 而 OccurrenceOrderPlugin 外掛會按引入次數最多的模組進行排序,引入次數的模組的 moduleId 越小,比如說上面引用的 utilB 模組引用次數為 2(最多),所以它的 moduleId 為 0。

最後說下在非同步載入模組時, webpack2 是基於 Promise 的,所以說如果你要相容低版本瀏覽器,需要引入 Promise-polyfill,另外為引入請求新增了錯誤處理。

可以看出,原本基於回撥函式的方式已經變成基於 Promise 做非同步處理,另外新增了 onScriptComplete 用於做指令碼載入失敗處理。

在 webpack1 的時候,如果由於網路原因當你載入指令碼失敗後,即使網路恢復了,你再次進行某種操作需要同個 chunk 時候都會無效,主要原因是失敗之後沒把 installedChunks[chunkId] = undefined; 導致之後不會再對該 chunk 檔案發起非同步請求。

而在 webpack2 中,當指令碼請求超時了(2min)或者載入失敗,會將 installedChunks[chunkId] 清空,當下次重新請求該 chunk 檔案會重新載入,提高了頁面的容錯性。

這些是我在打包檔案中看到主要的區別,難免有所遺漏,如果你有更多的見解,歡迎在評論區留言。

webpack2 如何做到 tree shaking?

什麼是 tree shaking,即 webpack 在打包的過程中會將沒用的程式碼進行清除(dead code)。一般 dead code 具有一下的特徵:

  1. 程式碼不會被執行,不可到達
  2. 程式碼執行的結果不會被用到
  3. 程式碼只會影響死變數(只寫不讀)

是不是很神奇,那麼需要怎麼做才能使 tree shaking 生效呢?

首先,模組引入要基於 ES6 模組機制,不再使用 commonjs 規範,因為 es6 模組的依賴關係是確定的,和執行時的狀態無關,可以進行可靠的靜態分析,然後清除沒用的程式碼。而 commonjs 的依賴關係是要到執行時候才能確定下來的。

其次,需要開啟 UglifyJsPlugin 這個外掛對程式碼進行壓縮。

我們先寫一個例子來說明:

打包的配置也很簡單:

通過 npm run build:es6 對壓縮的檔案進行分析:

引入但是沒用的變數,函式都會清除,未執行的程式碼也會被清除。但是類方法是不會被清除的。因為 webpack 不會區分不了是定義在 classC 的 prototype 還是其它 Array 的 prototype 的,比如 classC 寫成下面這樣:

webpack 無法保證 prototype 掛載的物件是 classC,這種程式碼,靜態分析是分析不了的,就算能靜態分析程式碼,想要正確完全的分析也比較困難。所以 webpack 乾脆不處理類方法,不對類方法進行 tree shaking。

更多的 tree shaking 的副作用可以查閱:Tree shaking class methods

webpack3 如何做到 scope hoisting?

scope hoisting,顧名思義就是將模組的作用域提升,在 webpack 中不能將所有所有的模組直接放在同一個作用域下,有以下幾個原因:

  1. 按需載入的模組
  2. 使用 commonjs 規範的模組
  3. 被多 entry 共享的模組

在 webpack3 中,這些情況生成的模組不會進行作用域提升,下面我就舉個例子來說明:

這個例子比較典型,utilA 被 pageA 和 pageB 所共享,utilB 被 pageB 單獨載入,utilC 被 pageB 非同步載入。

想要 webpack3 生效,則需要在 plugins 中新增 ModuleConcatenationPlugin。

webpack 配置如下:

執行 npm run build:hoist 進行編譯,簡單看下生成的 pageB 程式碼:

通過程式碼分析,可以得出下面的結論:

  1. 因為我們配置了共享模組抽離,所以 utilA 被抽出為單獨模組,故這部分內容不會進行作用域提升。
  2. utilB 無牽無掛,被 pageB 單獨載入,所以這部分不會生成新的模組,而是直接作用域提升到 pageB 中。
  3. utilC 被非同步載入,需要抽離成單獨模組,很明顯沒辦法作用域提升。

結尾

好了,講到這差不多就完了,理解上面的內容對前端模組化會有更多的認知,如果有什麼寫的不對或者不完整的地方,還望補充說明,希望這篇文章能幫助到你。

相關文章