Question
core-js 3.x: Transitioning proposal polyfills to stable imports
Dev Orbit
0 reputation · 10 Dec 2020, 04:54 UTC
65.3K views
Loading…
0 reputation · 10 Dec 2020, 04:54 UTC
In core-js version 3, the library distinguishes between stable ECMAScript features and those currently in the proposal stage. This allows developers to opt into experimental functionality via specific proposal imports before they are finalized in the official specification.
A challenge arises when a feature transitions from a proposal to a stable standard. Because the internal structure and import paths for proposals differ from those in core-js/stable, maintaining a consistent bundle requires a strategy for updating these references across minor releases.
Given the modular architecture of version 3, there is uncertainty regarding the synchronization of these promotions. Specifically, it is unclear if a feature promoted to stable in a new minor release remains available under its previous proposal path for backward compatibility, or if it necessitates an immediate migration to the stable import path to avoid duplication.
34275 reputation · 10 Dec 2020, 05:53 UTC
In core‑js 3.x a proposal import such as core-js/es/array/flat is a temporary shim. Once the feature is finalized in the ECMAScript spec, the same module is re‑exported under the stable path core-js/es/array/flat (the same string, but the internal implementation switches from the proposal module to the final one). core‑js does not keep an alias that points the old proposal path to the stable implementation; the path itself remains unchanged, but the module content is updated. Therefore you can continue to import the same string after promotion, but you should not rely on a legacy core-js/proposals/… path that existed in older minor releases.
corejs
javascriptproposals to the stable namespace. The core-js GitHub releases page is the authoritative source.npm view core-js@<minor> dist.tarball to download the tarball, extract lib/es/… and verify that the file exists. If it does, the feature is available in the stable namespace for that release.@babel/preset-env detection. Configure Babel with corejs: { version: 3, proposals: true }. Babel will emit imports from the stable path once the proposal is promoted; you can observe the emitted code in the transpiled bundle to confirm the switch.3.x release: npm install core-js@latest.import 'core-js'; or require('core-js');.import 'core-js/es/array/flat';.To give a precise migration plan, I need to know which proposal you are currently using. Could you share the import path you are migrating (e.g., core-js/proposals/array/flat)?
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 10 Dec 2020, 12:47 UTC
When a proposal‑level feature is promoted to the stable distribution in a minor release, core-js usually leaves the original proposal import (for example core-js/proposals/string/match-all) as a deprecated alias that points to the newly stable implementation. This alias is present only for that minor release; it is removed in the following major version, and using it will trigger a deprecation warning. To verify whether a specific feature still retains such an alias in a given version, you can inspect the lib/proposals/ directory of the published package or look for a “deprecated” note in the changelog entry for that release.