共计 1424 个字符，预计需要花费 4 分钟才能阅读完成。
Babel polyfill 和 Babel polyfills 就一个 s 之遥，前者是已被弃用的旧时 Babel 官网基于 regenerator-runtime 和 core-js 保护的 polyfill，后者是仍在测试的当初 Babel 官网保护的 polyfill 抉择 – 策略 – 插件 – 集。
相较于保护本人的 polyfill，Babel 更专一于提供更为灵便的 polyfill 抉择策略。
以后，@babel/preset-env 反对指定指标浏览器，通过 useBuiltIns 提供 entry 和 usage 两种注入模式；@babel/plugin-transform-runtime 不净化全局作用域，复用辅助函数为库开发者减小 bundle 体积。然而，这两个组件并不能很好地配合应用，二者的 polyfill 注入模式只能任选其一。另外，它们只反对 core-js，有很大的局限性。
Babel 社区在 历时一年的探讨 后，设计开发 Babel polyfills 作为这些问题的对立解决方案。它 同时：
- 反对指定指标浏览器；
- 反对不净化全局作用域；
- 反对配合 @babel/plugin-transform-runtime 复用辅助函数；
- 反对
core-js和es-shims，并反对、激励开发者写本人的 polyfill provider。
致力于对立 Babel 对 polyfill 的抉择策略。Babel polyfills 长处很多，应用是大势所趋。官网的应用文档 写得很清晰，有须要的同学能够点击链接查看。
Exclude
应用 Babel 很容易引入“不太须要的”polyfill，使得打包后的库大小剧增。
- 例如，应用 URL API 很容易引入
web.url模块，在压缩后大小占 11 KB。它还牵涉到web.url-search-params、es.array.iterator和es.string.iterator三个模块，压缩后四者总大小约 16 KB；思考到其引入的 core-js 外部模块（引入任意 core-js polyfill 简直都会引入的局部），总大小约 32 KB。
这其实不算 Babel 的锅。core-js 提供的各 API 浏览器兼容性 core-js-compat 明确地写明 web.url 须要 Safari 14，因而在指标 Safari 版本小于 14 时就会引入 web.url polyfill。那为什么 core-js-compat 会这样要求？因为 Safari 的这些晚期版本的 URL() constructor 存在这样一个 BUG，在给定第二个参数且给定值为 undefined 时会报错。
相似的问题，
- 呈现在数组的
reduce办法上，并且没有在 caniuse 等数据库里失去体现：Chromium 80-83 该办法有时会给出谬误初值，core-js-compat 也因而将该办法的兼容 Chrome 要求进步到了 83+； - 呈现在 Promise Rejection Event 上，指标浏览器不反对该 Event（Firefox < 69）时会引入整个 Promise polyfill。
相似的问题其实有很多，只是目前作者遇到的根本只有这三个。在代码中加上相应的判断、排除极其状况，就能够齐全不应用这几个 polyfill，缩小 bundle 大小。在 Babel 配置文件的插件中设置 “exclude”：
["polyfill-corejs3", {
"method": "usage-pure",
"exclude": [
"web.url",
"es.array.reduce",
"es.promise"
]
}]
