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

[lluzak]

🐛 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

[open-collective-bot]

Hey @lluzak 👋,
Thank you for opening an issue. We'll get back to you as soon as we can.
Please, consider supporting us on Open Collective. We give a special attention to issues opened by backers.
If you use Loadable at work, you can also ask your company to sponsor us ❤️.

[prateekr1]

I am also facing same issue. In my case i am getting below error

react-dom.production.min.js:5058 TypeError: Cannot read property 'call' of undefined
    at u (bootstrap:83)
    at Object.230 (ReviewCard.js:1)
    at u (bootstrap:83)
    at Object.234 (index.js:1)
    at u (bootstrap:83)
    at Module.96 (applyhomepage.4f1a6611.chunk.js:1)
    at u (bootstrap:83)
    at Object.e [as requireSync] (Loadable.js:9)
    at o.h.loadSync (loadable.esm.js:183)
    at new o (loadable.esm.js:133)`

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
  `

[theKashey]

Could you (both) clarify when the issue is happening:

• on the initial page load (that means loadable is not waiting for all used chunks to load)
• on the transition (that means loadable is thinking that something is ready while it is not)

And I also need an example of how you import component which is breaking - something inside ReviewCard in the second example, and why not moduleId in the first.

See #400

[prateekr1]

This bug is random in nature and whenever it occurs it occurs after loadableReady is resolved for initial page load.

Scenario,
Suppose a project has 3 chunks a,b & common chunk a~b and each chunks has 5 modules in it. 1-5 belongs to a, 6-10 to b & 11-15 to a~b.
So, imagine a scenario in which chunk a gets loaded first and then chunk a~b and then some part of chunk a start looking for module 11 but at that time module is still to be the part of modules.

/******/ 	function webpackJsonpCallback(data) {
/******/ 		var chunkIds = data[0];
/******/ 		var moreModules = data[1];
/******/ 		var executeModules = data[2];
/******/
/******/ 		// add "moreModules" to the modules object,
/******/ 		// then flag all "chunkIds" as loaded and fire callback
/******/ 		var moduleId, chunkId, i = 0, resolves = [];
/******/ 		for(;i < chunkIds.length; i++) {
/******/ 			chunkId = chunkIds[i];
/******/ 			if(Object.prototype.hasOwnProperty.call(installedChunks, chunkId) && installedChunks[chunkId]) {
/******/ 				resolves.push(installedChunks[chunkId][0]);
/******/ 			}
/******/ 			installedChunks[chunkId] = 0;
/******/ 		}
/******/ 		for(moduleId in moreModules) {
/******/ 			if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
/******/ 				modules[moduleId] = moreModules[moduleId];
/******/ 			}
/******/ 		}
/******/ 		if(parentJsonpFunction) parentJsonpFunction(data);
/******/
/******/ 		while(resolves.length) {
/******/ 			resolves.shift()();
/******/ 		}
/******/
/******/ 		// add entry modules from loaded chunk to deferred list
/******/ 		deferredModules.push.apply(deferredModules, executeModules || []);
/******/
/******/ 		// run deferred modules when all chunks ready
/******/ 		return checkDeferredModules();
/******/ 	}

function __webpack_require__(moduleId) {
/******/
/******/ 		// Check if module is in cache
/******/ 		if(installedModules[moduleId]) {
/******/ 			return installedModules[moduleId].exports;
/******/ 		}
/******/ 		// Create a new module (and put it into the cache)
/******/ 		var module = installedModules[moduleId] = {
/******/ 			i: moduleId,
/******/ 			l: false,
/******/ 			exports: {}
/******/ 		};
/******/ 		// Execute the module function
/******/ 		modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
/******/ 		// Flag the module as loaded
/******/ 		module.l = true;
/******/
/******/ 		// Return the exports of the module
/******/ 		return module.exports;
/******/ 	}

which leads modules[moduleId] as undefined.

P.S.: sorry for my bad English.

[prateekr1]

Error stack trace

