Invalid Import Path for core-js Imports When Using type: module

[trisys3]

Bug Report

• I would like to work on a fix!

Current behavior
A clear and concise description of the behavior.

• REPL, Codesandbox, or GitHub Repo helps!

When I use @babel/preset-env with the useBuiltIns option, the core-js imports still output without the .js. This is usually fine, except when running in a node environment that supports built-in modules, e.g. with type: module in the package.json or outputting to a file with the .mjs extension.

This happens even if I use --out-file-extension .mjs.

--out-file-extension .cjs works, if you don't use modules: false, but then you're not outputting modules.

Input Code

test.js

const greeting = new Set(['Hello', 'world!']);
console.log(Array.from(greeting).join(' '));

npx babel test.js -d test/
node test/test.js

Output:

internal/process/esm_loader.js:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '<repo>/node_modules/core-js/modules/esnext.set.add-all' imported from <repo>/test/test.js
Did you mean to import core-js/modules/esnext.set.add-all.js?
    at finalizeResolution (internal/modules/esm/resolve.js:275:11)
    at packageResolve (internal/modules/esm/resolve.js:668:12)
    at moduleResolve (internal/modules/esm/resolve.js:716:14)
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:809:11)
    at Loader.resolve (internal/modules/esm/loader.js:85:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:229:28)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:51:40)
    at link (internal/modules/esm/module_job.js:50:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Expected behavior
A clear and concise description of what you expected to happen (or code).

No errors

Babel Configuration (babel.config.js, .babelrc, package.json#babel, cli command, .eslintrc)

• Filename: babel.config.js

const presets = [['@babel/preset-env', {
  targets: {node: true},
  modules: false,
  useBuiltIns: 'usage',
  corejs: {version: 3, proposals: true},
}]];

export default {presets};

Environment

System:
  OS: android
Binaries:
  Node: 14.8.0 - /data/data/com.termux/files/usr/bin/node
  npm: 6.14.7 - /data/data/com.termux/files/usr/bin/npm
npmPackages:
  @babel/cli: ^7.10.5 => 7.10.5
  @babel/core: ^7.11.4 => 7.11.4
  @babel/preset-env: ^7.11.0 => 7.11.0

Possible Solution

One possible solution would be to always output with the extension. This would create longer output, but it would be future-proof and wouldn't require the user to do anything.

The best solution would probably be to guess whether the extension is needed, based on whether the package.json has type: module, and have a configuration option like addExtension or addCorejsExtension to force it one way or the other.

The last option I can think of is to always output .cjs, or add a configuration like changeExtension. .mjs would output to a .mjs file AND add the corejs path extensions. .cjs would output to .cjs and wouldn't add the extensions. .js, the default, would output to .js and possibly guess or use the addCorejsExtension option. I notice there is a --out-file-extension option for @babel/cli: having this keep the corejs extensions when you use .mjs would be fine, too.

Additional context
Add any other context about the problem here. Or a screenshot if applicable

[babel-bot]

Hey @trisys3! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite."

[nicolo-ribaudo]

As a workaround, it should already work when using the new babel-plugin-polyfill-corejs3 from https://github.com/babel/babel-polyfills

[JLHwung]

Duplicate of #10548

We had fixed it before but reverted later due to compatibility issues for systemjs. This issue should be fixed by #10853.

[trisys3]

Sorry, to be honest I wasn't even sure what to search for, though I did try. Also, even if I did, that issue has been closed for a long time.

Do you have an idea of when this will be (re-)implemented?

[chaffeqa]

@nicolo-ribaudo to your point, we are waiting on this fix to and its stopping us from moving to webpack 5 + esmodule modern build... would using babel-plugin-polyfill-corejs3 fix this issue?

I'm trying it currently but the documentation of how to switch to it is a bit difficult, so i was hoping to know if im wasting my time, since it seems i may run into the same issue (since by my understanding, we would still be using @babel/transform-runtime and it will still error on importing)

[chaffeqa]

argh yeah i switched from:

@babel/preset-react + @babel/plugin-transform-runtime

to:

@babel/preset-react + polyfill-corejs3

and am still getting:

ERROR in ./node_modules/@babel/runtime/helpers/esm/toConsumableArray.js 3:0-70
Module not found: Error: Can't resolve './unsupportedIterableToArray' in '.../node_modules/@babel/runtime/helpers/esm'

is there another workaround to this issue while waiting for #10853 ?

[jedwards1211]

@nicolo-ribaudo since @babel/runtime/helpers/esm/package.json contains type: "module", shouldn't all import statements within that folder contain the full extension? The extension is required in ES Modules.

For example I'm getting this error with webpack 5:

ERROR in ./node_modules/@babel/runtime/helpers/esm/get.js 1:0-44
Module not found: Error: Can't resolve './superPropBase' in '/Users/andy/clarity/node_modules/@babel/runtime/helpers/esm'
Did you mean 'superPropBase.js'?
BREAKING CHANGE: The request './superPropBase' failed to resolve only because it was resolved as fully specified
(probably because the origin is a '*.mjs' file or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

This is because the first line of get.js is an import without an extension:

import superPropBase from "./superPropBase";

[jedwards1211]

I guess I should file a new issue for what I described above

[JLHwung]

@jedwards1211 You don't need file one. It will be fixed by #10853.

[jedwards1211]

Ah okay, OP seemed like it was only about import statements injected by @babel/plugin-transform-runtime, not the files within @babel/runtime.