详细了解前端模块化

发表于 3年以前 | 总阅读数：387 次

前言

本篇是关于前端模块化的文章，主要关注于理解什么是模块化，为什么要模块化，模块化规范的优缺点以及模块化规范的演变历程，让大家对模块化编程有一个更加清晰的理解和认识，这样在对后续一些概念进行学习时会有更深刻的认识与理解(比如为什么会出现tree-shaking呀等等)。

什么是模块化？

什么是"模块"?，比较简单的理解就是将一个工程项目代码依据一定的规则封装成多个模块(文件)，这些模块又通过向外提供一些方法与其他模块形成一种依赖的关系。从广义上来说的话，又可以将我们的工程项目里的模块归纳于内部的模块，项目引入调用的那些外部的包(package)则可以归纳为外部的模块。

外部模块的管理

2009年Node.js的创立使Javascript不再局限于前端，同时还成为了一门后端语言，我们可以使用Node.js独立开发App的后台，创建静态资源服务器，也可将它作为开发的工具将我们的代码编译转换为浏览器兼容的格式。一年之后Node.js模块管理工具npm(node package manager)的发布则颠覆了我们对外部模块的使用方式。

NPM之前对外部模块的使用

在npm发布之前，我们在项目中如果需要使用某个外部模块，可能需要去包的官网直接把文件下载下来放到我们的项目里，然后再在html里通过<Script>tag引入。

但是使用这种方法当然会带来许多麻烦，首先使用上肯定是不方便的，其次没有统一的版本管理机制，也难以追踪各个外部模块的来源

NPM之后对外部模块的使用

NPM是一个远程的JavaScript代码仓库，所有的开发者都可以向这里提交可共享的模块(npm publish)，使用者使用时只需通过命令行npm install对应的模块名便可将别人的模块下载到自己项目更目录中一个叫node_modules的子目录下，且每次npm install的时候，都会在package.json这个文件中更新模块和对应的版本信息。

内部模块的管理

本篇文章将重点讲解内部模块的管理，从最初的原生JS组织(IIFE)到后来的那些规范，例如CommonJS，AMD再到现在的ES6

原生JS组织

function模式：根据功能将代码封装为全局函数

function plusOne() {
  // ...
}



