Global core-js versus core-js-pure for a distributable component library

Global core-js versus core-js-pure for a distributable component library

A distributable component library must support IE11 alongside modern browsers. Assuming a recent core-js major version, the unresolved decision is whether to rely on global core-js polyfills at the application entry point or to import core-js-pure within each module. Global polyfills ensure that third-party dependencies expecting standard prototype methods function correctly, but they mutate the host environment and risk collisions if consumers already load a different core-js version. Pure imports avoid prototype pollution, yet they must be repeated in every module and may increase bundle size when granular features are imported individually.

The uncertainty increases because the library is consumed by multiple applications, some of which already include global polyfills and others that do not. Mixing both strategies in the same project can produce inconsistent behavior and duplicate code. A strategy is needed that supports IE11 without forcing host applications to alter their build configuration or inspect generated bundles to reconcile differences.

Should the library declare core-js as a peer dependency and document global setup, or should it self-contain core-js-pure imports? Is there a documented pattern for detecting existing global polyfills before applying pure ones? What bundle-size trade-offs arise when granular pure imports are used across many modules?