TypeError: Cannot read property 'exports' of undefined function getModuleExports(moduleId) { return __webpack_require__.c[moduleId].exports; }

[liuhaidi1209]

My app encountered the following error when I tried integrating @pmmmwh/react-refresh-webpack-plugin.
"@pmmmwh/react-refresh-webpack-plugin": "0.4.2",

https://user-images.githubusercontent.com/16359954/97874554-1e6f4880-1d54-11eb-85cf-9d969db57e4b.png

[HOUCe]

Anyone could give this issue a little love plz? Got the same problem here when I upgraded Create-react-app to 4.0.0

[pmmmwh]

Hi. For me to be able to look into issues, I would need more information about the actual setup. Things like React/Webpack versions, how your app is being structured, etc. If possible a reproducible example would help with triaging a lot.

The error itself to me seems like the Webpack require.cache is not defined - so either it was not provided by Webpack to the module (because we did not declare it - I think explicit declaration for stuff like this is required in Webpack 5), or your module cache is corrupt.

Edit: if you two don't mind changing node_modules, feel free to try stub that call out to require.cache[moduleId].exports and see if it works.

[pmmmwh]

Hi, I did a bit of digging and I think if you have ANY variable named module within your project it will crash Webpack.

[scristobal]

it solved my problem and made my day, thank you @pmmmwh !!

[iMoses-Apiiro]

@pmmmwh seems that this bug is still happening, so why is this issue closed?

[pmmmwh]

@pmmmwh seems that this bug is still happening, so why is this issue closed?

Do you have a variable named module? That is working as intended, reusing special Webpack injected variables will break things as expected.

[iMoses-Apiiro]

You're talking about a global module variable as part of the commonjs standard, or any local variable named module would break?

[pmmmwh]

You're talking about a global module variable as part of the commonjs standard, or any local variable named module would break?

As far as I know, any module-level declaration of module would break. I haven't tested local variables, maybe this is fixable if we change how we would search for exports, but no guarantees.

Thought about the possibilities quickly, we could potential emit warnings instead of throwing here, so the build could continue to work, but the affected modules will not have HMR working properly.

[pmmmwh]

A change is now in place - exports failures will now warn in console instead of throwing.

[kryops]

I ran into this via callstack/linaria#891.
Apparently for some kinds of virtual modules webpack does not provide a moduleId at all (see callstack/linaria#891 (comment)).

With the change from #546, everything seems to be working fine again, however now I get lots of warnings in my console 😅

@pmmmwh Is moduleId === undefined a special case where it would be possible to skip the warning and just ignore the module?

[pmmmwh]

@pmmmwh Is moduleId === undefined a special case where it would be possible to skip the warning and just ignore the module?

In theory, the better approach would be to exclude these virtual modules to be processed by our loader, I'm not sure if that would work (if there is even some kind of pattern we can ignore against) in you case though.

Silencing warnings could be a way out, since moduleId being undefined is essentially an indicator of special types of modules where we will not be able to capture exports anyways, so we could probably also do that.