Webpack reports "the request of a dependency is an expression" (SSR, Server-Side only)

[swernerx]

🐛 Bug Report

Webpack v4 reports the following issue when executed:

WARNING in ./node_modules/@loadable/server/lib/util.js 26:9-28
    Critical dependency: the request of a dependency is an expression

The code involved in loadable looks like this:

var smartRequire = function smartRequire(modulePath) {
  if (process.env.NODE_ENV !== 'production') {
    clearModuleCache(modulePath);
  } // Use __non_webpack_require__ to prevent Webpack from compiling it
  // when the server-side code is compiled with Webpack
  // eslint-disable-next-line camelcase


  if (typeof __non_webpack_require__ !== 'undefined') {
    // eslint-disable-next-line no-undef
    return __non_webpack_require__(modulePath);
  } // eslint-disable-next-line global-require, import/no-dynamic-require


  return require(modulePath);
};

The error seems to happen in the last line.

We do not have any dynamic imports in the whole application. All of our code is using simple strings right now.

Interestingly, beside the critical warning we cannot see any negative side effect. The application seems to work correctly.

I tried to figure out where this __non_webpack_require__ is coming from. Seems like it is a convention introduced by Webpack. Maybe there is some error in the combination of Babel/Webpack plugins we use.

Earlier in our development this error was not there. It seems it was introduced by some updates to the dependencies. Right now we have the following versions installed:

yarn list --depth 0 --pattern loadable
yarn list v1.13.0
├─ @loadable/[email protected]
├─ @loadable/[email protected]
├─ @loadable/[email protected]
└─ @loadable/[email protected]

yarn list --depth 0 --pattern webpack
yarn list v1.13.0
├─ @svgr/[email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]

To Reproduce

Steps to reproduce the behavior:

I am not sure. Seems to be related to SSR, Webpack and Loadable.

Expected behavior

That the error/warning is gone.

Link to repl or repo (highly encouraged)

Please provide a minimal repository on GitHub.

Issues without a reproduction link are likely to stall.

Run npx envinfo --system --binaries --npmPackages @loadable/component,@loadable/server,@loadable/webpack-plugin,@loadable/babel-plugin --markdown --clipboard

Paste the results here:

## System:
 - OS: macOS 10.14.3
 - CPU: (8) x64 Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
 - Memory: 988.22 MB / 16.00 GB
 - Shell: 5.3 - /bin/zsh
## Binaries:
 - Node: 11.9.0 - /usr/local/bin/node
 - Yarn: 1.13.0 - ~/Workspace/witt/emma-boilerplate/node_modules/.bin/yarn
 - npm: 6.7.0 - /usr/local/bin/npm
## npmPackages:
 - @loadable/babel-plugin: 5.6.0 => 5.6.0
 - @loadable/component: 5.6.0 => 5.6.0
 - @loadable/server: 5.6.0 => 5.6.0
 - @loadable/webpack-plugin: 5.5.0 => 5.5.0

[swernerx]

I am trying to reduce the code in our SSR "branch" right now. I figured when I remove the following import: import { ChunkExtractor } from '@loadable/server' the issue is gone.

[swernerx]

The error is server-side only and is gone when removing the ChunkExtractor import.

Probably the issue is somehow related to: #181

[swernerx]

Please note: We bundle all app-code on client+server with Webpack. The only excluded package right now is node-fetch.

[swernerx]

It seems like going back to return eval('module.require')(modulePath) in the last line fixes the issue for me.

[gregberge]

I think your issue is a webpack one, you do: import(dynamicPath). It is not supported by webpack. Please restrict your path using an interpolated string import(``./some/${page}``)

[swernerx]

Actually your assumption is not true. We do not use a single dynamic import. All static imports based on plain strings. So closing this report might be a little too early.

[swernerx]

The Webpack reporting is true as it seems. It mentions the problem inside the loadable code. As I tried to explain: changing back the require code to eval fixes the issue for us.

[gregberge]

@swernerx OK sorry, I got it, yeah we need to change it to eval.