Babel 配置和使用

Babel文档：https://babeljs.io/docs/en/。

Babel 既可以单独使用，也可以使用其他构建工具，把 Babel 作为构建中的一个工具来使用。

Babel 最重要的两个功能：

• 编译语法，把一些新出的语法，比如 const、箭头函数等，在保证功能不变的前提下，编译为低版本平台可以支持的语法，产出的 js 可以直接在node和浏览器中使用。
• 编译新API，一些 js 新出的 API，比如 Promise、includes 等，Babel 会提供一个“垫片”，也就是在编译产出的 js 中，会依赖 Babel 的一些相关的代码。

由于编译新 API 时需要其他依赖文件，导致直接使用 Babel 编译产出的文件，不能直接给浏览器使用。

所以这时，就需要使用其他的构建工具来编译代码，Babel 作为编译工具的一个插件来起作用。

有了构建工具，产出的 js 就会把用到的文件也导出到 js 文件中，不再依赖 node_modules，详见 https://babeljs.io/en/setup 中的 「In the browser」的说明。

下面直接使用 Babel 编译代码，来更清晰的了解 Babel 的配置。

配置文件说明

无论是单独使用 Babel 来编译js，还是使用了其他编辑工具，这个编译工具又使用了 Babel，这两种情况中，Babel 的配置方式都是一样的。

配置时有两种配置模式。

• 全项目配置：应该配置在项目根目录，是针对整个项目生效的。
  • babel.config.*文件，扩展名如下：.json、.js、.cjs、.mjs。
• 文件相关配置：可以配置在项目中任意一个文件夹中，只对所处的文件夹下的文件生效。
  • .babelrc.*文件，扩展名如下：.json、.js、.cjs、.mjs。
  • .babelrc文件，没有扩展名。
  • package.json文件，带有"babel"键。

如果格式是 json 或者无格式，那里面直接写 json。

如果是 js、cjs 格式的，则需要使用 module.exports = {} 导出。

如果是 mjs 格式的，则需要使用 export default 导出。

下面的示例，都是假定配置写在项目根目录的 .babelrc 文件中。

核心模块 @babel/core

核心模块 @babel/core。

文档：https://babeljs.io/docs/en/babel-core。

babel 的核心，没有显式的使用，但必须安装。

常用的工具

@babel/cli

文档：https://babeljs.io/docs/en/babel-cli。

非必须，安装后才能在 package.json 的 scripts 脚本中使用 babel 指令，用来编译一文件生成到某处的。

比如可以在 package.json 中添加指令：

{
  "scripts": {
    "build": "rm -rf ./dist && babel ./src -d dist/src --copy-files"
  },
}

意思为：

• rm -rf ./dist：删除 dist 文件夹。
• babel ./src -d dist/src：编译 src/ 下的文件到 dist/ 文件夹下
• --copy-files：遇到 babel 不支持的文件格式时，直接把文件复制过去。

但是，编译的配置会自动从 babel 的配置文件中读取，如果没有配置文件，或者配置文件中没有指定编译时使用的插件，那么编译完成后，输出的文件和源文件完全相同。

@babel/node

文档：https://babeljs.io/docs/en/babel-node。

非必须，安装后才能在 package.json 的 scripts 脚本中使用 babel-node，它的作用是替换 node，主要用于 node 开发时使用。

比如进行以下修改 package.json 中：

{
  "scripts": {
-    "start": "node ./src/index.js"
+    "start": "babel-node ./src/index.js"
  },
}

这样当 npm start 时，此文件 ./src/index.js 和此文件引入的文件，都会被 Babel 编译并执行。

但注意，babel-node 由于性能和一些其他原因，只适用于开发时，如果项目要上线，需要使用 babel 编译出文件后，再使用 node 运行。

配置相关

编译语法

@babel/preset-env

@babel/preset-env 文档：https://babeljs.io/docs/en/babel-preset-env。

这就是在 Babel 配置文件中进行配置时需要的工具了。

@babel/preset-env 一套预设的语法转换，默认只转换语法，比如 const、let、箭头函数等。

最基本配置 .babelrc 中：

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

编译API

在之前的 Babel 版本，垫片的使用是使用 @babel/polyfill，但这个包在 Babel@7.4.0 开始被弃用了。

现在有两种推荐的方式来编译 API，具体原理详情，也可以参考另一篇讲解 Babel 历史和原理的文档。

使用 @babel/preset-env

使用 @babel/preset-env 编译 api 的方式，是会造成全局污染的，也就是比如使用了 Array.form 方法，那真的会给 Array 添加 from 这个静态方法，所以说会污染。

在 @babel/preset-env 的配置中启用编译新 API 的功能，举例详见 Babel 配置列举。

使用 @babel/plugin-transform-runtime

使用 @babel/preset-env 编译 api 的方式，不会造成全局污染，他是引入一个新方法，来替换原来的写法。