react-lifecycles-compat.es.js:46 TypeError: Cannot read property 'call' of undefined
    at __webpack_require__ (bootstrap:86)
    at Module.96 (applyhomepage.a6b11d8a.chunk.js:1241)
    at __webpack_require__ (bootstrap:86)
    at Object.requireSync (Loadable.js:9)
    at InnerLoadable.loadSync (react-lifecycles-compat.es.js:46)
    at new InnerLoadable (react-lifecycles-compat.es.js:46)
    at Ug (react-lifecycles-compat.es.js:46)
    at ui (react-lifecycles-compat.es.js:46)
    at gk (react-lifecycles-compat.es.js:46)
    at fk (react-lifecycles-compat.es.js:46)

[lluzak]

For me it's also happening after loadableReady on initial page load. Currently moved to react-universal-component, which works without any problems.

[prateekr1]

@theKashey As I am using React streaming api and loadable-components yet not support prefetching for same. Please refer below line

It only works with renderToString API. Since <link> must be added in the <head>, you can't do it using renderToNodeStream.

so because all chunks are getting loaded in async manner it may be possible whenever runtime~main chunk is getting loaded after all or almost all other required chunks for a page to hydrate then it is leading to this error. As, I intentionally put a delay of 5 sec for runtime~main chunk which made it the last chunk to get loaded and thereafter leading to loadableReady which means loadableReady is working as expected but in this scenario, I am getting same above specified error with more frequency like 7 times out of 10.

[theKashey]

Ok. So the root cause it that loadable is trying to require modules in a sync way (it actually thinks it can call them synchronously), while they are not yet present.
webpack instruments dynamic import with all the required chunks to handle the requests, which is not the case here.

So the questions:

• why loadable thinks that it could call it sync. 👉 because it checks module existence in the cache and have no idea about module's requirements.
• once it was proposed that only modules in the SSR-ed chunks should be the subject for cache based isReady - any other, or anything after loadableReady should remember was it loaded or not. Look like this has to be done.

chunks are getting loaded in async manner it may be possible whenever runtime~main chunk is getting loaded after all or almost all other required chunks for a page to hydrate then it is leading to this error.

Webpack controls chunks execution and will not run the "main" one until it's dependencies are resolved, no matter how you do load them.
However, the list of chunks to be "awaited" has to be known before calling loadableReady

👉 try to run your code on DOMReady. That would ensure that all variables, and actually HTML to hydrate, is ready.

[prateekr1]

@theKashey

point_right try to run your code on DOMReady. That would ensure that all variables, and actually HTML to hydrate, is ready.
you mean instead of hydrate after loadableReady I should try below

