@babel/preset-env: useBuiltIns usage vs entry for serverless polyfill size

Answer to the exact question

• Can usage reliably detect polyfills needed only by dynamic imports or runtime feature checks? No. usage only scans the static AST of each file it compiles. Polyfills that are required by code that is loaded dynamically (e.g., via import() or require() at runtime) or by feature‑detection logic that runs after the file is parsed will not be injected, leading to ReferenceError at runtime.
• Is the payload reduction from usage worth the missing‑polyfill risk compared with entry for an infrequently invoked function? For a low‑traffic serverless function, the extra cold‑start latency introduced by entry (which bundles all polyfills for the configured browserslist) is usually negligible. The safety net of having every required polyfill reduces the risk of runtime failures, especially when the code base changes or new dynamic imports are added.
• Should corejs be pinned to a major version to prevent silent polyfill changes after dependency updates? Yes. Pinning the major version (e.g., "core-js": "^3.30.0") guarantees that the set of polyfills shipped with entry remains stable. Minor upgrades can add or drop polyfills, which may break the function if the code paths that use them are exercised.

Why entry is the safer choice for serverless

Serverless functions are often invoked infrequently, so the cold‑start cost of loading a slightly larger bundle is typically outweighed by the assurance that all target‑environment features are available. usage can produce a smaller payload, but it requires exhaustive static analysis and continuous audit of every change that might introduce a new dynamic import or feature check.

Recommended configuration

/* .babelrc or babel.config.js */
module.exports = {
  presets: [
    [
      "@babel/preset-env",
      {
        targets: {
          node: "14.17.0" // or your runtime
        },
        useBuiltIns: "entry",
        corejs: { version: 3, proposals: true }
      }
    ]
  ]
};

Then add the core‑js entry import at the top of your main file:

import 'core-js/actual'; // or 'core-js/stable' for older polyfills

Pinning core-js

In package.json:

"dependencies": {
  "core-js": "^3.30.0"
}

Run npm install and npm audit to ensure no unexpected changes creep in after future dependency updates.

Verification steps

1. Inspect generated bundle: Run npx babel src/index.js --out-file dist/index.js --config-file .babelrc and search for import 'core-js/ lines to confirm all expected polyfills are present.
2. Test all code paths: Deploy the function to a staging environment and execute a full test suite that covers dynamic imports, feature checks, and edge cases.
3. Monitor cold‑start latency: Measure the function’s start‑up time before and after the change to confirm that the increased payload does not exceed acceptable thresholds.

Missing diagnostic detail

To fine‑tune the decision, could you confirm whether the function uses any dynamic import() statements, require() calls, or runtime feature detection that might rely on polyfills not statically referenced in the source?