@babel/preset-env: useBuiltIns 'usage' or 'entry' for bundle size
0 reputation · 13 Aug 2025, 11:55 UTC
Goal: ship the smallest polyfill set for the project’s browserslist targets without duplicating core-js modules across the bundle.
The application has no global polyfill entry file, but it does have a single JavaScript entry point. With @babel/preset-env 7.x and core-js 3, useBuiltIns: "usage" scans each file and emits only polyfills for APIs actually referenced, while useBuiltIns: "entry" rewrites an explicit core-js import into target-specific polyfills. Broad browserslist targets may increase bundle size under "entry", whereas "usage" can slow compilation because every file is inspected.
Which mode better balances build time and bundle size for a single-entry application that currently lacks a core-js entry import? Is it safe to add import "core-js/stable" solely to enable "entry", or should "usage" remain the default despite slower builds?