Polyfill方式解决前端兼容性问题：core-js包结构与各种配置策略

优质文章学习记录

— 23 min read
Polyfill方式解决前端兼容性问题：core-js包结构与各种配置策略

简介

在之前我介绍过Babel：解锁Babel核心功能：从转义语法到插件开发，Babel是一个使用AST转义JavaScript语法，提高代码在浏览器兼容性的工具。但有些ECMAScript并不是新的语法，而是一些新对象，新方法等等，这些并不能使用AST抽象语法树来转义。因此Babel利用core-js实现这些代码的兼容性。

core-js是一个知名的前端工具库，里面包含了ECMAScript标准中提供的新对象/新方法等，而且是使用旧版本支持的语法来实现这些新的API。这样即使浏览器没有实现标准中的新API，也能通过注入core-js代码来提供对应的功能。

像这种通过注入代码实现浏览器没有提供的API特性，叫做Polyfill。这个单词的本意是填充材料，在JavaScript领域中，这些注入的代码就类似“填充材料”一样，帮助我们提高代码的兼容性。另外core-js还提供了一些还在提议中的API的实现。

core-js使用方式

使用前后对比

要想看到core-js使用前后的效果对比，首先需要确定某个特性和对应的执行环境，在这个环境中对应的特性不存在。我本地是Node.js v18.19.1版本，这个版本并没有实现Promise.try这个方法，因此我们就用这个方法进行实验。首先是没有引入core-js的场景：

Promise.try(()=>{ console.log('jzplp!')})/* 执行结果 Promise.try(() => { ^ TypeError: Promise.try is not a function */

可以看到没有引入core-js，直接使用Promise.try时，会因为没有该方法而报错。然后再试试引入core-js的效果：

require('core-js') Promise.try(()=>{ console.log('jzplp!')})/* 输出结果 jzplp! */

可以看到引入core-js后，原本不存在的API被填充了，我们的代码可以正常执行并拿到结果了。这就是core-js提高兼容性的效果。

单个API引入

core-js不仅可以直接引入全部语法，还可以仅引入单个API，比如某个对象或某个方法。首先看下只引入Promise对象：

// require('core-js/full') 等于 require('core-js')require('core-js/full/promise') Promise.try(()=>{ console.log('jzplp!')})/* 输出结果 jzplp! */

然后再看下直接引入对象中的某个方法：

require('core-js/full/promise/try') Promise.try(()=>{ console.log('jzplp!')})/* 输出结果 jzplp! */

不注入全局对象

前面展示的场景，core-js都是将API直接注入到全局，这样使用这些API就如环境本身支持一样，基本感受不到区别。但如果我们不希望直接注入到全局时，core-js也提供了使用方式：

const promise =require('core-js-pure/full/promise'); promise.try(()=>{ console.log('jzplp!')}) Promise.try(()=>{ console.log('jzplp!2')})/* 输出结果 jzplp! Promise.try(() => { ^ TypeError: Promise.try is not a function */

可以看到，使用core-js-pure这个包之后，可以直接导出我们希望要的API，而不直接注入到全局。此时直接使用全局对象方法依然报错。而core-js这个包虽然也能导出，但它还是会直接注入全局，我们看下例子：

const promise =require('core-js/full/promise'); promise.try(()=>{ console.log('jzplp!')}) Promise.try(()=>{ console.log('jzplp!2')})/* 输出结果 jzplp! jzplp!2 */

因此，如果希望仅使用导出对象，还是需要使用core-js-pure这个包。core-js-pure也可以仅导出对象方法：

const try2 =require("core-js-pure/full/promise/try"); Promise.try = try2; Promise.try(()=>{ console.log("jzplp!");});/* 输出结果 jzplp! */

因为导出的对象方法不能独立使用，因此在例子中我们还是将其注入到Promise对象后使用。

特性分类引入

