关于babel:一口气了解babel

最近几年，如果你是一名前端开发者，如果你没有应用甚至据说过 babel，可能会被当做穿梭者吧？

说到 babel，一连串名词会蹦出来：

babel-cli
babel-core
babel-runtime
babel-node
babel-polyfill
…

这些都是 babel 吗？他们别离是做什么的？有区别吗？

简略来说把 JavaScript 中 es2015/2016/2017/2046 的新语法转化为 es5，让低端运行环境 (如浏览器和 node) 可能意识并执行。本文以 babel 6.x 为基准进行探讨。最近 babel 出了 7.x，放在最初聊。

严格来说，babel 也能够转化为更低的标准。但以目前状况来说，es5 标准曾经足以笼罩绝大部分浏览器，因而惯例来说转到 es5 是一个平安且风行的做法。

如果你对 es5/es2015 等等也不理解的话，那你可能真的须要先补补课了。

总共存在三种形式：

应用单体文件 (standalone script)
命令行 (cli)
构建工具的插件 (webpack 的 babel-loader, rollup 的 rollup-plugin-babel)。

其中前面两种比拟常见。第二种多见于 package.json 中的 scripts 段落中的某条命令；第三种就间接集成到构建工具中。

这三种形式只有入口不同而已，调用的 babel 内核，解决形式都是一样的，所以咱们先不纠结入口的问题。

babel 总共分为三个阶段：解析，转换，生成。

babel 自身不具备任何转化性能，它把转化的性能都合成到一个个 plugin 外面。因而当咱们不配置任何插件时，通过 babel 的代码和输出是雷同的。

插件总共分为两种：

当咱们增加 语法插件 之后，在解析这一步就使得 babel 可能解析更多的语法。(顺带一提，babel 外部应用的解析类库叫做 babylon，并非 babel 自行开发)

举个简略的例子，当咱们定义或者调用办法时，最初一个参数之后是不容许减少逗号的，如 callFoo(param1, param2,) 就是非法的。如果源码是这种写法，通过 babel 之后就会提醒语法错误。

但最近的 JS 提案中曾经容许了这种新的写法(让代码 diff 更加清晰)。为了防止 babel 报错，就须要减少语法插件 babel-plugin-syntax-trailing-function-commas

当咱们增加 转译插件 之后，在转换这一步把源码转换并输入。这也是咱们应用 babel 最实质的需要。

比起语法插件，转译插件其实更好了解，比方箭头函数 (a) => a 就会转化为 function (a) {return a}。实现这个工作的插件叫做 babel-plugin-transform-es2015-arrow-functions。

同一类语法可能同时存在语法插件版本和转译插件版本。如果咱们应用了转译插件，就不必再应用语法插件了。

既然插件是 babel 的基本，那如何应用呢？总共分为 2 个步骤：

将插件的名字减少到配置文件中 (根目录下创立 .babelrc 或者 package.json 的 babel 外面，格局雷同)
应用 npm install babel-plugin-xxx 进行装置

具体书写格局就不详述了。

比方 es2015 是一套标准，蕴含大略十几二十个转译插件。如果每次要开发者一个个增加并装置，配置文件很长不说，npm install 的工夫也会很长，更不谈咱们可能还要同时应用其余标准呢。

为了解决这个问题，babel 还提供了一组插件的汇合。因为罕用，所以不用反复定义 & 装置。(单点和套餐的差异，套餐省下了巨多的工夫和配置的精力)

preset 分为以下几种：

官网内容，目前包含 env, react, flow, minify 等。这里最重要的是 env，前面会具体介绍。
stage-x，这外面蕴含的都是当年最新标准的草案，每年更新。
这外面还细分为
- Stage 0 – 稻草人: 只是一个想法，通过 TC39 成员提出即可。
- Stage 1 – 提案: 初步尝试。
- Stage 2 – 初稿: 实现初步标准。
- Stage 3 – 候选: 实现标准和浏览器初步实现。
- Stage 4 – 实现: 将被增加到下一年度公布。

