CommonJS与ES6 Module的本质区别

清疚 2023-10-06 14:00 7阅读 0赞

上篇：[模块打包中CommonJS与ES6 Module的导入与导出问题详解][CommonJS_ES6 Module]

#### 目录 ####

*  动态与静态
 *  值拷贝与动态映射
 *  循环依赖

## 动态与静态 ##

动态与静态`CommonJS`与`ES6 Module`最本质的区别在于前者对模块依赖的解决是“动态的”，而后者是“静态的”。在这里“动态”的含义是，模块依赖关系的建立发生在代码运行阶段；而“静态”则是模块依赖关系的建立发生在代码编译阶段。

让我们先看一个`CommonJS`的例子：

// calculator.js
    module.exports = {
         name: 'calculator' };
    // index.js
    const name = require('./calculator.js').name;

在上面介绍`CommonJS`的部分时我们提到过，当模块`A`加载模块`B`时（在上面的例子中是`index.js`加载`calculator.js`），会执行`B`中的代码，并将其`module.exports`对象作为require函数的返回值进行返回。并且`require`的模块路径可以动态指定，支持传入一个表达式，我们甚至可以通过if语句判断是否加载某个模块。因此，在`CommonJS`模块被执行前，并没有办法确定明确的依赖关系，模块的导入、导出发生在代码的运行阶段。

同样的例子，让我们再对比看下`ES6 Module`的写法：

// calculator.js
    export const name = 'calculator';
    // index.js
    import {
         name } from './calculator.js';

`ES6 Module`的导入、导出语句都是声明式的，它不支持导入的路径是一个表达式，并且导入、导出语句必须位于模块的顶层作用域（比如不能放在`if`语句中）。因此我们说，`ES6 Module`是一种静态的模块结构，在`ES6`代码的编译阶段就可以分析出模块的依赖关系。它相比于`CommonJS`来说具备以下几点优势：

*  死代码检测和排除。  
    我们可以用静态分析工具检测出哪些模块没有被调用过。比如，在引入工具类库时，工程中往往只用到了其中一部分组件或接口，但有可能会将其代码完整地加载进来。未被调用到的模块代码永远不会被执行，也就成为了死代码。通过静态分析可以在打包时去掉这些未曾使用过的模块，以减小打包资源体积。
 *  模块变量类型检查。  
    `JavaScript`属于动态类型语言，不会在代码执行前检查类型错误（比如对一个字符串类型的值进行函数调用）。`ES6 Module`的静态模块结构有助于确保模块之间传递的值或接口类型是正确的。
 *  编译器优化。  
    在`CommonJS`等动态模块系统中，无论采用哪种方式，本质上导入的都是一个对象，而`ES6 Module`支持直接导入变量，减少了引用层级，程序效率更高。

## 值拷贝与动态映射 ##

在导入一个模块时，对于`CommonJS`来说获取的是一份导出值的拷贝；而在`ES6 Module`中则是值的动态映射，并且这个映射是**只读**的。

上面的话直接理解起来可能比较困难，首先让我们来看一个例子，了解一下什么是`CommonJS`中的值拷贝。

// calculator.js
    var count = 0;
    module.exports = {
        
        count: count,
        add: function(a, b) {
        
            count += 1;
            return a + b;
        }
    };
    
    // index.js
    var count = require('./calculator.js').count;
    var add = require('./calculator.js').add;
    
    console.log(count); // 0（这里的count是对 calculator.js 中 count 值的拷贝）
    add(2, 3);
    console.log(count); // 0（calculator.js中变量值的改变不会对这里的拷贝值造成影响）
    
    count += 1;
    console.log(count); // 1（拷贝的值可以更改）

`index.js`中的`count`是对`calculator.js`中`count`的一份值拷贝，因此在调用add函数时，虽然更改了原本`calculator.js`中`count`的值，但是并不会对`index.js`中导入时创建的副本造成影响。

另一方面，在`CommonJS`中允许对导入的值进行更改。我们可以在`index.js`更改`count`和`add`，将其赋予新值。同样，由于是值的拷贝，这些操作不会影响`calculator.js`本身。

下面我们使用E`S6 Module`将上面的例子进行改写：

// calculator.js
    let count = 0;
    const add = function(a, b) {
        
        count += 1;
        return a + b;
    };
    export {
         count, add };
    
    // index.js
    import {
         count, add } from './calculator.js';
    
    console.log(count); // 0（对 calculator.js 中 count 值的映射）
    add(2, 3);
    console.log(count); // 1（实时反映calculator.js 中 count值的变化）
    
    // count += 1; // 不可更改，会抛出SyntaxError: "count" is read-only

