Minimizing bundle size versus guaranteeing compatibility with useBuiltIns modes

Direct answer to the three questions

How useBuiltIns: 'usage' treats conditional/dynamic imports: Babel’s usage mode scans each file it transpiles and injects core-js imports for the built‑ins that are statically referenced in that file. It does not analyse the module graph, so a dynamic import() or a conditional require that cannot be resolved at build time is treated as a separate file (or chunk) when the bundler later splits it. Each resulting chunk receives its own polyfill imports based on the static usages inside that chunk. Consequently, features accessed only through a runtime‑dynamic property (e.g., global['Promise']) or via a string name are not seen by usage and will not be polyfilled.

Measurable bundle‑size difference between the two modes in a monorepo with shared utility packages: In practice, usage usually yields a smaller initial payload because only the polyfills actually used in each transpiled file are imported. However, if the bundler does not deduplicate identical core-js imports across chunks, the same polyfill may appear multiple times, potentially offsetting the size gain. entry mode replaces a manual core-js import in the entry file with the full set of polyfills required by the target browsers, producing a single upfront import that is larger than the sum of the individually needed polyfills but avoids duplication. The exact delta depends on:

• the list of target browsers (older targets → more polyfills),
• how much of the shared utility code is actually used across entry points,
• whether the bundler (Webpack, Rollup, etc.) is configured to deduplicate identical modules.

Reliable verification of polyfill coverage without extra tooling: Developers can get a reasonable confidence level by:

1. Enabling Babel’s debug output (debug: true) to see which core-js modules are being injected and why.
2. Inspecting the emitted bundles for the presence or absence of specific core-js imports (e.g., core-js/modules/es.promise.js).
3. Running the application’s smoke tests in the oldest supported browser (or a service like BrowserStack) and checking for runtime errors such as "Promise is undefined" or "Symbol is not a function".

These steps do not require a dedicated bundle‑analysis plugin, but they are manual and may miss subtle gaps in code that is only executed in rare code paths.

When the recommendation changes

The advice above assumes that your bundler can deduplicate identical core-js imports across chunks. If you are unsure whether deduplication is active, the size advantage of usage may disappear or even reverse. Therefore, please confirm:

Does your bundler configuration include a mechanism to deduplicate duplicate modules (e.g., Webpack’s splitChunks with cacheGroups or Rollup’s dedupe plugin)?

If deduplication is not enabled, you may prefer entry mode to avoid polyfill duplication, especially in a large monorepo with many shared utility packages.

Assumptions and version notes

The explanation assumes:

• Babel 7.15+ (the version where the default useBuiltIns behavior was clarified, though no default shift occurred).
• Explicitly set corejs: 3 (or another version) in @babel/preset-env options.
• That node_modules are not transpiled unless you have overridden the ignore rule.

If any of these assumptions differ in your setup, the behavior may vary and should be re‑evaluated.