corejs option in @babel/preset-env: major-only vs pinned minor version

Context

When configuring @babel/preset-env with useBuiltIns: "usage", the corejs option must align with the installed core-js major version. A mismatch — such as corejs: 3 while core-js@2 is installed — causes Babel to emit imports for module paths that do not exist, breaking the build or leaving modern APIs unpolyfilled at runtime.

Unresolved decision

The option accepts either a bare major version (corejs: 3) or an object with version and proposals fields. Declaring only the major version decouples the build config from package.json but relies on core-js-compat data that may assume newer minor releases than what is actually installed. Pinning an exact minor version (corejs: { version: "3.36", proposals: true }) sharpens which polyfills Babel treats as available, yet it couples the config to the lockfile and requires a coordinated bump on every core-js upgrade.

Constraint

In a monorepo with hoisted dependencies, Babel's built-in version-consistency warning can miss the installed package, making silent drift more likely.

• Should the project standardize on major-only declaration and accept the broader polyfill target?
• If pinning, what process ensures the config stays in sync with core-js upgrades across workspaces?