浏览器兼容性
项目打包后如果要支持的浏览器版本过低,那么我们就要利用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的打包结果:
modules:'auto'的打包结果:
总结
一般的应用项目用上面的配置就行了,更改的话就是改你要兼容的浏览器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 是通过非全局Object.enties api使用的方式,如此避免了全局污染。
既然如此,是否我们在做应用项目的时候也可以直接用这个方案了?其实并不是。
transform-runtime 也不是完美的方案,在 polyfill 方面不会读取 targets,因此凡是项目用到的语法都会注入 polyfill,对于一些需要兼容低端浏览器的项目可能影响并不大,但如果是现代浏览器,会注入很多没有必要的 polyfill 代码,导致bundle体积明显增大。因此 transform-runtime 和 preset-env 两个方面没有绝对的好与坏,到底选择哪个看需求场景。
总结
经过以上分析对比,我们可以得到一个大方向没错的结论:
- 应用项目采用@babel/preset-env方案
- 类库项目采用@babel/plugin-transform-runtime方案