引言

最近在項(xiàng)目中使用了typescript + rollup，滿心歡喜測試打包結(jié)果的時(shí)候，發(fā)現(xiàn)打包出來的文件竟然無法運(yùn)行，具體報(bào)錯(cuò)如下：

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

乍一看這個(gè)錯(cuò)誤非常抽象，在平時(shí)的開發(fā)中也很少會遇到，定位到錯(cuò)誤行，發(fā)現(xiàn)是這樣的代碼：

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

這里傳入的 _stream_readable 應(yīng)該是undefined從而導(dǎo)致致報(bào)錯(cuò)。

感覺可能是rollup配置的問題，于是去谷歌了一下，發(fā)現(xiàn)這其實(shí)是rollup的一個(gè)bug。在翻了github上幾個(gè)issue之后，終于弄清了報(bào)錯(cuò)的原因。

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

背景1

我們都知道rollup本身是不支持commonjs模塊的，要想打包c(diǎn)ommonjs模塊的代碼，必須借助@rollup/plugin-node-resolve和@rollup/plugin-commonjs這兩個(gè)插件，并且在打包過程中會把cjs的模塊轉(zhuǎn)成es modules。而cjs模塊機(jī)制和esm模塊機(jī)制在處理循環(huán)引用的時(shí)候，行為是不同的。

背景2

nodejs中的readable stream和duplex stream兩個(gè)模塊之間產(chǎn)生了循環(huán)引用。具體來說就是Duplex（在_stream_duplex.js中定義）繼承了Readable（在_stream_readable.js中定義），但是在ReadableState（也在_stream_readable.js中定義）中做了和Duplex類型相關(guān)的檢查，因此在代碼執(zhí)行的過程中引入了_stream_duplex.js，構(gòu)成了循環(huán)引用。

那么cjs和esm在處理循環(huán)引用的時(shí)候到底有什么區(qū)別呢，為什么會最終導(dǎo)致錯(cuò)誤呢？

又是一番研究，通過幾個(gè)demo終于理解了二者的區(qū)別，順便復(fù)習(xí)了兩個(gè)模塊系統(tǒng)的基礎(chǔ)知識。

commonjs

一提起cjs，大家想到的就是它的靈活，因?yàn)樗窃趫?zhí)行時(shí)加載的，模塊的名字和路徑不僅可以是常量，也可以是表達(dá)式，這也是為什么cjs模塊不能使用treeshaking優(yōu)化，因?yàn)橐絡(luò)s實(shí)際執(zhí)行的時(shí)候才能知道到底引入了哪個(gè)模塊。

第一次require模塊之后，就會執(zhí)行整個(gè)模塊的腳本，并把結(jié)果緩存起來，后續(xù)引入這個(gè)模塊的時(shí)候，直接讀取緩存的結(jié)果。所以第一次導(dǎo)入后，即使原模塊發(fā)生了變化，再次導(dǎo)入值也是不變的。

因此遇到循環(huán)引用的時(shí)候，cjs的這種讀取緩存的方法雖然避免了無限循環(huán)，但也會導(dǎo)致一些不容易察覺的錯(cuò)誤，比如：

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

執(zhí)行a.js會直接報(bào)錯(cuò)TypeError: foo is not a function

a先加載b，然后b又加載a，這時(shí)a還沒有任何執(zhí)行結(jié)果，所以輸出結(jié)果為null，即對于b.js來說，變量foo的值等于null，后面的foo()就會報(bào)錯(cuò)。

如果你在a.js第一行就導(dǎo)出foo，就可以避免這個(gè)問題，但是不推薦在實(shí)際代碼中這樣寫，實(shí)在要用到循環(huán)引用，只要保證require的對象已被實(shí)際導(dǎo)出就好了。

es modules

在esm模塊加載機(jī)制中，import是靜態(tài)執(zhí)行的，export是動(dòng)態(tài)綁定的。也就是說，js引擎會對import語句進(jìn)行提升，不管你import寫在哪，總是最先執(zhí)行的，并遞歸加載所有導(dǎo)入的模塊，遇到加載過的模塊直接跳過，是一個(gè)深度優(yōu)先遍歷的過程。

而動(dòng)態(tài)綁定指的是export導(dǎo)出的接口，與其對應(yīng)的值是動(dòng)態(tài)綁定的，運(yùn)行的時(shí)候從模塊內(nèi)部實(shí)時(shí)取值。

所以esm模塊加載機(jī)制根本不關(guān)心是否出現(xiàn)了循環(huán)應(yīng)用，只是生成一個(gè)指向被加載模塊的引用，需要開發(fā)者自己保證，真正取值的時(shí)候能夠取到值。

如果不注意，esm中的循環(huán)引用也會導(dǎo)致一些令人困惑的結(jié)果，比如：

//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');

執(zhí)行node foo.mjs結(jié)果如下

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確實(shí)導(dǎo)出了foo。

為什么會這樣呢，仔細(xì)看這一句export var foo = false，由于var存在變量提升，所以我們確實(shí)導(dǎo)出了foo，但foo的值還未被初始化，因此在bar.mjs中foo的值為undefined。如果我們改成export let foo = false，那么執(zhí)行foo.mjs就會直接報(bào)錯(cuò)：

ReferenceError: Cannot access 'foo' before initialization

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

總結(jié)

導(dǎo)致rollup打包問題的原因?yàn)椋捍虬倪^程中rollup將cjs模塊轉(zhuǎn)換成esm，由于esm會跳過之前已加載過的模塊，實(shí)際引入的變量變成了undefined，導(dǎo)致在最終生成的代碼中存在undefined的變量。

這個(gè)問題至今尚未有效解決，涉及到大量commonjs模塊時(shí)，建議使用webpack打包。

以上就是rollup打包引發(fā)的對JS模塊循環(huán)引用的思考的詳細(xì)內(nèi)容，更多關(guān)于rollup打包JS模塊循環(huán)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論