例如 syntax-dynamic-import 就是 stage-2 的内容，transform-object-rest-spread 就是 stage-3 的内容。
此外，低一级的 stage 会蕴含所有高级 stage 的内容，例如 stage-1 会蕴含 stage-2, stage-3 的所有内容。
stage-4 在下一年更新会间接放到 env 中，所以没有独自的 stage-4 可供使用。

es201x, latest
这些是曾经纳入到标准规范的语法。例如 es2015 蕴含 arrow-functions，es2017 蕴含 syntax-trailing-function-commas。但因为 env 的呈现，使得 es2016 和 es2017 都曾经废除。所以咱们常常能够看到 es2015 被独自列出来，但极少看到其余两个。
latest 是 env 的雏形，它是一个每年更新的 preset，目标是蕴含所有 es201x。但也是因为更加灵便的 env 的呈现，曾经废除。

很简略的几条准则：

Plugin 会运行在 Preset 之前。
Plugin 会从前到后程序执行。
Preset 的程序则 刚好相同(从后向前)。

preset 的逆向程序次要是为了保障向后兼容，因为大多数用户的编写程序是 ['es2015', 'stage-0']。这样必须先执行 stage-0 能力确保 babel 不报错。因而咱们编排 preset 的时候，也要留神程序，其实只有依照标准的工夫程序列出即可。

简略状况下，插件和 preset 只有列出字符串格局的名字即可。但如果某个 preset 或者插件须要一些配置项(或者说参数)，就须要把本人先变成数组。第一个元素仍然是字符串，示意本人的名字；第二个元素是一个对象，即配置对象。

最须要配置的当属 env，如下：

"presets": [
    // 带了配置项，本人变成数组
    [
        // 第一个元素仍然是名字
        "env",
        // 第二个元素是对象，列出配置项
        {"module": false}
    ],

    // 不带配置项，间接列出名字
    "stage-2"
]

因为 env 最为罕用也最重要，所以咱们有必要重点关注。

env 的外围目标是通过配置得悉指标环境的特点，而后只做必要的转换。例如指标浏览器反对 es2015，那么 es2015 这个 preset 其实是不须要的，于是代码就能够小一点(个别转化后的代码总是更长)，构建工夫也能够缩短一些。

如果不写任何配置项，env 等价于 latest，也等价于 es2015 + es2016 + es2017 三个相加(不蕴含 stage-x 中的插件)。env 蕴含的插件列表保护在这里

上面列出几种比拟罕用的配置办法：

{
  "presets": [
    ["env", {
      "targets": {"browsers": ["last 2 versions", "safari >= 7"]
      }
    }]
  ]
}

如上配置将思考所有浏览器的最新 2 个版本 (safari 大于等于 7.0 的版本) 的个性，将必要的代码进行转换。而这些版本已有的性能就不进行转化了。这里的语法能够参考 browserslist

{
  "presets": [
    ["env", {
      "targets": {"node": "6.10"}
    }]
  ]
}

如上配置将指标设置为 nodejs，并且反对 6.10 及以上的版本。也能够应用 node: 'current' 来反对最新稳固版本。例如箭头函数在 nodejs 6 及以上将不被转化，但如果是 nodejs 0.12 就会被转化了。

另外一个有用的配置项是 modules。它的取值能够是 amd, umd, systemjs, commonjs 和 false。这能够让 babel 以特定的模块化格局来输入代码。如果抉择 false 就不进行模块化解决。

以上探讨了 babel 的外围解决机制和配置办法等，不管任何入口调用 babel 都走这一套。但文章结尾提的那一堆 babel-* 还是让人一头雾水。实际上这些 babel-* 大多是不同的入口 (形式) 来应用 babel，上面来简略介绍一下。

顾名思义，cli 就是命令行工具。装置了 babel-cli 就可能在命令行中应用 babel 命令来编译文件。

在开发 npm package 时常常会应用如下模式：

把 babel-cli 装置为 devDependencies
在 package.json 中增加 scripts (比方 prepublish)，应用 babel 命令编译文件
npm publish

这样既能够应用较新标准的 JS 语法编写源码，同时又能反对旧版环境。因为我的项目可能不太大，用不到构建工具 (webpack 或者 rollup)，于是在公布之前用 babel-cli 进行解决。

babel-node 是 babel-cli 的一部分，它不须要独自装置。

