core-js 3 升级避坑指南包怎么选、Babel 怎么配、polyfill 体积如何压到最小【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-jscore-js 3 升级后core-js/modules/...找不到babel/polyfill提示 deprecated这篇文章一次解决三个决策选对 core-js 包、选对入口级别、配好 Babel preset-env 与 swc并给出把 polyfill 体积压到最小的完整方案。一句话结论绝大多数项目直接用全局版core-js 入口core-js/actualBabel 侧配useBuiltIns: entry并写出具体小版本号剩下的是把targets收紧。场景选什么说明业务应用愿意 patch 全局原型core-js全局版polyfill 后直接调用原生写法类库 / 不想污染全局命名空间core-js-pureponyfill方法变成静态方法或独立导入不想手动挑模块core-js-bundle预打包好的全局版需要按目标引擎出定制包core-js-builder可排除特性或针对指定引擎生成先做决策包、入口和 Babel 配置怎么选 这一步回答我到底该 import 什么、配什么。包层面core-js是全局版polyfill 直接打到原生对象上core-js-pure是不污染全局版——因为不能改原生原型原型方法会以静态方法或独立函数形式提供core-js-bundle就是前两者的打包产物。业务应用默认选全局版即可库作者选 pure。入口层面全局版下路径第一段就是加载范围core-js或core-js/full一切含早期 stage 提案最重core-js/actual稳定 ES Web 标准 stage 3 提案——官方推荐档既有即将入标的能力又不掺实验性特性core-js/stable只有稳定部分ES Web 标准core-js/es仅稳定 ES连 Web 标准都不含单模块如core-js/actual/array/flat-map按需精确加载。如果团队是从 2 时代迁上来最容易忽略的一点入口从stable升到actualSet方法、Promise.allSettled、Promise.any、String.prototype.replaceAll这类 stage 3 提案会自动进包而 stage 1/2 的提案Array.prototype.lastItem、Object.groupBy、iterator helpers 这类不会要用得显式引core-js/proposals/xxx。模块内部命名也已规范化稳定功能es.前缀提案功能esnext.前缀。Babel 层面先换掉已弃用的babel/polyfill// 等价替代 babel/polyfill import core-js/stable; import regenerator-runtime/runtime; // 生成器 / async 支持再配 preset-env// babel preset-env { targets: 0.25%, not dead, useBuiltIns: entry, corejs: 3.50, }useBuiltIns: entry会把你写的core-js入口自动改写成目标浏览器真正缺的那几个core-js/modules/...所有入口级别、入口组合都适用useBuiltIns: usage则改为按文件静态分析、自动在文件顶部插入缺失模块——这种模式下不要再手写 core-js 导入会重复。默认两者都只补稳定特性要连提案一起补加proposals: truecorejs: { version: 3.50, proposals: true }。哪些是日常会用到的哪些只是可选件 这一节把 3 时代新增能力分成两层方便你判断入口档位和 proposals 开关。日常高频Array.prototype.flat/flatMapES2018、Object.fromEntriesES2019、Symbol.prototype.descriptionES2019、ES2015 补齐的isConcatSpreadable与species——这些在 stable 里写core-js/actual就都覆盖了。Web 标准侧则是完整实现的URL/URLSearchParams、queueMicrotask、DOM 集合的迭代器与forEach——跨端项目尤其 Node 浏览器同构最容易在 URL 上踩空。进阶可选Array.prototype.lastItem/lastIndex、集合新方法、String.prototype.codePoints、Array.prototype.at的后续提案等 stage 1/2 特性。它们只在显式导入core-js/proposals/xxx或打开proposals: true时进入产物。建议除非团队在主动跟进提案否则别开——早期提案的 API 形态可能变注入进产物等于给自己埋债。Babel 与 swc 配置避坑corejs 版本、usage 模式与注入冲突⚠️ 配置坑比入口选择更致命以下每一条都有真实翻车案例。corejs: 3还是corejs: 3.50必须写具体小版本号。只写大版本3时小版本新增的模块不会被注入——你会得到看起来配了、实际漏了的产物。swc 同理env: { targets, mode: entry | usage, coreJs: 3.50 }其 usage 模式成熟度略逊于 Babel。usage 模式下别手写导入polyfill 由 Babel 按文件自动注入手写导入只会造成重复模块。preset-env 与 babel/runtime 二选一配 corejs两者功能重叠同时配置会互相打架。babel/runtime的corejs: 3会把实例方法调用改写为core-js-pure导入3 时代补上了实例方法 polyfill 这一历史短板并同样支持proposals。检测行为过严/过松core-js 默认做 feature detection原生实现坏了才 patch。个别环境检测太严如 Promise 要求 unhandledrejection 支持或环境有未覆盖的已知 bug 时可用core-js/configurator按 API 精细指定useNative/usePolyfill/useFeatureDetection——这是逃生门不是常规选项。自定义体积上限要用到modules内部路径或生成定制 bundle 时走core-js-builder它依赖 core-js-compat 的目标环境数据而 preset-env 本身在 3 时代也已把兼容性数据源切到 core-js-compat不再吃旧的 compat-table。行动清单升级或核对 core-js 3 时按顺序执行这五条检查依赖树core-js2与3不能混装若因间接依赖锁死在 2先升级依赖而不是自己再装一份。定包应用用core-js库用core-js-pure删掉babel/polyfill改引core-js/stableregenerator-runtime/runtime。定入口业务代码统一core-js/actual确需提案再显式引core-js/proposals/xxx而不是整体开 proposals。定 Babel/swcuseBuiltIns: entry或 usage 具体小版本corejs: 3.50preset-env 与 runtime 的 corejs 只在一处配置。定体积收紧targets后核对构建产物确认只剩目标缺失的模块极限场景用core-js-builder按引擎出定制包。参考文档入口与 Babel 集成说明、项目更新日志。【免费下载链接】core-jsStandard Library项目地址: https://gitcode.com/GitHub_Trending/co/core-js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考