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.

Hey, I just wanted to chime in with something that might help folks. I just upgraded a home-grown config library to Webpack 5, bumped all my dependencies, and have been integrating this into my various projects. A JavaScript project using @material-ui exploded with these errors when I did this.

The resolve/fullySpecified fix mentioned above did nothing for me. I was stuck here for a bit, but then I found something that did work.

I’m using yarn, and there’s the “resolutions” option you can add to the package.json. @material-ui was pulling in @babel/runtime 7.11.1, and I wanted to make sure it was on the latest 7.12.5. So I added this resolution to my package.json:

"resolutions": {
    "@babel/runtime": "^7.12.5"
  },

And viola, everything is fixed now. The fullySpecified option isn’t even needed anymore. The app appears to be working fine, although more testing is definitely required.

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.

Ran into this issue with Babel 7.11.~ after updating to Webpack 5. Enumerating the error messages here so other people looking for help will find the fix here.

Can't resolve './objectWithoutPropertiesLoose'
Can't resolve './arrayWithHoles'
Can't resolve './iterableToArrayLimit'
Can't resolve './unsupportedIterableToArray'
Can't resolve './nonIterableRest'
Can't resolve './arrayWithoutHoles'
Can't resolve './iterableToArray'
Can't resolve './unsupportedIterableToArray'
Can't resolve './nonIterableSpread'

BREAKING CHANGE: The request './<module>' failed to resolve only because it was resolved as fully specified

Fix (as mentioned above):

Add the following rule to your webpack.config.js:

--snip--
 module: {
    rules: [
        {
            test: /\.m?js/,
            resolve: {
                fullySpecified: false
            }
        },
--snip--

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 believe that fullySpecified: true is a very good default option, because it encourages everyone to work towards the future of ES Modules and to stop supporting anything else that is not spec-compliant. Library authors will have incentive to fix their libs so that they work in Webpack with defaults that enforce ES Module standards. This will make the ecosystem a lot better and progress towards everything working with native ES Modules.

Imagine if fullySpecified: false was the default: we’d have a whole new generation of Webpack where people are writing code that isn’t ES Module compliant, and therefore encouraging further fragmentation between real ES Module code and ES-Module-like code.

@trusktr Try to install the latest @babel/runtime by npm i @babel/runtime -D, it works for me.

Happening to me as well. Upgrading Webpack from beta.29 to beta.30, not doing literally anything else, breaks the build:

ModuleNotFoundError: Module not found: Error: Can't resolve './assertThisInitialized' in '/node_modules/@babel/runtime/helpers/esm'
    at /node_modules/webpack/lib/Compilation.js:1470:28
    at /node_modules/webpack/lib/NormalModuleFactory.js:647:13
    at eval (eval at create (/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:10:1)
    at /node_modules/webpack/lib/NormalModuleFactory.js:233:22
    at eval (eval at create (/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:9:1)
    at /node_modules/webpack/lib/NormalModuleFactory.js:357:22
    at /node_modules/webpack/lib/NormalModuleFactory.js:116:11
    at /node_modules/webpack/lib/NormalModuleFactory.js:576:24
    at finishWithoutResolve (/node_modules/enhanced-resolve/lib/Resolver.js:284:11)
    at /node_modules/enhanced-resolve/lib/Resolver.js:350:15
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:27:1)
    at /node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:87:43
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:16:1)
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:27:1)
    at /node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:87:43
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:16:1)
    at /node_modules/enhanced-resolve/lib/ConditionalPlugin.js:39:48
    at _next0 (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:8:1)
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:30:1)
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:57:1)
    at /node_modules/enhanced-resolve/lib/ConditionalPlugin.js:52:42
    at /node_modules/enhanced-resolve/lib/Resolver.js:398:5
    at eval (eval at create (/node_modules/enhanced-resolve/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:16:1)
resolve './assertThisInitialized' in '/node_modules/@babel/runtime/helpers/esm'
  using description file: /node_modules/@babel/runtime/helpers/esm/package.json (relative path: .)
    Field 'browser' doesn't contain a valid alias configuration
    using description file: /node_modules/@babel/runtime/helpers/esm/package.json (relative path: ./assertThisInitialized)
      Field 'browser' doesn't contain a valid alias configuration
      /node_modules/@babel/runtime/helpers/esm/assertThisInitialized doesn't exist

@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)

