本文尝试从 CommonJS 和 ES Module 两者规范的差异，详细说明该配置是如何影响 tsc 编译结果的。
tsconfig有个配置项esModuleInterop: boolean，它会影响 typescript 在编译时如何处理模块加载。该配置修改后(false -> true) 导致图片上传代码报错，报错部分代码摘要如下：
import * as TPS from '@ali/tps-node';const tps = new TPS({accesstoken: config.accessToken,});
报错信息如下：
TypeError: TPS is not a constructor-
把 esModuleInterop改回false，同时修改新增代码的模块导入方式。 -
调整已有代码，变更如下：
- import * as TPS from '@ali/tps-node';+ import TPS from '@ali/tps-node';
问题很快被修复。但是细想下，自己没有深究过这个特性背后的细节，例如还有没有其他修复方案？本文尝试从 CommonJS 和 ES Module 两者规范的差异，详细说明该配置是如何影响 tsc 编译结果的。
▐ ES Module 语法简介
foo.ts
定义如下：
export const foo = 'foo';class Foo {};export default Foo;
import Foo from './foo'表示导入 foo 模块的默认导出，即Foo Class
import * as foo from './foo'表示导入 foo 模块的所有导出，即：{ foo: 'foo', default: Foo }。
▐ CommonJS 语法简介
CommonJS 比较简单，类似前面示例 1，转为 CommonJS 写法如下：
exports.foo = 'foo',class Foo {};exports.default = Foo;
-
默认不做特殊处理，即： esModuleInterop=false，使用import * as XX from 'XX'语法导入一个 CommonJS 模块 -
兼容模式，即： esModuleInterop=true，将 CommonJS 的所有导出合并作为一个 default export，使用import XX from 'XX'语法导入 CommonJS 模块。
false
或
true
对
导入 ES Module 模块无影响。
▐ esModuleInterop = false 时如何编译
其默认编译行为如下：
import * as foo from 'abc'会被编译为：const foo = require('abc')。import foo, { bar } from 'abc'会被编译为：const foo_1 = require('abc')，同时调用该模块的代码会被 tsc 一同修改：
- foo.xxx();- bar();+ foo_1.default.xxx();+ foo_1.bar();
此时，当我们导入一个 CommonJS 模块时，主要注意：
该 CommonJS 模块导出的是否为一个普通对象，如果是的话，也可以用
import { XX } from 'abc'导入该模块的部分属性。该 CommonJS 模块是否导出
default属性（一般情况下是没有的）。没有则不能使用import XX from 'abc'的语法。
▐ esModuleInterop = true 时如何编译
Interop：可以理解为系统间不需要特殊配置就可以配合工作。
配置开启后，tsc 会对 CommonJS 打补丁，将其转为一个符合 ES Module 规范的模块：tsc 会引入两个助手方法：__importDefault、__importStar，来抹平 CommonJS 和 ES module 模块导出的差异。
__importDefault 说明
当使用默认导入语法时：import XX from 'abc'，其会被编译为：const XX_1 = __importDefault(require('abc'))。
一般情况下 CommonJS 模块是没有导出 default 属性的，所以无法使用默认导入语法。__importDefault就是将 CommonJS 导出的内容，合并为一个默认导出：
{"default": require('一个CommonJS模块')}
这么一来，类似fs模块，就可以直接用import fs from 'fs'导入了：
import fs from 'fs'fs.readFileSync();// 编译后伪代码如下所示：const fs = __importDefault(require('fs'));// 此时 fs = { default: { readFileSync, writeFileSync} };fs.default.readFileSync();
__importStar 说明
当使用导入所有语法import * as XX from 'abc'时，其会被编译为：const XX = __importStar(require('abc')
importStar是importDefault的升级版：除了设置default属性为被导出模块，还会将被导入模块的所有可枚举属性（不含原型链继承），都代理过去。示例如下：
import * as fs from 'fs'fs.readFileSync();// 编译后伪代码如下所示：const fs = __importStar(require('fs'));// 此时 fs = { readFileSync, writeFileSync, default: { readFileSync, writeFileSync} };fs.readFileSync();
通过前面 importStar 和 importDefault 的实现分析会发现：对于类似 fs 这样的模块（导出结果是一个普通对象），不论是使用哪种方法是导入，都是可以正确使用的。即，在开启 esModuleInterop 前，使用import * as fs 语法导入 fs 模块，开启 esModuleInterop 后，改写法仍然是兼容的，不需要修改。
而文章开头的代码之所以会在运行时报错，是因为 tps-node 模块导出的是一个 class。__importStar 会把模块可枚举属性导出，但是在 module.exports = 函数/类 这一场景下，是否无法导出函数、类的。但是我们可以用 default 属性来调用：
import * as TPS from '@ali/tps-node';- const tps = new TPS({+ const tps = new TPS.default({accesstoken: config.accessToken,});
这就是第三种解法。这种写法看上去比较怪异，不熟悉的人会完全看不懂：default 属性哪里来的？所以，ts 中导入一个 CommonJS 模块最佳实践仍然是：
esModuleInterop=false，使用import * as XX语法esModuleInterop=true，使用import XX from 'XX'语法
我们是大淘宝技术前端 - 活动与场制作团队，负责阿里最核心业务(电商)的最核心板块(淘宝营销活动)；团队核心亮点：
-
负责并深度参与双十一、618、造物节等大促活动； -
负责营销活动对应面向小二的营销页面搭建产品；服务淘宝、天猫数千运营小二，所有营销会场页面从这里诞生； -
负责营销活动对应面向商家的营销页面搭建产品；这是大淘宝前端内唯一一个纯nodejs开发的面向数十万商家提供服务的中后台应用，挑战基于nodejs下的超高稳定性、开放性、扩展性和性能要求 -
负责大淘宝营销活动页面的终端渲染方案：基于搭建场景下，业务隔离可扩展、极致性能体验的营销终端渲染架构 -
负责构建营销搭建产品的产研平台 ：提供可扩展可编排营销页面制作能力的产研平台；在这里有要解决业务研发效率的面向中后台前端+后端的应用功能扩展方案，有面向数十万行代码的中大型应用下的技术架构设计：微服务化、DDD模式、faas化、nodejs热更新等等
本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。