在平时通过babel转code的时候，有没有认真去研究一下这三个我们最常用的包呢？额……好像前面两个最常用，最后一个不常用。有没有去思考过，为啥要有这些包的区分？在什么情况下使用呢？这篇文章就讲解一下。
@babel/preset-env ↑
这可以说是babel官方的得意之作，最早的时候没有这个包，有的是babel-preset-es2015这样的包，后来每次新标准发布之后，就要新加一个包。babel顺应民意，发布了babel-preset-env这个包，它一次性囊括了已发布的所有标准包。
首先我们需要明确一下，preset-env的首要作用，不是帮我们把ES6+代码转成ES5.它的首要作用是认读ES6+代码。在使用preset-env之前，babel是无法认识ES6+代码的，运行时会报Token错误。在使用preset-env之后，babel才能认识这些代码语法，并将它们抽象出AST树。
其次的作用，才是帮我们转码代码。babel preset说白了，就是一大堆babel plugin的集合。babel的一切转码功能都是靠插件完成的。当然，插件要发挥作用，离不开babel本身的AST抽象能力。也就是babel为插件提供了AST能力，而插件利用该能力，创建/修改AST。
preset-env本身包含了一大堆plugin，并通过配置来控制插件，从而控制转码效果。我们来看下它的几个我们需要了解的常用选项（非常用的不介绍）。
targets
转码之后，要兼容哪些环境。可以在这里控制目标浏览器。随着版本控制的不同，最终生成的代码量也不一样，所以，不要一次性兼容到最低版本，没必要。
它有一个特殊选项 targets.esmodules ，如果这个选项为true，那么表示直接转化为ES6+代码，而不会转码到ES5，目前完全支持ES6+代码的浏览器不多。而且，此时，polyfill也没有必要。
modules
将当前模块加载类型转为哪个目标模块类型。默认为commonjs，设置为false时，不会转码模块加载，import from 语法不会转码，这样可以用来为webpack做tree shaking。
useBuiltIns
是否自动加载polyfill。它有三个值可选：false（默认）, entry, usage。
默认false表示不自动加载polyfill，此时，需要你自己手动在项目中引入polyfill，这在下面一节细讲。
entry时，需要你在代码中自己手写 import 'core-js' 这行的代码（注意只需要在整个应用中写一次），但是在转码时，它会根据上文targets的情况，选择import对应的core-js模块，而不是把整个core-js都引入。
usage时，不需要你手写 import 'core-js' 但是它能自动识别你当前这个文件都用到哪些core-js模块，然后自动在转码后的代码中import进来。
看上去有点麻烦，感觉好像直接用usage不就好了么。但是实际上，在使用过程中你自然而然就会发现需要采用不同的策略。
corejs
承接useBuiltIns，当useBuiltIns值为entry或usage时，有效。它可以设置为：2，3，{ version, proposals }
因为目前core-js只有2和3两个版本，以后可能会有更多版本。proposals是指提案，在ES标准中，有些提案是铁定会进入到标准的，虽然标准还没有发布，但是core-js已经将它们做进去了。通过 { version: 3, proposals: true } 就可以在代码中使用那些虽然没有被发布，但是肯定要进标准的提案了。
include/exclude
只包含/不包含被列出的文件需要被转码。注意，include如果被设置，那么只包含于这些文件中的文件才会被转码。
loose
这个选项设置为true时，它会尽可能的将ES6+代码转化为ES5标准代码，而非用ES5去实现的ES6+代码，最核心的体现就是class语法的实现。在ES5中，我们通过SomeFunction.prototype.someMethod来创建原型链方法，而在ES6中它的实现完全不同。当loose为true时，preset-env将class语法转化为原型链的实现方式。
@babel/polyfill ↑
这个包是一个纯运行时的包，不是babel插件。它的作用是直接改写全局变量，从而让运行环境支持经过present-env转码后的代码。
大部分情况下，preset-env转码后的代码可以直接使用，但是在涉及到基于generator实现的语法时，例如 for...of 语法，则必须引入regenerator-runtime，因为转码后的代码会生成regeneratorRuntime这个全局变量，而@babel/polyfill引入了core-js和regenerator-runtime/runtime两个包。所以每次你安装完@babel/polyfill之后，它都会提示你，不要在用它了，直接用core-js和regenerator-runtime/runtime就好了。所以，虽然我这里说@babel/polyfill，实际上，大部分情况下，它是指core-js。
在我们设置preset-env的useBuiltIns为false（默认值）时，preset-env不会为我们自动引入polyfill，我们要手动引入@babel/polyfill，并会导致整个core-js和regenerator-runtime/runtime被打包进我们的项目。
useBuiltIns为entry时，我们手动引入@babel/polyfill，比false好的是，它不会把所有的core-js模块引入，而是只引入targets需要的。虽然引入的模块比直接引入@babel/polyfill少，但总体而言，它还是会引入很多模块，而这些模块中，很多可能是不需要引入的。
使用usage模式，preset-env会自动帮你插入需要的core-js模块，不需要你手动import任何代码。缺点是：babel默认不会检测第三方依赖包代码，所以使用 usage 时，可能会出现引入第三方的代码包未注入模块而引发bug。
@babel/plugin-transform-runtime ↑
这是一个babel插件，使用这个插件的同时，必须同时安装@babel/runtime这个包。
它有两个作用：
- 将preset-env所产生的helpers函数提出到一个独立文件中，从而减少代码量
- 建立运行时沙盒，避免全局污染
当我们在写一个独立的第三方库时，在做构建的时候需要用到它。使用这个包之后，在我们自己写的库的代码体系内，可以实现上述两个效果，这样有利于减少代码量，同时又避免污染全局。
我们从它的配置项来看看这两个效果如何配置。
corejs
配置版本，传入corejs的值和同时安装的@babel/runtime包是不一致的，你需要手动安装。例如，你传入2则需要手动安装@babel/runtime-corejs2，传入3则需要手动安装@babel/runtime-corejs3，并且，这三个包只安装对应的一个就好，它们是互斥的。
corejs3有一些新特性，但是会增加代码量。
只有传入corejs只会，上面提到的“建立运行时沙盒”才会生效。它的效果实际上，就是在当前文件使用独立的变量来使用某些ES特性。
helpers
是否要将所有helper函数提炼到另外一个公共文件中。默认为true。
一般情况下，@babel/plugin-transform-runtime插件不需要传入任何配置。在真正使用时，要配合@babel/preset-env同时使用，两者的corejs配置要一致，useESModules也要一致。
推荐配置 ↑
经过上文的分析只会，从特性、代码量等考虑，当我们要打包一个提供给其他团队使用的第三方包时，我的推荐配置如下：
{
"presets": [
["@babel/preset-env", { "modules": false, "useBuiltIns": "usage", "corejs": 3 }]
],
"plugins": [
["@babel/plugin-transform-runtime", { "corejs": 3 }]
],
"env": {
"test": {
"presets": [
["@babel/preset-env", { "useBuiltIns": "usage", "corejs": 3 }]
]
}
}
}需要手动安装：
# 构建时用
npm i -D @babel/plugin-transform-runtime @babel/preset-env @babel-core
# 运行时用
npm i core-js@3 @babel/runtime-corejs3 regenerator-runtime这样，我们就可以定制我们自己的包了。
而如果是构建整个应用，则不需要使用@babel/plugin-transform-runtime，推荐配置如下：
{
"presets": [
["@babel/preset-env", { "modules": false, "useBuiltIns": "usage", "corejs": 3 }]
],
"env": {
"test": {
"presets": [
["@babel/preset-env", { "useBuiltIns": "usage", "corejs": 3 }]
]
}
}
}手动安装：
# 构建时用
npm i -D @babel/preset-env @babel-core
# 运行时用
npm i core-js@3 regenerator-runtime但是，使用 useBulitIns: 'usage' 不能保证所有的第三方库也使用了上面提到的构建方法，在这种情况下，干脆直接将所有的polyfill全部包含在应用中，从而避免出现有些小问题。
{
"presets": [
["@babel/preset-env", { "modules": false, "useBuiltIns": "entry", "corejs": 3 }]
],
"env": {
"test": {
"presets": [
["@babel/preset-env", { "useBuiltIns": "entry", "corejs": 3 }]
]
}
}
}安装的包一样。并且，这个时候，你需要在你的 app 入口文件中增加如下两句：
import 'core-js'
import 'regenerator-runtime'转码之后，import 'core-js'会被展开为很多行，但是它不会把整个core-js所有模块引入，而是只引入targets配置中所指出的环境所需要的模块。
总之，上面3总配置和使用方法都是比较好的，绝对不推荐直接不配置useBuiltIns而直接import '@babel/polyfill'的做法。
