webpack 5.0.0-beta.30 Module not found: Error: Can't resolve '../../core-js/object/define-property'

[noe132]

Bug report

What is the current behavior?

install @babel/runtime-corejs3 for file index.js

import '@babel/runtime-corejs3/helpers/esm/defineProperty'

and run webpack ./index.js

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

beta.29 is working properly on this.

but if we manually edit line 1 in file ./node_modules/@babel/runtime-corejs3/helpers/esm/defineProperty.js from

import _Object$defineProperty from "../../core-js/object/define-property";

to

import _Object$defineProperty from "../../core-js/object/define-property.js";

and this issue goes away.

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?

Other relevant information: webpack version: 5.0.0-beta.30 Node.js version: 12.16.1 Operating System: win10 2004 Additional tools: at the time I'm using @babel/runtime-corejs3@^7.11.2

[EvHaus]

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.

[duan602728596]

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.

[sokra]

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.

[ocdi]

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

[duan602728596]

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

[sokra]

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.

[alexander-akait]

@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

[alexander-akait]

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

[vankop]

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

[alexander-akait]

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

[JamesAlen9352]

[otakustay]

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.

[sokra]

It's not forbidden. The import request need to be fully specified as './iterableToArray.js'.

[wojtekmaj]

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

[nickbouton]

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.

[alexander-akait]

There is no problems on webpack side

[EvHaus]

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?

[alexander-akait]

@EvHaus Can you create reproducible test repo?

[alexander-akait]

/cc @vankop

[EvHaus]

Logged as a new issue with reproducible test repo here: https://github.com/webpack/webpack/issues/11518 I think it's unrelated to this issue actually.

[X-neuron]

I'm having the similar problem:

webpack version: 5.0.0-rc.0 node version:14.11.0

.babelrc.js

"plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "absoluteRuntime": false,
        "corejs": 3,
        "helpers": true,
        "regenerator": true,
        "useESModules": true
      }
    ],
  ]

ERROR in ./node_modules/@babel/runtime-corejs3/helpers/esm/jsx.js 1:0-51
Module not found: Error: Can't resolve '../../core-js/symbol/for' in 'E:\project\antdFront2\node_modules\@babel\runtime-corejs3\helpers\esm'
Did you mean 'for.js'?
BREAKING CHANGE: The request '../../core-js/symbol/for' 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.

[mkermani144]

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

[SokichiFujita]

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.

[alexander-akait]

@SokichiFujita it means you have other broken packages please provide screenshots or the error message

[SokichiFujita]

@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 

[alexander-akait]

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

[SokichiFujita]

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

[gtwilliams03]

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

[ScriptedAlchemy]

@sokra it might be worth pinning this issue. I’m getting a lot of traffic around mjs resolution, everyone needs the same thing

[alexander-akait]

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

[doberkofler]

This problem was resolved by using this role but only after upgrading to webpack 5.1.0

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

[bertho-zero]

@SokichiFujita You may have added fullySpecified in the wrong place, I made this error, it is not the general resolve but that of a rule:

    module: {
      rules: [
        {
          test: /\.(js|mjs|jsx)$/,
          enforce: 'pre',
          loader: require.resolve('source-map-loader'),
          resolve: {
            fullySpecified: false
          }
        },
        // ...
      ]
    }

[joebnb]

similar configuration still not working with webpack 5.1.0

{
test: /\.(mj|j|t)sx?$/,
resolve: {
    fullySpecified: false
  },
  type: "javascript/auto",
  exclude: /node_modules/,
  use: {
    loader: "babel-loader",
    options: {
      cwd: BABEL_PATH,
      babelrcRoots: BABEL_PATH,
      cacheDirectory: true,
      babelrc: false,
... ...
}

[ScriptedAlchemy]

You need extensions as well most likely. Or to include node modules

[doberkofler]

I really just used this role in 5.1.0 and it worked

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

[kagawagao]

similar configuration still not working with webpack 5.1.0

{
test: /\.(mj|j|t)sx?$/,
resolve: {
    fullySpecified: false
  },
  type: "javascript/auto",
  exclude: /node_modules/,
  use: {
    loader: "babel-loader",
    options: {
      cwd: BABEL_PATH,
      babelrcRoots: BABEL_PATH,
      cacheDirectory: true,
      babelrc: false,
... ...
}

make fullySpecified to works on all files, not only source files, but also node_modules, like:

{
        test: /\.m?js/,
        resolve: {
          fullySpecified: false,
        },
      },
      {
        test: /\.(j|t)sx?$/,
        include: [srcDir],
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true,
            },
          },
        ],
      }

[maurobalbi]

{
        test: /\.m?js/,
        resolve: {
          fullySpecified: false,
        },
      },
      {
        test: /\.(j|t)sx?$/,
        include: [srcDir],
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true,
            },
          },
        ],
      }

This solution fixed the problem for me. Thanks alot.

[alexander-akait]

Fixed https://babeljs.io/blog/2020/10/15/7.12.0, please leave feedback

[lucalooz]

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

[sokra]

Awesome

[doberkofler]

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

[lucalooz]

@doberkofler for me it was the combination of webpack 5 + babel 7.11 + preset-env + core-js@3 that surfaced the issue. Once they've fixed the ESM handling on babel 7.12 the issue disappeared. Unfortunately I can't think of what can it be the issue in your project.

[anajavi]

@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

[ScriptedAlchemy]

This error happens most commonly with Babel. Which is now fixed. But other packages that have not fixed this issue will require that mjs resolution or you want to contact the project author and ask them to update

[doberkofler]

What really confuses me, is the fact that I actually do not actually have any rules that would use Babel. Does this problem also arise when webpack just uses packages that have been build with Babel?

[bertho-zero]

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

[otakustay]

What really confuses me, is the fact that I actually do not actually have any rules that would use Babel.

Some third party packages may contain code compiled via babel, and those file can have an import statement to @babel/runtime

[bertho-zero]

This is what I describe just above, these dependencies are normally defined with a ^ and the lockfile (yarn.lock or package-lock.json) blocks them, you have to remove the entry from the lockfile and then restart an installation to update them.

[alexander-akait]

If somebody needs help please provide error message

[SokichiFujita]

@bertho-zero Thank you. Regarding previous babel 7.11.6 and webpack v5.0.0, I also had been tried the following configuration. But it was failed.

  module: {
    rules: [
      {
        test: /.(js|jsx|mjs)$/,
        exclude: [path.resolve(__dirname, "node_modules")],
        loader: "babel-loader",
        resolve: {
          fullySpecified: false
        }
      },
    ],
  },