Occasionally seeing undefined error while accessing `readyState`
KyleBastien opened this issue · comments
This is the stack trace when I see the error:
<e> [MFLiveReloadPlugin] TypeError: Cannot read property 'readyState' of undefined
<e> at MFLiveReloadPlugin._afterEmit (C:\source\.yarn\cache\@module-federation-fmr-npm-0.0.5-5047596128-d8648b1820.zip\node_modules\@module-federation\fmr\src\index.js:207:27)
<e> at C:\source\.yarn\cache\@module-federation-fmr-npm-0.0.5-5047596128-d8648b1820.zip\node_modules\@module-federation\fmr\src\index.js:171:12
<e> at Hook.eval [as callAsync] (eval at create (C:\source\.yarn\cache\tapable-npm-2.2.0-516ee6aa5b-5a7e31ddd2.zip\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:9:1)
<e> at C:\source\.yarn\__virtual__\webpack-virtual-6b0c007d3f\0\cache\webpack-npm-5.27.2-9c59c0498d-45ea8bd0b4.zip\node_modules\webpack\lib\Compiler.js:825:27
<e> at C:\source\.yarn\cache\neo-async-npm-2.6.2-75d6902586-deac9f8d00.zip\node_modules\neo-async\async.js:2818:7
<e> at done (C:\source\.yarn\cache\neo-async-npm-2.6.2-75d6902586-deac9f8d00.zip\node_modules\neo-async\async.js:3522:9)
<e> at writeOut (C:\source\.yarn\__virtual__\webpack-virtual-6b0c007d3f\0\cache\webpack-npm-5.27.2-9c59c0498d-45ea8bd0b4.zip\node_modules\webpack\lib\Compiler.js:786:16)
<e> at C:\source\.yarn\__virtual__\webpack-virtual-6b0c007d3f\0\cache\webpack-npm-5.27.2-9c59c0498d-45ea8bd0b4.zip\node_modules\webpack\lib\util\fs.js:227:5
<e> at Immediate._onImmediate (C:\source\.yarn\cache\memory-fs-npm-0.4.1-0a5f9b8954-6db6c8682e.zip\node_modules\memory-fs\lib\MemoryFileSystem.js:303:5)
<e> at processImmediate (internal/timers.js:461:21)
This happens maybe 30% of the time when I serve the Federated Module when I test it locally. The behavior ends up being that auto-reloading stops working, but manual reloading does still work. Restarting webpack, usually ends up fixing this.
My guess for why I might be seeing this is that tcpPortUsed.waitUntilUsed never resolved it's Promise, and then _afterEmit is called at some point.
If there is any other info I can help provide, please feel free to let me know, happy to help.
Thanks so much for filing this issue, Kyle! I like where your head is at. Will look into it today. Just curious what your set up is like. Is this a monorepo? How is each webpack dev server being run?
Alright! Have a fix for this in PR now. Will keep you updated! Thanks again
Is this a monorepo?
It is. We use Nx as our monorepo. We don't though currently share that monorepo with the application consuming the Federated Module we develop. So currently our setup is we have one federation package in our monorepo, which has the Webpack config for the ModuleFederationPlugin. That federated module is then consumed by a different repo.
How is each webpack dev server being run?
In our case, we only run one webpack dev server, by basically running webpack serve --config ./webpack.config.js --mode development. We wrap this in our case with an Nx run-command, but that's just to make it more convenient to run the command from the root of the repo, and have Nx manage it. We don't run a second webpack dev server, because we can point a deployed "dog food" instance of the application that consumes our federated module at our locally running federated module, using a query param.
Alright! Have a fix for this in PR now. Will keep you updated! Thanks again 🙏
Wow, that's awesome turn around, thank you so much!
0.0.6 published
@alexUXUI and @ScriptedAlchemy thank you both so much for the quick turn around time here.
The behavior I'm now seeing, is that the stack trace above doesn't show up anymore, but now the browser doesn't seem to reload. I see the ports that FMR opens get's established, but the browser just doesn't seem to actually reload.
Any thoughts here? Or anything I can get to help with debugging?
@KyleBastien DM me and we can arrange access to the private repo if you'd like to dive deeper - our capacity is stretched