文章详情

登录

短信预约-IT技能 免费直播动态提醒

选择考试省份

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团

请输入下面的图形验证码

提交验证

短信预约提醒成功

教你彻底搞懂ESM与CJS互相转换

2023-03-03 11:57

关注

正文

ESM 和 CJS 是我们常用的模块格式，两种模块系统具有不同的语法和加载机制。在项目中，我们可能会遇到 ESM 和 CJS 转换的场景：

最近在项目中也刚好遇到的转换上的一些问题，于是就研究了一下

本文将介绍 ESM 和 CJS 之间转换，帮助大家加深对它们的了解，并从中了解它们之间转换的细节与局限性

ESM 转 CJS

ESM 转 CJS 的使用场景非常常见，例如：

各大工具，如 TSC、Babel、Vite、webpack、Rollup 等，都自带了 ESM 转 CJS 的能力。

export 的转换

export default 666

Rollup 会转换成

modules.exports = 666

很好理解，modules.exports 导出的整个东西就是默认导出嘛

用 CJS 引用该模块的方式：

const lib = require('lib')
console.log(lib)
// 666

export const a = 123
export const b = 234

转换成

module.exports.a = 123
module.exports.b = 234

命名导出用 module.exports.xxx 一个个导出就行

用 CJS 引用该模块的方式：

const {a, b} = require('lib')
console.log(a, b)
// 123 234

export default 666
export const a = 123
export const b = 234

这时候会发现，前面两种情况的转换思路不能用了，你不能这样转换

modules.exports = 666
module.exports.a = 123
module.exports.b = 234

毕竟 modules.exports 不是对象，因此设置不了属性。

那莫得办法了，只能这样表示了：

为了跟前两种情况做区分，因此还要新增一个标记__esModule

于是就会编译成这样的代码：

+ Object.defineProperty(exports, '__esModule', { value: true })
+ module.exports.default = 666
- module.exports = 666
module.exports.a = 123
module.exports.b = 234

用 CJS 引用该模块的方式：

const lib = require('lib')
console.log(lib.default, lib.a, lib.b)
// 666 123 234

在这种情况下，必须要用 .default 访问默认导出

但这样子看起来非常的别扭，但是没有办法，混用默认导出和命名导出是有代价的。

为什么我们项目中，从来就遇到过该问题？

一般情况下，我们使用 ESM 写项目，然后编译成 CJS

假如，我们写的代码引用了上述的代码（默认导出和命名导出混用）:

// foo.js
import lib from 'lib'
import {a, b} from 'lib'
console.log(lib, a, b)

这段代码，会被转换成：

'use strict';
var lib = require('lib');
function _interopDefault (e) { 
  return e && e.__esModule ? e : { default: e }; 
}
var lib__default = _interopDefault(lib);
console.log(lib__default.default, lib.a, lib.b);

_interopDefault 函数会自动根据 __esModule，将导出对象标准化，使 .default 一定为默认导出

工具在转译 lib.js 的同时，也会转译引入它的 foo.js，会加上标准化 require 对象的逻辑。

我们的项目，在编译的时候，全部 ESM 模块都转为 CJS（不是只转换一个，不转另外一个） ，在这个过程中它自动屏蔽了模块默认导出的差异，由于编译工具已经帮我们处理好，因此我们没有任何感知。

如果我们直接写 CJS，去引入 ESM 转换后的 CJS，就需要自行处理该问题

要想尽量避免这种情况，建议全部都使用命名导出，由于没有默认导出，就不需要担心默认导出是 module.exports 还是 module.exports.default，都用以下方式进行引入即可：

const {a, b} = require('lib')

这样开发者在任何情况下都没有心智负担。

import 的转换

其实上一小节已经讲了

import lib from 'lib'
import {a, b} from 'lib'
console.log(lib, a, b)

会被转换成

'use strict';
var lib = require('lib');
function _interopDefault (e) { 
  return e && e.__esModule ? e : { default: e }; 
}
var lib__default = _interopDefault(lib);
console.log(lib__default.default, lib.a, lib.b);

加上 _interopDefault，屏蔽了不同情况下默认导出的差异，因此如果所有代码都是从 ESM 转 CJS，就不用担心默认导出的差异问题。

小结

其实 ESM 转 CJS，不同的工具的输出会稍微有些不同。以上是 Rollup 的的转换方式，个人认为这种更为简洁，而 TSC 的转换则更复杂。

不过这些工具的思路都是相同的，都遵守 __esModule 的约定，标记 __esModule 的模块默认导出是 .default

ESM 转 CJS 有哪些局限性？

存在以下情况可能无法进行转换：

CJS 转 ESM

CJS 转 ESM 的场景不多，一般不会用 CJS 写 npm 库然后输出 ESM；用 CJS 写的库，当时不会输出 ESM。新写的 npm 库，一般来说也是用 ESM 写。

因此一般只有写 ESM 项目，引入了一个只有 CJS 的库时，且编译出 ESM 时，才会用到 CJS 转 ESM。

为什么我们用 webpack 写 ESM，然后引入 CJS 的时候，基本上没遇到什么问题？

要运行 ESM 引入 CJS 的代码，有两种方式：

因为 webpack 是前者，ESM 转 CJS 能够很好地进行转换。

CJS 转 ESM，没有一种统一的转换标准（相对来说，ESM 转 CJS 有 __esModule 约定），不同的工具和库，可能转换出来的结果是不一样的，可能会导致代码不兼容。

