低版本浏览器的兼容方案@babel/preset-env 与 @babel/plugin-transform-runtime的对比

浏览器兼容性

项目打包后如果要支持的浏览器版本过低,那么我们就要利用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方案

你可能感兴趣的:(低版本浏览器的兼容方案@babel/preset-env 与 @babel/plugin-transform-runtime的对比)