@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模式不能用，明明后者有一定的体积优势，最终得到答案；这一过程虽然耗费一定的时间，但是有收获，值！