export 的转换

场景一：

module.exports = {
    a: 3,
    b: 4
}

Rollup 会转换成

var lib = {
    a: 3,
    b: 4
};
export { lib as default };

module.exports 会被当做默认导出

而 esbuild 会这样转换

var __getOwnPropNames = Object.getOwnPropertyNames;
var __commonJS = (cb, mod) => function __require() {
  return mod || (0, cb[__getOwnPropNames(cb)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
};
var require_lib = __commonJS({
  "src/cjs/lib.js"(exports, module) {
    module.exports = {
      a: 3,
      b: 4
    };
  }
});
export default require_lib();

esbuild 会给代码包一层辅助函数，然后将代码搬过去就好了。好处是，这样编译工具就不需要考虑代码的真正意义，直接简单包一层即可

这种情况下，虽然 Rollup 和 esbuild 转换的代码不太相同，但代码的运行结果是相同的

场景二：

exports.c =123

Rollup 会转换成：

var lib = {};
var c = lib.c =123;
export { c, lib as default };

Rollup 会转换成默认导出和命名导出。

esbuild 则转换成：

var __getOwnPropNames = Object.getOwnPropertyNames;
var __commonJS = (cb, mod) => function __require() {
  return mod || (0, cb[__getOwnPropNames(cb)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
};
var require_lib = __commonJS({
  "src/cjs/lib.js"(exports) {
    exports.d = 666;
  }
});
export default require_lib();

仍然是包一层辅助函数，但 esbuild 全部都当做默认导出

在这种情况下，Rollup 和 esbuild 转换的代码，其运行结果是不同的

场景三：

exports.d = 123
module.exports = {
    a: 3,
    b: 4
}
exports.c =123

exports.d = 123 其实是无效的

Rollup 会编译成这样：

var libExports = {};
var lib$1 = {
  get exports(){ return libExports; },
  set exports(v){ libExports = v; },
};
(function (module, exports) {
	exports.d =123;
	module.exports = {
	    a: 3,
	    b: 4
	};
	exports.c =123;
} (lib$1, libExports));
var lib = libExports;
export { lib as default };

此时 Rollup 也会加上一层辅助函数

而 esbuild 仍然是加一层辅助函数

var __getOwnPropNames = Object.getOwnPropertyNames;
var __commonJS = (cb, mod) => function __require() {
  return mod || (0, cb[__getOwnPropNames(cb)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
};
var require_lib = __commonJS({
  "src/cjs/lib.js"(exports, module) {
    exports.d = 666;
    module.exports = {
      a: 3,
      b: 4
    };
    exports.c = 666;
  }
});
export default require_lib();

辅助函数的好处之前也说了，不需要关注代码逻辑，可以看到，即使 exports.d = 666; 是一行无效语句，照样执行也是没有问题的，不需要先分析出代码的语义。

总体对比下来，esbuild 的处理还是相对简单的

require 的转换

const lib = require('./lib')
const {c} = require('./lib')
console.info(lib,c)

Rollup 转换成：

import require$$0 from './lib';
const lib = require$$0;
const {c} = require$$0;
console.info(lib,c);

require 的转换比较简单，不管你解不解构，反正我就只有默认引入

而 esbuild。。。还不支持，干脆就报错了

小结

为什么工具的转换结果是不同的？

CJS 转换成 ESM 是有歧义的

module.export.a = 123
module.export.b = 345

等价于

module.export = {
    a: 123,
    b: 345,
}

那么它是默认导出，还是命名导出呢？都行

本质上，是因为 CJS 只有一个导出方式，不确定它对应的是 ESM 的命名导出还是默认导出。

用一个形象点的例子就是，女朋友回了一句哦，但是你不知道女朋友是想说肯定的意思，还是表示无语的意思、还是其他别的意思。。。

对于 require

const {c} = require('./lib')

你说这个是默认导入呢？还是命名导入？好像也都行。。。

正是由于这个歧义，且没有一个标准去规范这个转换行为，因此不同工具的转换结果是不同的

CJS 转换成 ESM 有哪些局限性？

module.exports.a = 123
if( Date.now() % 2){
    module.exports.b = 234
}

由于没有统一的标准，CJS 转 ESM 的工具，相对来说少了很多，目前仅有少量工具能够进行转换，esbuild、babel-plugin-transform-commonjs、@rollup/commonjs。

有时候 Vite 使用一些 CJS 包不兼容，也是因为有些 CJS 转不了 ESM。但幸运的是，目前大部分常见的 npm 包，都已经支持 ESM，或者能够比较好的被转换成 ESM，因此也不需要太担心 Vite 的问题。

以上就是教你彻底搞懂ESM与CJS互相转换的详细内容，更多关于ESM与CJS互相转换的资料请关注编程网其它相关文章！

阅读原文内容投诉

免责声明：

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析（完整版）

    难度     807人已做
    查看

  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     351人已做
    查看

  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     314人已做
    查看

  • 2024年上半年软考高项第一、二批次真题考点汇总（完整版）

    难度     433人已做
    查看

  • 2024年上半年系统架构设计师考试综合知识真题

    难度     221人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机

教你彻底搞懂ESM与CJS互相转换

前端开发2023-03-03

ESM与CJS互相转换怎么实现

前端开发2023-07-05
位置：首页-资讯-前端开发
咦！没有更多了？去看看其它编程学习网 内容吧
首页课程
资料下载问答资讯