它的作用是在 node 环境中，间接运行 es2015 的代码，而不须要额定进行转码。例如咱们有一个 js 文件以 es2015 的语法进行编写(如应用了箭头函数)。咱们能够间接应用 babel-node es2015.js 进行执行，而不必再进行转码了。

能够说：babel-node = babel-polyfill + babel-register。那这两位又是谁呢？

babel-register 模块改写 require 命令，为它加上一个钩子。尔后，每当应用 require 加载 .js、.jsx、.es 和 .es6 后缀名的文件，就会先用 babel 进行转码。

应用时，必须首先加载 require('babel-register')。

须要留神的是，babel-register 只会对 require 命令加载的文件转码，而 不会对以后文件转码。

另外，因为它是实时转码，所以 只适宜在开发环境应用。

babel 默认只转换 js 语法，而不转换新的 API，比方 Iterator、Generator、Set、Maps、Proxy、Reflect、Symbol、Promise 等全局对象，以及一些定义在全局对象上的办法 (比方 Object.assign) 都不会转码。

举例来说，es2015 在 Array 对象上新增了 Array.from 办法。babel 就不会转码这个办法。如果想让这个办法运行，必须应用 babel-polyfill。(外部集成了 core-js 和 regenerator)

应用时，在所有代码运行之前减少 require('babel-polyfill')。或者更惯例的操作是在 webpack.config.js 中将 babel-polyfill 作为第一个 entry。因而必须把 babel-polyfill 作为 dependencies 而不是 devDependencies

babel-polyfill 次要有两个毛病：

应用 babel-polyfill 会导致打进去的包十分大，因为 babel-polyfill 是一个整体，把所有办法都加到原型链上。比方咱们只应用了 Array.from，但它把 Object.defineProperty 也给加上了，这就是一种节约了。这个问题能够通过独自应用 core-js 的某个类库来解决，core-js 都是离开的。
babel-polyfill 会净化全局变量，给很多类的原型链上都作了批改，如果咱们开发的也是一个类库供其余开发者应用，这种状况就会变得十分不可控。

因而在理论应用中，如果咱们无法忍受这两个毛病(尤其是第二个)，通常咱们会偏向于应用 babel-plugin-transform-runtime。

但如果代码中蕴含高版本 js 中类型的实例办法 (例如 [1,2,3].includes(1))，这还是要应用 polyfill。

咱们时常在我的项目中看到 .babelrc 中应用 babel-plugin-transform-runtime，而 package.json 中的 dependencies (留神不是 devDependencies) 又蕴含了 babel-runtime，那这两个是不是成套应用的呢？他们又起什么作用呢？

先说 babel-plugin-transform-runtime。

babel 会转换 js 语法，之前曾经提过了。以 async/await 举例，如果不应用这个 plugin (即默认状况)，转换后的代码大略是：

// babel 增加一个办法，把 async 转化为 generator
function _asyncToGenerator(fn) {return function () {....}} // 很长很长一段

// 具体应用处
var _ref = _asyncToGenerator(function* (arg1, arg2) {yield (0, something)(arg1, arg2);
});

不必过于纠结具体的语法，只需看到，这个 _asyncToGenerator 在以后文件被定义，而后被应用了，以替换源代码的 await。但每个被转化的文件都会插入一段 _asyncToGenerator 这就导致反复和节约了。

在应用了 babel-plugin-transform-runtime 了之后，转化后的代码会变成

// 从间接定义改为援用，这样就不会反复定义了。var _asyncToGenerator2 = require('babel-runtime/helpers/asyncToGenerator');
var _asyncToGenerator3 = _interopRequireDefault(_asyncToGenerator2);

// 具体应用处是一样的
var _ref = _asyncToGenerator3(function* (arg1, arg2) {yield (0, something)(arg1, arg2);
});

从定义方法改成援用，那反复定义就变成了反复援用，就不存在代码反复的问题了。

但在这里，咱们也发现 babel-runtime 出场了，它就是这些办法的汇合处，也因而，在应用 babel-plugin-transform-runtime 的时候必须把 babel-runtime 当做依赖。

再说 babel-runtime，它外部集成了