core-js中包含非常多API特性的兼容代码，有些是已经稳定的特性，有些是还处在提议阶段的，不稳定的特性。我们直接引入core-js会把这些特性全部引入，但如果不需要那些不稳定特性，core-js也提供了多种引入方式：

  • core-js 引入所有特性，包括早期的提议
  • core-js/full 等于引入core-js
  • core-js/actual 包含稳定的ES和Web标准特性，以及stage3的特性
  • core-js/stable 包含稳定的ES和Web标准特性
  • core-js/es 包含稳定的ES特性

这里我们举两个例子尝试下。首先由于ECMAScript标准一直在更新中，有些特性现在是提议，未来可能就已经被列入正式特性了。因此这里的例子需要明确环境和core-js版本。这里我们使用Node.js v18.19.1和[email protected]版本，以写这篇文章的时间为准。

首先第一个特性是：数组的lastIndex属性，这是一个stage1阶段的API，这里针对不同的引入方式进行尝试：

// 不引入core-js尝试const arr =["jz","plp"]; console.log(arr.lastIndex);/* 输出结果 undefined */// 引入core-js/fullrequire("core-js/full");const arr =["jz","plp"]; console.log(arr.lastIndex);/* 输出结果 1 */// 引入core-js/actualrequire("core-js/actual");const arr =["jz","plp"]; console.log(arr.lastIndex);/* 输出结果 undefined */

首先当不引入core-js时，因为不支持这个API，所以输出undefined。core-js/full支持stage1阶段的API，可以正确输出结果。但core-js/actual仅支持stage3阶段的API，因此还是不支持这个API。

然后我们再看下另外一个API，数组的groupBy方法。这是一个stage3阶段的API：

// 不引入core-js尝试const arr =[{group:1,value:"jz"},{group:2,value:"jz2"},{group:1,value:"plp"},];const arrNew = arr.groupBy(item=> item.group); console.log(arrNew)/* 输出结果 const arrNew = arr.groupBy(item => item.group); ^ TypeError: arr.groupBy is not a function */// 引入core-js/actualrequire("core-js/actual");const arr =[{group:1,value:"jz"},{group:2,value:"jz2"},{group:1,value:"plp"},];const arrNew = arr.groupBy(item=> item.group); console.log(arrNew)/* 输出结果 [Object: null prototype] { '1': [ { group: 1, value: 'jz' }, { group: 1, value: 'plp' } ], '2': [ { group: 2, value: 'jz2' } ] } */// 引入core-js/stablerequire("core-js/stable");const arr =[{group:1,value:"jz"},{group:2,value:"jz2"},{group:1,value:"plp"},];const arrNew = arr.groupBy(item=> item.group); console.log(arrNew)/* 输出结果 const arrNew = arr.groupBy(item => item.group); ^ TypeError: arr.groupBy is not a function */

可以看到，不引入core-js时不支持，引入了core-js/actual（包含stage3阶段的API）后支持并能输出正确的结果。core-js/stable中不支持又报错了。

core-js源码结构

前面描述了很多core-js的引入方式，这里我们看一下源码结构，看看core-js内部是如何组织的。

core-js源码目录

core-js ├─actual │ ├─array │ │ ├─at.js │ │ ├─concat.js │ │ └─... │ ├─set │ │ └─... │ └─... ├─es │ └─... ├─features │ └─... ├─index.js └─...

首先列出core-js源码目录的示意图，可以看到core-js内部有很多目录，对应前面的各种引入方式。这里我们列出每个目录的内容：

  • actual 包含稳定的ES和Web标准特性，以及stage3的特性
  • es 包含稳定的ES特性
  • features 没有说明，猜测和full类似
  • full 所以特性包括早期提议
  • internals 包内部使用的逻辑
  • modules 实际特性的代码实现
  • proposals 包含提议的特性
  • stable 包含稳定的ES和Web标准特性
  • stage 按照stage阶段列出提议特性
  • web 包含Web标准特性
  • configurator.js 是否强制引入逻辑，后面会描述
  • index.js 内容为导出full目录，因此导入core-js等于导入core-js/full

层层引用

在目录中actual, es, full, stable, es是我们已经介绍过的。另外还有web目录仅包含web标准的特性，features和full类似（index.js中直接导出full目录）。

