记录自己零散的收获，随笔。

一些基础

babel的作用是转换JS新的特性代码为大部分浏览器能运行的代码。
babel转码又分为两部分，一个是语法转换，一个是API转换。
对于API的转换又分为两部分，一个是全局API例如Promise，Set，Map还有静态方法Object.assign，另一个是实例方法例如Array.prototype.includes。对于实例方法core-js@2是转换不了的，只有core-js@3才会转换。
babel代码转换依赖plugin，没有plugin的情况下babel做的事情只是 code => code。
plugin 有很多，一个个导入又特别麻烦，这时候我们又知道了preset。

preset是很多plugin的集合，配置如下：

.babelrc文件

{"presets": ["env"]
}

如果preset-env是有配置项的：

{"presets": [["env",{// 这里就是配置项}]]
}

可以观察出如果某个preset需要配置可以将字符串换成一个数组，第一项是preset的name，第二项就是options。plugin同preset。

注：preset是从右往左执行，plugin是从左往右执行，并且plugin先于preset执行。

babel6到babel7的升级是具有破坏性的，主要总结下polyfill的用法和在babel6和babel7中的不同。

babel-polyfill

上面说到babel主要做两件事，一个是转换语法，一个是兼容新的API。

babel-polyfill 的作用是兼容新的API。

babel7

babel7进行了较大的改动，废弃了 stage-x的preset，还增加了命名空间区分官方插件和非官方插件，@babel/core，@babel/cli等。

建议使用@babel/preset-env 。

@babel/plugin-transform-runtime

该插件的引入主要有两个作用

在babel7中，原先的插件babel-plugin-transform-runtime也做了修改 -> @babel/plugin-transform-runtime。并且在功能上也变强大了。

移除了polyfill的配置项添，加了corejs配置项。

@babel/plugin-transform-runtime的默认配合如下：

{plugins: [["@babel/plugin-transform-runtime", {"absoluteRuntime": false, // 不是很清除干啥的"corejs": false, // 下面详解"helpers": true, // 助手函数是否提取，同babel-plugin-transform"regenerator": true, // 同babel-plugin-transform"useESModules": false}]]
}

对于配置项 corejs: false | 2 | 3。

false 依赖 @babel/runtime，是默认选项，认为需要填充的API以被填充，所以不对API作polyfill（对于@babel/runtime的依赖是提取的helper的依赖）。
2 依赖@babel/runtime-corejs2
3 依赖@babel/runtime-corejs3

corejs2和corejs3还是有很大区别的。corejs2只转换全局变量(Object)和静态方法(Object.assign)，并不转换原型上的方法(Array.prototype.includes)，corejs3会转换原型上的方法。

注意transform-runtime这个插件添加的polyfill都是私有的，不会影响到全局环境，而且还是按需引入，非常nice。

小结：
@babel/plugin-transform-runtime主要有三个作用：
- 当使用 generators/async的时候自动引入 @babel/runtime/regenerator。
- 为新特性的API添加实现。
- 提取每个模块内联的helper们问引用。

@babel/preset-env

除了上面说的 @babel/plugin-transform-runtime插件，还想记录下 @babel/preset-env关于polyfill的改变。

这个preset在babel6的时候就承担了很多功能，本文只记录和polyfill相关的配置，useBuiltIns和 corejs。

useBuiltIns

在babel-preset-env的配置项中是一个boolean值，在@babel/preset-env的时候则扩展了几个选项 "useage"和 "entry"。

默认值是false，表示不会自动引入polyfills，并且不会处理 import “@babel/polyfill” 和 import “corejs”。

注：babel7.4会放弃 @babel/polyfill，所以建议直接使用 corejs。

entry

在入口文件有 import "core-js/stable"和 import "regenerator-runtime/runtime"。
会被自动分割为各个模块的导入。

require("core-js/modules/es.symbol");require("core-js/modules/es.symbol.description");require("core-js/modules/es.symbol.async-iterator");require("core-js/modules/es.symbol.has-instance");...
...
...require("core-js/modules/web.url-search-params");require("regenerator-runtime/runtime");

只能在入口引入一次，多次会报错。

usage

按需引入。同样会造成全局污染。在我的理解中这个选项只是entry的一种增强，不需要在入口手动引入一次，并且可以按照使用特性多少按需引入。

corejs

值：2, 3 或者 { version: 2 | 3, proposals: boolean }, 默认是 2.

这是新加的一个配置项。该选项只会在 useBuiltIns选项为 usage或者 entry并且 @babel/preset-env正确导入对应的corejs版本的情况下起作用。

默认情况下只会注入稳定功能的 ECMAScript 特性。有三个特性可以修改：

当时用配置 useBuiltIns: "entry"可以直接导入提案 import "core-js/proposals/string-replace-all"
当时用 useBuiltIns: usage 的时候又有两个可选：
- 将shippedProposals（@babel/preset-env的另一个配置项）选项设置为true。这将启用已在浏览器中提供一段时间的提议的polyfill和转换。
- 使用 corejs: {version：3，proposal：true}。这样可以实现对core-js支持的每个提案的填充。

babel6

据我所知，在babel6中使用polyfill有四种方法：

直接引入（影响全局，一劳永逸）

在入口文件中 import 'babel-polyfill' / require('babel-polyfill')。使用webpack的话也可以在entry中添加 entry: ['babel-polyfill', 'src/index.js']。

优点：
一次引入，全局使用。
会转换实例方法和静态方法，比较全面。

缺点：
影响全局作用域。
打出来的包比较大，不管用没用到都打进去了。

使用场景：
开发业务项目，比较全面，不会漏了从而出问题，比如Object.assign这样的方法在ios8上面还是需要polyfill的。
在babel-runtime中单独引入

和直接在入口引入polyfill不同，该插件引入的polyfill是模块私有的。
对于需要的polyfill需要手动引入，import Promise from 'babel-runtime/core-js/promise'

优点：
该模块私有，不会影响到全局作用域。
打出来的包因为按需引入包不会很大。

缺点：
因为不影响全局作用域，所以不会转实例和静态方法这样的API。
手动引入所需，搞不好会漏掉。

使用场景：
开发库，框架之类可以使用，因为别人用你的东西然后不知情的情况下你改了别人的全局环境，然后出错了就尴尬了。
使用babel-plugin-transform-runtime按需引入

这个插件可不简单，有好几个功能：
1. 和插件babel-runtime一样引入的polyfill是私有的，不会影响全局作用域。并且是自动按需引入需要的polyfill，不需要想babel-runtime一样一个一个手动引入。
2. 可以提取语法转换时候每个模块都生成的各种helper，成一个引用。
3. 自动转换generators/async。
优点：
该模块私有，不会影响到全局作用域。
打出来的包因为按需引入包不会很大。
自动按需引入，不需要手动，防止遗漏。
提取helper，大大减少冗余代码。

缺点：
因为不影响全局作用域，所以不会转实例和静态方法这样的API。

使用场景：
同babel-runtime。

注：该插件依赖babel-runtime。
在babel-preset-env中设置配置项

{"presets": [["env", {"useBuiltIns": boolean}]]
}

useBuiltIns 选项是为了分割入口的 import 'babel-polyfill' / require(babel-polyfill)成按环境引入polyfill。该方式同第一中引入polyfill的方式，但是会按照配置的环境去按需引入，稍微好点。

小结：
1. babel6的核心有 babel-core babel-cli babel-node babel-register babel-polyfill，这些在babel7会有所修改。
2. polyfill 是依赖core-js的
3. babel7.4放弃了@babel/polyfill直接依赖core-js@2或者3。

babel-plugin-transform-runtime的配置项

{"helpers": false, // defaults to true"polyfill": false, // defaults to true"regenerator": true, // defaults to true"moduleName": "babel-runtime" // defaults to "babel-runtime"
}

对于polyfill的自动处理和helper的提取都是依赖babel-runtime完成的，所以该插件依赖babel-runtime。

polyfill例子

input:

var promise = new Promise;

output:

var _promise = require("babel-runtime/core-js/promise");  // 注意这里，根本是从core-js里面引入的var _promise2 = _interopRequireDefault(_promise);function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }var promise = new _promise2.default();

helper的例子：

input:

class Person {}

usually turns into:

"use strict";// 这就是helper函数，每个模块都会被实现一遍，十分浪费，冗余。
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }var Person = function Person() {_classCallCheck(this, Person);
};

通过runtime转一下：

"use strict";var _classCallCheck2 = require("babel-runtime/helpers/classCallCheck"); // 从runtime中引入，没有再实现一遍var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }var Person = function Person() {(0, _classCallCheck3.default)(this, Person);
};