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/runtime[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.
I'm thinking about adding it to core-js@4.
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).
Most helpful comment
I'm thinking about adding it to
core-js@4.