core-js: 转换一些内置类 (Promise, Symbols等等) 和静态方法 (Array.from 等)。绝大部分转换是这里做的。主动引入。
regenerator: 作为 core-js 的拾遗补漏，次要是 generator/yield 和 async/await 两组的反对。当代码中有应用 generators/async 时主动引入。
helpers, 如下面的 asyncToGenerator 就是其中之一，其余还有如 jsx, classCallCheck 等等，能够查看 babel-helpers。在代码中有内置的 helpers 应用时 (如下面的第一段代码) 移除定义，并插入援用(于是就变成了第二段代码)。

babel-plugin-transform-runtime 不反对 实例办法 (例如 [1,2,3].includes(1))

此外补充一点，把 helpers 抽离并对立起来，防止反复代码的工作还有一个 plugin 也能做，叫做 babel-plugin-external-helpers。但因为咱们应用的 transform-runtime 曾经蕴含了这个性能，因而不用重复使用。而且 babel 的作者们也曾经开始探讨这两个插件过于相似，正在探讨在 babel 7 中把 external-helpers 删除，探讨在 issue#5699 中。

后面提过 babel 的三种应用办法，并且曾经介绍过了 babel-cli。但一些大型的我的项目都会有构建工具 (如 webpack 或 rollup) 来进行代码构建和压缩 (uglify)。实践上来说，咱们也能够对压缩后的代码进行 babel 解决，但那会十分慢。因而如果在 uglify 之前就退出 babel 解决，岂不完满？

所以就有了 babel 插入到构建工具外部这样的需要。以(我还算相熟的) webpack 为例，webpack 有 loader 的概念，因而就呈现了 babel-loader。

和 babel-cli 一样，babel-loader 也会读取 .babelrc 或者 package.json 中的 babel 段作为本人的配置，之后的内核解决也是雷同。惟一比 babel-cli 简单的是，它须要和 webpack 交互，因而须要在 webpack 这边进行配置。比拟常见的如下：

module: {
  rules: [
    {
      test: /\.js$/,
      exclude: /(node_modules|bower_components)/,
      loader: 'babel-loader'
    }
  ]
}

如果想在这里传入 babel 的配置项，也能够把改成：

// loader: 'babel-loader' 改成如下：use: {
  loader: 'babel-loader',
  options: {// 配置项在这里}
}

这里的配置项优先级是最高的。但我认为放到独自的配置文件中更加清晰正当，可读性强一些。

最近 babel 公布了 7.0。因为下面局部都是针对 6.x 编写的，所以咱们关注一下 7.0 带来的变动(外围机制方面没有变动，插件，preset，解析转译生成这些都没有变动)

我只筛选一些和开发者关系比拟大的列在这里，省略的少数是针对某一个 plugin 的改变。残缺的列表能够参考官网。

淘汰 es201x 的目标是把抉择环境的工作交给 env 主动进行，而不须要开发者投入精力。但凡应用 es201x 的开发者，都该当应用 env 进行替换。但这里的淘汰 (原文 deprecated) 并不是删除，只是不举荐应用了，不好说 babel 8 就真的删了。

与之相比，stage-x 就没那么好运了，它们间接被删了。这是因为 babel 团队认为为这些“不稳固的草案”破费精力去更新 preset 相当节约。stage-x 尽管删除了，但它蕴含的插件并没有删除(只是被更名了，能够看上面一节)，咱们仍然能够显式地申明这些插件来取得等价的成果。残缺列表

为了缩小开发者替换配置文件的机械工作，babel 开发了一款 babel-upgrade 的工具，它会检测 babel 配置中的 stage-x 并且替换成对应的 plugins。除此之外它还有其余性能，咱们一会儿再具体看。(总之目标就是让你更加平滑地迁徙到 babel 7)

