JS模块化，Javascript 模块化管理的历史

模块管理这个概念其实在前几年前端度过了刀耕火种年代以后就一直被提起。

直接回想起来的就是 cmd amd commonJS 这三大模块管理的印象。接下来，咱们来详细聊聊。

1、什么是模块化开发

为了让一整个庞大的项目看起来整整齐齐，规规整整而出现的模块化管理，咱们常见的三种模块化管理的库： requireJS、seaJS、commonJS规范 ( 注意，这里的commonJS不是一个库，而是一种规范) 逐渐的在咱们平常的开发中出现。 同时依赖于 这三类规范而出现的一些构建工具，但最后都败给了 webpack 。这是一篇介绍 webpack 基本入门的文章，能够结合着这篇文章来进行解读。 《前端之路》之 webpack 4.0+ 的应用构建

1-一、模块化第一阶段

在这个阶段中，咱们经常会把很是多复杂的功能 封装成一个个的函数：

function f1() {
    // todo
}

function f2() {
    // todo
}
.
.
.

可是当整个项目变大了之后，就会遇到不少问题，都是定义的全局变量，造成了比较严重的污染，还有可能会出现由于重命名致使的各类问题。

因此这些是须要进化的。因此就会进入到模块化的第二阶段： 对象。

1-二、封装到对象

到了第二个阶段为了不全局变量的污染，咱们会将单个模块封装到一个对象内部。以下：

const module = {
    _number: 10,
    f1: () => { 
        console.log(123)
    },
    f2: () => { 
        console.log(456)
    },
    .
    .
    .
}

这样咱们就设个模块定义一个对象，在须要的时候直接调用就行了，可是这样也会存在一个问题 这样写的话会暴露所有的对象内部的属性，内部状态能够被外部改变. 例如：

module._number = 100

若是咱们支付相关模块这样子来写的话。咱们随意的来改变支付的金额，那样就会出现比较危险的状况。

1-三、 对象的优化

后来，聪明的人类就想到了利用 当即执行函数 来达到 不暴露私有成员的目的

const module2 = (function() {
    let _money = 100
    const m1 = () => {
        console.log(123)
    }
    const m2 = () => {
        console.log(456)
    }
    return {
        f1: m1,
        f2: m2
    }
})()

经过当即执行函数，让外部根本没有时间从外部去修改内部的属性，从而达到必定的防护做用。

以上就是模块化开发的基础中的基础。 没有库，没有规范，一切的维护都是靠人力，一切的创新，都是来源于 解放生产力。

2、模块化管理的发展历程

2-一、CommonJS

CommonJS 的出发点： JS 没有完善的模块系统，标准库较少，缺乏包管理工具。（虽然这些东西，在后端语言中已是 早就被玩的不想玩的东西了） 伴随着 NodeJS 的兴起，能让 JS 能够在任何地方运行，特别是服务端，以达到 也具有 Java、C#、PHP这些后台语言具有开发大型应用的能力，因此 CommonJS 应运而生。

2-1-一、 CommonJS常见规范

• 一个文件就是一个模块，拥有单独的做用域
• 普通方式定义的 变量、函数、对象都属于该模块内
• 经过 require 来加载模块
• 经过 exports 和 module.exports 来暴露模块中的内容

咱们经过编写一个 Demo 来尝试写这个规范

Demo 1 : 经过 module.exports 来导出模块

// module.js
module.exports = {
  name: "zhang",
  getName: function() {
    console.log(this.name);
  },
  changeName: function(n) {
    this.name = n;
  }
};

// index.js
const module = require("./module/index");
console.log(module)    //  {name: "zhang", getName: ƒ, changeName: ƒ} "commons"

Demo 2 : 经过 exports 来导出模块

// module1.js
const getParam = () => {
  console.log(a);
};
let a = 123;
let b = 456;

exports.a = a;
exports.b = b;
exports.getParam = getParam;

// index.js
const module1 = require("./module/index1");
consoel.log(module1, "commons1")    // {a: 123, b: 456, getParam: ƒ} "commons1"

Demo 3 : 同时存在 exports 和 module.exports 来导出模块

// module2.js
let a = 123;

const getSome = () => {
  console.log("yyy");
};

const getA = () => {
  console.log(a);
};

exports.getSome = getSome;
module.exports = getA;

