Limits of core-js Promise polyfill when global and pure builds coexist

Direct answer

Global and pure core-js Promise builds can coexist in the same realm, but only if exactly one global core-js Promise polyfill version is present. core-js does not offer a mechanism to scope the global globalThis.Promise injection to an individual bundle. The global polyfill defers to a conformant native Promise; it does not replace it unconditionally. There is no separate compatibility matrix beyond the core-js README’s ES2015 Promise targeting notes.

Confirmed behavior vs. likely explanation

The following points are established for core-js v3:

• A global import such as import 'core-js/es/promise' assigns globalThis.Promise only when the existing global is missing or fails a basic conformance check: typeof Promise === 'function' && Promise.resolve && Promise.prototype.then.
• A pure import such as import { Promise } from 'core-js/pure/es/promise' never modifies globalThis.Promise. It returns the same constructor that the global polyfill installed, or the native Promise if the polyfill skipped installation.
• If two different core-js versions both include the global polyfill, the later load overwrites globalThis.Promise. That swap can change microtask timing for code that captured the earlier constructor.
• In engines where a native Promise exists but is non-conforming (for example, early Android 4.4 WebView), core-js replaces it. Both global and pure imports then observe the replaced implementation, so microtask order follows the polyfill rather than the original native engine.
• core-js provides no built-in way to isolate the global injection per bundle. Isolation requires either avoiding the global import entirely or executing code in a separate realm (iframe or worker).

The likely source of a silent overwrite is therefore duplicate global polyfills in the bundle graph, not the mere presence of a pure import alongside a global one. If your bundler resolves both entry points to a single core-js version, the pure widget shares the same Promise implementation as the global entry.

Steps for this case

1. Audit the final bundle to confirm that only one core-js version contributes the global Promise polyfill.
2. Keep the global import in the legacy entry point only; let the widget consume the pure import.
3. If multiple core-js versions are unavoidable, isolate one version in an iframe or worker rather than attempting same-realm coexistence.

Verification commands

Run these in the browser console after the bundle loads:

// 1. Check whether the global Promise is the core-js polyfill
globalThis.Promise.toString().includes('core-js');

// 2. Compare a pure import to the global constructor
import { Promise as PurePromise } from 'core-js/pure/es/promise';
PurePromise === globalThis.Promise;

If the second check returns true, both paths reference the same implementation. If it returns false, a second global polyfill or a realm boundary is involved.

One diagnostic that changes the recommendation

Do both entry points resolve to the same core-js version in the final bundle? If they do, deduplication is sufficient. If they do not, same-realm coexistence is unsupported and you should isolate the versions in separate realms.