feat: make packages webpack 5 compatible

[StephaneRob]

Summary

make packages compatible with Webpack 4 and Webpack 5

[theKashey]

Fixes #636. PS @ScriptedAlchemy this is the fix you were looking for.

[theKashey]

@StephaneRob - just it time. Thank you so much for this contribution.

[ajayjaggi]

Hi.Even after these changes loadable is failing in SSR for federated modules while using webpack 5. I have also raised the issue.

[ScriptedAlchemy]

Federated modules need to be handled a specific way. I don't think Babel can extract chunk mappings. @theKashey I'll update my ssr example then let's see what's needed for MF support.

[ajayjaggi]

Thanks @ScriptedAlchemy . I saw your Repo https://github.com/module-federation/module-federation-examples/tree/master/server-side-render-only. It works when @Loadable fixes are merged into this.But there is no example where components are imported using loadable function.It fails for me there in SSR
It would be a great help if you could look into this.
Thanks.

https://github.com/ajayjaggi/MicroForntEnd-Basic-Structure - This is my repo where i have tried this.

[ScriptedAlchemy]

Ahhh. Yeah that's because loadable probs tried to babelify the import into a hoc. But there's no chunkmapping so hydration issues can happen.

You could try enabling top level await. But I think chunk flushing might still be a problem.

[ScriptedAlchemy]

Same issue I ran into with next. I've been using lazy hydration so the component remains static till webpack runtime is booted, then I'd resolve the import client side and allow the component to hydrate

[ajayjaggi]

Also i wanted to know that how module federation along with loadable will handle the issue of larger waterfall.
Currently all the scripts from remotes server are loaded serially after container.js is loaded on the client side.So what would be the approach to load them in parallel.

How can host server find out the dependencies from the client container of remote server ?
@ScriptedAlchemy Pls help as this is a critical part for performance.

[theKashey]

Meanwhile - can we move from merged PR to an open issue -> #638

[ScriptedAlchemy]

If you have the remotes on the page immediately. Like hardcoded. All remote code should transport down in a single RTT.

If you want to SSR the chunks a remote requires:

1. loadable needs a new way to map names of remotes to federated chunk maps.
2. I need to extend the MF api so remotes will export their chunk maps so loadable can extract them during render.

Whenever you use loadable. Babel basically transforms the import into a object with a normal require statement and the module / chunk id. Then it's executed the HOC pushes these IDs into a scope that the server can access after the react render.

The only Id it will have is ./someExposedModule - and we would need to go over the remotes stats and find what the browser side script is for that module.

Same problem exists in next js. The loadable method straight crashes.
No existing code split tool is capable of MF chunk coronations. I work around hydration issues with top level awaits. Which work on both client and server.

You could also use partial hydration and simply hydrate markup when visible.

I don't foresee this being hard to accomplish. Especially since I can extend MF apis at will.

We could even change the getter on the remote so whenever a server gets code from the remote, it's container will report what request was asked for from the remote. It actually could be done without and need for Babel at all, or even loadable HOC. The only part we would need to adapt is ChunkExtractor to read from the second scope the remote containers are accessing directly.

This mechanism would work exactly like react-universal does. Push right into a map, but we will be doing this inside the webpack runtime directly.

[KittyGiraudel]

Out or curiosity—and sorry for interjecting in the middle of the conversation, is there a reason this update has not been published on npm already?

[theKashey]

the absence of a webpack5 based automated test to make this release a little more secure

[theKashey]

During the testing, I've actually found a real blocker for loadable usage. But it's not on the loadable side - so I am releasing a beta version of loadable to let others test it as well.