Minimizing bundle size versus guaranteeing compatibility with useBuiltIns modes

A project using @babel/preset-env must decide between useBuiltIns: 'usage' and useBuiltIns: 'entry' to control polyfill inclusion for browsers listed in the target configuration. The goal is to limit JavaScript payload while ensuring that runtime features required by the application's user-facing components are available across supported environments.

The 'usage mode leverages tree-shaking to polyfill only features imported in the entry module, which typically reduces bundle size for modular codebases. The 'entry mode polyfills all features referenced anywhere in the project, providing broader compatibility at the cost of increased file size. Since the default mode shifted from 'entry' to 'usage' in @babel/preset-env v7.15 and may change in subsequent releases, predictable outcomes depend on explicit configuration and alignment with the installed core-js version.

How does useBuiltIns: 'usage' handle conditional or dynamic imports that are not statically analyzable at build time? What is the measurable bundle-size difference between the two modes in a monorepo with shared utility packages? Can developers reliably verify polyfill coverage without additional tooling?