Mid 2019 Personal Recommendation for Babel Core Config(2019年年中个人推荐的Babel核心配置)

[H2rmone]

最近的一些发布

Babel 在2019年7月3号发布了v7.5.0版本，这个版本将最近纳入 stage-4 阶段的 dynamic import() 语法收入到官方插件中，也就意味着 preset-env 内置了这个插件，以后不用再单独放在 plugin 里了。

React16.8 这个版本其实发布也有近半年了，这个版本的添加了Hooks支持。

4个月之前，大名鼎鼎的 core-js 也升级到3，这个版本做了大量的调整，使得在配合 Babel 使用的时候更加便捷，同时少量的 WHATWG / W3C standards 相关的也有加入到 core-js 中，例如 URL 的 polyfill。

核心配置的个人推荐

那么废话少说，这个时候如果要新建一个 react 项目（各种脚手架方式请绕道），babel 核心基础配置(注意这里是核心配置不是实际项目最终方案) 应该长什么样呢，请看下面的代码示例：

// babel.config.js 
const presets = [
  '@babel/preset-env',
  '@babel/preset-react',
]

const plugins = [
  '@babel/plugin-transform-runtime',
]

module.exports = {
  presets,
  plugins,
}

这个时候可以看到，原先的 dynamic import() 收录到 preset-env 中，公有类字段@babel/plugin-proposal-class-properties 也由于Hooks的支持可以将其移除 plugin 队列。这样看一眼下来，我这种强迫症就”治“好了。为什么说治好了呢？这里讲一段小插曲，ECMAScript 有一个 proposals 提案流程，新的语法提案会依次进入stage 0 - stage 4 这几个不同的阶段，preset-env 这个包会收录所有 stage-4 之后的语法，只有到了 stage-4 之后才会纳入 ECMAScript 语法规范。而公有类字段目前尚在 stage-3 阶段，虽然 create-react-app 以及其他脚手架可能也内置了这个写法，但实际情况它还不是真正的规范语法。像 @ 这种装饰器语法更是在 stage-2 阶段（尤雨溪等人也提到过），很有可能被修改或者永远进不了规范。甚至很多库的作者用到了各种 stage-1 或者 stage-0 阶段的语法。对于这些行为，我个人的想法是反对的，任何没有到规范的语法使用在企业级项目或者库中都是存在技术债的。

所以再来看一下上面的配置，结合这个时机，负面影响基本消除。

最后说一下 polyfill

目前我知道的主流的几种方案有：

• 全量引入

import "core-js/stable"
import "regenerator-runtime/runtime"

• 配合 preset-env 里的 uesBuiltIns: 'entry' + browserslist
• 配合 preset-env 里的 uesBuiltIns: 'usage' + browserslist
• polyfill.io

这几个方案都有不同的优缺点这里就不展开了，有兴趣的可以留言讨论。目前我采用的是第三种。