上面的例子展示了`ES6 Module`中导入的变量其实是对原有值的动态映射。`index.js`中的`count`是对`calculator.js`中的`count`值的实时反映，当我们通过调用`add`函数更改了`calculator.js`中`count`值时，`index.js`中`count`的值也随之变化。

我们不可以对`ES6 Module`导入的变量进行更改，可以将这种映射关系理解为一面镜子，从镜子里我们可以实时观察到原有的事物，但是并不可以操纵镜子中的影像。

## 循环依赖 ##

循环依赖循环依赖是指`模块A`依赖于`模块B`，同时`模块B`依赖于`模块A`。比如下面这个例子：

// a.js
    import {
         foo } from './b.js';
    foo();
    
    // b.js
    import {
         bar } from './a.js';
    bar();

一般来说工程中应该尽量避免循环依赖的产生，因为从软件设计的角度来说，单向的依赖关系更加清晰，而循环依赖则会带来一定的复杂度。而在实际开发中，循环依赖有时会在我们不经意间产生，因为当工程的复杂度上升到足够规模时，就容易出现隐藏的循环依赖关系。

简单来说，`A`和`B`两个模块之间是否存在直接的循环依赖关系是很容易被发现的。但实际情况往往是`A`依赖于`B`，`B`依赖于`C`，`C`依赖于`D`，最后绕了一大圈，`D`又依赖于`A`。当中间模块太多时就很难发现`A`和`B`之间存在着隐式的循环依赖。

因此，如何处理循环依赖是开发者必须要面对的问题。我们首先看一下在`CommonJS`中循环依赖的例子。

// foo.js
    const bar = require('./bar.js');
    console.log('value of bar:', bar);
    module.exports = 'This is `foo.js`';
    
    // bar.js
    const foo = require('./foo.js');
    console.log('value of foo:', foo);
    module.exports = 'This is bar.js';
    
    // index.js
    require('./foo.js');

在这里，`index.js`是执行入口，它加载了`foo.js`，`foo.js`和`bar.js`之间存在循环依赖。让我们观察`foo.js`和`bar.js`中的代码，理想状态下我们希望二者都能导入正确的值，并在控制台上输出。

value of foo: This is foo.js
    value of bar: This is bar.js

而当我们运行上面的代码时，实际输出却是：

value of foo: {
        }
    value of bar: This is bar.js

为什么`foo`的值会是一个空对象呢？让我们从头梳理一下代码的实际执行顺序。  
1）`index.js`导入了`foo.js`，此时开始执行`foo.js`中的代码。

2）`foo.js`的第1句导入了`bar.js`，这时`foo.js`不会继续向下执行，而是进入了`bar.js`内部。

3）在`bar.js`中又对`foo.js`进行了`require`，这里产生了循环依赖。需要注意的是，执行权并不会再交回`foo.js`，而是直接取其导出值，也就是`module.exports`。但由于`foo.js`未执行完毕，导出值在这时为默认的空对象，因此当`bar.js`执行到打印语句时，我们看到控制台中的`value of foo`就是一个空对象。

4）`bar.js`执行完毕，将执行权交回`foo.js`。

5）`foo.js`从`require`语句继续向下执行，在控制台打印出`valueof bar`（这个值是正确的），整个流程结束。由上面可以看出，尽管循环依赖的模块均被执行了，但模块导入的值并不是我们想要的。因此在`CommonJS`中，若遇到循环依赖我们没有办法得到预想中的结果。

我们再从`Webpack`的实现角度来看，将上面例子打包后，`bundle`中有这样一段代码非常重要：

