当前位置：首页 > news >正文

关于JavaScript、TypeScript Module的配置和用法

news 来源：原创 2025/5/30 13:17:20

文章目录

1、 CommonJS到ES的历史原因
2、[package.json 的type字段](https://nodejs.org/api/packages.html#type)
3、[tsconfig.json 的compilerOptions.module](https://www.typescriptlang.org/tsconfig/#module)
4、示例
- ES6
- - 编译成不同模块的输出的js代码
  - - tsconfig.json 的compilerOptions.module设置为 `"module": "es6"`，上述代码生成的js代码
    - 设置为 `"module": "commonjs"`，上述代码生成的js代码
- CommonJS
- - 编译成不同模块的输出的js代码
  - - tsconfig.json 的compilerOptions.module设置为 `"module": "es6"` 和 `"module": "commonjs"`，上述ts代码生成的js代码是一样的

1、 CommonJS到ES的历史原因

JavaScript模块系统的发展历史，主要是为了解决代码组织、复用和依赖管理的问题，尤其是在语言本身最初缺乏内置模块机制的情况下。

早期 (无模块系统)

最初，JavaScript主要用于浏览器中的简单脚本，代码通常写在单个文件或通过多个<script>标签引入。
这导致了全局命名空间污染、代码难以维护和复用等问题。

CommonJS (CJS) 的出现

背景: Node.js 的诞生 (2009年) 需要一种在服务器端组织和管理代码的方式。浏览器端的同步加载不是问题，因为文件都在本地。
主要特点:
- 使用 require() 同步加载模块。
- 通过 module.exports 或 exports 导出模块内容。
- 每个文件是一个模块，拥有自己的作用域。
原因:
- 服务器端需求: Node.js 需要一种强大的模块化方案来构建大型应用。
- 同步加载可行性: 在服务器端，模块文件通常在本地磁盘，同步加载性能影响较小。
影响: CommonJS 成为 Node.js 社区事实上的标准，极大地促进了 Node.js 生态的发展。

AMD (Asynchronous Module Definition) 的出现

背景: CommonJS 的同步加载机制不适合浏览器环境。在浏览器中，脚本通常需要从网络异步加载，同步加载会阻塞页面渲染。
主要特点:
- 使用 define() 函数定义模块，并明确声明依赖。
- 依赖的模块会被异步加载，加载完成后执行回调。
- 代表库: RequireJS。
原因:
- 浏览器异步需求: 解决浏览器中脚本加载的阻塞问题。
- 依赖前置: 需要在使用模块前声明所有依赖。

UMD (Universal Module Definition)

背景: 为了让同一个模块代码能同时在 CommonJS (如Node.js) 和 AMD (如浏览器) 环境下运行，UMD 模式应运而生。
主要特点: UMD 本质上是一个立即执行函数，它通过判断当前环境支持哪种模块规范 (CommonJS, AMD, 或全局变量) 来决定如何导出模块。
原因:
- 代码复用: 提高库的通用性，使其能在不同环境中使用。

ES Modules (ESM) 的出现 (官方标准)

背景: JavaScript 语言本身需要一个统一的、官方的模块化标准，以结束各种社区方案并存的局面，并更好地支持静态分析。
主要特点:
- 使用 import 关键字导入模块，export 关键字导出模块。
- 可以使用require
- 静态结构: import 和 export 必须在模块的顶层，不能在条件语句或函数中。这使得编译时就能确定模块的依赖关系。
- 异步加载: 设计上支持异步加载，对浏览器友好。
- Tree Shaking: 静态结构使得打包工具（如Webpack, Rollup）可以进行 Tree Shaking，移除未使用的代码，减小打包体积。
- 浏览器和现代 Node.js 版本原生支持。
原因:
- 语言标准化: TC39 (JavaScript 的标准制定委员会) 推动了 ESM 作为官方标准。
- 静态分析和优化: 静态结构便于工具进行代码分析、优化（如 Tree Shaking）和错误检查。
- 浏览器和服务器统一: 提供一个在浏览器和服务器端都能良好工作的统一模块系统。
- 更好的开发体验: 语法更简洁、更符合现代编程习惯。

发展原因总结:

代码组织和复用: 最根本的需求是更好地组织和复用代码，避免全局污染。
环境差异: 服务器端 (Node.js) 和浏览器端对模块加载方式 (同步 vs. 异步) 的不同需求催生了 CommonJS 和 AMD。
统一性需求: 社区中多种模块方案并存导致了混乱，需要一个官方标准来统一。
性能和工具链优化: 对静态分析、Tree Shaking 等优化的需求推动了 ESM 的设计。
语言现代化: 作为一门现代编程语言，拥有内置的模块系统是其发展的必然趋势。

目前，ES Modules 是 JavaScript 官方推荐和未来的标准模块系统，虽然 CommonJS 仍然在 Node.js 生态中有大量存量代码，但新的项目和库越来越倾向于使用 ESM。Node.js 也通过 package.json 中的 "type": "module" 字段以及 .mjs 和 .cjs 文件扩展名来支持 ESM 和 CJS 的共存与互操作。