模块化规范类型——很火的commonjs和Es Module

模块化的出现

为了解决的问题——相对于script标签引入的js文件
变量污染问题，每个文件都是独立的作用域，所以不存在变量污染——js文件作用域都是顶层，这会造成变量污染
代码维护问题，一个文件里代码非常清晰
文件依赖问题，一个文件里可以清楚的看到依赖了那些其它文件

模块化的规范

commonjs

module.exports导出变量及函数，也可以导出任意类型的值，require语法导入。
exports导出的值是值的拷贝，用解构拿到单个值
支持动态导入，代码发生在运行时指
顶层的this指向这个模块本身
require第一次加载某个模块时，Node会缓存该模块。以后再加载该模块，就直接从缓存取出该模块的module.exports属性
——基于服务端使用而生，同步执行，不适合客户端运行。浏览器端模块都放在服务器端，等待时间取决于网速的快慢，可能会阻塞。而服务器端所有的模块都存放在本地硬盘，可以同步加载完成，等待时间就是硬盘的读取时间
node加载：

// a.js
module.exports = {name:'ysl}
// main.js
let obj = require('./a.js')
// node环境可以直接使用

浏览器加载会报错，可以使用Browserify对模块进行转换

Es Module

使用export和export default导出。import语法导入。使用{}单个导入，但不是解构
export导出的值是值的引用，并且内部有映射关系。导入值不能修改
静态的，import只能声明在该文件的最顶部，不能动态加载语句
顶层this指向undefined
node加载：采用.mjs后缀文件名,项目的package.json文件中，指定type字段为module（未指定默认为commonjs）
浏览器加载：使用

<script src="index.js" type="module"></script>

通过 type=“module” 告诉浏览器，当前脚本使用 ESM 模式，浏览器会构建一个依赖关系图，借助浏览器原生的 ESM 能力完成模块的查找、解析、实例化到执行的过程。——解决了重复加载的问题

AMD

AMD是"Asynchronous Module Definition"的缩写，意思就是"异步模块定义"

模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到加载完成之后，运行回调函数
require.js类库实现了AMD规范

　　require([module], callback);

   define(id?, dependencies?, factory);

模块id和依赖都是可选的，factory函数的内容就是实际代码内容

cmd

对于依赖的模块AMD是提前执行，CMD是延迟执行
CMD推崇依赖就近，AMD推崇依赖前置

umd

对 CommonJs、CMD、AMD 进一步处理，集结了 CommonJs、CMD、AMD 的规范于一身
通过运行时或者编译时让同一个代码模块在使用 CommonJs、CMD 甚至是 AMD 的项目中运行

应用UMD规范的js文件其实就是一个立即执行函数。函数有两个参数，第一个参数是当前运行时环境，第二个参数是模块的定义体。在执行UMD规范时，会优先判断是当前环境是否支持AMD环境，然后再检验是否支持CommonJS环境，否则认为当前环境为浏览器环境（ window ）

结合Webpack看打包格式

output.library输出一个库为入口做导出

output.libraryTarget参数可以配置输出模块规范，与output.library.type作用相同

output.libraryTarget的取值：
（1）var，对一个变量赋值var Library = xxx
（2）this，设置this的Library属性，var Library = xxx
（3）commonjs，设置exports的Library属性，exports[“Library”] = xxx
（4）commonjs2，设置module.exports = xxx
（5）amd，导出为AMD格式
（6）umd，导出为AMD，CommonJS2，以及全局对象的一个属性

不同格式webpack打包后的结果

• var
  

• amd
  

• commonjs2
  

• umd
  

• window
  参考：
  聊聊什么是CommonJs和Es Module及它们的区别
  Javascript模块化编程（二）：AMD规范