rollup打包引發對JS模組迴圈參照思考

引言

最近在專案中使用了typescript + rollup，滿心歡喜測試打包結果的時候，發現打包出來的檔案竟然無法執行，具體報錯如下：

    throw new ERR_INVALID_ARG_TYPE('superCtor', 'Function', superCtor);
    ^
TypeError [ERR_INVALID_ARG_TYPE]: The "superCtor" argument must be of type function. Received undefined

乍一看這個錯誤非常抽象，在平時的開發中也很少會遇到，定位到錯誤行，發現是這樣的程式碼：

util$3.inherits(Duplex$1, _stream_readable);

這裡傳入的 _stream_readable 應該是undefined從而導致致報錯。

感覺可能是rollup設定的問題，於是去谷歌了一下，發現這其實是rollup的一個bug。在翻了github上幾個issue之後，終於弄清了報錯的原因。

為了講清楚問題，首先介紹一下問題發生的背景：

背景1

我們都知道rollup本身是不支援commonjs模組的，要想打包commonjs模組的程式碼，必須藉助@rollup/plugin-node-resolve和@rollup/plugin-commonjs這兩個外掛，並且在打包過程中會把cjs的模組轉成es modules。而cjs模組機制和esm模組機制在處理迴圈參照的時候，行為是不同的。

背景2

nodejs中的readable stream和duplex stream兩個模組之間產生了迴圈參照。具體來說就是Duplex（在_stream_duplex.js中定義）繼承了Readable（在_stream_readable.js中定義），但是在ReadableState（也在_stream_readable.js中定義）中做了和Duplex型別相關的檢查，因此在程式碼執行的過程中引入了_stream_duplex.js，構成了迴圈參照。

那麼cjs和esm在處理迴圈參照的時候到底有什麼區別呢，為什麼會最終導致錯誤呢？

又是一番研究，通過幾個demo終於理解了二者的區別，順便複習了兩個模組系統的基礎知識。

commonjs

一提起cjs，大家想到的就是它的靈活，因為它是在執行時載入的，模組的名字和路徑不僅可以是常數，也可以是表示式，這也是為什麼cjs模組不能使用treeshaking優化，因為要到js實際執行的時候才能知道到底引入了哪個模組。

第一次require模組之後，就會執行整個模組的指令碼，並把結果快取起來，後續引入這個模組的時候，直接讀取快取的結果。所以第一次匯入後，即使原模組發生了變化，再次匯入值也是不變的。

因此遇到迴圈參照的時候，cjs的這種讀取快取的方法雖然避免了無限迴圈，但也會導致一些不容易察覺的錯誤，比如：

//a.js
const bar = require("./b.js");function foo() {  bar();  console.log("執行完畢");}module.exports = foo
foo();
//b.js
const foo = require("./a.js")
function bar(){
  foo()
}
module.exports = bar

執行a.js會直接報錯TypeError: foo is not a function

a先載入b，然後b又載入a，這時a還沒有任何執行結果，所以輸出結果為null，即對於b.js來說，變數foo的值等於null，後面的foo()就會報錯。

如果你在a.js第一行就匯出foo，就可以避免這個問題，但是不推薦在實際程式碼中這樣寫，實在要用到迴圈參照，只要保證require的物件已被實際匯出就好了。

es modules

在esm模組載入機制中，import是靜態執行的，export是動態繫結的。也就是說，js引擎會對import語句進行提升，不管你import寫在哪，總是最先執行的，並遞迴載入所有匯入的模組，遇到載入過的模組直接跳過，是一個深度優先遍歷的過程。

而動態繫結指的是export匯出的介面，與其對應的值是動態繫結的，執行的時候從模組內部實時取值。

所以esm模組載入機制根本不關心是否出現了迴圈應用，只是生成一個指向被載入模組的參照，需要開發者自己保證，真正取值的時候能夠取到值。

如果不注意，esm中的迴圈參照也會導致一些令人困惑的結果，比如：

//foo.mjs
console.log('foo is running');import {bar} from './bar.mjs'console.log('bar = %j', bar);setTimeout(() => console.log('bar = %j after 500 ms', bar), 500);export var foo = false;console.log('foo is finished');

//bar.mjs
console.log('bar is running');import {foo} from './foo.mjs';console.log('foo = %j', foo)export var bar = false;setTimeout(() => bar = true, 500);console.log('bar is finished');

執行node foo.mjs結果如下

bar is running
foo = undefined
bar is finished
foo is running
bar = false
foo is finished
bar = true after 500 ms

可以看到bar.mjs中輸出了foo = undefined，但我們在foo.mjs確實匯出了foo。

為什麼會這樣呢，仔細看這一句export var foo = false，由於var存在變數提升，所以我們確實匯出了foo，但foo的值還未被初始化，因此在bar.mjs中foo的值為undefined。如果我們改成export let foo = false，那麼執行foo.mjs就會直接報錯：

ReferenceError: Cannot access 'foo' before initialization

這也提醒了我們使用let/const替代var，否則可能會出現難以預測的情況

總結

導致rollup打包問題的原因為：打包的過程中rollup將cjs模組轉換成esm，由於esm會跳過之前已載入過的模組，實際引入的變數變成了undefined，導致在最終生成的程式碼中存在undefined的變數。

這個問題至今尚未有效解決，涉及到大量commonjs模組時，建議使用webpack打包。

以上就是rollup打包引發的對JS模組迴圈參照的思考的詳細內容，更多關於rollup打包JS模組迴圈的資料請關注it145.com其它相關文章！