关于webpack:前端工程化模块化开发下22

后面说了 gulp 工作流
这边当初来讲下模块化开发
模块化开发是当下最重要的开发范式
模块化只是思维。
模块化的演变过程：

文件划分的形式（原始形式齐全靠约定）
毛病：
1. 净化全局作用域
2. 命名抵触
3. 无奈治理模块依赖关系

2. 命名空间形式（放到一个对象，而后再对立应用）
3. 而后就是 AMD 和 CMD 标准 (社区逐步提出的标准, 历史本章不作为重点讲)
而后当初最初就是模块化标准的最佳实际：
node.js 的 CommonJS 和 eES Modules（官网推出）
Es Modules 根本个性：

主动采纳严格模式，疏忽 ”use strict”
每个 ESM 模块都是独自的公有作用域
ESM 是通过 CORS 去申请内部 js 模块（须要容许 CORS 资源申请）
ESM 的 script 标签会提早执行脚本（不会像失常 script 标签立刻执行）

这里导入的是一个只读性援用，所以模块内部不可更改，多个中央导入，模块外部值变动都会影响导入中央。
import 是一个导入申明，在头部应用，不可呈现在条件中
属于是动态阶段确定依赖，能够按需引入依赖项，动静执行，理论执行的时候去模块内取值。
和 commonjs 相互导入反对 export {}是固定语法，不是导出对象

动静导入 import()返回一个 promsie

CommonJS 特点：

所有代码都运行在模块作用域，不会净化全局作用域。
模块能够屡次加载，然而只会在第一次加载时运行一次，而后运行后果就被缓存了，当前再加载，就间接读取缓存后果。要想让模块再次运行，必须革除缓存。
模块加载的程序，依照其在代码中呈现的程序。
属于动静加载，一导入会把其余模块导出的货色，整体导入

对 module 对象的形容：
1.module.exports 属性
module.exports 属性示意以后模块对外输入的接口，其余文件加载该模块，实际上就是读取 module.exports 变量。
2.exports 变量
node 为每一个模块提供了一个 exports 变量(能够说是一个对象)，指向 module.exports。这相当于每个模块中都有一句这样的命令 var exports = module.exports;

这样，在对外输入时，能够在这个变量上增加办法。例如 exports.add = function (r){return Math.PI r r}; 留神：不能把 exports 间接指向一个值，这样就相当于切断了 exports 和 module.exports 的关系。例如 exports=function(x){console.log(x)};
一个模块的对外接口，就是一个繁多的值，不能应用 exports 输入，必须应用 module.exports 输入。module.exports=function(x){console.log(x);};

在浏览器咱们是不适宜应用 CommonJS 标准的，动静读取时查看到这个 require 模块，而后发申请返回文件，这会程序会卡在那里，这对服务器端不是一个问题，因为所有的模块都寄存在本地硬盘，能够同步加载实现，等待时间就是硬盘的读取工夫。然而，对于浏览器，这却是一个大问题，因为模块都放在服务器端，等待时间取决于网速的快慢，可能要等很长时间，浏览器处于 ” 假死 ” 状态。

所以浏览器应用的是 ESM, 然而因为它是 es6 的模块，有局部浏览器还不反对

模块化开发

用阮老师的话来说，这两个不好辨别，那就放弃 exports，只用 module.exports 就好（手动机智）