core-js v3 pure imports and webpack module cache interoperability

Direct Answers

Does core-js/pure reduce stale polyfill risk? Yes. Granular imports give webpack separate cache entries per feature, so a change to one polyfill invalidates only that entry.

Is there documented guidance for cache invalidation when individual polyfill files change? No. The core-js README and CHANGELOG describe entry points but do not specify bundler‑level cache expectations.

What is the status of the version‑hash proposal? It remains an open issue in the core-js repository; no implementation has been merged as of the last known state.

Why Pure Imports Reduce Stale‑Cache Surface Area (Likely Explanation)

Webpack 5’s persistent cache stores each module by the hash of its resolved file. With the default import 'core-js' the entry point is a single file that re‑exports all polyfills; its content hash changes only when the entry file itself is edited, not when an internal polyfill is patched. Consequently the cached module may be reused even though the underlying implementation changed, presenting a risk of stale code.

With core-js/pure each import such as import 'core-js/pure/array/flat-map' resolves to a distinct polyfill file. The cache key is the hash of that file, so a change to the file updates the hash and webpack invalidates only that module. Other polyfills stay cached, limiting the stale‑code surface to the changed feature.

Confirmed Facts

• core-js declares sideEffects: false in its package.json, enabling tree‑shaking of pure imports.
• Webpack 5’s filesystem cache invalidates a module when the resolved file’s content changes (documented behavior).
• No official core-js documentation addresses webpack persistent cache or version‑hash injection.

Practical Verification Steps

1. Set up a minimal webpack 5 project with cache: { type: 'filesystem' }.
2. Entry file: import 'core-js/pure/array/flat-map';.
3. Run npx webpack --mode=production and note the emitted modules.
4. Modify the polyfill source (e.g., edit node_modules/core-js-pure/array/flat-map.js) to simulate a change.
5. Rebuild and verify that only the flat‑map module is recompiled.
6. Repeat the steps with import 'core-js'; as the entry and observe whether the whole core-js module is reused from cache despite the internal change.

One Diagnostic Detail That May Change the Recommendation

Are you using a custom cache.key function or cache.buildDependencies that includes lockfiles (package-lock.json or yarn.lock)? If yes, a lockfile change on a core-js upgrade may already invalidate the cache, reducing the practical difference between entry styles. If no, the pure‑import granularity remains the primary defense against stale polyfills.