@babel/preset-env: useBuiltIns 'usage' or 'entry' for bundle size

Direct answer

Keep useBuiltIns: "usage" for a single-entry application that has no core-js entry import. It usually produces the smaller polyfill set because Babel scans each compiled file and injects imports only for APIs the code actually references. Adding import "core-js/stable" solely to switch to "entry" is not recommended: it pulls in the full stable polyfill set, can enlarge the bundle, and defeats per-file injection.

Confirmed behavior

• "usage" scans every file Babel transforms and emits core-js imports only for referenced APIs.
• "entry" rewrites an explicit core-js import into target-specific polyfills based on browserslist.
• Set corejs: 3 to match the installed core-js major line; mismatched versions commonly cause missing or duplicated polyfills.

Trade-offs

Mode	Build time	Bundle size	Best for
"usage"	Slower; every file is inspected	Usually smaller for scanned application code	Single-entry apps without a core-js entry file
"entry"	Faster; one import is rewritten	Can include unused polyfills with broad targets	Apps with an existing core-js entry or unscanned runtime code

Steps for this case

1. Set useBuiltIns: "usage" and corejs: 3 in @babel/preset-env.
2. Do not add import "core-js/stable" unless a diagnostic shows unscanned code needs built-ins.
3. Keep browserslist targets as narrow as ship requirements allow; broad targets increase output in both modes.

Verification

1. Build with "usage", no core-js/stable import, and your real browserslist; inspect which core-js modules enter the bundle.
2. Optionally build a comparison with "entry" plus a temporary explicit import and compare bundle size and build time on identical targets.
3. Confirm the bundler dedupes identical core-js modules across files and chunks before treating per-file imports as duplication.
4. Smoke-test the specific built-ins your app uses in the oldest targeted browser instead of assuming the polyfill set is complete.

Missing diagnostic

Do untranspiled dependencies or non-Babel runtime code rely on built-ins that Babel never scans? If yes, "usage" alone can miss them and an explicit entry import may be justified. If no, keep "usage".

Assumptions: @babel/preset-env 7.x with core-js 3. Bundle-size claims are typical behavior, not guaranteed measurements; verify against your actual bundle.