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