rollup打包对JS模块循环引用的方法是什么

2023-05-14,

本篇内容主要讲解“rollup打包对JS模块循环引用的方法是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“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.mjsfoo的值为undefined。如果我们改成export let foo = false,那么执行foo.mjs就会直接报错:

    ReferenceError: Cannot access 'foo' before initialization

    这也提醒了我们使用let/const替代var,否则可能会出现难以预测的情况

    到此,相信大家对“rollup打包对JS模块循环引用的方法是什么”有了更深的了解,不妨来实际操作一番吧!这里是本站网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

    《rollup打包对JS模块循环引用的方法是什么.doc》

    下载本文的Word格式文档,以方便收藏与打印。