Why having to manually specify the core-js version using useBuiltIns=usage in preset-env?

[tavoyne]

This is the error I get when using @babel/preset-env with "useBuiltIns": "usage" without setting the corejs option:

WARNING (@babel/preset-env): We noticed you're using the 'useBuiltIns' option without declaring a core-js version. Currently, we assume version 2.x when no version is passed. Since this default version will likely change in future versions of Babel, we recommend explicitly setting the core-js version you are using via the 'corejs' option.

You should also be sure that the version you pass to the 'corejs' option matches the version specified in your package.json's 'dependencies' section.

I don't understand why we have to manually specify the core-js version. Can't babel figure it out by itself by checking what's in the package.json file ?

Otherwise, every time we'd upgrade core-js we'd have to remember to update its associated version number inside babel.config.js. This is way too easy to forgot.

[romainmenke]

I came here to ask the exact same thing.
Looking through past issues and the source code I couldn't figure out why this mechanic exists.

I did find that I can do this : corejs: '3.9999999.9999999'

It is incredibly hacky but I don't see the point of having to manually increase a string literal every few days.

[JLHwung]

corejs: '3.9999999.9999999'

Although this approach mutes Babel's warning. It may generate output that will throw a runtime error.

Let's say core-js 3.999 supports ES 2086 feature Array#flatFilterMap and one has authored

class Foo {
  flatFilterMap() { ... }
}
const foo = new Foo;
foo.flatFilterMap()

Now when one upgrade preset-env which supports core-js 3.999. With corejs: '3.9999999.9999999', Babel will generate:

require("core-js/array/flatFilterMap");
// The above will throw on core-js 3.998 because it is not supported
class Foo {
  flatFilterMap() { ... }
}
const foo = new Foo;
foo.flatFilterMap()

If you know for sure where the bundled core-js is, you can always provide Babel the corejs version from corejs's package.json:

["preset-env", { corejs: require("path/to/your/core-js/package.json").version }]

[romainmenke]

This might be controversial but I highly prefer this behaviour and how it fails.
Receiving a runtime exception for require("core-js/array/flatFilterMap"); would be caught quickly (minutes) and would be easy to reproduce and resolve.

The inverse is much more difficult to figure out.
I've been wondering for months why [].at(...) wasn't working in older browsers.
It is unintuitive that updating core-js itself doesn't have any effect on the available features.

Is there any way to just have a current or installed flag?

[Salmandabbakuti]

so, in order to use the newest corejs@3, we need to specify it in project dependencies, isn't it? why not babel simply do that for us based on package.json?

[JLHwung]

why not babel simply do that for us based on package.json?

Because we can not assume users are eventually bundling with the core-js in node modules. If you are a library author and core-js@3 is one of dependencies, then the corejs version here should be the earliest version of what you specified in package.json (.e.g 3.20 for "core-js": "^3.20"), not the actual version in your node_modules, which could be any version higher than 3.20.

See also https://github.com/babel/babel-polyfills/tree/main/packages/babel-plugin-polyfill-corejs3#version.

[chkpnt]

For those using renovate to manage your dependencies, this might help, if you configure babel within your package.json: renovatebot/renovate#20703 (reply in thread)