function minusOne() {
  // ...

这里的问题很明显，一来污染全局命名空间, 容易引起命名冲突和数据不安全，二来看不出模块之间的依赖关系

对象模式：通过对象进行封装

var caculator = {
  plusOne() {
    //...
  },
  minusOne() {
    //...
  }
}

这样通过对象封装虽然减少了全局变量，一定程度上解决了命名冲突的问题，但是还是存在数据安全的问题，从外部可以直接修改模块内部的数据

IIFE模式：通过立即调用函数封装

var calculator = (function(){
  var count = 0; 
  function plusOne() {
    count++;
  }
  function minusOne() {
    count--;
  }
  function printCount() {
    console.log(count);
  }
  return {
    plusOne,
    minusOne,
    printCount
  }
})()



calculator.plusOne();
calculator.printCount(); // 1

这里通过闭包与IIFE的概念解决了数据安全的问题，外部只有通过暴露的方法来操作。这里我们保持了内部数据私有的状态，这个对象类型的返回值则可以看成是这个模块的公共API，这个返回值最终被赋给了变量calculator，后续则可以通过calculator来调用API中的属性方法。

除了上面的方式，还有一个比较常见的方法则为通过全局对象windows来向外部暴露接口，这种方法也被广泛运用于一些项目里。比如jquery

(function (window) {
  //... 一些方法与变量
  // Expose jQuery to the global object
   window.jQuery = window.$ = jQuery;
})(window);

但是在我们项目开发过程中如果都用这种方式来阻止模块的话也会造成许多麻烦

看下面的代码：

<script type="text/javascript" src="modules/a.js"></script>
<script type="text/javascript" src="modules/b_dep_a.js"></script>
<script type="text/javascript" src= "modules/c_dep_b.js" ></script>

如上面的代码所示：

随着项目的增大html文件里的<script> tag会变得非常多，导致请求过多
在开发过程中通常各个模块的关系通常是树状的或者网状的，<script> tag的这种简单的先后顺序很难组织开发中模块间复杂的依赖关系，让代码的逻辑关系难以理解
出于<script> tag对顺序的要求，必须使用同步加载，因此在页面加载时也会导致页面卡死

模块化规范

后来的后来涌现出了各种各样的模块化规范来解决原生JS组织下的种种问题。

AMD&CMD

这两种规范历史比较久远，且比较接近，现在已经被淘汰，这里只做下简单的介绍（没用过）

两者的核心API类似：

define:定义一个模块
require:使用一个模块

代表工具库：

AMD:RequireJS[1]
CMD:Sea.js[2]

解决了什么问题？

首先我们假设一个场景：我们要输出模块a.js, a.js依赖于b.js和c.js, b.js又依赖于b1.js和b2.js。我们看下通过原生js组织与通过requireJS组织的区别

原生JS组织：

<script type="text/javascript" src="scripts/b1.js"></script>
<script type="text/javascript" src="scripts/b2.js"></script>
<script type="text/javascript" src="scripts/b.js"></script>
<script type="text/javascript" src="scripts/c.js"></script>
<script type="text/javascript" src= "scripts/a.js" ></script>

Require.js:

b.js:


define(function (require) {
    var dependency1 = require('b1'),
        dependency2 = require('b2');

    return function () {};
});

a.js:

define(function (require) {
    var dependency1 = require('c'),
        dependency2 = require('b');
    return function () {};
});

<script data-main="scripts/a" src="scripts/require.js"></script>

<!-- 或者 -->

<script src="scripts/require.js"></script> 
<script>require(["scripts/a"])</script>

可以看到Require.js的写法更好地显示了模块之间的依赖关系而不是简单的先后顺序，同时AMD正如其名 Asynchronous Module Definition, 可以去异步地加载模块，这里简单描述下实现逻辑：在浏览器执行时，RequireJS会对每一个模块创建一个Script标签，同时带上async参数[3]，加载完所有依赖的模块之后再通过load事件回调去执行我们最终输出的JS逻辑(类似Promise.all)

虽然AMD&CMD的出现解决了原生JS组织模块的一些问题，但是这种方案的显著痛点就是必须得等到用户浏览器下载了对应的require.js或者sea.js文件之后，才能进行模块依赖关系的分析，等于说整个过程放在了线上去执行，这必然会延长前端页面的加载时间，影响用户体验，同时在加载过程中突然生出了众多script标签http请求也影响页面性能。所以AMD和CMD后来自然而然被抛弃了。

CommonJS

CommonJS是Node.js使用的模块规范[4]，在 Node.js 模块系统中，每个文件都被视为独立的模块(对象)，模块的本地变量将是私有的，因为在执行模块代码之前，Node.js 将使用IIFE的方式对其进行封装：

(function(exports, require, module, __filename, __dirname) {
// 模块代码实际存在于此处
});

使用方法大家也比较熟悉，通过module.exports导出一个对象，再通过require来引用：

创建一个模块a.js：

const EventEmitter = require('events');

module.exports = new EventEmitter();

// 做一些工作，一段时间后从模块本身触发 'ready' 事件。
setTimeout(() => {
  module.exports.emit('ready');
}, 1000);

在另一个文件中引用这个模块：

const a = require('./a');
a.on('ready', () => {
  console.log('module "a" is ready');
});

ES6

这里重点讲下ES6，ES6 模块的设计思想是尽量的静态化，其模块依赖关系是确定的，和运行时的状态无关，我们先简单介绍下什么是静态分析。

静态分析

所谓静态分析就是不执行代码，从字面量上对代码进行分析，这里我们可以简单介绍下JS Engine的编译过程：

词法分析(Tokenizing/Lexing)：

这个过程会将由字符组成的字符串分解成(对编程语言来说)有意义的代码块，这些代码块被称为词法单元(var a = 2;。这段程序通常会被分解成为下面这些词法单元:var、a、=、2)

解析/语法分析(Parsing) :

这个过程是将词法单元流(数组)转换成一个由元素逐级嵌套所组成的代表了程序语法结构的树。这个树被称为“抽象语法树”(Abstract Syntax Tree，AST)。var a = 2; 的抽象语法树中可能会有一个叫作 VariableDeclaration 的顶级节点，接下来是一个叫作 Identifier(它的值是 a)的子节点，以及一个叫作 AssignmentExpression 的子节点。AssignmentExpression 节点有一个叫作 NumericLiteral(它的值是 2)的子节点。

代码生成:

将 AST 转换为可执行代码的过程被称为代码生成，简单来说就是有某种方法可以将 var a = 2; 的 AST 转化为一组机器指令，用来创建一个叫作 a 的变量(包括分配内存等)，并将一个值储存在 a 中。

ES6 Module特点：

只能作为模块顶层的语句出现
import 的模块名只能是字符串常量
import binding 是 immutable的

这些特点使我们在运行前就能确定ES6模块依赖关系，而在CommonJS中，我们可以动态require一个模块，所以只能在运行时确定这些东西：

const path = './' + fileName;

const myModual = require(path); // 非字符串常量
const foo = require(`./${['f', 'o', 'o'].join('')}`) // 非字符串常量

var load = function(path, name) { 
    if (name) { 
        return require(path + name); // 不在模块顶层
        } 
    return require(path) 
    }; 
}

再看ES6:

import foo from './foo';
import bar from './bar';

可以看到在编译过程通过识别import很容易就能得出使用了哪些模块，也正是因为ES6的这一特性让tree-shaking成为可能! 我们可以在编译时就将那些没有使用的模块功能摇掉来删除无用代码，这也是为什么 rollup 和 webpack 都要用 ES6 module syntax 才能 tree-shaking。