core-js3 与 Babel polyfill 配合完全指南从体积臃肿到按需注入【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js构建产物里那几百 KB 的 polyfill你清楚每一行在补什么吗core-js 是一个模块化 JavaScript 标准库为 ECMAScript 及相关 Web 标准提供 polyfill即给缺失 API 的旧环境补实现而 Babel preset-env 负责根据你的目标浏览器判断该补哪些。这篇文章围绕这套 core-js3 Babel 的组合讲清楚 polyfill 策略到底该怎么选。先说清楚core-js 是什么为什么你不知道它在项目里core-js 做的事情很朴素目标环境缺Object.entries、缺Promise.allSettled它就给出标准实现而且完全模块化可以整包引入也可以只引入某一个 API。它为什么隐形因为 core-js 长期作为间接依赖存在Vue CLI、Create React App、Umi 等脚手架默认通过 Babel preset-env 引入它产物分析时它常被混进 vendor 块和几十个模块的依赖搅在一起。很多时候只有打开构建输出或翻依赖树你才发现它在。说白了你的项目里没有一行import core-js但产物里的 polyfill 很可能都出自 core-js。想清楚这层关系是后面所有选型的前提。core-js3 的三个核心变化对你意味着什么稳定能力落地从逐个手动补到引标准入口core-js3 之前想用 ES2019 的flat/flatMap、Object.fromEntries得自己找到对应模块逐个引入而且稳定入口的覆盖不完整。core-js3 把 ES2015 到 ES2019 的稳定特性对齐了一遍Array.prototype.flat/flatMap、Object.fromEntries、Symbol.prototype.description全部就位同时收进了 WHATWG 侧的URL/URLSearchParams、微任务方法queueMicrotask、以及给 DOM 集合补的.forEach。对你的价值很直接稳定入口变得可信。只要目标端覆盖旧浏览器引一次稳定入口就能覆盖这些常用方法补什么、不补什么交给工具链去判断不用再人工核对清单。前沿提案按 stage 跟进不用等浏览器也不用自己赌对尚未入标的特性core-js 有一套提案跟踪机制每个功能按其 ECMAScript 提案当前所处的 stage 标记维护一旦提案升格为正式标准模块就从esnext.前缀挪进es.前缀。正文里用到的globalThis、Promise.allSettled和Promise.any就属于这一批——写作时它们还在讨论阶段core-js 已经提供了可用实现。这套机制有两层含义新特性可以提前试用不用等浏览器跟进提案命名若调整变的是 core-js 的模块名你的调用习惯基本不受影响。当前跟进了哪些提案可以直接看 proposals 入口目录。 三个包 一套前缀体积成本第一次真正由你决定core-js3 最大的架构动作是拆成三个包各对应一种使用姿态包行为典型场景core-js直接改写修补全局内置对象应用代码需要整个运行环境都变新core-js-pure不碰全局每个 API 单独引入库代码避免与宿主项目互相干扰core-js-bundle预先打包成单文件不走构建步骤、只想要一个文件的环境模块命名也统一成两类前缀es.是已入标的能力esnext.是提案中的能力。以后看构建输出里的模块名一眼能分清它补的是标准还是提案。对库作者来说core-js-pure 的用法边界很明确你的包不应改写宿主的全局对象需要标准库能力时用 pure 版本逐个引入即可。 和 Babel 配合的正确姿势babel/polyfill 弃用后的标准引法老的import babel/polyfill写法已正式弃用——问题在于它捆绑了固定的一整套能力不看目标环境。core-js3 时代的标准引法是import core-js/stable; import regenerator-runtime/runtime; // 支持 generator / async-await 时这是粗模式整包引一次剩下交给打包器摇树。适合无法精确控制注入点的场合。preset-env 的 corejs 选项数据源换成了 core-js-compatpreset-env 开启useBuiltIns时建议显式写corejs: 3。它声明 Babel 按哪个版本的兼容数据来决策core-js3 之后这份数据来自 core-js-compat取代了早期手工维护的兼容表——你给它一组 browserslist 查询它还你一份精确的每个目标浏览器需要哪些 core-js 模块的清单。// babel.config.js module.exports { presets: [ [babel/preset-env, { useBuiltIns: usage, corejs: 3, }], ], };这也是core-js 和 Babel 如何配合这个问题的核心答案Babel 负责判断目标环境缺什么core-js 负责实现提供对应模块core-js-compat 是中间的裁判数据。entry 与 usage 模式怎么选entryusage谁决定注入什么你在代码里显式引入入口Babel扫描代码里实际用到的 API覆盖方式以引入的入口为准入口本身也会按目标优化用到哪补哪精确到调用点适合需要整个环境先就绪应用全局、worker体积敏感、希望按需注入的项目代价简单可控但入口引入多处需注意去重依赖静态分析动态拼出来的 API 名扫不到换个角度看想要某个环境一定就绪选 entry想要哪里有洞补哪里选 usage。两者也可以搭配——用 entry 兜住全局环境让 usage 补剩下的缺口。usage 模式下还能打开proposals选项把esnext.前缀的提案特性也纳入注入范围。babel/runtime 与 core-js-pure 的关系babel/runtime管的是编译产物里的 helper 函数本身不带标准库能力。想给实例方法补 polyfill比如库内部用到的arr.flatMap配合的是babel/runtime-corejs3——它内部接的就是 core-js-pure。这对库作者是一套标准答案能力用 pure 实现不污染宿主全局宿主补什么仍由它自己的构建配置决定。✅ 落地决策清单四类场景如果你是新项目preset-env 配useBuiltIns: usagecorejs: 3browserslist 的目标尽量收窄。usage 是绝大多数场景的默认答案目标越窄Babel 要补的越少。如果你是遗留项目不必一步到位。先把babel/polyfill换成上面两行引入、把 core-js 升到 v3再对比一次构建体积——旧版本不看目标端、固定注入一整套升级后通常会有明显下降。如果你对体积极度敏感除了 usage 模式再核对两处corejs: 3与本地实际安装的 core-js 版本要一致数据源按版本出模块清单拿 core-js-compat 的 API 在本地跑一遍看看目标下到底会注入哪些模块心里有数。如果你在写库SDK / 组件库用 core-js-pure不要引全局的core-jsbabel/runtime-corejs3useBuiltIns: usage是这类场景的标配组合。最后说一句polyfill 生态的趋势已经很明确从整包引入走向按目标环境判断 按需注入core-js3 与 Babel 的组合正是这一趋势最成熟的落地——数据在 core-js-compat判断在 preset-env实现在模块化的 core-js。理解了这条分工链下次再看到构建产物里陌生的 polyfill你就知道它从哪来、能不能砍掉了。【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考