core-js/stable global polyfills mutate native built-ins after import

Question

Adding core-js to a bundle should provide polyfills without changing how existing native methods behave for code that does not opt in. When core-js/stable is used with Babel preset-env, third-party libraries that feature-test built-ins may see modified globals such as Promise or Array.
The exact behavior depends on whether core-js/stable or core-js/pure is imported, the core-js major version, and the Babel useBuiltIns mode. Once global polyfills are applied in a running Node or browser environment, it is unclear whether removing the import reverts the built-ins or whether the mutation persists for the lifetime of the process.
Does importing core-js/stable permanently modify global built-ins in the current environment? Can core-js/pure be mixed with core-js/stable without reintroducing global pollution? Which combination of core-js version and Babel preset-env useBuiltIns mode avoids unexpected native changes?

Tasadduq Burney · Answer

Direct answer
Yes. Importing core-js/stable patches the current JavaScript realm's native built-ins, such as Promise, Array.prototype, and Object methods. The change persists for the lifetime of that realm or Node process. Removing the import statement does not revert the built-ins, and core-js provides no unimport or restore operation.
Likely explanation versus confirmed behavior
core-js/stable is a global entry polyfill: it mutates natives so all code in the same realm sees the patched versions. core-js/pure exports polyfilled members without touching globals. Mixing core-js/pure with core-js/stable does not undo the pollution; if stable runs anywhere in the realm, the built-ins remain patched for every script, library, and feature detector that runs afterward.
Recommended core-js and Babel combination
Use core-js 3.x with @babel/preset-env configured as:
useBuiltIns: 'usage',
corejs: { version: 3, proposals: false }
This transforms only the features your code actually uses into per-file imports, typically backed by core-js-pure, instead of injecting a global entry polyfill. Avoid useBuiltIns: 'entry' with core-js/stable, because that mode explicitly expects global patching at the entry point. useBuiltIns: false disables automatic polyfills and is not a substitute when you need them.
Assumption and uncertainty
This guidance targets core-js 3.x and a recent @babel/preset-env. Exact import mapping can vary across preset-env versions, so verify against your installed toolchain before deploying.
Steps for this case

Remove direct import 'core-js/stable' or import 'core-js/es' statements from entry files.
Set @babel/preset-env to useBuiltIns: 'usage' with corejs: { version: 3, proposals: false }.
Pin core-js@3 in package.json; do not mix core-js 2 and core-js 3 in the same bundle.
Run npm ls core-js to check whether any dependency imports core-js/stable transitively. If one does, globals are polluted regardless of your application's Babel config.

Verification
In a clean Node process, record a native method such as Array.prototype.flat, import core-js/stable, and confirm the method changed. Then start a fresh process without the import to confirm the change does not carry over. For a bundle, load it in an isolated realm or iframe after snapshotting built-ins; any new or replaced built-ins after loading indicate global pollution.
Missing diagnostic detail
Are you importing core-js/stable directly, or is it arriving transitively through a dependency? This determines whether fixing your own Babel configuration is sufficient or whether you must also address a dependency.

core-js/stable global polyfills mutate native built-ins after import

1 answer

Direct answer

Likely explanation versus confirmed behavior

Recommended core-js and Babel combination

Assumption and uncertainty

Steps for this case

Verification

Missing diagnostic detail

Your perspective belongs here.

0 question comments