利用webpack理解CommonJS和ES Modules的差异区别

 更新时间:2020年06月16日 15:31:40   作者:B2D1  
这篇文章主要介绍了利用webpack理解CommonJS和ES Modules的差异区别,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

前言

问: CommonJS 和 ES Modules 中模块引入的区别?

CommonJS 输出的是一个值的拷贝;ES Modules 生成一个引用,等到真的需要用到时,再到模块里面去取值,模块里面的变量,绑定其所在的模块。

我相信很多人已经把这个答案背得滚瓜烂熟,好,那继续提问。

问:CommonJS 输出的值是浅拷贝还是深拷贝?

问:你能模拟实现 ES Modules 的引用生成吗?

对于以上两个问题,我也是感到一脸懵逼,好在有 webpack 的帮助,作为一个打包工具,它让 ES Modules, CommonJS 的工作流程瞬间清晰明了。

准备工作

初始化项目,并安装 beta 版本的 webpack 5,它相较于 webpack 4 做了许多优化:对 ES Modules 的支持度更高,打包后的代码也更精简。

$ mkdir demo && cd demo
$ yarn init -y
$ yarn add webpack@next webpack-cli
# or yarn add webpack@5.0.0-beta.17 webpack-cli

早在 webpack4 就已经引入了无配置的概念,既不需要提供 webpack.config.js 文件,它会默认以 src/index.js 为入口文件,生成打包后的 main.js 放置于 dist 文件夹中。

确保你拥有以下目录结构:

├── dist
│  └── index.html
├── src
│  └── index.js
├── package.json
└── yarn.lock

在 index.html 中引入打包后的 main.js:

<!DOCTYPE html>
<html lang="en">
 <head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Document</title>
 </head>
 <body>
  <script src="main.js"></script>
 </body>
</html>

在 package.json 中添加命令脚本:

"scripts": {
 "start": "webpack"
},

运行无配置打包:

$ yarn start

终端会提示:

WARNING in configuration
The 'mode' option has not been set, webpack will fallback to 'production' for this value. Set 'mode' option to 'development' or 'production' to enable defaults for each environment.
You can also set it to 'none' to disable any default behavior. Learn more: https://webpack.js.org/configuration/mode/

webpack 要求用户在打包时必须提供 mode 选项,来指明打包后的资源用于开发环境还是生产环境,从而让 webpack 相应地使用其内置优化,默认为 production(生产环境)。

我们将其设置为 none 来避免默认行为带来的干扰,以便我们更好的分析源码。
修改 package.json:

"scripts": {
 "start": "webpack --mode=none"
},

重新运行,webpack 在 dist 目录下生成了打包后的 main.js,由于入口文件是空的,所以 main.js 的源码只有一个 IIFE(立即执行函数),看似简单,但它的地位却极其重要。

(() => {
 // webpackBootstrap
})();

我们知道无论在 CommonJS 或 ES Modules 中,一个文件就是一个模块,模块之间的作用域相互隔离,且不会污染全局作用域。此刻 IIFE 就派上了用场,它将一个文件的全部 JS 代码包裹起来,形成闭包函数,不仅起到了函数自执行的作用,还能保证函数间的作用域不会互相污染,并且在闭包函数外无法直接访问内部变量,除非内部变量被显式导出。

var name = "webpack";

(() => {
 var name = "parcel";
 var age = 18;
 console.log(name); // parcel
})();

console.log(name); // webpack
console.log(age); // ReferenceError: age is not defined

引用 vs 拷贝

接下里进入实践部分,涉及源码的阅读,让我们深入了解 CommonJS 和 ES Modules 的差异所在。

CommonJS

新建 src/counter.js

let num = 1;

function increase() {
 return num++;
}

module.exports = { num, increase };

修改 index.js

const { num, increase } = require("./counter");

console.log(num);
increase();
console.log(num);

如果你看过前面叙述,毫无疑问,打印 1 1.

so why?我们查看 main.js,那有我们想要的答案,去除无用的注释后如下:

(() => {
 var __webpack_modules__ = [
  ,
  module => {
   let num = 1;

   function increase() {
    return num++;
   }

   module.exports = { num, increase };
  },
 ];

 var __webpack_module_cache__ = {};

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

  // Execute the module function
  __webpack_modules__[moduleId](module, module.exports, __webpack_require__);

  return module.exports;
 }

 (() => {
  const { num, increase } = __webpack_require__(1);

  console.log(num);
  increase();
  console.log(num);
 })();
})();

可以简化为:

(() => {
 var __webpack_modules__ = [...];
 var __webpack_module_cache__ = {};

 function __webpack_require__(moduleId) {...}

 (() => {
  const { num, increase } = __webpack_require__(1);

  console.log(num);
  increase();
  console.log(num);
 })();
})();

最外层是一个 IIFE,立即执行。

__webpack_modules__,它是一个数组,第一项为空,第二项是一个箭头函数并传入 module 参数,函数内部包含了 counter.js 中的所有代码。