这是 babel 7 的一个重大变动，把所有 babel-* 重命名为 @babel/*，例如：

babel-cli 变成了 @babel/cli。
babel-preset-env 变成了 @babel/preset-env。进一步，还能够省略 preset 而简写为 @babel/env。
babel-plugin-transform-arrow-functions 变成了 @babel/plugin-transform-arrow-functions。和 preset 一样，plugin 也能够省略，于是简写为 @babel/transform-arrow-functions。

这个变动不单单利用于 package.json 的依赖中，包含 .babelrc 的配置 (plugins, presets) 也要这么写，为了保持一致。例如

{
  "presets": [
-   "env"
+   "@babel/preset-env"
  ]
}

顺带提一句，下面提过的 babel 解析语法的内核 babylon 当初重命名为 @babel/parser，看起来是被收编了。

上文提过的 stage-x 被删除了，它蕴含的插件尽管保留，但也被重命名了。babel 团队心愿更显著地区分曾经位于标准中的插件 (如 es2015 的 babel-plugin-transform-arrow-functions) 和仅仅位于草案中的插件 (如 stage-0 的 @babel/plugin-proposal-function-bind)。形式就是在名字中减少 proposal，所有蕴含在 stage-x 的转译插件都应用了这个前缀，语法插件不在其列。

最初，如果插件名称中蕴含了标准名称 (-es2015-, -es3- 之类的)，一律删除。例如 babel-plugin-transform-es2015-classes 变成了 @babel/plugin-transform-classes。(这个插件我本人没有独自用过，羞愧)

babel 7.0 开始不再反对 nodejs 0.10, 0.12, 4, 5 这四个版本，相当于要求 nodejs >= 6 (以后 nodejs LTS 是 8，要求也不算太过分吧)。

这里的不再反对，指的是在这些低版本 node 环境中不能应用 babel 转译代码，但 babel 转译后的代码仍然能在这些环境上运行，这点不要混同。

在 babel 6 时，ignore 选项如果蕴含 *.foo.js，实际上的含意 (转化为 glob) 是 ./**/*.foo.js，也就是当前目录 包含子目录 的所有 foo.js 结尾的文件。这可能和开发者惯例的意识有悖。

于是在 babel 7，雷同的表达式 *.foo.js 只作用于当前目录，不作用于子目录。如果仍然想作用于子目录的，就要依照 glob 的残缺标准书写为 ./**/*.foo.js 才能够。only 也是雷同。

这个规定变动只作用于通配符，不作用于门路。所以 node_modules 仍然蕴含所有它的子目录，而不单单只有一层。(否则全世界开发者都要爆炸)

和 babel 6 不同，如果要应用 @babel/node，就必须独自装置，并增加到依赖中。

在提到删除 stage-x 时候提过这个工具，它的目标是帮忙用户自动化地从 babel 6 降级到 7。

这款降级工具的性能包含：(这里并不列出残缺列表，只列出比拟重要和罕用的内容)

package.json
把依赖 (和开发依赖) 中所有的 babel-* 替换为 @babel/*
把这些 @babel/* 依赖的版本更新为最新版 (例如 ^7.0.0)
如果 scripts 中有应用 babel-node，主动增加 @babel/node 为开发依赖
如果有 babel 配置项，查看其中的 plugins 和 presets，把短名 (env) 替换为残缺的名字 (@babel/preset-env)
.babelrc
查看其中的 plugins 和 presets，把短名 (env) 替换为残缺的名字 (@babel/preset-env)
查看是否蕴含 preset-stage-x，如有替换为对应的插件并增加到 plugins

应用形式如下：

# 不装置到本地而是间接运行命令，npm 的新性能
npx babel-upgrade --write

# 或者惯例形式
npm i babel-upgrade -g
babel-upgrade --write

babel-upgrade 工具自身也还在开发中，还列出了许多 TODO 没有实现，因而之后的性能可能会更加丰盛，例如下面提过的 ignore 的通配符转化等等。

关于babel:一口气了解babel

babel 到底做了什么？怎么做的？

应用办法

运行形式和插件

配置文件

preset

执行程序

插件和 preset 的配置项

env (重点)

其余配套工具

babel-cli

babel-node

babel-register

babel-polyfill

babel-runtime 和 babel-plugin-transform-runtime (重点)

babel-loader

小结一下

Babel 7.x

preset 的变更：淘汰 es201x，删除 stage-x，强推 env (重点)

npm package 名称的变动 (重点)

不再反对低版本 node

only 和 ignore 匹配规定的变动

@babel/node 从 @babel/cli 中独立了

babel-upgrade