I'm having a very similar problem after upgrading from beta.29 to beta.30 but with this different import:

ERROR in ./node_modules/graphql/language/parser.mjs 1:0-41
Module not found: Error: Can't resolve '../jsutils/inspect' in '/Users/my_project/node_modules/graphql/language'
 @ ./node_modules/graphql-tag/src/index.js 1:13-47
 @ ./webapp/src/index.jsx 23:0-26 68:7-11

Clearing the local filesystem cache (rm -rf node_modules/.cache) didn't help. But rolling back to beta.29 worked for me as well.

I also encountered the same problem, which seems to be caused by enabling mjs experiments, and I did not find a way to close mjs experiments.

These are all the same issues. In .mjs files or .js files with a package.json with "type": "module" imports need to be fully specified. This means you need to have an extension.

That how ESM in node.js is defined, and you are opting in into this behavior by using the .mjs extension resp the field in the package.json.

We didn't enforce this behavior in previous versions while this was still experimental in node.js, but it left this status, so I feel ok with enforcing this and pointing out these incorrect packages.

You could disable that with { test: /\.m?js/, type: "javascript/auto" } in module.rules.

@sokra I have extremely similar symptoms, even with the above module.rules suggestion. Rolling back to beta.29 compiles successfully

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

I tried various positions of adding the rule, setting type in other potential rules involving .js/typescript that might affect it, but none solved this module not found issue.

I suspect babel need to fix their code to support this correctly, otherwise there will be many people having issues with this on webpack5.

For now I am sticking to beta.29.

After configuring like this, there will still be some modules can't resolve.

const path = require('path');

module.exports = {
  mode: 'development',
  entry: { index: path.join(__dirname, 'src/index.js') },
  devtool: 'source-map',
  module: {
    rules: [
      { test: /\.m?js/, type: "javascript/auto" },
      {
        test: /.*\.js$/,
        type: 'javascript/auto',
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: [
                [
                  '@babel/preset-env',
                  {
                    targets: {
                      browsers: ['IE 11']
                    },
                    debug: false,
                    modules: false,
                    useBuiltIns: 'usage',
                    bugfixes: true,
                    corejs: 3
                  }
                ]
              ],
              plugins: [
                [
                  '@babel/plugin-transform-runtime',
                  {
                    corejs: { version: 3, proposals: true },
                    helpers: true,
                    regenerator: true,
                    useESModules: true
                  }
                ]
              ]
            }
          }
        ]
      }
    ]
  }
};

import _asyncToGenerator from '@babel/runtime-corejs3/helpers/esm/asyncToGenerator.js';

function main() {
  console.log(_asyncToGenerator);
}

main();

btw this is not an webpack-only error. If you run import("@babel/runtime-corejs3/helpers/esm/defineProperty.js") in node.js you get an error too:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '...\node_modules\@babel\runtime-corejs3\core-js\object\define-property' imported from ...\node_modules\@babel\runtime-corejs3\helpers\esm\defineProperty.js

You could disable that with { test: /\.m?js/, type: "javascript/auto" } in module.rules.

Ok I tried that by myself and it doesn't work correctly. Instead you have to do that to change the resolving for these modules:

{
  test: /\.m?js/,
  resolve: {
    fullySpecified: false
  }
}

type: "javascript/auto" might be added to fully disable the different behavior for .mjs files, but that doesn't affect the resolving. It only affects e. g. how interop with non-ESM modules is handled.

@sokra maybe we can put this option to https://webpack.js.org/configuration/resolve/ (by default true), I'm afraid of too many projects use wrong paths in import, using:

{
  test: /\.m?js/,
  resolve: {
    fullySpecified: false
  }
}

with babel/ts/other loaders will increase the size an complex of configurations

Also I think we need docs this

/cc @chenxsan , can you open an issue? Maybe we should rewrite all import in docs on using extensions

@evilebottnawi

@sokra maybe we can put this option to https://webpack.js.org/configuration/resolve/ (by default true), I'm afraid of too many projects use wrong paths in import, using:

thats how Node.js resolves.. Maybe we need to point in docs workaround..

@vankop yes, I known, in theory we can improve error messages out of box, like:

ERROR in ./node_modules/@babel/runtime-corejs3/helpers/esm/defineProperty.js 1:0-74
Module not found: Error: Can't resolve '../../core-js/object/define-property' in 'xxx\node_modules\@babel\runtime-corejs3\helpers\esm'
 @ ./index.js 1:0-58

You're using ES module syntax, maybe you meant:
import '@babel/runtime-corejs3/helpers/esm/defineProperty.js'
or
import '@babel/runtime-corejs3/helpers/esm/defineProperty.mjs'

Because now you might think something wrong with resolving (not found, etc)