ES6的模块、构建工具及应用的发布

总的说来就是按照将来的标准书写，现在使用工具来适配。

我们已经有了服务端的依赖管理方案

1. 安装并声明依赖；
2. 在代码中获取（require）依赖；
3. 将通用的代码打包并发布到同一个地方。（npm、gems等等）

浏览器端的依赖管理远远没有完成，并且现在情况看上去很糟糕

1. 有各种各样的模块规范；
2. 有很多包管理工具；
3. 通用的代码被打包，到处发布，用户用起来还是很不方便。

这很重要

我们需要把这个问题解决掉——当有人搞了一个Angular的directive、一个Ember组件、一个web组件抑或一个老的但是有用javascript类库，他们需要一种简单方式来分享这些代码。Node在这方面很成功，因为npm使用起来很简单。

在Node中使用第三方的代码很简单。

1. 在cli中运行$ npm install backbone来安装backbone；
2. 在你的程序中通过var Backbone = require(‘backbone‘)来使用backbone。

我想在浏览器端也这么做，但是首先：

我们有三种分发的方式

1. （通常的做法是）一次加载整个程序；
2. 逐步加载部分打包（也很常见）；
3. 完全不打包（虽然可行，但是最坑爹）。

程序打包策略不一样

1. 配置合并
1. 加载整个目录；
2. 添加显示的配置，指定加载顺序。
2. 依赖分析（r.js、browserify）
1. 这正是服务端使用的方式，只是不打包而已；
2. 整个打包背后的关键，就是为浏览器创建一个模块的运行时。

程序分发表

根据程序的分发方式和打包策略，我们得到下面这张表：

CJS/globals也可以通过$.getScript或者类似的工具来实现程序的局部加载，但这并不是模块规范的一部分。

以前，如你所见，我支持AMD，因为它支持所有的场景。虽然AMD获得了大量的关注，但是并没有被所有的类库作者、包管理器和JavaScript运行环境所接受。

现存的工具并不能处理所有这些使用场景。你必须使用你依赖的工具使用的规范，你所依赖的类库也需要这样做。

我们需要一种模块规范，能适配现存的工具

1. global，非申明式的，无法使用工具来分析依赖，不行；
2. AMD，坑爹，不是所有的人都适配它；
3. CJS，并不能满足所有的程序分发方式。

所以，不管你为你的程序选择什么，你都必须为这那些第三方模块整点hack，因为这些模块并不满足你使用的模块系统

直到UMD“横空出世”。

什么是UMD！

很久之前，我和少数几个童鞋（https://github.com/umdjs?tab=members）提出了一种最绝望的JavaScript模块规范——Universal Module Definition。

和它名字的意思一样，这种规范基本上可以在任何一个模块环境中工作。

如果Backbone、Ember、moment、angular，或者某人的某段代码都是以UMD规范写的，那你在它们上使用任何现有前端工具。例如，你可以：

1. 选择AMD，用bower安装，用r.js构建；
2. 和1一样，不构建；
3. 选择CommonJS，用npm安装，用browserify安装；
4. 选择AMD，用npm安装，r.js构建；
5. 什么规范都不用，直接使用script在页面中引用；
6. 使用那些有支持UMD的组件。

我可以弄出一个交叉的表格，包含所有的模块格式、包管理器以及构建工具。但是你应该清楚了，因为它支持了所有现有的工具，所以支持所有程序分发的方式。

但是有一个问题，umd让自动修正变得很乱，我没有撒谎，举个例子，这里有一种非常糟糕的使用backbone的方式：

(function (root, factory) {
  if (typeof define === ‘function‘ && define.amd) {
    // AMD
    define(‘backbone‘, [‘jquery‘, ‘underscore‘], function (jQuery, _) {
      return factory(jQuery, _);
    });
  } else if (typeof exports === ‘object‘) {
  // Node.js
    module.exports = factory(require(‘jquery‘), require(‘underscore‘));
  } else {
    // Browser globals
    root.Backbone = factory(root.jQuery, root._);
  }
}(this, function (jQuery, _) {
  var Backbone = {};
  // Backbone code that depends on jQuery and _
  return Backbone;

}));

你看得出为什么这无法流行起来，它太恐怖了，没有人会这样写，看着它，我只想咒骂。

使用ES6，编译成UMD，到处使用

ES6模块规范出现，于是类库开发者可以使用ES6来编写代码，然后转成UMD格式，发到哪里都可以（npm、bower等等）。

1. 这与非结构化的CJS一样优秀，甚至超过CJS；
2. 这是未来，无论如何，你最终要使用这种模式。

现在还差的就是给umdjs/es6-module-transpiler · GitHub添加对UMD支持就好了，这正是https://twitter.com/machty和我正在做的事情。

这需要类库作者的支持

这可能是一场艰苦卓绝的战斗，但是：

1. 任何关注浏览器端模块化的人看得出它的好处；
2. 最终ES6会落地，有一个平台鼓励人们这么做；
3. 我们可以fork或者shim他们的repos，然后让模块管理器使用这个fork或者shim（bower一直都是这么干的）。

未来

第一步，让类库作者支持ES6；

第二步，让模块管理器支持es5，并为我们编译；

第三步，坐等es6落地。

我们可以！

请关注umdjs/es6-module-transpiler · GitHub，等着我们搞定UMD，接下来会给出几个例子。

原文：ES6 Modules, Build Tools and Browser App Delivery ? Ryan Florence Online