rollup打包引發對JS模塊循環引用思考

Posted on by

引言

最近在項目中使用瞭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模塊循環的資料請關註WalkonNet其它相關文章！

推薦閱讀：