core-js/stable global built-in patching before application code loads

Answer

No. Importing core-js/stable before application code will mutate native built-ins for the lifetime of the process. In a long-running Node.js worker that mutation cannot be reverted without a restart, so a rolling zero-downtime migration will produce mixed workers with different built-in identities during the rollout. For a small Node.js or bundler app that needs safe rollback, core-js/pure with explicit imports is the lower-risk option.

Confirmed facts

• core-js 3.x core-js/stable is designed to polyfill and patch native globals such as Promise, Array and String at import time.
• The patches are applied once per process and remain for the process lifetime. There is no unload API.
• core-js/pure provides the same polyfill implementations as isolated modules that do not mutate globals.

Likely explanation for your constraints

Global patching is process-wide and irreversible without restart, which complicates zero-downtime rollback. During a rolling deployment some workers will have patched built-ins and some will not, leading to inconsistent feature detection and identity checks across requests.

Code that captures references before the import, or performs identity checks like constructor equality and instanceof against native prototypes, can behave differently after core-js/stable runs. Libraries loaded after the patch see patched globals; code loaded before may have captured original references.

Steps needed for this case

1. Audit current usage. Confirm core-js major version and whether core-js/stable or core-js/es* is already imported. List entry points in package.json and bundler config.
2. Staging identity check. In a staging process log built-in identity before and after import:

const before = Promise.toString();
const beforeRef = Promise;
import 'core-js/stable';
console.log(Promise === beforeRef, Promise.toString() !== before);

1. Run the test suite twice: once with core-js/stable imported first, once with core-js/pure explicit imports. Compare failures related to built-in identity or feature detection.
2. Map required ES features to core-js/pure modules and verify bundler tree-shaking removes unused polyfills. Check sideEffects configuration.
3. Canary a single worker with the new import order and monitor error rates and feature-detection logs for divergence from existing workers.

Missing diagnostic detail that changes the recommendation: the exact Node.js runtime version and whether the bundle targets Node only or browser. Node versions already include many ES features natively, so the need for global patching versus pure imports depends on the runtime feature baseline.