这么一来 @babel/preset-env 只用专注于编译语法就行。

在 @babel/plugin-transform-runtime 的配置中启用编译新 API 的功能，举例详见 Babel 配置列举。

指定目标平台 Browserslist

Browserslist 版本指定说明：https://github.com/browserslist/browserslist#queries

Babel 会要求指定目标平台，也就是代码编译后需要能兼容的平台：

• 如果产出的js要给前端页面使用，配置者需要指定要兼容的浏览器，比如占比超过百分之多少的浏览器、某个浏览器的某个版本等等。

• 如果产出js要是给服务端node使用，需要指定要兼容到那个 node 版本。

因为 Babel 是使用 Browserslist 提供的信息来查询不同平台对语法的支持情况的，所以配置者指定版本的语法写法需要符合 Browserslist 的要求。

未设置目标平台时的默认值

也可以不指定，如果不指定，则会使用 Browserslist 的默认值：

0.5%, last 2 versions, Firefox ESR, not dead

目标平台的指定写法一

写在 Babel 配置文件中，@babel/preset-env 配置的同组的插件配置对象的 targets 字段中。

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": [
          "> 1%",
          "last 2 versions",
          "not ie <= 8",
          "node 12.0"
        ]
      }
    ]
  ]
}

目标平台的指定写法二

写在 package.json 文件的 browserslist 字段中。

{
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "not ie <= 8",
    "node 12.0"
  ]
}

目标平台的指定写法三

新建 .browserslistrc 文件，内容：

> 1%
last 2 versions
not ie <= 8
node 12.0

目标平台的指定写法四

这个写法，是当使用了其他构建工具，把 Babel 作为构建工具的一个插件时的写法。

此时，Babel 的配置可以直接写在构建工具的配置文件中，目标平台指定的代码也就可以跟过去了。

Babel 配置列举

目前，Babel 处理兼容性问题有两种方案：

• @babel/preset-env + corejs@3：实现语法转换 + 在全局和实例上添加api，支持全量加载和按需加载，我们简称 polyfill 方案；

  • 缺点：就是会造成全局污染。
  • 优点：可以根据浏览器对新特性的支持度，来选择性的进行兼容性处理。

• @babel/preset-env + @babel/runtime-corejs3 + @babel/plugin-transform-runtime：实现语法转换 + 模拟替换 api，只支持按需加载，我们简称 runtime 方案。

  • 优点：不会存在全局污染。
  • 不能根据浏览器对新特性的支持度来选择性的进行兼容性处理，也就是说只要在代码中识别到的 api，并且该api也在 corejs3 的 core-js-pure 包中存在，就会自动替换，这样一来就会造成一些不必要的转换，从而增加代码体积。

两种方案都依赖核心包 corejs@3，只不过依赖的模块(一个污染包一个清洁包)不同，导致实现方式不同。

所以，polyfill 方案比较适合单独运行的业务项目，如果你是想开发一些供别人使用的第三方工具库，则建议你使用 runtime 方案来处理兼容性方案，以免影响使用者的运行环境。

下面是两中配置方案的基础模板。

如果需要配置其他比如要支持的平台，按照上面的文档自行添加即可。

polyfill 方案的配置

污染全局，适合单独运行的业务项目。

必须的依赖：

• @babel/core
• @babel/preset-env
• core-js：配置 corejs: 3 需要的，因为 core-js 当前最新的为版本 3，正好对应，可以直接使用。

使用 babel 指令编译时需要额外添加的依赖：

• @babel/cli：用于支持 babel 指令。

使用 babel-node 指令编译时需要额外添加的依赖：

• @babel/node：用于支持 babel-node 指令。

在其他编译工具(webpack)中编译时需要额外添加的依赖：

• babel-loader：允许使用 Babel 和 webpack 传输 JavaScript 文件。

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage", // "usage": 按需引入
        "bugfixes": true, // 一项优化，默认为false，Babel 8版本将默认为true
        "corejs": 3 // 指定要使用的 core-js 版本，建议 3
      }
    ]
  ]
}

runtime 方案的配置

不污染全局，适合开发供别人使用的第三方工具库是使用，不会免影响使用者的运行环境。

必须的依赖：

• @babel/core
• @babel/preset-env
• @babel/plugin-transform-runtime
• @babel/runtime-corejs3：配置 corejs: 3 需要的。

使用 babel 指令编译时需要额外添加的依赖：

• @babel/cli：用于支持 babel 指令。

使用 babel-node 指令编译时需要额外添加的依赖：

• @babel/node：用于支持 babel-node 指令。

在其他编译工具(webpack)中编译时需要额外添加的依赖：

• babel-loader：允许使用 Babel 和 webpack 传输 JavaScript 文件。

{
  "presets": [
    [
      "@babel/preset-env"
    ]
  ],
  "plugins": [
    ["@babel/plugin-transform-runtime", { "corejs": 3 }]
  ]
}