@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.

I have what I think might be a similar problem using apollo-upload-client, which uses extract-files:

ERROR in ../../../node_modules/apollo-upload-client/public/createUploadLink.js 18:19-63
Module not found: Error: Can't resolve 'extract-files/public/extractFiles' in '/Users/ross/Projects/project/node_modules/apollo-upload-client/public'
 @ ./src/app/state/client.ts 844:0-79 931:42-58
 @ ./src/app/views/app/AppContainer.tsx 283:0-40 335:14-20
 @ ./src/app.js 556:0-56 641:9-21

The author is adamant that it’s not a problem with their library.

I have the fullySpecificed: false rule in place, but it’s not making a difference. Since the issue lies in a third party library and not our source code, do I need to modify the additional rule to specifically target that library?

I’m pretty surprised that we got this many comments in without anybody linking to https://github.com/microsoft/TypeScript/issues/16577 – I’d bet dollars to doughnuts that all the libraries that people are having trouble with were compiled from Typescript, which 1) encourages users to write extensionless relative import specifiers, then 2) does not give any way to convert those to valid (extension-included) specifiers.

(I’m also having this problem with a compiled-from-TS library…)

@evilebottnawi just upgraded to babel 7.12 and removed the fullySpecified rule. Works as intended 👍

I also encounter similar issue but the message is like:

error  in ./node_modules/@babel/runtime/helpers/esm/toConsumableArray.js

Module not found: Error: Can't resolve './iterableToArray' in '/xxx/node_modules/@babel/runtime/helpers/esm'

To what I know this is an error when @babel/runtime is importing its internal module (both inside helpers/esm folder), es module resolution of node should not forbid internal imports, it only affects how other modules import it from external.

Having tried quite a few things to debug this, I found eventually that deleting lockfile and node_modules and reinstalling resulted in a working build

I’m not having luck with the fullySpecified: false solution. When I add that to my module rules and try the latest rc.0 build I end up with this failure:

/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/Resolver.js:362
			newStack = new Set(resolveContext.stack);
			           ^

