Mixing core-js global polyfills and core-js-pure in one dependency graph: which mode should a shared library depend on

Recommendation

For a shared library intended for distribution, declare core-js-pure as the dependency mode. This avoids adding polyfill code to the consumer's global namespace and lets each consumer decide which polyfills to apply (e.g., via useBuiltIns: 'usage' and corejs: 3 in Babel).

Interoperability boundary

Both core-js (global build) and core-js-pure provide the same polyfill implementations and patch the same built-in prototypes (Array.prototype, String.prototype, etc.). If an application has already patched Array.prototype through the global core-js build, a library that imports core-js-pure will apply the same patch again; the operation is idempotent and results in identical prototype state. The two modes do not operate on separate wrapped implementations.

Importing both modes in one bundle

• Importing core-js and core-js-pure in the same bundle can duplicate module code if the bundler does not dedupe shared dependencies.
• Core-js internal guards prevent double-patching of prototypes, so the prototype consistency is maintained regardless of import order.
• To avoid unnecessary bundle size, verify that your bundler (Webpack, Rollup, Vite, etc.) removes duplicate core-js modules. A production build with proper dedup will show a single copy of the polyfill code.

Published-library trade-off

Choosing core-js-pure for a published library eliminates the risk of unexpectedly modifying the consumer's globals. The cost is a modest increase in the library's own bundle size, because the polyfill implementations are included directly rather than pulled from the host environment. This trade-off is generally favorable for library authors who want predictable, isolated behavior.

To refine the dedup guidance for your specific setup, which bundler and configuration are you using? This helps determine whether automatic module deduplication is active.