loadable-components: 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
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 37
Commits related to this issue
- fix: allow webpack cache is ready only for initial chunks, fixes #558 — committed to gregberge/loadable-components by theKashey 4 years ago
- fix: allow webpack cache is ready only for initial chunks, fixes #558 — committed to fivethreeo/loadable-components by theKashey 4 years ago
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
but
modules[moduleId]is undefined (not loaded yet). Further investigation found this is because loadable component checksoptions.ssr !== false && ctor.isReady && ctor.isReady(props)andisReadyreturnstruebecause it checks:This
keyhere is themoduleIdfor 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.isReadygives false positive to loadable to useloadSync. 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:isReadywill still returntruein our case. AlsoLOADABLE_SHARED.initialChunks[ctor.chunkName(props)]will be true because page.js is loaded from SSR process. SoloadSyncwill 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.So, just to clarify:
And the solution is not to “trust” any non initial page. Sounds like a small change to
isReady- it should bailout for:this.resolved[key] === falsebeforeLoadableReadyevent (as right now)this.resolved[key] !== trueafterLoadableReadyevent (should fix this case)@theKashey would be great if you release master to npm a bit more frequently. I like the fact that loadable-components is stable, but last release was in January and it misses a lot of fixes.
Ok. I’ll try to update one of examples here to break them.
That was just breadcrumbs for myself. The PR with the fix for the current problem has been already raised.