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!

很久之前,我和少数几个童鞋(github.com/umdjs?)提出了一种最绝望的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支持就好了,这正是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

文章被以下专栏收录
3 条评论