proposals目录包含提议的特性，以特性名来命名文件名。而stage目录中包含0.js, 1.js, 2.js等等，是根据stage阶段来整理的，方便整理和引入对应阶段的特性。

这样整理目录虽然清晰，但这些目录中的特性都是重复的，不可能在每个目录中把特性都实现一遍。因此上面这些目录的文件中，存放的都是实现的引用，并不是特性代码实现本身。真正的实现在modules目录中。modules目录中是以特性名作为命名的文件，文件有固定的前缀名：es.表示ES标准；esnext.表示提议中的标准；web.表示web标准。

这里以我们上面提到过的两个特性为例，看看引用路径，首先是Promise.try：

  • 使用者引入 core-js/full/promise/try.js
  • 引入 actual/promise/try.js
  • 引入 actual/promise/try.js
  • 引入 stable/promise/try.js
  • 引入 es/promise/try.js
  • 最终引入 modules/es.promise.try.js

然后是groupBy方法：

  • 使用者引入 core-js/actual/array/group-by.js
  • 最终引入 modules/esnext.array.group-by.js

可以看到，core-js内部的特性是经过层层引入，最终引入具体的实现代码的。

core-js-pure与core-js-bundle

除了core-js之外，core-js-pure与core-js-bundle这两个包也提供了兼容性。core-js-pure内部的目录结构与core-js一致，只不过core-js-pure不将特性注入到全局。core-js-bundle比较特殊，它是将core-js代码经过打包后再提供，它的结构如下：

core-js-bundle ├─index.js ├─minified.js ├─minified.js.map └─...

其中index.js是打包过后的特性集合代码，minified.js是经过压缩混淆后的代码。core-js-bundle只能全部引入并注入到全局，不能引入部分目录或者导出某个属性。

打包和浏览器效果

创建Webpack示例

首先创建一个Webapck项目，方便后续打包查看效果。首先执行：

# 创建项目npm init -y # 安装webpack依赖npmadd webpack webpack-cli html-webpack-plugin # 安装core-js依赖npmadd core-js core-js-pure core-js-bundle

创建src/index.js，内容如下：

const arr =["jz","plp"]; console.log(arr.lastIndex);

在package.json文件的scripts中增加命令：“build”: “webpack”。最后是Webpack配置文件webpack.config.js:

const path =require('path');const HtmlWebpackPlugin =require('html-webpack-plugin'); module.exports ={mode:'production',// 生产模式entry:'./src/index.js',// 源码入口plugins:[newHtmlWebpackPlugin({// 生成HTML页面入口title:'jzplp的core-js实验',// 页面标题}),],output:{filename:'main.js',// 生成文件名path: path.resolve(__dirname,'dist'),// 生成文件目录clean:true,// 生成前删除dist目录内容},};

命令行运行npm run build，即可使用Webpack打包。在dist目录中生成了两个文件，一个是main.js，里面是打包后的js代码；index.html可以让我们在浏览器查看效果。由于我们没有引入core-js，浏览器没有预置lastIndex这个提议中的特性，因此输出undefined。

core-js打包

这里引入core-js，然后打包查看效果。首先是全量引入：

require("core-js");const arr =["jz","plp"]; console.log(arr.lastIndex);

此时浏览器输出1，表示core-js注入成功，lastIndex特性生效了。但是我们查看main.js，发现居然有267KB。这是因为它把所有特性都引入了。

如果引入require("core-js/full/array")，此时新特性也可以生效。因为只引入了数组相关特性，因此main.js的大小为59.3KB，比全量引入小很多。

如果引入require("core-js/full/array/last-index")，此时新特性也可以生效。因为只引入了这一个特性，因此main.js的大小为12.2KB。

Babel与core-js

从前面打包的例子中可以看到，core-js整个打包进项目中是非常巨大的，可能比你正常项目的大小还要更大。这样明显会造成占用资源更多，页面加载时间变慢等问题。一个解决办法是，只引入我们代码中使用到的特性，以及我们要适配的浏览器版本中不兼容的特性，用不到的特性不打包进代码中。Babel就提供了这样的功能。

创建Babel示例

# 创建项目npm init -y # 安装webpack依赖npmadd @babel/core @babel/cli @babel/preset-env # 安装core-js依赖npmadd core-js core-js-pure core-js-bundle

创建src/index.js，内容如下：

require('core-js');const jzplp =1;

在package.json文件的scripts中增加命令：“babel”: “babel src --out-dir lib”。最后是Babel配置文件babel.config.json:

{"presets":[["@babel/preset-env",{"targets":{"chrome":"100"}}]]}

targets中表示我们需要兼容的浏览器版本。执行npm run babel，生成结果再lib/index.js中，内容如下。可以看到未对core-js做任何处理。

"use strict";require('core-js');const jzplp =1;

preset-env配置entry

@babel/preset-env是一个Babel预设，可以根据配置为代码增加兼容性处理。前面创建Babel示例时已经增加了这个预设，但是没有增加core-js配置。这里我们加一下：

{"presets":[["@babel/preset-env",{"targets":{"chrome":"100"},"useBuiltIns":"entry","corejs":"3.47.0"}]]}

这里增加了corejs版本和useBuiltIns配置，值为entry。配置这个值，会使得@babel/preset-env根据配置的浏览器版本兼容性，选择引入哪些core-js中的特性。这里再执行命令行，结果如下：

"use strict";require("core-js/modules/es.symbol.async-dispose.js");require("core-js/modules/es.symbol.dispose.js");// ... 更多es特性省略require("core-js/modules/esnext.array.filter-out.js");require("core-js/modules/esnext.array.filter-reject.js");// ... 更多esnext特性省略require("core-js/modules/web.dom-exception.stack.js");require("core-js/modules/web.immediate.js");// ... 更多web特性省略const jzplp =1;

可以看到core-js被拆开，直接引入了特性本身。在配置chrome: 100版本时，引入的特性为215个。我们修改配置chrome: 140版本时，再重新生成代码，此时引入的特性为150个。可以看到确实时根据浏览器版本选择不同的特性引入。这对于其它core-js的引入方式也生效：

// 源代码require('core-js/stable');const jzplp =1;// 生成代码"use strict";require("core-js/modules/es.symbol.async-dispose.js");require("core-js/modules/es.symbol.dispose.js");// ... 更多es特性省略require("core-js/modules/web.dom-exception.stack.js");require("core-js/modules/web.immediate.js");// ... 更多web特性省略const jzplp =1;

我们引入core-js/stable，可以看到生成代码中不引入esnext特性了。在配置chrome: 100版本时，引入的特性为71个，配置chrome: 100版本时，引入的特性为6个。同样的，如果引入换成core-js/full/array，就会只引入数组相关特性，而且也是根据浏览器兼容版本引入。

preset-env配置usage

@babel/preset-env的useBuiltIns配置值为usage时，Babel不仅会跟根据配置的浏览器版本兼容性，还会根据代码中实际使用的特性来选择引入哪些core-js中的特性。首先是Babel配置：

{"presets":[["@babel/preset-env",{"targets":{"chrome":"100"},"useBuiltIns":"usage","corejs":"3.47.0"}]]}

然后是要处理的代码，注意配置usage时是不需要手动引入core-js的。我们配置不同的Chrome浏览器版本，看看输出结果如何：

// 源代码const jzplp =newPromise();const b =newMap();// chrome 50 生成代码 "use strict";require("core-js/modules/es.array.iterator.js");require("core-js/modules/es.map.js");require("core-js/modules/es.promise.js");require("core-js/modules/web.dom-collections.iterator.js");const jzplp =newPromise();const b =newMap();// chrome 100 生成代码 "use strict";const jzplp =newPromise();const b =newMap();

首先可以看到，引入core-js中的特性数量变得非常少了，代码中没有用到的特性不再引入。其次不同的浏览器版本引入的特性不一样，因此还是会根据浏览器兼容性引入特性。我们再修改一下源代码试试：

// 源代码const jzplp =newPromise();const b =newMap(); Promise.try(()=>{});// chrome 50 生成代码 "use strict";require("core-js/modules/es.array.iterator.js");require("core-js/modules/es.map.js");require("core-js/modules/es.promise.js");require("core-js/modules/es.promise.try.js");require("core-js/modules/web.dom-collections.iterator.js");const jzplp =newPromise();const b =newMap(); Promise.try(()=>{});// chrome 100 生成代码 "use strict";require("core-js/modules/es.promise.try.js");const jzplp =newPromise();const b =newMap(); Promise.try(()=>{});

可以看到，源代码中增加了Promise.try，引入的特性也随之增加了对应的core-js特性引入。因此，使用@babel/preset-env的usage配置，可以保证兼容性的同时，最小化引入core-js特性。另外这个配置并不会自动引入提议特性，如果需要则额外配置proposals为true。

@babel/polyfill

@babel/polyfill是一个已经被弃用的包，推荐直接使用core-js/stable。查看@babel/polyfill源码，发现他就是引入了core-js特性与regenerator-runtime这个包。regenerator-runtime也是一个兼容性相关的包，可以帮助添加generatore和async/await相关语法。作为替代可以这样引入：

import'core-js/stable';import'regenerator-runtime/runtime';

@babel/runtime

@babel/runtime就像自动引入版的core-js-pure。它还是根据代码实际使用的特性来注入core-js特性，但它不注入到全局，而是引入这些API再调用。这里我们使用@babel/plugin-transform-runtime插件，里面包含了@babel/runtime相关逻辑。首先看下Babel配置：

{"plugins":[["@babel/plugin-transform-runtime",{"corejs":3}]]}

再转义上一节中的代码，结果如下：

// 源代码const jzplp =newPromise();const b =newMap(); Promise.try(()=>{});// 生成代码import _Promise from"@babel/runtime-corejs3/core-js-stable/promise";import _Map from"@babel/runtime-corejs3/core-js-stable/map";const jzplp =new_Promise();const b =new_Map(); _Promise.try(()=>{});

可以看到，虽然没有直接引入core-js-pure，但效果是一样的。打开@babel/runtime-corejs3这个包查看，里面实际上就是导出了core-js-pure中的特性。例如：

// @babel/runtime-corejs3/core-js-stable/map.js 文件内容 module.exports =require("core-js-pure/stable/map");

core-js/configurator强制控制

如果希望在正常引入core-js时，对于部分特殊属性进行引入或者不引入的控制，就需要用到core-js/configurator。这个工具可以配置三种选项：

  • useNative: 当环境中有这个特性时不引入，当确定没有时才引入
  • usePolyfill: 明确引入这个特性
  • useFeatureDetection: 默认行为，和不使用core-js/configurator一致

useNative不引入

首先试试不引入特性，这里我们使用Promise这个特性为例。首先是不引入core-js的效果，可以看到全局Promise对象被我们改掉了。

const jzplp ={}; Promise = jzplp; console.log(Promise, Promise === jzplp);/* 输出结果 {} true */

然后在中间引入core-js试试。可以看到我们改掉的Promise，被core-js给改回去了。

const jzplp ={}; Promise = jzplp;require("core-js/actual"); console.log(Promise, Promise === jzplp);/* 输出结果 [Function: Promise] false */

这时候，如果不希望core-js改掉我们自定义的Promise，可以利用useNative配置，强制core-js不引入这个特性。看结果core-js引入之后，我们自定义的Promise依然存在。

const configurator =require("core-js/configurator");configurator({useNative:["Promise"],});const jzplp ={}; Promise = jzplp;require("core-js/actual"); console.log(Promise, Promise === jzplp);/* 输出结果 {} true */

usePolyfill强制引入

想要验证usePolyfill的效果，需要找一个环境中本来存在的特性，core-js即使引入也不会修改的特性。Promise不行，因为core-js引入时会对这个Promise增加子特性。Promise.try也不行，因为原来环境中不存在。这里试一下Promise.any，这是环境中本来就存在的特性：

console.log(Promise.any);constjzplp=()=>{}; Promise.any = jzplp; console.log(Promise.any, Promise.any === jzplp);/* 输出结果 [Function: any] [Function: jzplp] true */

可以看到，Promise.any原来就存在，但是被我们修改成了新函数。再引入core-js试试：

console.log(Promise.any);constjzplp=()=>{}; Promise.any = jzplp;require('core-js'); console.log(Promise.any, Promise.any === jzplp);/* 输出结果 [Function: any] [Function: jzplp] true */

引入了core-js之后，结果没有变化。这说明core-js并不会修改我们自定义的函数。这时候就可以试一下usePolyfill的效果了：

const configurator =require("core-js/configurator");configurator({usePolyfill:["Promise.any"],}); console.log(Promise.any);constjzplp=()=>{}; Promise.any = jzplp;require('core-js'); console.log(Promise.any, Promise.any === jzplp);/* 输出结果 [Function: any] [Function: any] false */

可以看到，Promise.any又被改为了真正起效果的函数，这说明usePolyfill的强制引入特性是有效的。

core-js中的特性选择

前面我们体验了Babel根据浏览器兼容性，选择不同的core-js特性引入，那么不同浏览器兼容哪些特性的数据是从哪里获取呢？core-js本身就提供了这个功能。

core-js-compat

core-js-compat提供了不同浏览器对应特性的兼容性数据。它有好几个参数，这里先列举一下含义：

  • targets: Browserslist格式的浏览器兼容配置
  • modules: 需要设置兼容性配置的模块，可以是core-js/full，也可以是某个特性，甚至是正则
  • exclude: 需要排除的模块
  • version: 使用的core-js版本
  • inverse: 反向输出，即输出不需要兼容的特性列表

这里举几个例子试一下：

const compat =require("core-js-compat");const data =compat({targets:"> 10%",modules:["core-js/actual"],version:"3.47",}); console.log(data);/* 输出结果 { list: [ 'es.iterator.concat', 'es.math.sum-precise', 'es.async-iterator.async-dispose', 'esnext.array.group', 'esnext.array.group-by', ...其它特性 ], targets: { 'es.iterator.concat': { 'chrome-android': '143' }, 'es.math.sum-precise': { 'chrome-android': '143' }, 'es.async-iterator.async-dispose': { 'chrome-android': '143' }, 'esnext.array.group': { 'chrome-android': '143' }, 'esnext.array.group-by': { 'chrome-android': '143' }, ...其它特性 } } */

compat会根据我们设置的浏览器兼容性配置，输出特性列表，包含两个字段：list是一个特性名称列表；targets是一个Map结构，key为特性名，值为可以兼容的浏览器。假设我们把上面的 targets改成 > 50%，此时会输出空值：

const compat =require("core-js-compat");const data =compat({targets:"> 50%",modules:["core-js/actual"],version:"3.47",}); console.log(data);/* 输出结果 { list: [], targets: {} } */

我们增加exclude，排除部分属性，可以看到特性数量大大减少：

const compat =require("core-js-compat");const data =compat({targets:"> 10%",modules:["core-js/actual"],exclude:["esnext"],version:"3.47",}); console.log(data);/* 输出结果 { list: [ 'es.iterator.concat', 'es.math.sum-precise', 'es.async-iterator.async-dispose', 'web.dom-exception.stack', 'web.immediate', 'web.structured-clone' ], targets: { 'es.iterator.concat': { 'chrome-android': '143' }, 'es.math.sum-precise': { 'chrome-android': '143' }, 'es.async-iterator.async-dispose': { 'chrome-android': '143' }, 'web.dom-exception.stack': { 'chrome-android': '143' }, 'web.immediate': { 'chrome-android': '143' }, 'web.structured-clone': { 'chrome-android': '143' } } } */

再试一下inverse的效果：

const compat =require("core-js-compat");const data =compat({targets:"> 10%",modules:["core-js/actual"],version:"3.47",inverse:true}); console.log(data);/* 输出结果 { list: [ 'es.symbol', 'es.symbol.description', ...其它特性 ], targets: { 'es.symbol': {}, 'es.symbol.description': {}, ...其它特性 } } */

因为输出的是不需要引入core-js兼容的特性，所以特性数量非常多，而且targets中没有列出支持的浏览器版本。

core-js-builder

前面介绍的core-js-compat是接收参数之后，输出core-js的特性列表数组。而core-js-builder接收类似的参数，直接输出引用core-js的代码。我们首先列举一下参数：

  • targets: Browserslist格式的浏览器兼容配置
  • modules: 需要设置兼容性配置的模块，可以是core-js/full，也可以是某个特性，甚至是正则
  • exclude: 需要排除的模块
  • format: 'bundle’输出打包后的源码；'cjs’和’esm’输出对应格式的引用代码
  • filename: 输出的文件名

我们先试一下例子。首先是format格式的：

const builder =require("core-js-builder");asyncfunctionfunJzplp(){const data =awaitbuilder({targets:"> 30%",modules:["core-js/actual"],format:'bundle',}); console.log(data);}funJzplp();/* 输出结果 ...代码很长，这里节选部分 (function(module, exports, __webpack_require__) { "use strict"; var NATIVE_BIND = __webpack_require__(8); var FunctionPrototype = Function.prototype; */

可以看到，builder函数输出了非常长的代码，内容实际为输出的特性经过打包之后的结果代码。再试一下’cjs’和’esm’，输出的是对应木块的引用代码：

// format: 'cjs' 输出结果...代码很长，这里节选部分 require('core-js/modules/es.iterator.concat');require('core-js/modules/es.math.sum-precise');require('core-js/modules/es.async-iterator.async-dispose');*/// format: 'esm' 输出结果...代码很长，这里节选部分 import'core-js/modules/es.iterator.concat.js';import'core-js/modules/es.math.sum-precise.js';import'core-js/modules/es.async-iterator.async-dispose.js';*/

如果设置了filename，core-js-builder会创建该名称的文件，并将代码写入到文件中。

总结

这篇文章描述了core-js相关包的代码内容和使用方式。core-js实际上就是提供了JavaScript中一些API特性的兼容实现方式。它与实现语法兼容的Babel一起，可以做到大部分JavaScript的兼容性。当然core-js和Babel也不是万能的，它们都有各自无法转义和兼容的语法和特性。

core-js这个包名字起的非常好，一听就是JavaScript的“核心”包。由于它实现了很多API特性，而且引用数量非常非常大，因此叫“核心”也不为过。虽然这个包引用量很大，但不如React/Vue或者一些其它包出名。因为这个包是处理的更底层的兼容性有问题，因此用户感知不强。core-js包的作者还因为没有钱而遇到很多问题，这个包并没有让他变的富有。

参考

  • core-js 文档
    https://core-js.io/
  • Github core-js
    https://github.com/zloirock/core-js
  • 解锁Babel核心功能：从转义语法到插件开发
    https://jzplp.github.io/2025/babel-intro.html
  • @babel/preset-env 文档
    https://babeljs.io/docs/babel-preset-env
  • @babel/polyfill 文档
    https://babeljs.io/docs/babel-polyfill
  • @babel/runtime 文档
    https://babeljs.io/docs/babel-runtime
  • Github regenerator-runtime
    https://github.com/facebook/regenerator/tree/main/packages/runtime
  • Github core-js-compat
    https://github.com/zloirock/core-js/blob/master/packages/core-js-compat
  • Github core-js-builder
    https://github.com/zloirock/core-js/tree/master/packages/core-js-builder
  • So, what’s next?
    https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md

Read more

Lostlife2.0下载官网整合LLama-Factory引擎，增强NPC对话逻辑

Lostlife2.0整合LLama-Factory引擎，重塑NPC对话逻辑 在文字冒险游戏的世界里，玩家最怕什么？不是任务太难，也不是剧情平淡——而是和一个“话术机械、反应呆板”的NPC对话时，那种瞬间出戏的割裂感。明明世界观设定是末世废土，结果NPC张口就是“绝绝子”“破防了”，这种语言风格的崩塌足以让沉浸感荡然无存。 《Lostlife2.0》作为一款以深度叙事和角色互动为核心卖点的文字冒险游戏，在开发过程中就直面了这一难题。早期版本中，NPC的对话依赖传统的决策树系统：每句台词都由编剧手动编写，每个分支都需要精确配置。这不仅导致内容维护成本极高，更带来了“选项爆炸”问题——新增一条剧情线，往往要额外添加数十个节点，最终形成一张难以管理的复杂网络。 真正的转机出现在团队引入 LLama-Factory 之后。这个开源的大模型微调框架，原本主要用于科研与企业级AI定制，但《Lostlife2.0》团队敏锐地意识到：它或许能成为解决NPC智能瓶颈的关键工具。通过将LLama-Factory深度集成到开发流程中，他们成功构建了一套动态、可进化、风格一致的对话生成系统，彻底改变了传

VSCode中GitHub Copilot的大模型体系、订阅策略与 Agent 模式模型管理机制

一、引言 随着大语言模型（Large Language Models, LLMs）在软件工程领域的广泛应用，智能编程助手逐渐成为现代开发工具链的重要组成部分。其中，由 GitHub 推出的 GitHub Copilot 已成为最具影响力的 AI 编程辅助工具之一，并深度集成于 Visual Studio Code 等主流开发环境。 早期版本的 Copilot 主要依赖单一模型进行代码补全，而近年来其架构已经演进为 多模型（multi-model）驱动的智能编程平台。该平台不仅支持来自多个 AI 厂商的大模型，还通过 Agent 模式、模型路由与按需调用机制提升复杂软件开发任务的自动化程度。 本文将系统介绍以下四个方面： 1. VS Code 中 GitHub Copilot 的 大模型支持体系 2. Copilot 的 订阅策略与计费机制

KRS（Kratos Robotics Stack）：让 Zynq / FPGA 机器人开发真正“跑”起来

在机器人与自主系统开发中，ROS 2 已经成为事实标准，但当它遇到 FPGA / Zynq / Kria 这类异构平台时，工程复杂度往往直线上升。 KRS（Kratos Robotics Stack） 正是为了解决这个问题而诞生的。 KRS 是一个由 Xilinx（AMD）官方推动的 开源机器人软件栈，目标非常明确： 让基于 ROS 2 的机器人应用，能够高效、可重复、工程化地运行在 Zynq 和 Kria 平台上。 先看下下面的应用视频： 🧠 什么是 KRS？ KRS（Kratos Robotics Stack） 是一个围绕 ROS 2 + FPGA 加速 构建的完整开发框架，主要面向： * Zynq UltraScale+ MPSoC

从零构建FPGA上的Cortex-M0 SoC：解密AHB总线与软核协同设计

从零构建FPGA上的Cortex-M0 SoC：解密AHB总线与软核协同设计 在嵌入式系统开发领域，FPGA与ARM Cortex-M0处理器的结合为开发者提供了前所未有的灵活性和定制化可能。这种组合不仅能够满足特定应用场景的性能需求，还能大幅降低系统功耗和成本。本文将带您深入探索如何在FPGA平台上从零构建一个完整的Cortex-M0 SoC系统，重点解析AHB总线协议的关键实现细节，并分享软硬件协同设计的实战经验。 1. Cortex-M0软核基础与FPGA集成 ARM Cortex-M0作为ARM家族中最精简的32位处理器内核，以其出色的能效比和精简指令集架构（Thumb ISA子集）著称。在FPGA环境中，我们可以通过软核形式将其部署到可编程逻辑器件中，构建完整的片上系统。 1.1 Cortex-M0软核获取与特性 从ARM官网获取的Cortex-M0 DesignStart版本提供了完整的RTL代码（通常以加密网表形式提供），包含以下核心组件： * 三级流水线处理器核心 * 嵌套向量中断控制器(NVIC) * AHB-Lite总线接口 * JTAG调试接