__webpack_module_cache__ 缓存已经加载过的模块。

function __webpack_require__(moduleId) {...} 类似于 require(),他会先去 __webpack_module_cache__ 中查找此模块是否已经被加载过,如果被加载过,直接返回缓存中的内容。否则,新建一个 module: {exports: {}},并设置缓存,执行模块函数,最后返回 module.exports

最后遇到一个 IIFE,它将 index.js 中的代码包装在内,并执行 __webpack_require__(1),导出了 num 和 increase 供 index.js 使用。

这里的关键点在于 counter.js 中的 module.exports = { num, increase };,等同于以下写法:

module.exports = {
 num: num,
 increase: increase,
};

num 属于基本类型,假设其内存地址指向 n1,当它被 赋值 给 module.exports['num'] 时,module.exports['num'] 已经指向了一个新的内存地址 n2,只不过其值同样为 1,但和 num 已是形同陌路,毫不相干。

let num = 1;
// mun 相当于 module.exports['num']
mun = num;

num = 999;
console.log(mun); // 1

increase 是一个函数,属于引用类型,即 increase 只作为一个指针,当它被赋值给 module.exports['increase'] 时,只进行了指针的复制,是 浅拷贝(基本类型没有深浅拷贝的说法),其内存地址依旧指向同一块数据。所以本质上 module.exports['increase'] 就是 increase,只不过换个名字。

而由于词法作用域的特性,counter.js 中 increase() 修改的 num 变量在函数声明时就已经绑定不变了,永远绑定内存地址指向 n1 的 num.

JavaScript 采用的是词法作用域,它规定了函数内访问变量时,查找变量是从函数声明的位置向外层作用域中查找,而不是从调用函数的位置开始向上查找

function foo() {
 var x = 10;
 console.log(x);
}
function bar(f) {
 var x = 20;
 f();
}
bar(foo); // 10

调用 increase() 并不会影响内存地址指向 n2 的 num,这也就是为什么打印 1 1 的理由。

ES Modules

分别修改 counter.js 和 index.js,这回使用 ES Modules.

let num = 1;

function increase() {
 return num++;
}

export { num, increase };
import { num, increase } from "./counter";

console.log(num);
increase();
console.log(num);

很明显,打印 1 2.

老规矩,查看 main.js,删除无用的注释后如下:

(() => {
 "use strict";
 var __webpack_modules__ = [
  ,
  (__unused_webpack_module, __webpack_exports__, __webpack_require__) => {
   __webpack_require__.d(__webpack_exports__, {
    num: () => /* binding */ num,
    increase: () => /* binding */ increase,
   });
   let num = 1;

   function increase() {
    return num++;
   }
  },
 ];

 var __webpack_module_cache__ = {};

 function __webpack_require__(moduleId) {} // 笔者注:同一个函数,不再展开

 /* webpack/runtime/define property getters */
 (() => {
  __webpack_require__.d = (exports, definition) => {
   for (var key in definition) {
    if (
     __webpack_require__.o(definition, key) &&
     !__webpack_require__.o(exports, key)
    ) {
     Object.defineProperty(exports, key, {
      enumerable: true,
      get: definition[key],
     });
    }
   }
  };
 })();

 /* webpack/runtime/hasOwnProperty shorthand */
 (() => {
  __webpack_require__.o = (obj, prop) =>
   Object.prototype.hasOwnProperty.call(obj, prop);
 })();

 (() => {
  var _counter__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(1);

  console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
  (0, _counter__WEBPACK_IMPORTED_MODULE_0__.increase)();
  console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
 })();
})();

经过简化,大致如下:

(() => {
 "use strict";
 var __webpack_modules__ = [...];
 var __webpack_module_cache__ = {};

 function __webpack_require__(moduleId) {...}

 (() => {
  __webpack_require__.d = (exports, definition) => {...};
 })();

 (() => {
  __webpack_require__.o = (obj, prop) => {...}
 })();

 (() => {
  var _counter__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(1);

  console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
  (0, _counter__WEBPACK_IMPORTED_MODULE_0__.increase)();
  console.log(_counter__WEBPACK_IMPORTED_MODULE_0__.num);
 })();
})();

首先查看两个工具函数:__webpack_require__.o 和 __webpack_require__.d。

__webpack_require__.o 封装了 Object.prototype.hasOwnProperty.call(obj, prop) 的操作。

__webpack_require__.d 则是通过 Object.defineProperty(exports, key, { enumerable: true, get: definition[key] }) 来对 exports 对象设置不同属性的 getter

随后看到了熟悉的 __webpack_modules__,它的形式和上一节差不多,最主要的是以下这段代码:

__webpack_require__.d(__webpack_exports__, {
 num: () => /* binding */ num,
 increase: () => /* binding */ increase,
});

