Preset‑Env Target Limits for Low‑Traffic Workloads

Goal

For a low‑traffic application, the primary objective is to shrink the JavaScript bundle and speed up the build by eliminating polyfills and syntax transformations that are unnecessary for the browsers actually used.

Constraints & Uncertainty

• The targets option in @babel/preset‑env is evaluated at compile time; any change requires a full rebuild.
• Choosing a too‑narrow target set may break functionality in edge browsers that are still in use by a small subset of users.
• Using useBuiltIns: "usage" increases build time because Babel must statically analyze the entire codebase to determine which core‑js polyfills to inject.

Unresolved Questions

1. What combination of targets (e.g., Chrome 90+, Safari 14+) and useBuiltIns setting yields the optimal trade‑off between bundle size and build duration for a typical low‑traffic workload?
2. How does the choice of corejs: 3 versus corejs: 2 affect polyfill size and compatibility when targeting only the latest major browsers?
3. Can ignoreBrowserslistConfig be leveraged to override a project‑wide .browserslistrc without introducing conflicts in a monorepo that shares Babel configurations?