@babel/preset-env使用polyfill遇到的坑
场景还原
最近将一个项目由babel@6升级到babel@7，升级后最重要的两个包：
@babel/preset-env: 提供代码的转换和API的polyfill的能力@babel/plugin-transform-runtime: 复用babel注入的helper代码以及提供无污染全局环境的polyfill功能
基于此，对项目中js语法的transform和API的polyfill进行了调整：
- 关闭
@babel/plugin-transform-runtime的polyfill功能 - 开启
@babel/preset-env的polyfill和transform功能
其中，@babel/preset-env的polyfill使用usage形式（不了解的可以查看官方文档），意思是以项目设置的target环境为前提，根据项目中使用到的api功能进行polyfill；具体babel配置片段如下：
{
"plugins": [
[
"@babel/plugin-transform-runtime",
{
"corejs": false,
"regenerator": false
}
]
],
"sourceType": "unambiguous",
"presets": [
[
"@babel/preset-env",
{
"modules": false,
"shippedProposals": true,
"useBuiltIns": "usage",
"corejs": {
"version": "3.10",
"proposals": true
},
"targets": {
...
}
}
]
]
}
然后项目中使用到了Promise.allSettled静态方法:
Promise.allSettled([p1, p2, p3]).then(res => console.log(res));
通过webpack打包后运行，js会报错：
TypeError: Promise.allSettled is not a function
不对呀，按照官网就是这么配置的，一度对babel的配置产生怀疑，折腾半天最后都排除掉；没招了，那就试试断点调试，别说还真发现问题，直接上图：
相信大家能够看出问题所在，Promise.allSettled的polyfill之后重新引入Promise的polyfill，后面的Promise的polyfill覆盖了Promise.allSettled的polyfill，导致调用该方法时报错。
那会不会是babel的bug导致的呢，于是开起查找问题之旅了。。。
问题追踪
首先，简要说明下@babel/preset-env实现polyfill的思路：babel会生成代码的ast，并对其traverse过程中，根据代码使用的新API来确定需要填充的polyfill。
遇到这种问题，首先想到会不会是@babel/preset-env的bug，google半天也没有找到类似问题，于是就开启debug调试模式。在调试追踪到babel-plugin-polyfill-corejs3/lib/index.js中的usageGlobal方法，其在解析代码中使用到了Promise和allSettled的api，如下图：
babel会根据代码用到的api，最终解析出为这些api注入的polyfill，如下图：
从图可以看出最终需要为Promise和allSettled注入的依赖polyfill；但是注入的polyfill存在问题，即es.promise与es.promise.all-settled顺序反了，后者依赖前者；由此可见是babel的bug已确定无疑了。
接着进如resolve方法，发现其在确定代码的相关polyfill依赖后，对与依赖的先后顺序存在bug；因为代码调用Promise.allSettled会依赖：
- 全局global的
Promiseapi - Promise的静态方法
allSettledapi
所以babel在获取二者对应的polyfill在合并时产生了问题，这可以在babel-plugin-polyfill-corejs/lib/built-in-definitions.js文件中：
// 所有静态方法的polyfill
const StaticProperties = {
...
Promise: {
all: define(null, PromiseDependenciesWithIterators),
allSettled: define(null, ["es.promise.all-settled", ...PromiseDependenciesWithIterators]),
any: define(null, ["esnext.promise.any", ...PromiseDependenciesWithIterators]),
race: define(null, PromiseDependenciesWithIterators),
try: define(null, ["esnext.promise.try", ...PromiseDependenciesWithIterators])
},
...
}
可以看出Promise的相关静态方法的polyfill都放置到第一位，而define为对该数值进行任何排序：
const define = (pure, global, name = global[0], exclude) => {
return {
name,
pure,
global,
exclude
};
};
查到这里可以猜测这个babel-plugin-polyfill-corejs3@0.1.7有bug，查看最新版本0.2.0的代码发现对这个方法进行了修复:
var _data = _interopRequireDefault(require("../core-js-compat/data.js"));
const polyfillsOrder = {};
Object.keys(_data.default).forEach((name, index) => {
polyfillsOrder[name] = index;
});
const define = (pure, global, name = global[0], exclude) => {
return {
name,
pure,
global: global.sort((a, b) => polyfillsOrder[a] - polyfillsOrder[b]),
exclude
};
};
可以看出该方法对注入的polyfill做了排序，进过排序得到正确的依赖顺序，于是果断升级@babel/preset-env@到7.13.15，因为之前@babel/preset-env@7.13.10依赖的是babel-plugin-polyfill-corejs3@0.1.7，至此一直困扰我的这个大坑给堵上了。
出于好奇心，对babel-plugin-polyfill-corejs3代码进行blame，果然发现这个问题在24天前进行了修复：
进一步查看发现，之前已经有人提出过类似的bug：The order of promise and promise.finally after compilation seems to be wrong，于是做了修复。
总结
困扰我一天的问题算是解决了，分享给大家希望大家避坑。
不过话说回来，开始遇到这个问题时，换成@babel/preset-env的entry模式的polyfill模式不会发生任何问题，但是心中过不去这个坎为啥usage模式不能用，明明后者有一定的体积优势，最终得到答案；这一过程虽然耗费一定的时间，但是有收获，值！
