Will core-js supports `exports` ESM field?

[JLHwung]

Node.js ESM introduces an "exports" field to instruct whether submodule imports like

import "core-js/modules/es6.array.copy-within"

is allowed.

@babel/preset-env generate imports of core-js as import "core-js/modules/es6.array.copy-within". However core-js package does not specify exports in its package.json. Thus it throws on Node.js and Webpack 5: https://github.com/babel/babel/issues/12378

For such imports to work, core-js can specify exports like

{
  "exports" : {
    "./modules/es6.array.copy-within" : "./modules/es6.array.copy-within.js"
  }
}

similar to what Babel did for @babel/runtime-corejs3: https://unpkg.com/@babel/[email protected]/package.json

In https://github.com/babel/babel/pull/10862 Babel tries to workaround this issue by adding .js to such imports

import "core-js/modules/es6.array.copy-within.js"

However it will break if core-js later adds exports but do not support exporting ./, or core-js decides to ship the .mjs version. I feel it is better to coordinate here.

[zloirock]

I'm thinking about adding it to core-js@4.

[zloirock]

After adding all core-js entries to this field, CI randomly dies (2 / 3 chance) on MacOS https://github.com/zloirock/core-js/actions/runs/432880677 - seems 3k+ entries in this field is too much -/ (sure, we can use patterns and don't specify entries with file extensions - it will reduce the number of lines 3x, but it was planned to increase the number of entries 6x in the next version of core-js for allowing maximal optimization).

[zloirock]

Removing some unnecessary entries allowed to reduce the number of patterns to a reasonable number.