对于有过前端工程化经验的同学来说，babel可谓是一个不得不知的知识点。babel从广义上来说是一个js编译器，中文的意思为通天塔，联想到它的作用是转换es6代码从而让代码可以在各个环境下运行，不得不说这个起名也是非常妙啊。而具体来说，babel是一堆工具链的集合，包括@babel/core和各种插件。

之前学习webpack打包工具的时候，对这个babel的配置总是一知半解。对@babel/core @babel/preset-env @babel/transform-run-time这一堆乱七八糟的总是一头雾水。这两天趁着项目的闲隙，看了姜瑞涛的babel教程(https://www.jiangruitao.com/babel/)后，终于对其有了一个系统的认识。现将自己的学习成果记录如下。

babel转换过程

跟要把大象装冰箱总共分三步一样，babel的转换过程也是分三步：解析（parse），转换（transform），生成（generate）。而负责这一转换过程的是babel的核心库@babel/core，这个具体的转换过程是对代码进行词法分析，生成AST，通过遍历AST生成最终转换后的代码。当然了，这个说法不完整也不专业，其中@babel/core里面还有许多包括@babel/tranverse之类的包，专门负责parse transform等过程，如果要了解这方面知识的话可以查阅更加专业的文章，在这里不多做赘述。

babel插件

既然有@babel/core对代码进行转换，那babel的插件有什么作用呢，我的理解是babel/core只做代码转换，至于按照什么规则来转换就要靠babel的插件系统来配置。这种可配置的方法也给了代码转换结果很大的自由度，让开发者可以根据自己代码的运行环境和开发需要来自己配置。如果没有配置任何插件的话，代码也只能原样输出了。

babel预设

对于es6转es5的大多数配置其实都需要用到一些插件，如果这些插件都要一条一条的来配置的话太麻烦了，因此presets就出现了，所有预设其实就是一系列插件的集合，对于开发中最常用的@babel/presets-env来说，就是一个js es6代码转es5的插件集合。

babel配置

上面说到了babel的插件和预设，其实babel的配置就主要是由这两项组成的。babel的配置文件可以是放在项目目录下的单独文件.babelrc babelrc.js babel.config.js外，也可以放在package.json里面。如果放在package.json里面的话，在json文件里面写一个babel配置，如图所示

"babel":{
  "presets":["env"],
  "plugins":["transform-class-properties"]
}

笔者自己还是比较喜欢单独写babel.config.js的配置文件形式，babel.config.js使用common.js的模块化规范编写，可以根据环境变量等加逻辑。

polyfill

通常情况下，babel只对es6的最新语法做转换，例如箭头函数转换为普通函数，对于es5中缺失的api例如promise Map Weak等则无能为力，为了能在低版本环境中使用这些新的api，必须引入polyfill。引入polyfill的方式有两种，第一种是直接引入polyfill文件，即直接在代码中将polyfill.js引进去，在这里姜瑞涛(https://www.jiangruitao.com/babel/babel-polyfill/)提出了七种方式。但是采用这种方式引入polyfill文件的缺点很明显，增加了代码体积，新增了全局变量，第二种方式是通过插件配置的方式来引入polyfill，这种方式引入polyfill的一个最大优点就是不污染全局变量。
下面我们先讲第一种直接引入polyfill的方式，具体来说，就是通过修改@babel/preset-env的配置来引入polyfill,@babel/preset-env和polyfill有关的行为的配置有两个分别是useBuiltIns和corejs。

modules.exports = {
  presets:[[
    @babel/preset-env,
    {
        targets:""
        useBuiltIns:"usage",
        corejs:3,
       modules:"false"
    }
 ]],
  "plugins":["transform-class-properties"]
}

useBuiltIns的取值有三个，false，“entry” ，“usage”。其默认值为false。当取值为false的时候，polyfill会被全部引入到代码中。所以，一般不会取false；剩下的两个配置要和corejs搭配使用，当取值为当取值为“entry"或"usage"的时候，须声明corejs的版本并安装corejs库，如果不安装的话，执行babel命令时会弹出提示。

当取值为"entry"时，需要在项目的入口文件处手动引入”core-js”，执行babel命令时根据配置项的targets目标环境找出需要的polyfill进行部分引入。当取值为"usage"的时，除了会考虑目标环境缺失的API以外，同时还会关注我们项目代码里使用到的ES6特性。只有我们使用到的ES6特性API在目标环境缺失的时候，才会进行引入。所以在项目中，一般是采用"usage"的配置。因此在这里可以对”entry"和“usage”的区别做一个总结，主要有以下两点：

采用entry配置时，须在入口文件处手动引入 core-js，usage不需要

import "core-js"

采用entry配置时，会将环境中缺失的api全部引入，而usage只会引入项目中用到api

采用第二种方式来引入polyfill就不得不提到一个插件@babel/plugin-transform-runtime，对于这个插件我想学习过工程化的人都会对它有所耳闻，而说到这个插件又不得不提到它的好基友@babel/plugin-runtime。这个@babel/plugin-runtime包里几乎包含了所有babel语法转换时需要用到的辅助函数。而@babel/plugin-transform-runtime这个插件的第一个作用就是将这些函数注入到转换后的代码中去。而@babel/plugin-transform-runtime插件剩下的两大作用就和polyfill有关(https://www.jiangruitao.com/babel/transform-runtime2/)，而用这个插件补齐缺失的api的话，它的好基友@babel/runtime就不太够用了，这个时候我们要用它的加强版@babel/runtime-corejs3，用这种方式babel的配置如下

 { 
    "plugins": [
      [
        "@babel/plugin-transform-runtime",
        {
          "helpers": true, //默认为true 是否自动引入辅助函数包
          "corejs": false,//是否做API转换以避免污染全局环境 
          "regenerator": true,//是否做API转换以避免污染全局环境 
          "useESModules": false,
          "absoluteRuntime": false,
          "version": "7.0.0-beta.0"
        }
      ]
    ]
  }

两种polyfill引入方式的选择

前端业务项目：使用方法1直接引入polyfill方式
js库发包：使用方法2api补齐的方式

why？

在这里就用姜瑞涛博客中的原文(https://www.jiangruitao.com/babel/transform-runtime2/)回答吧

可以想象，如果开发JS库的人使用polyfill补齐API，我们前端工程也使用polyfill补齐API，但JS库的polyfill版本或内容与我们前端的不一致，那么我们引入该JS库后很可能会导致我们的前端工程出问题。所以，开发JS库或npm包等的人会用到API转换功能。

当然，业务项目里要用api补齐的方式也不是不行吧。为此，我特意看了一下我们公司项目的babel配置，嗯，不过确实用的是第一种。

后记

关于babel这一工具其实知识点远远不止本文这些，本文也只是起一个抛砖引玉的作用，想要真正的学会babel，并不是学几个插件的配置方式就够了，需要从编译原理入手，作为一名合格的开发者，可以从babel作为切入点学习这种底层知识。不仅仅是babel，处理代码生成AST的过程不仅babel有，笔者猜想一些css的处理工具postcss autoprefixer也会用到，只有学习了底层知识，才能以不变应万变，对自己独立开发一些插件也会有莫大的帮助。

关于babel新手必须了解的知识点