Avoiding Global Pollution: When to Use core-js-pure for Library Development

The Global Prototype Conflict

When you use a standard polyfill, you are typically modifying the global environment. For example, adding Array.prototype.flat to a browser that doesn't support it is helpful for an application, but it is dangerous for a library. If your library modifies a global prototype and the end-user's application also modifies it—or relies on a different version of that polyfill—you create a collision that is notoriously difficult to debug.

The core problem is global pollution: the act of altering built-in objects (like Object, Array, or Promise) in a way that affects every other script running on the page. For library authors, the goal is to use modern JavaScript features without forcing those changes on the consumer of the library.

The Solution: core-js-pure

core-js-pure is a version of the core-js library that provides the same polyfills but without modifying the global prototype chain. Instead of adding a method to Array.prototype, it provides a standalone function that you call with the target object as the first argument.

This approach ensures that your library remains isolated. You get the stability of the ECMAScript specification without risking the stability of the environment where your code is deployed.

Comparing the Implementation

To understand the difference, consider how you would implement a feature like Array.prototype.includes in a legacy environment.

Approach	Implementation	Impact
Standard core-js	import 'core-js/features/array/includes';	Modifies Array.prototype globally.
core-js-pure	import includes from 'core-js-pure/features/array/includes';	Provides a local function; global Array remains untouched.

Worked Example: Non-Polluting Polyfills

Assume you are building a utility library that needs to use Object.entries, but you must support environments where this is not natively available. You should avoid import 'core-js/stable' because that would pollute the global Object for your users.

Installation:
Run this in your project root via npm or yarn:
npm install core-js-pure

Implementation:
In your source file, import the specific feature as a function rather than a side-effect:

import entries from 'core-js-pure/features/object/entries';

export function summarizeObject(obj) {
  // Instead of Object.entries(obj),
  // use the imported pure function
  const entriesList = entries(obj);
  
  return entriesList.map(([key, value]) => `${key}: ${value}`).join(', ');
}

Verification:
To verify this is working without pollution, run the following check in a legacy browser or a simulated environment:

// Before calling your library function
console.log(Object.entries); // Should be undefined if native support is missing

summarizeObject({ a: 1 });

// After calling your library function
console.log(Object.entries); // Should STILL be undefined
Trade-offs and Limitations
While core-js-pure solves the pollution problem, it introduces a developer overhead: you can no longer use the native syntax (e.g., [].flat()) and must instead use the imported function (e.g., flat([])). This makes the code less idiomatic and slightly more verbose.
Additionally, if you are using babel-preset-env with useBuiltIns: 'usage', Babel typically defaults to the global-polluting version of core-js. To use the pure version automatically, you must configure Babel to use corejs: { version: "3", proposals: true } and potentially use a plugin like babel-plugin-transform-runtime with the corejs option enabled. This tells Babel to replace global references with imports from core-js-pure.
Closing Action
If you are building a standalone application, the standard core-js is appropriate. However, if you are publishing a package to npm, switch to core-js-pure. Audit your package.json and bundled output to ensure no prototype modifications are leaking into the global scope, ensuring your library is a good citizen in any environment.