场景还原
最近将一个项目由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的
Promise
api - Promise的静态方法
allSettled
api
所以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
};
};
查到这里可以猜测这个[email protected]
有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/[email protected]
依赖的是[email protected]
,至此一直困扰我的这个大坑给堵上了。
出于好奇心,对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
模式不能用,明明后者有一定的体积优势,最终得到答案;这一过程虽然耗费一定的时间,但是有收获,值!