RangeError: Maximum call stack size exceeded
    at new Set (<anonymous>)
    at Resolver.doResolve (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/Resolver.js:362:15)
    at resolver.getHook.tapAsync (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/ConditionalPlugin.js:42:14)
    at Hook.eval [as callAsync] (eval at create (/myproject/client/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:37:1)
    at Resolver.doResolve (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/Resolver.js:394:16)
    at resolver.getHook.tapAsync (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/NextPlugin.js:30:14)
    at Hook.eval [as callAsync] (eval at create (/myproject/client/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:7:1)
    at Resolver.doResolve (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/Resolver.js:394:16)
    at DescriptionFileUtils.loadDescriptionFile (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFilePlugin.js:74:17)
    at forEachBail (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:118:13)

And sometimes this one:

/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:42
	(function findDescriptionFile() {
	                             ^

RangeError: Maximum call stack size exceeded
    at findDescriptionFile (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:42:31)
    at forEachBail (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:125:14)
    at iterator (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/forEachBail.js:16:12)
    at resolver.fileSystem.readJson (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:58:16)
    at CacheBackend.provide (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:174:31)
    at forEachBail (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:52:26)
    at next (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/forEachBail.js:14:3)
    at forEachBail (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/forEachBail.js:24:9)
    at findDescriptionFile (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:47:3)
    at forEachBail (/myproject/client/node_modules/webpack/node_modules/enhanced-resolve/lib/DescriptionFileUtils.js:125:14)

The same issues don’t happen on beta.29. Is anyone else seeing similar problems?

If you’re using chainWebpack, then it’s like this

chain.module.rule(“mjs-rule”).test(/.m?js/).resolve.set(fullySpecified, false);

I’m really looking forward to when the ecosystem isn’t so fragmented around native ESM. That’ll be very nice!

There is no problems on webpack side, please read the error message, problem in @lume/element package, they used ES module syntax, but don’t use .js/.mjs extensions in import, try to run this code in node or browsers without webpack, you will get the problems

@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

This worked for me - but I needed to add a dollar sign to the end of the regular expression (/\.m?js$/) or webpack 5 started failing on JSON files (it matched .json as well as .mjs and .js).

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();

babel-plugin-proposal-private-methods from babel/core@7.14.0 worked as well and doesn’t require the extra webpack rule for node_modules

{
  "env": {
    "development": {
      "plugins": [
        [
          "@babel/plugin-proposal-private-methods",
          {
            "loose": true
          }
        ]
      ]
    },
  }
}

Also needed to manually remove older versions of babel from yarn.lock

@llooz I actually do not use Babel in my build but still had the same problem. Do I need to keep the

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

rule until all my dependencies upgrade Babel?

You might need to refresh your npm/yarn lockfile.

Check that your currently installed runtime is at least 7.12.0 with npm ls @babel/runtime

I really just used this role in 5.1.0 and it worked

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

@evilebottnawi I got it. Maybe this issue https://github.com/babel/babel/issues/12058 . Babel 7.12 may solve this issue.

There is no problems on webpack side

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.

This fixed it for me

@chooban this problem not related to original problem, already reported https://github.com/webpack/enhanced-resolve/issues/256

@doberkofler yes, because it is wrong, this code will not work on node or browser, so webpack starts to use strict rules for this, it is even not webpack problem, try to use node@14 and run this code, you will get the same problem

@ScriptedAlchemy Already pinned https://github.com/webpack/webpack 😄

Yes, it is bug on Babel side, they will do release on the next week

@evilebottnawi Thanks. Does it mean webpack 5 has no problem but material-ui or babel (plugins) has problem?

Error messages:

ERROR in ./node_modules/@babel/runtime/helpers/esm/objectWithoutProperties.js 1:0-74
Module not found: Error: Can't resolve './objectWithoutPropertiesLoose' in '/Users/s/mydev/react/starter-react-flux/__test/node_modules/@babel/runtime/helpers/esm'
Did you mean 'objectWithoutPropertiesLoose.js'?
BREAKING CHANGE: The request './objectWithoutPropertiesLoose' 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.
 @ ./node_modules/@material-ui/core/esm/styles/transitions.js 1:0-90 57:16-40
 @ ./node_modules/@material-ui/core/esm/styles/index.js 9:0-30 9:0-30
 @ ./app/App.js 4:0-76 7:15-29 18:41-57
 :

same messages 

I’ve been investigating and trying workarounds. However the error still exists with stable v5.0.0. { fullySpecified: false } or another workarounds which are proposed in related issue does not work well now.

Also seeing this issue with beta 30->32 as well, 29 still works ok. All of the errors we’re getting are coming from Material UI via @babel/runtime. Adding the fullySpecified: false workaround seems to do the trick.

Can anyone solve this please… i am getting it in the browser console 😃

Uncaught TypeError: (0 , codecs_data_structures_1.getBytesCodec) is not a function at ./node_modules/@solana/spl-token-metadata/lib/cjs/state.js (state.ts:7:1) at options.factory (react refresh:6:1) at __webpack_require__ (bootstrap:22:1) at fn (hot module replacement:61:1) at ./node_modules/@solana/spl-token-metadata/lib/cjs/index.js (index.ts:4:1) at options.factory (react refresh:6:1) at __webpack_require__ (bootstrap:22:1) at fn (hot module replacement:61:1) at ./node_modules/@metaplex-foundation/mpl-token-metadata/node_modules/@solana/spl-token/lib/cjs/extensions/tokenMetadata/actions.js (actions.ts:4:1) at options.factory (react refresh:6:1)

@doberkofler please read the error message, problem in fullcalendar

https://github.com/fullcalendar/fullcalendar/blob/master/packages/core/package.json#L12, it say what it is ES modules

But https://github.com/fullcalendar/fullcalendar/blob/master/packages/core/src/main.ts#L2 :

import './vdom'
export { Calendar } from './Calendar'
export * from '@fullcalendar/common'

import './vdom' is invalid and even not work on node, it should be import './vdom.js'

reexport also invalid, they should have .js at the end of exports

@doberkofler For my part I have dependencies which use @babel/runtime-corejs2, I had to remove the entry from yarn.lock then run yarn to install the latest version.

I have the same issue as @wojtekmaj. { fullySpecified: false } doesn’t work for me. I use webpack 5 (stable release) alongside latest versions of babel packages (core-js, etc.).