core-js isn't backed by a company, so the future of this project depends on you. Become a sponsor or a backer if you are interested in core-js: Open Collective, Patreon, Bitcoin ( bc1qlea7544qtsmj2rayg0lthvza9fau63ux0fstcz ).
import'core-js/actual';// <- at the top of your entry pointArray.from(newSet([1,2,3,2,1]));// => [1, 2, 3][1,2,3,4,5].group(it=>it%2);// => { 1: [1, 3, 5], 0: [2, 4] }Promise.resolve(42).then(x=>console.log(x));// => 42structuredClone(newSet([1,2,3]));// => new Set([1, 2, 3])queueMicrotask(()=>console.log('called as microtask'));
You can load only required features:
import'core-js/actual/array/from';// <- at the top of your entry pointimport'core-js/actual/array/group';// <- at the top of your entry pointimport'core-js/actual/set';// <- at the top of your entry pointimport'core-js/actual/promise';// <- at the top of your entry pointimport'core-js/actual/structured-clone';// <- at the top of your entry pointimport'core-js/actual/queue-microtask';// <- at the top of your entry pointArray.from(newSet([1,2,3,2,1]));// => [1, 2, 3][1,2,3,4,5].group(it=>it%2);// => { 1: [1, 3, 5], 0: [2, 4] }Promise.resolve(42).then(x=>console.log(x));// => 42structuredClone(newSet([1,2,3]));// => new Set([1, 2, 3])queueMicrotask(()=>console.log('called as microtask'));
You can import only-required-for-you polyfills, like in examples at the top of README.md. Available CommonJS entry points for all polyfilled methods / constructors and namespaces. Just some examples:
// polyfill all `core-js` features, including early-stage proposals:import"core-js";// or:import"core-js/full";// polyfill all actual features - stable ES, web standards and stage 3 ES proposals:import"core-js/actual";// polyfill only stable features - ES and web standards:import"core-js/stable";// polyfill only stable ES features:import"core-js/es";// if you want to polyfill `Set`:// all `Set`-related features, with early-stage ES proposals:import"core-js/full/set";// stable required for `Set` ES features, features from web standards and stage 3 ES proposals:import"core-js/actual/set";// stable required for `Set` ES features and features from web standards// (DOM collections iterator in this case):import"core-js/stable/set";// only stable ES features required for `Set`:import"core-js/es/set";// the same without global namespace pollution:importSetfrom"core-js-pure/full/set";importSetfrom"core-js-pure/actual/set";importSetfrom"core-js-pure/stable/set";importSetfrom"core-js-pure/es/set";// if you want to polyfill just required methods:import"core-js/full/set/intersection";import"core-js/actual/array/find-last";import"core-js/stable/queue-microtask";import"core-js/es/array/from";// polyfill iterator helpers proposal:import"core-js/proposals/iterator-helpers";// polyfill all stage 2+ proposals:import"core-js/stage/2";
Note: The usage of the /actual/ namespace is recommended since it includes all actual JavaScript features and does not include unstable early-stage proposals that are available mainly for experiments.
modules path is an internal API, does not inject all required dependencies and can be changed in minor or patch releases. Use it only for a custom build and/or if you know what are you doing.
If you use core-js with the extension of native objects, recommended load all core-js modules at the top of the entry point of your application, otherwise, you can have conflicts.
For example, Google Maps use their own Symbol.iterator, conflicting with Array.from, URLSearchParams and/or something else from core-js, see related issues.
Such conflicts also resolvable by discovering and manual adding each conflicting entry from core-js.
core-js is extremely modular and uses a lot of very tiny modules, because of that for usage in browsers bundle up core-js instead of usage loader for each file, otherwise, you will have hundreds of requests.
CommonJS and prototype methods without global namespace pollution⬆
In the pure version, we can't pollute prototypes of native constructors. Because of that, prototype methods transformed into static methods like in examples above. But with transpilers, we can use one more trick - bind operator and virtual methods. Special for that, available /virtual/ entry points. Example:
Now it's deprecated in favour of separate inclusion of required parts of core-js and regenerator-runtime and, for preventing breaking changes, left on core-js@2.
As a full equal of @babel/polyfill, you can use this:
@babel/preset-env has useBuiltIns option, which optimizes working with global version of core-js. With useBuiltIns option, you should also set corejs option to used version of core-js, like corejs: '3.24'.
Warning! Recommended to specify used minor core-js version, like corejs: '3.24', instead of corejs: 3, since with corejs: 3 will not be injected modules which were added in minor core-js releases.
useBuiltIns: 'entry' replaces imports of core-js to import only required for a target environment modules. So, for example,
useBuiltIns: 'usage' adds to the top of each file import of polyfills for features used in this file and not supported by target environments, so for:
// first file:varset=newSet([1,2,3]);// second file:vararray=Array.of(1,2,3);
if target contains an old environment like IE 11 we will have something like:
// first file:import'core-js/modules/es.array.iterator';import'core-js/modules/es.object.to-string';import'core-js/modules/es.set';varset=newSet([1,2,3]);// second file:import'core-js/modules/es.array.of';vararray=Array.of(1,2,3);
By default, @babel/preset-env with useBuiltIns: 'usage' option only polyfills stable features, but you can enable polyfilling of proposals by proposals option, as corejs: { version: '3.24', proposals: true }.
Warning! In the case of useBuiltIns: 'usage', you should not add core-js imports by yourself, they will be added automatically.
@babel/runtime with corejs: 3 option simplifies work with core-js-pure. It automatically replaces usage of modern features from JS standard library to imports from the version of core-js without global namespace pollution, so instead of:
客服电话
APP下载
官方微信
请发表评论