与 CommonJS 不同,ES Modules 并没有对 module.exports 直接赋值,而是将值作为箭头函数的返回值,再把箭头函数赋值给 module.exports,之前我们提过词法作用域的概念,即这里的 num() 和 increase() 无论在哪里执行,返回的 num 变量和 increase 函数都是 counter.js 中的。

在遇到最后一个 IIFE 时,调用 __webpack_require__(1),返回 module.exports 并赋值给 _counter__WEBPACK_IMPORTED_MODULE_0__,后续所有的属性获取都是使用点操作符,这触发了对应属性的 get 操作,于是执行函数返回 counter.js 中的值。

所以打印 1 2.

懂了词法作用域的原理,就可以实现一个”乞丐版“的 ES Modules:

function my_require() {
 var module = {
  exports: {},
 };
 let counter = 1;

 function add() {
  return counter++;
 }

 module.exports = { counter: () => counter, add };
 return module.exports;
}

var obj = my_require();

console.log(obj.counter()); // 1
obj.add();
console.log(obj.counter()); // 2

总结

多去看源码,会有不少的收获,这是一个思考的过程。
ES Modules 已经写入了 ES2020 规范中,意味着浏览器原生支持 import 和 export,有兴趣的小伙伴可以试试 Snowpack,它能直接 export 第三方库供浏览器使用,省去了 webpack 中打包的时间。

到此这篇关于利用webpack理解CommonJS和ES Modules的差异区别的文章就介绍到这了,更多相关webpack CommonJS和ES Modules 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • JS定时器不可靠的原因及解决方案

    JS定时器不可靠的原因及解决方案

    JavaScript中所有的任务分为同步任务与异步任务,同步任务,顾名思义就是立即执行的任务,它一般是直接进入到主线程中执行,这篇文章主要介绍了JS定时器不可靠的原因及解决方案,需要的朋友可以参考下
    2022-01-01
  • JS 巧妙获取剪贴板数据 Excel数据的粘贴

    JS 巧妙获取剪贴板数据 Excel数据的粘贴

    最近需要在浏览器端实现excel数据的粘贴,一开始去找获取剪贴板数据的方法。但是在浏览器端,JS去取是受安全限制的。
    2009-07-07
  • BootstrapTable请求数据时设置超时(timeout)的方法

    BootstrapTable请求数据时设置超时(timeout)的方法

    使用bootstrapTable获取数据时,有时由于网络或者服务器的原因,无法及时获取到数据,页面显示一直处于等待状态。为了改善效果,考虑设置超时,请求发送后超时即显示无数据,过段时间重新发起请求
    2017-01-01
  • javascript+HTML5的canvas实现七夕情人节3D玫瑰花效果代码

    javascript+HTML5的canvas实现七夕情人节3D玫瑰花效果代码

    这篇文章主要介绍了javascript+HTML5的canvas实现七夕情人节3D玫瑰花效果代码,使用了html5的canvas技术,可呈现出带有3D效果的玫瑰花渐显效果,非常逼真自然,需要的朋友可以参考下
    2015-08-08
  • JavaScript数组的一些奇葩行为

    JavaScript数组的一些奇葩行为

    今天,复习了一下JavaScript的数组,然后,把他的一些奇葩行为总结了一下,分享在脚本之家平台,欢迎大家参考
    2016-01-01
  • javascript结合Flexbox简单实现滑动拼图游戏

    javascript结合Flexbox简单实现滑动拼图游戏

    本文给大家分享的是一则使用javascript结合Flexbox简单实现滑动拼图游戏的代码,虽然没有实现完整的功能,但是还是推荐给大家,喜欢的朋友可以继续做完
    2016-02-02
  • JavaScript 对引擎、运行时、调用堆栈的概述理解

    JavaScript 对引擎、运行时、调用堆栈的概述理解

    这篇文章旨在深入挖掘JavaScript,以及向大家解释JavaScript是如何工作的。非常不错,具有一定的参考借鉴价值,需要的朋友可以参考下
    2018-10-10
  • JavaScript学习笔记(三):JavaScript也有入口Main函数

    JavaScript学习笔记(三):JavaScript也有入口Main函数

    大家都知道在c和java中,有main函数货main方法作为一个程序的入口函数或方法。在JS中从js源文件的头部开始运行的,我们仍然可以虚构出一个main函数来作为程序的起点,这样一来不仅可以跟其他语言统一了,而且说不定你会对JS有更深的理解。感兴趣的小伙跟着小编一起学习吧
    2015-09-09
  • VUE基于NUXT的SSR 服务端渲染

    VUE基于NUXT的SSR 服务端渲染

    这篇文章主要介绍了VUE基于NUXT的SSR 服务端渲染,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-11-11
  • javascript中[]和{}对象使用介绍

    javascript中[]和{}对象使用介绍

    []不仅仅可以表示数组,可以直接通过对象的属性设置值和访问值,接下来为大家介绍下[]和{}对象的使用,感兴趣的你可以参考下哈
    2013-03-03

最新评论