// index.js
const module2 = require("./module/index2");
consoel.log(module2, "commons2")    // function getA() {...}

总结 ： 经过这样的一个对比的例子就能够比较清晰的对比出 exports 和 module.exports 的区别: 一、当 exports 和 module.exports 同时存在的时候，module.exports 会盖过 exports 二、当模块内部所有是 exports 的时候， 就等同于 module.exports 三、最后 咱们就能够认定为 exports 其实就是 module.exports 的子集。

以上就是咱们对于 CommonJS 的一个初级的介绍。 还有一个硬性的规范，这里咱们只是作一下列举，就不作详细的 Demo 演示了。

2-1-二、 CommonJS 规范 --- 加载、做用域

全部代码都运行在模块做用域，不会污染全局做用域；模块能够屡次加载，但只会在第一次加载的时候运行一次，而后运行结果就被缓存了，之后再加载，就直接读取缓存结果；模块的加载顺序，按照代码的出现顺序是同步加载的;

2-1-三、 CommonJS 规范 --- __dirname、__filename

__dirname表明当前模块文件所在的文件夹路径，__filename表明当前模块文件所在的文件夹路径+文件名;

2-二、CommonJS 与 ES6（ES2015） 的 import export

在 ES2015 标准为出来以前，最主要的是CommonJS和AMD规范。上文中咱们已经介绍了 CommonJS 规范（主要是为了服务端 NodeJS 服务），那么当 ES6标准的出现，为浏览器端 模块化作了一个很是好的补充。

2-2-一、 ES6 的 export

export用于对外输出本模块（一个文件能够理解为一个模块）变量的接口

Demo 1 export { xxx }

// export/index.js
const a = "123";
const fn = () => window.location.href;

export { fn };

// show/index.js
const ex = require("./export/index");
import x from "./export/index";
import { fn } from "./export/index";
console.log(ex, "export1"); // {fn: ƒ, __esModule: true} "export1"
console.log(x, "export-x"); // undefined "export-x"
console.log(fn, "export-fn"); // function() { return window.location.href; } "export-x"

Demo 2 export default xxx

// export/index1.js
const a = "123";
const fn = () => window.location.href;
export default fn;


// show/index1.js
const ex1 = require("./export/index1");
import x from "./export/index1";

console.log(ex1, "export1"); 
// {default: ƒ, __esModule: true} "export1"
console.log(x, "export2"); 
// ƒ fn() {return window.location.href;} "export2"

经过 Demo 1 和 Demo 2 咱们能够很好的 对比了下 export 和 export default 的区别

export 能够导出的是一个对象中包含的多个 属性，方法。 export default 只能导出 一个 能够不具名的 对象。

import {fn} from './xxx/xxx' ( export 导出方式的 引用方式 ) import fn from './xxx/xxx1' ( export default 导出方式的 引用方式 )

同时，咱们发现 能够直接使用 require 来引用

这个也能引用其实有点神奇的。可是功能和 import 同样。（缘由就是我这里起了 webpack 的 server 相关）

2-2-二、 ES6 的 import

这里就同上面 Demo 中的例子同样了得出的结论就是

import {fn} from './xxx/xxx' ( export 导出方式的 引用方式 ) import fn from './xxx/xxx1' ( export default 导出方式的 引用方式 ，能够不用在乎导出模块的模块名)

总结： 以前对于 模块的导出、引用 的概念都比较的魔幻，此次经过知识的梳理终于搞清楚了。😄

4、总结

4-一、 为何会有这个东西？

方便组织你的代码，提升项目的可维护性。一个项目的可维护性高不高，也体现一个程序员的水平，在现在愈来愈复杂的前端项目，这一点尤其重要。

4-二、 为何不用requirejs，seajs等

它们功能强大，可是文件体积是个问题，此外还有就是业务有时候可能没那么复杂。

4-三、 适用场景

移动端页面，将js注入到html页面，这样就不用考虑模块加载的问题，从而节省了不少的代码，在实现上也更为的简单。 若是是多文件加载的话，须要手动执行文件加载顺序，那么其实最好用库来进行依赖管理会好一点。

4-四、 现实状况

webpack + commonJS + ES6 (import + export )

这样来 实现模块管理，实现 较大项目的管理。 好了，模块化管理就先介绍到这里了，欢迎一块儿探讨