@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的
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
};
};
查到这里可以猜测这个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
模式不能用,明明后者有一定的体积优势,最终得到答案;这一过程虽然耗费一定的时间,但是有收获,值!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· 记一次.NET内存居高不下排查解决与启示
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· .NET10 - 预览版1新功能体验(一)