rollup打包對JS模塊循環(huán)引用的方法是什么

本篇內(nèi)容主要講解“rollup打包對JS模塊循環(huán)引用的方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“rollup打包對JS模塊循環(huán)引用的方法是什么”吧!

引言

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

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

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

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

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

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

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

背景1

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

背景2

nodejs中的readable stream和duplex stream兩個模塊之間產(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)引用的時候到底有什么區(qū)別呢，為什么會最終導(dǎo)致錯誤呢？

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

commonjs

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

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

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

//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會直接報錯TypeError: foo is not a function

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

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

es modules

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

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

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

如果不注意，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確實導(dǎo)出了foo。

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

ReferenceError: Cannot access 'foo' before initialization

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

到此，相信大家對“rollup打包對JS模塊循環(huán)引用的方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！