浏览器兼容性

项目打包后如果要支持的浏览器版本过低，那么我们就要利用babel对js代码进行语法降级和polyfill注入。也就是我们常说的es6 转es5。目前有两种主流方案：（为什么只有两种，后面会说）

• @babel/preset-env
• @babel/plugin-transform-runtime

@babel/preset-env 方案使用

新建一个项目babel-test, 采用高性能的包管理器pnpm

pnpm init

首先我们要安装相关依赖，由于es6转es5这是在构建的过程中去编译转换的，而非运行时代码，所以会设置为devDependencies

pnpm install @babel/cli @babel/core @babel/preset-env -D

然后 新建src/index.js

const obj = {a: 1}
const a = Object.entries(obj)

const b = () => {}

console.log(a, b)

这里用到了Object.entries 这个es6 API与箭头函数语法，然后再建立babel配置文件.babelrc.json

{
    "presets": [
      [
        "@babel/preset-env", 
        {
          // 指定兼容的浏览器版本
          "targets": {
            "ie": "11"
          },
          // 基础库 core-js 的版本，一般指定为最新的大版本
          "corejs": 3,
          // Polyfill 注入策略
          "useBuiltIns": "usage",
          // 不将 ES 模块语法转换为其他模块语法
          "modules": false
        }
      ]
    ]
  }

参数说明：

• targets: {"ie": "11"}这个参数，这是根据broswerlist的写法，表示兼容ie11。而ie11是不支持Object.entries 这个api 与箭头函数语法的，所以我们要通过@babel/preset-env去转换。更多浏览器版本兼容写法可以参考browserslist

• corejs: 3, 表示使用哪个版本的corejs进行polyfill, 可选值2、3、false；其中版本2会有一些在原型上的api缺失，比如Array.prototype.includes()，false就是不进行polyfill，这明显不符合我们的预期。

• "useBuiltIns": "usage", 表示按需加载polyfill, 比如上面我只用到了 Object.entries，那么打包时就只把这个 Object.entries的polyfill注入到全局window上面，其他没有用到polyfill就不注入，大大减少打包后bundle的体积。

• "modules": false ，意思是不将 ES 模块语法转换为其他模块语法，可选值有 'commonjs', 'amd', 'umd', 'systemjs' 'auto' ，我的index.js的写法是esm写法，这里false关闭就是保持esm写法，不然就会自动给你转commonjs写法。

在package.json增加一条命令

 "scripts": {
    "build": "babel src --out-dir dist"
  },

然后执行 npm run build

modules：false的打包结果：

esm的打包结果.png

modules：'auto'的打包结果：

commonjs.png

总结
一般的应用项目用上面的配置就行了，更改的话就是改你要兼容的浏览器targets。然而上面的配置也会有一些问题：如果使用新特性，往往是通过基础库(如 core-js)往全局环境添加 Polyfill，如果是开发应用没有任何问题，如果是开发第三方工具库，则很可能会对全局空间造成污染。所以下面这种方案就适用于解决第三方工具库的兼容性问题。

@babel/plugin-transform-runtime 方案使用

pnpm i @babel/plugin-transform-runtime -D
pnpm i @babel/runtime-corejs3 -S

更改.babelrc.json

{
  "plugins": [
    // 添加 transform-runtime 插件
    [
      "@babel/plugin-transform-runtime", 
      {
        "corejs": 3
      }
    ]
  ],
  "presets": [
    [
      "@babel/preset-env", 
      {
        "targets": {
          "ie": "11"
        },
        "corejs": 3,
        // 关闭 @babel/preset-env 默认的 Polyfill 注入
        "useBuiltIns": false,
        "modules": false
      }
    ]
  ]
}

注意，我们加了"plugins"配置，并且这里要把preset-env的useBuiltIns设为false，这样子把全局polyfill关闭掉才能让我们的引入的polyfill不污染全局。

可以看到结果

_Object$entries.png

仔细这个 _Object$entries 是通过非全局Object.enties api使用的方式，如此避免了全局污染。

既然如此，是否我们在做应用项目的时候也可以直接用这个方案了？其实并不是。

transform-runtime 也不是完美的方案，在 polyfill 方面不会读取 targets，因此凡是项目用到的语法都会注入 polyfill，对于一些需要兼容低端浏览器的项目可能影响并不大，但如果是现代浏览器，会注入很多没有必要的 polyfill 代码，导致bundle体积明显增大。因此 transform-runtime 和 preset-env 两个方面没有绝对的好与坏，到底选择哪个看需求场景。

总结

经过以上分析对比，我们可以得到一个大方向没错的结论：

• 应用项目采用@babel/preset-env方案
• 类库项目采用@babel/plugin-transform-runtime方案