Module的加载实现
1. 浏览器加载
1)传统方法
HTML 网页中,浏览器通过``标签加载 JavaScript 脚本。
上面代码中,由于浏览器脚本的默认语言是 JavaScript,因此type="application/javascript"
可以省略。
默认情况下,浏览器是同步加载 JavaScript 脚本,即渲染引擎遇到``标签就会停下来,等到执行完脚本,再继续向下渲染。如果是外部脚本,还必须加入脚本下载的时间。
如果脚本体积很大,下载和执行的时间就会很长,因此造成浏览器堵塞,用户会感觉到浏览器“卡死”了,没有任何响应。这显然是很不好的体验,所以浏览器允许脚本异步加载,下面就是两种异步加载的语法。
上面代码中,`标签打开
defer或
async`属性,脚本就会异步加载。渲染引擎遇到这一行命令,就会开始下载外部脚本,但不会等它下载和执行,而是直接执行后面的命令。
defer
与async
的区别是:defer
要等到整个页面在内存中正常渲染结束(DOM 结构完全生成,以及其他脚本执行完成),才会执行;async
一旦下载完,渲染引擎就会中断渲染,执行这个脚本以后,再继续渲染。一句话,defer
是“渲染完再执行”,async
是“下载完就执行”。另外,如果有多个defer
脚本,会按照它们在页面出现的顺序加载,而多个async
脚本是不能保证加载顺序的。
2)加载规则
浏览器加载 ES6 模块,也使用`标签,但是要加入
type="module"`属性。
上面代码在网页中插入一个模块foo.js
,由于type
属性设为module
,所以浏览器知道这是一个 ES6 模块。
浏览器对于带有type="module"
的,都是异步加载,不会造成堵塞浏览器,即等到整个页面渲染完,再执行模块脚本,等同于打开了
标签的defer
属性。
如果网页有多个<script type="module">
,它们会按照在页面出现的顺序依次执行。
标签的async属性也可以打开,这时只要加载完成,渲染引擎就会中断渲染立即执行。执行完成后,再恢复渲染。
一旦使用了async
属性,``就不会按照在页面出现的顺序执行,而是只要该模块加载完成,就执行该模块。
浏览器使用es6模块,有几点注意事项
代码是在模块作用域之中运行,而不是在全局作用域运行。模块内部的顶层变量,外部不可见。
模块脚本自动采用严格模式,不管有没有声明
use strict
。模块之中,可以使用
import
命令加载其他模块(.js
后缀不可省略,需要提供绝对 URL 或相对 URL),也可以使用export
命令输出对外接口。模块之中,顶层的
this
关键字返回undefined
,而不是指向window
。也就是说,在模块顶层使用this
关键字,是无意义的。同一个模块如果加载多次,将只执行一次。
利用顶层的this
等于undefined
这个语法点,可以侦测当前代码是否在 ES6 模块之中。
2. ES6模块和CommonJS模块的差异
ES6 模块与 CommonJS 模块完全不同。它们有两个重大差异:
CommonJS 模块输出的是一个值的拷贝,ES6 模块输出的是值的引用。
CommonJS 模块是运行时加载,ES6 模块是编译时输出接口。
CommonJS 模块输出的是值的拷贝,也就是说,一旦输出一个值,模块内部的变化就影响不到这个值。请看下面这个模块文件lib.js
的例子。
在main.js
里面加载这个模块:
上面代码说明,lib.js
模块加载以后,它的内部变化就影响不到输出的mod.counter
了。这是因为mod.counter
是一个原始类型的值,会被缓存。除非写成一个函数,才能得到内部变动后的值。
上面代码中,输出的counter
属性实际上是一个取值器函数。现在再执行main.js
,就可以正确读取内部变量counter
的变动了。
ES6 模块是动态引用,并且不会缓存值,模块里面的变量绑定其所在的模块。原始值变了,import
加载的值也会跟着变。
3. NodeJs 加载
1)概述
Node.js 对 ES6 模块的处理比较麻烦,因为它有自己的 CommonJS 模块格式,与 ES6 模块格式是不兼容的。目前的解决方案是,将两者分开,ES6 模块和 CommonJS 采用各自的加载方案。从 v13.2 版本开始,Node.js 已经默认打开了 ES6 模块支持。
Node.js 要求 ES6 模块采用.mjs
后缀文件名。也就是说,只要脚本文件里面使用import
或者export
命令,那么就必须采用.mjs
后缀名。Node.js 遇到.mjs
文件,就认为它是 ES6 模块,默认启用严格模式。
如果不希望将后缀名改成.mjs
,可以在项目的package.json
文件中,指定type
字段为module
。
一旦设置了以后,该目录里面的 JS 脚本,就被解释用 ES6 模块。
注意,ES6 模块与 CommonJS 模块尽量不要混用。require
命令不能加载.mjs
文件,会报错,只有import
命令才可以加载.mjs
文件。反过来,.mjs
文件里面也不能使用require
命令,必须使用import
。
2)main 字段
package.json
文件有两个字段可以指定模块的入口文件:main
和exports
。比较简单的模块,可以只使用main
字段,指定模块加载的入口文件。
上面代码指定项目的入口脚本为./src/index.js
,它的格式为 ES6 模块。如果没有type
字段,index.js
就会被解释为 CommonJS 模块。
然后,import
命令就可以加载这个模块。
上面代码中,运行该脚本以后,Node.js 就会到./node_modules
目录下面,寻找es-module-package
模块,然后根据该模块package.json
的main
字段去执行入口文件。
这时,如果用 CommonJS 模块的require()
命令去加载es-module-package
模块会报错,因为 CommonJS 模块不能处理export
命令。
3)exports 字段
exports
字段的优先级高于main
字段。它有多种用法。
(1)子目录别名
package.json
文件的exports
字段可以指定脚本或子目录的别名。
上面的代码指定src/submodule.js
别名为submodule
,然后就可以从别名加载这个文件。
如果没有指定别名,就不能用“模块+脚本名”这种形式加载脚本。
(2)main 的别名
exports
字段的别名如果是.
,就代表模块的主入口,优先级高于main
字段,并且可以直接简写成exports
字段的值。
由于exports
字段只有支持 ES6 的 Node.js 才认识,所以可以用来兼容旧版本的 Node.js。
上面代码中,老版本的 Node.js (不支持 ES6 模块)的入口文件是main-legacy.cjs
,新版本的 Node.js 的入口文件是main-modern.cjs
。
(3)按需引入
利用.
这个别名,可以为 ES6 模块和 CommonJS 指定不同的入口。目前,这个功能需要在 Node.js 运行的时候,打开--experimental-conditional-exports
标志。
上面代码中,别名.
的require
条件指定require()
命令的入口文件(即 CommonJS 的入口),default
条件指定其他情况的入口(即 ES6 的入口)。
上面的写法可以简写如下。
注意,如果同时还有其他别名,就不能采用简写,否则或报错。
4)ES6模块加载CommonJS模块
目前,一个模块同时支持 ES6 和 CommonJS 两种格式的常见方法是,package.json
文件的main
字段指定 CommonJS 入口,给 Node.js 使用;module
字段指定 ES6 模块入口,给打包工具使用,因为 Node.js 不认识module
字段。
有了上一节的条件加载以后,Node.js 本身就可以同时处理两种模块。
上面代码指定了 CommonJS 入口文件index.cjs
,下面是这个文件的代码。
然后,ES6 模块可以加载这个文件。
注意,import
命令加载 CommonJS 模块,只能整体加载,不能只加载单一的输出项。
还有一种变通的加载方法,就是使用 Node.js 内置的module.createRequire()
方法。
5)CommonJS加载ES6模块
CommonJS 的require
命令不能加载 ES6 模块,会报错,只能使用import()
这个方法加载。
6)NodeJs 的内置模块
Node.js 的内置模块可以整体加载,也可以加载指定的输出项。
7)加载路径
ES6 模块的加载路径必须给出脚本的完整路径,不能省略脚本的后缀名。import
命令和package.json
文件的main
字段如果省略脚本的后缀名,会报错。
为了与浏览器的import
加载规则相同,Node.js 的.mjs
文件支持 URL 路径。
8)内部变量
ES6 模块应该是通用的,同一个模块不用修改,就可以用在浏览器环境和服务器环境。为了达到这个目标,Node 规定 ES6 模块之中不能使用 CommonJS 模块的特有的一些内部变量。
首先,就是this
关键字。ES6 模块之中,顶层的this
指向undefined
;CommonJS 模块的顶层this
指向当前模块,这是两者的一个重大差异。
其次,以下这些顶层变量在 ES6 模块之中都是不存在的。
arguments
require
module
exports
__filename
__dirname
4. 循环加载
“循环加载”(circular dependency)指的是,a
脚本的执行依赖b
脚本,而b
脚本的执行又依赖a
脚本。
通常,“循环加载”表示存在强耦合,如果处理不好,还可能导致递归加载,使得程序无法执行,因此应该避免出现。
但是实际上,这是很难避免的,尤其是依赖关系复杂的大项目,很容易出现a
依赖b
,b
依赖c
,c
又依赖a
这样的情况。这意味着,模块加载机制必须考虑“循环加载”的情况。
1)CommonJS模块的加载原理
CommonJS 的一个模块,就是一个脚本文件。require
命令第一次加载该脚本,就会执行整个脚本,然后在内存生成一个对象。
上面代码就是 Node 内部加载模块后生成的一个对象。该对象的id
属性是模块名,exports
属性是模块输出的各个接口,loaded
属性是一个布尔值,表示该模块的脚本是否执行完毕。其他还有很多属性,这里都省略了。
以后需要用到这个模块的时候,就会到exports
属性上面取值。即使再次执行require
命令,也不会再次执行该模块,而是到缓存之中取值。也就是说,CommonJS 模块无论加载多少次,都只会在第一次加载时运行一次,以后再加载,就返回第一次运行的结果,除非手动清除系统缓存。
2)CommonJS模块的循环加载
上面代码之中,a.js
脚本先输出一个done
变量,然后加载另一个脚本文件b.js
。注意,此时a.js
代码就停在这里,等待b.js
执行完毕,再往下执行。
再看b.js
的代码。
上面代码之中,b.js
执行到第二行,就会去加载a.js
,这时,就发生了“循环加载”。系统会去a.js
模块对应对象的exports
属性取值,可是因为a.js
还没有执行完,从exports
属性只能取回已经执行的部分,而不是最后的值。
a.js
已经执行的部分,只有一行。
因此,对于b.js
来说,它从a.js
只输入一个变量done
,值为false
。
然后,b.js
接着往下执行,等到全部执行完毕,再把执行权交还给a.js
。于是,a.js
接着往下执行,直到执行完毕。我们写一个脚本main.js
,验证这个过程。
执行main.js
,运行结果如下。
上面的代码证明了两件事。一是,在b.js
之中,a.js
没有执行完毕,只执行了第一行。二是,main.js
执行到第二行时,不会再次执行b.js
,而是输出缓存的b.js
的执行结果,即它的第四行。
另外,由于 CommonJS 模块遇到循环加载时,返回的是当前已经执行的部分的值,而不是代码全部执行后的值,两者可能会有差异。所以,输入变量的时候,必须非常小心。
上面代码中,如果发生循环加载,require('a').foo
的值很可能后面会被改写,改用require('a')
会更保险一点。
3)ES6模块的循环加载
执行a.mjs
,结果如下。
执行a.mjs
以后会报错,foo
变量未定义,这是为什么?
让我们一行行来看,ES6 循环加载是怎么处理的。首先,执行a.mjs
以后,引擎发现它加载了b.mjs
,因此会优先执行b.mjs
,然后再执行a.mjs
。接着,执行b.mjs
的时候,已知它从a.mjs
输入了foo
接口,这时不会去执行a.mjs
,而是认为这个接口已经存在了,继续往下执行。执行到第三行console.log(foo)
的时候,才发现这个接口根本没定义,因此报错。
解决这个问题的方法,就是让b.mjs
运行的时候,foo
已经有定义了。这可以通过将foo
写成函数来解决。
这时再执行a.mjs
就可以得到预期结果。
这是因为函数具有提升作用,在执行import {bar} from './b'
时,函数foo
就已经有定义了,所以b.mjs
加载的时候不会报错。这也意味着,如果把函数foo
改写成函数表达式,也会报错。
上面代码的第四行,改成了函数表达式,就不具有提升作用,执行就会报错。
最后更新于
这有帮助吗?