window.addEventListener('DOMContentLoaded', (event) => { //'hydrate'; });

correct me if I am wrong.

[prateekr1]

I have completed all required task for migration from https://github.com/jamiebuilds/react-loadable to this library but this bug is a road blocker to make it to production.

Early solution to this bug would be a great justification to all my work involved in migration to this library.

[prateekr1]

@theKashey @gregberge When we are planning to get this fixed?

along with this bug i am facing below bug too
#553

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

[prateekr1]

@theKashey I am not much aware of internal working of this library. So, Please help me in understanding some of the points

• Difference between loadSync & loadAsync

• What are possible values for this.resolved[key]?

[theKashey]

That was just breadcrumbs for myself. The PR with the fix for the current problem has been already raised.

[prateekr1]

@theKashey

Referring your previous comment

#558 (comment)

Just to be on same page in term of understanding

• there are a few chunks - main, page1, page2, page1~page2.

• So required chunks for Page 1 is main, page1 and page1~pag2

<script id="__LOADABLE_REQUIRED_CHUNKS__" type="application/json">[page1,page1~pag2]</script>

Here main will bootup the process and then loadable-components with the help above line will be able to know page level dependencies and hold the hydration until all required chunks got loaded. This is done via below lines

loadableReady(() => { //'hydrate'; });

before hydration everything is working fine but while hydration this error occurs and this can be occured for any page for there 1st or nth load as this bug is dynamic in nature.

Below is the number of times this bug is happening for me in last 24 hours

[theKashey]

So, just to double check - error is happening during hydrate? Not any time later?
This means that the problem is inside loadableReady, which is actually very simple function (so I don't know what could be broken here, thus how to fix it)

[prateekr1]

@theKashey
No loadableReady is working fine, As it is doing its task of telling all chunks got loaded perfectly fine.

The problem here is not with chunk loading but with module loading as each chunk can have multiple modules and the scenario i tried to explain in #558 (comment)

You have mentioned in a comment module-federation/module-federation-examples#19 (comment) i.e.

Meanwhile - loadable overrides webpack's jsonp_callback for living, and is it working for already bundled remote as well?

I dnt know exactly how loadable overrides webpack's jsonp_callback for living works but modules loading is handled by it, so It may be possible something related to it causing the issue.

In meanwhile,I will try to apply changes of PR #568.

[theKashey]

Every module is brought by a some chunk. If chunk is loaded - then all modules inside it are loaded. So if just after loadableReady you are getting an error - that means it's not actually ready, which is only possible if one more chunk is not loaded, and the question is why.

[prateekr1]

But I have tried blocking one of required chunk say page1 from below example then in that case loadableReady is not getting fired as expected.

<script id="__LOADABLE_REQUIRED_CHUNKS__" type="application/json">[page1,page1~pag2]</script>

[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 #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]

@Joey-z-rp - look like you are close to the solution. We have just find a real root cause. Here is what not working right (as PR #568):

• isReady will still return true in our case. Which is possible only if it is loaded using requireAsync. Which could never fail (but we could not use async for the initial hydrate)

   if (this.resolved[key] !== true) { 
      return false;	  
    }
  // ...
  requireAsync(props) {
    this.resolved[key] = false;
    return this.importAsync(props).then(resolved => {
      this.resolved[key] = true;
    });
  },

• LOADABLE_SHARED.initialChunks[ctor.chunkName(props)] will be true because page.js. Which is also means - loadableReady is done, and all chunks need for the application start were loaded. And you are clearly state that page-dependency.js was not yet loaded.

As a result the problem is hidden:

• or in __LOADABLE_REQUIRED_CHUNKS__ - could you check that all "required" chunks are inside
• or in loadableReady
• or in third place. Right now loadableReady is waiting only in chunks listed in __LOADABLE_REQUIRED_CHUNKS__ and that might not all required. Dependencies of dependencies might not be tracked.

[prateekr1]

@theKashey

or in LOADABLE_REQUIRED_CHUNKS - could you check that all "required" chunks are inside

Yes for my case.

LOADABLE_SHARED.initialChunks[ctor.chunkName(props)] will be true because page.js. Which is also means - loadableReady is done, and all chunks need for the application start were loaded. And you are clearly state that page-dependency.js was not yet loaded.

As per my analysis

page-dependency.js as a chunk is loaded but all modules in page-dependency.js is yet to be loaded by below code so that it becomes the part of modules[moduleId]

/******/ 		for(moduleId in moreModules) {
/******/ 			if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
/******/ 				modules[moduleId] = moreModules[moduleId];
/******/ 			}
/******/ 		}

but before that happens below line got executed for a moduleId that is present in page-dependency.js but not yet part of modules[moduleId] i.e. some kind of race condition.

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

[Joey-z-rp]

@theKashey
It turned out that we didn't use loadableReady in our client side code 😢 . After I put it in, the app works correctly. Sorry for the false alarm.
Although it would be nice if the documentation have more information about what would happen if loadableReady is not used properly. In our case, the loadable component "setup" was done a while ago and it had been working fine (because we didn't have page-dependency.js at that time) until now. Even without loadableReady it works fine the majority of times. Those a few times it throws type error (because page-denpendency.js loads after vendor.js for whatever reason), the error message Cannot read property 'call' of undefined doesn't give useful information about what/where went wrong. It took me quite a digging to find out the cause and realised I need to use loadableReady.
Thanks very much for your help!

[theKashey]

Ok. So component should throw if loadableReady is not finished work or was not even called. Good catch.

[prateekr1]

@theKashey

Just FYI, I am using

optimization: {
    // Keep the runtime chunk seperated to enable long term caching
    // https://twitter.com/wSokra/status/969679223278505985
    runtimeChunk: true,
  },

and error happens in below cases

main.js -> page.js -> vendor.js -> page-dependency.js->runtime~main.js
page.js -> main.js -> vendor.js -> page-dependency.js->runtime~main.js

Sample Code to Assure the order

router.use("/js/page.js", (req, res, next) => {
    setTimeout(next, 2000);
});
router.use("/js/vendor.js", (req, res, next) => {
    setTimeout(next, 3000);
});
router.use("/js/page-dependency.js", (req, res, next) => {
    setTimeout(next, 4000);
});
router.use("/js/runtime~main.js", (req, res, next) => {
    setTimeout(next, 5000);
});

LOADABLE_REQUIRED_CHUNKS value

<script id="__LOADABLE_REQUIRED_CHUNKS__" type="application/json">[page,page-dependency]</script>

[theKashey]

So there is a little problem:

• loadable uses babel plugin to inject webpackChunkName to the every import
• this gives it an ability to know those chunk names
• webpack could easily split one chunk to many smaller ones, like runtime~main.js
• server should collect all child scripts and still report them LOADABLE_REQUIRED_CHUNKS

Like what is vendor.js and runtime~main.js in your case? They are not in LOADABLE_REQUIRED_CHUNKS! As a result, loadableReady says "I am ready" while it is not.

So two ways to fix:

• fix LOADABLE_REQUIRED_CHUNKS / chunk collection
• solve it in any other way.

The simples solution would be to import any "expected to be loaded" loadable component, but full dynamic import is not letting you do that without knowing props.

So @prateekr1 - could you share your stats.json. We have to find how chunks are connected, and why their connection was not discovered by the loadable/server

[prateekr1]

@theKashey Because of my firm policy I would not be able to share stats.json but I am trying to create a sample example.

• As main, vendor and runtime~main are application initial requirement without any of it application does not boot up.

• While page & page-dependency are page level dependency and application is not aware of these dependencies so to make application aware of these dependencies this library takes help of LOADABLE_REQUIRED_CHUNKS and hold the loadableReady event untill all chunks specified in LOADABLE_REQUIRED_CHUNKS got loaded.

• After loadableReady event we hydrate the application.

So, I feel this library intelligently populating LOADABLE_REQUIRED_CHUNKS with page level dependencies only, not with initial application level dependencies i.e. main, vendor and runtime~main as LOADABLE_REQUIRED_CHUNKS will only come into picture once application got boot up.

So, here runtime has the code

/******/ 	function webpackJsonpCallback(data) {
/******/ 		var chunkIds = data[0];
/******/ 		var moreModules = data[1];
/******/ 		var executeModules = data[2];
/******/
/******/ 		// add "moreModules" to the modules object,
/******/ 		// then flag all "chunkIds" as loaded and fire callback
/******/ 		var moduleId, chunkId, i = 0, resolves = [];
/******/ 		for(;i < chunkIds.length; i++) {
/******/ 			chunkId = chunkIds[i];
/******/ 			if(Object.prototype.hasOwnProperty.call(installedChunks, chunkId) && installedChunks[chunkId]) {
/******/ 				resolves.push(installedChunks[chunkId][0]);
/******/ 			}
/******/ 			installedChunks[chunkId] = 0;
/******/ 		}
/******/ 		for(moduleId in moreModules) {
/******/ 			if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
/******/ 				modules[moduleId] = moreModules[moduleId];
/******/ 			}
/******/ 		}
/******/ 		if(parentJsonpFunction) parentJsonpFunction(data);
/******/
/******/ 		while(resolves.length) {
/******/ 			resolves.shift()();
/******/ 		}
/******/
/******/ 		// add entry modules from loaded chunk to deferred list
/******/ 		deferredModules.push.apply(deferredModules, executeModules || []);
/******/
/******/ 		// run deferred modules when all chunks ready
/******/ 		return checkDeferredModules();
/******/ 	}

function __webpack_require__(moduleId) {
/******/
/******/ 		// Check if module is in cache
/******/ 		if(installedModules[moduleId]) {
/******/ 			return installedModules[moduleId].exports;
/******/ 		}
/******/ 		// Create a new module (and put it into the cache)
/******/ 		var module = installedModules[moduleId] = {
/******/ 			i: moduleId,
/******/ 			l: false,
/******/ 			exports: {}
/******/ 		};
/******/ 		// Execute the module function
/******/ 		modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
/******/ 		// Flag the module as loaded
/******/ 		module.l = true;
/******/
/******/ 		// Return the exports of the module
/******/ 		return module.exports;
/******/ 	}

Out of which below code is responsible for loading all moduleId of each chunk to modules chunk by chunk.

/******/ 		for(moduleId in moreModules) {
/******/ 			if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
/******/ 				modules[moduleId] = moreModules[moduleId];
/******/ 			}
/******/ 		}

So, particularly in below sequence as soon as runtime~main.js gets loaded

main.js -> page.js -> vendor.js -> page-dependency.js->runtime~main.js

It leads to

• Loading all moduleId in modules from main.js then

• Loading all moduleId in modules from page.js then

• Loading all moduleId in modules from vendor.js and hence leading to application bootup and also to loadableReady as all required chunks all already there but

• Loading of all moduleId in modules from page-dependency.js is still pending let say moduleId 154 is one of moduleId of chunk page-dependency.js then

• As loadableReady already got fired and hence call from page.js looking for moduleId 154 came.

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

and moduleId 154 is not yet part of modules and hence leading to error

react-dom.production.min.js:5058 TypeError: Cannot read property 'call' of undefined
    at __webpack_require__ (bootstrap:84)
    at Module.96 (page.js:1248)
    at __webpack_require__ (bootstrap:84)
    at Object.requireSync (Loadable.js:9)
    at InnerLoadable.loadSync (loadable.esm.js:183)
    at new InnerLoadable (loadable.esm.js:133)
    at Lg (react-dom.production.min.js:3174)
    at fi (react-dom.production.min.js:4307)
    at Rj (react-dom.production.min.js:6700)
    at Qj (react-dom.production.min.js:6150)

[theKashey]

Let's just answer one question - it is breaking during initial hydrating (which means loadableReady is not working), or later?
#568 was created to fix only "later", and there is really problem with that "later", however look like the bigger issue is hidden inside chunk tracking.

[prateekr1]

Let's just answer one question - it is breaking during initial hydrating (which means loadableReady is not working), or later?

Yes, it is breaking during initial hydration.

And, It is only breaking when In webpack I use below config i.e. it create a separate chunk for runtime information in runtime~main.js instead of keeping the runtime information in main.js and why of it, has already been explained in depth in my previous comment
#558 (comment)

optimization: {
    // Keep the runtime chunk seperated to enable long term caching
    // https://twitter.com/wSokra/status/969679223278505985
    runtimeChunk: true,
  },

[theKashey]

Ok. I'll try to update one of examples here to break them.

[prateekr1]

After digging transpiled code via webpack. I found in page.js below code, where most of the time it is breaking when order of load of chunks is
main.js -> page.js -> vendor.js -> page-dependency.js->runtime~main.js

// EXTERNAL MODULE: ./src/utils/validation.js
var validation = __webpack_require__(1);

where moduleId 1 is in page-dependency.js.

so, interested to know when does webpack put EXTERNAL MODULE comment and it what it means

// EXTERNAL MODULE: ./src/utils/validation.js

P.S.: knowledge of this may help me in creating an example for this bug.

[prateekr1]

@theKashey can you help me with this #558 (comment).

[theKashey]

I am not a webpack expert. Sorry @prateekr1

[rytmis]

FYI, we ran into this issue with a project that mixes SSR and pure client-side pages depending on the context (we identify the SSR scenario and use loadableReady where appropriate). For some non-SSR pages, it was in one case consistently reproducible by first doing a clear cache + reload followed by a regular reload. The latest release from master indeed seems to have fixed it.

[theKashey]

That's good news. Sounds like the latest master should be published to npm.

[zeppelinen]

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

[theKashey]

On it...