undefined is not an object (evaluating 'e[t].call')

🐛 Bug Report

Sentry reports error about not being able to find module. It happens for a lot of people. I am having problem with reproducing it even, because it works for me. Tried for about a hour to cause a error and it happen only once.

TypeError: Cannot read property 'call' of undefined
  at __webpack_require__(webpack/bootstrap:84:22)
  at call(resources/pages-Home-160eba.js:26:26)
  at __webpack_require__(webpack/bootstrap:84:22)
  at call(resources/pages-Home-160eba.js:15:17)
  at __webpack_require__(webpack/bootstrap:84:22)
  at requireSync(./src/Boot/App.tsx:35:22)
  at loadSync(./node_modules/@loadable/component/dist/loadable.esm.js:185:35)
  at new h(./node_modules/@loadable/component/dist/loadable.esm.js:135:17)

Error coming from here.

// Execute the module function
 		modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);

I checked issues and problem has been resolved in 5.11.0 release when it comes to chunks.

Any idea what could be a cause ?

Expected behavior

Should not happen.

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.15.4
 - CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
 - Memory: 1.34 GB / 16.00 GB
 - Shell: 5.7.1 - /bin/zsh
## Binaries:
 - Node: 11.12.0 - ~/.nvm/versions/node/v11.12.0/bin/node
 - Yarn: 1.21.1 - ~/.yarn/bin/yarn
 - npm: 6.7.0 - ~/.nvm/versions/node/v11.12.0/bin/npm
 - Watchman: 4.9.0 - /usr/local/bin/watchman
## npmPackages:
 - @loadable/babel-plugin: ^5.12.0 => 5.12.0
 - @loadable/component: ^5.12.0 => 5.12.0
 - @loadable/server: ^5.12.0 => 5.12.0
 - @loadable/webpack-plugin: ^5.12.0 => 5.12.0

[Joey-z-rp]

Hi @theKashey , I’m experiencing a similar issue. Say a particular page on our site (SSR) needs 4 chunks: main.js, vendor.js, page.js, page-dependency.js. page-dependency.js normally loads before vendor.js and everything is fine. If for some reason page-dependency.js loads after vendor.js, it will throw TypeError: Cannot read property ‘call’ of undefined. So the following loading orders are fine: main.js -> page.js -> page-dependency.js -> vendor.js main.js -> page-dependency.js -> page.js -> vendor.js page-dependency.js -> page.js -> main.js -> vendor.js and these will error: main.js -> page.js -> vendor.js -> page-dependency.js page.js -> main.js -> vendor.js -> page-dependency.js After investigation I found the cause: main.js waits until vendor.js is loaded and executes, which executes page.js. However the dependency (page-dependency.js) for page.js is not ready at the moment, causing the type error - it tries to run

modules[moduleId].call(module.exports,` module, module.exports, __webpack_require__);

but modules[moduleId] is undefined (not loaded yet). Further investigation found this is because loadable component checks options.ssr !== false && ctor.isReady && ctor.isReady(props) and isReady returns true because it checks:

if (typeof __webpack_modules__ !== 'undefined') {
      return !!(__webpack_modules__[key])
}

This key here is the moduleId for one of the modules in page.js and it will exist in __webpack_modules__ because page.js is loaded. However it doesn’t mean that page.js is safe to execute because page-dependency.js is not loaded yet. isReady gives false positive to loadable to use loadSync. It only checks whether the module itself is loaded but misses its dependencies. I read your PR https://github.com/gregberge/loadable-components/pull/568. From my limited understanding of loadable library, I’m not sure if it will solve the issue in the above case: isReady will still return true in our case. Also LOADABLE_SHARED.initialChunks[ctor.chunkName(props)] will be true because page.js is loaded from SSR process. So loadSync will still be called causing the type error. Although not very frequent, this bug is causing production issue for our app. We would really appreciate it if the bug can be fixed soon. I can put up a sample project if the information is not enough. Thanks a lot.

[theKashey]

So, just to clarify:

• there are a few chunks - main, page1, page2, somestuff, someotherstuff
• you can load page1, it will also load, page2 and somestuff
• then you will try to load page2, it will be in the cache, so loadable will try to load it, but not all dependencies would be “ready”
• 💥

And the solution is not to “trust” any non initial page. Sounds like a small change to isReady - it should bailout for:

• all this.resolved[key] === false before LoadableReady event (as right now)
• all this.resolved[key] !== true after LoadableReady event (should fix this case)