为何已完成polyfill的组件库引入项目后仍需再次配置polyfill？

核心原因说明 #

1. 组件库的Babel配置本身没有做浏览器polyfill适配 #

你在组件库@babel/preset-env中配置的targets为"node": "current"，该配置会让Babel仅针对你当前构建使用的Node.js版本做语法转换和polyfill注入，完全不会处理浏览器环境下的API兼容问题，所以你以为组件库已经完成的浏览器polyfill实际上根本没有生效。

2. 主应用默认不会编译node_modules下的第三方依赖 #

几乎所有前端项目的默认构建规则中，babel-loader都会配置exclude: /node_modules/，跳过第三方依赖包的编译步骤。哪怕你后续修正了组件库的target配置，只要组件库没有把polyfill全量打包到产物中，主应用读取到组件库的代码时也不会做额外的polyfill处理，自然会抛出API不存在的报错。

3. useBuiltIns: "usage"的作用逻辑限制 #

useBuiltIns: "usage"的生效时机是当前文件被Babel编译的阶段，Babel会扫描当前文件用到的新API，在文件头部注入对应的corejs polyfill引入。如果你的组件库构建时没有把polyfill和代码一起打包，组件库的产物中仍然保留了原生新API的调用，主应用不编译组件库代码的话，就不会触发对应的polyfill注入逻辑。

你在主应用添加相同配置后问题解决，是因为主应用的polyfill会挂载到全局作用域，比如Array.prototype、Promise这类全局API的polyfill只要主应用引入了，所有依赖包的调用都会生效。

可选优化方案 #

• 如果你希望组件库可以开箱即用，不需要主应用做额外配置：
  • 将组件库Babel配置的targets修改为你需要兼容的浏览器范围，例如"chrome": "60", "firefox": "55", "ie": "11"
  • 组件库构建时将所需polyfill一起打包到产物中，可根据需要做polyfill作用域隔离，避免污染全局环境
• 如果你可以要求接入方统一做polyfill处理：
  • 保留当前主应用的配置即可，全链路的polyfill由主应用统一处理，还可以避免多个第三方组件库重复引入polyfill导致的产物体积冗余

内容的提问来源于stack exchange，提问作者Carven