Global Build vs. Ponyfill: Choosing core-js for Libraries

When integrating core-js into a reusable library, the goal is to provide modern JavaScript features without altering the consumer’s runtime. The library must avoid polluting global prototypes while still offering a stable API for downstream projects. The main uncertainty lies in selecting between the global build (core-js) that patches built‑ins and the ponyfill build (core-js-pure) that exports features as plain modules.

Constraints include:

• Ensuring that the library’s polyfills do not conflict with other polyfills that a consumer might already load.
• Verifying that the chosen build supports granular imports for tree‑shaking.
• Maintaining consistency across major core-js releases.

Unresolved questions:

1. What documented side‑effects arise when multiple core-js global builds are loaded on the same page?
2. Does core-js-pure guarantee no prototype mutation and how does that affect type compatibility?
3. How can an integration test be designed to confirm that a ponyfill import does not alter the global environment?