/******/ 	// The module cache
    /******/ 	var installedModules = {
        };
    /******/
    /******/ 	// The require function
    /******/ 	function __webpack_require__(moduleId) {
        
    /******/
    /******/ 		// Check if module is in cache
    /******/ 		if(installedModules[moduleId]) {
        
    /******/ 			return installedModules[moduleId].exports;
    /******/ 		}
    /******/ 		// Create a new module (and put it into the cache)
    /******/ 		var module = installedModules[moduleId] = {
        
    /******/ 			i: moduleId,
    /******/ 			l: false,
    /******/ 			exports: {
        }
    /******/ 		};

过程梳理一下

// The require function
    function __webpack_require__(moduleId) {
        
      // 1.在index.js里require('./foo.js')的时候，跳过这个if
      // 3.在foo.js里require('./bar.js')的时候，跳过这个if
      // 5.在bar.js里require('./foo.js')的时候，执行了这个if逻辑，bar.js里的foo是{}
      if(installedModules[moduleId]) {
        
        return installedModules[moduleId].exports;
      }
      // Create a new module (and put it into the cache)
      // 2.创建新模块缓存起来，记录foo里面的东西
      // 4.创建新模块缓存起来，记录bar里面的东西
      var module = installedModules[moduleId] = {
        
        i: moduleId,
        l: false,
        exports: {
        }
      };
      ...

当`index.js`引用了`foo.js`之后，相当于执行了这个`__webpack_require__`函数，初始化了一个`module`对象并放入`installedModules`中。当bar.js再次引用`foo.js`时，又执行了该函数，但这次是直接从`installedModules`里面取值，此时它的`module.exports`是一个空对象。这就解释了上面在第3步看到的现象。接下来让我们使用`ES6 Module`的方式重写上面的例子。

// foo.js
    import bar from './bar.js';
    console.log('value of bar:', bar);
    export default 'This is foo.js';
    
    // bar.js
    import foo from './foo.js';
    console.log('value of foo:', foo);
    export default 'This is bar.js';
    
    // index.js
    import foo from './foo.js';

执行结果如下：

value of foo: undefined
    value of bar: This is bar.js

很遗憾，在`bar.js`中同样无法得到`foo.js`正确的导出值，只不过和`CommonJS`默认导出一个空对象不同，这里获取到的是`undefined`。(可以写一个`html`引入打包出来的`js`查看`console`的打印结果)

上面我们谈到，在导入一个模块时，`CommonJS`获取到的是值的拷贝，`ES6 Module`则是动态映射，那么我们能否利用`ES6Module`的特性使其支持循环依赖呢？请看下面这个例子：

//index.js
    import foo from './foo.js';
    foo('index.js');
    
    // foo.js
    import bar from './bar.js';
    function foo(invoker) {
        
        console.log(invoker + ' invokes foo.js');
        bar('foo.js');
    }
    export default foo;
    
    // bar.js
    import foo from './foo.js';
    let invoked = false;
    function bar(invoker) {
        
        if(!invoked) {
        
            invoked = true;
            console.log(invoker + ' invokes bar.js');
            foo('bar.js');
        }
    }
    export default bar;

上面代码的执行结果如下：

index.js invokes foo.js
    foo.js invokes bar.js
    bar.js invokes foo.js

可以看到，`foo.js`和`bar.js`这一对循环依赖的模块均获取到了正确的导出值。下面让我们分析一下代码的执行过程。  
1）`index.js`作为入口导入了`foo.js`，此时开始执行`foo.js`中的代码。

2）从`foo.js`导入了`bar.js`，执行权交给`bar.js`。

3）在`bar.js`中一直执行到其结束，完成`bar`函数的定义。注意，此时由于`foo.js`还没执行完，`foo`的值现在仍然是`undefined`。

4）执行权回到`foo.js`继续执行直到其结束，完成`foo`函数的定义。由于`ES6 Module`动态映射的特性，此时在`bar.js`中`foo`的值已经从`undefined`成为了我们定义的函数，这是与`CommonJS`在解决循环依赖时的本质区别，`CommonJS`中导入的是值的拷贝，不会随着被夹在模块中原有值的变化而变化。

5）执行权回到`index.js`并调用`foo`函数，此时会依次执行`foo`→`bar`→`foo`，并在控制台打出正确的值。

由上面的例子可以看出，`ES6 Module`的特性使其可以更好地支持循环依赖，只是需要由开发者来保证当导入的值被使用时已经设置好正确的导出值。

简单小结:

> `CommonJS`和`ES6 Module`是目前使用较为广泛的模块标准。它们的主要区别在于  
> 1.前者建立模块依赖关系是在运行时，后者是在编译时；  
>   
> 2.在模块导入方面，`CommonJS`导入的是值拷贝，`ES6 Module`导入的是只读的变量映射；  
>   
> 3.`ES6 Module`通过其静态特性可以进行编译过程中的优化，并且具备处理循环依赖的能力。

参考来源：

*  Webpack实战：入门、进阶与调优

关注、留言，我们一起学习。  
  
===============Talk is cheap, show me the code================

[CommonJS_ES6 Module]: https://blog.csdn.net/qq_34115899/article/details/107727746