Open ScriptedAlchemy opened 4 years ago
Any news on this?
Just found this, it would be very useful indeed
I tried using nuxtjs as host and vue3 as remote, whether using webpack ModuleFederationPlugin or originjs/vite-plugin-federation, I have encountered v-model binding problems. I am not sure whether there is a problem with my shared or the bottom layer of nuxtjs does not support module federation.
would be cool if nuxt layers support this
We released vite support. Believe community is working on nuxt now.
Is your feature request related to a problem? Please describe.
Users likely want Module Federation, ive spoken to maintainers of Nuxt on twitter and we agreed that MF would be a great addition. Since nuxt is WP5 compatible, and unlike Next.js, it uses a modern async architecture - so it should just work (more or less) with nuxt
Describe the solution you'd like
I'm thinking of a new directory like
federated
similar topages
any module placed in the federated directory are automatically exposed with Module FederationSharing should still be a manual process as aggressive sharing can cause chunk sizes to increase. At this point, for the webpack 5 release tomorrow - we are not addressing tree-shaken shared exports automatically. Though one is able to manually export shaken modules.
We should share whatever nuxt uses, like vue. And unless vue supports multiple versions (unlike react 16) we can set it as a singleton.
I'm not a Nuxt user, but lets assume you hydrate page data with some kind of static? If the server can support suspense-like code loading, then we have more options.
Sharing pages should be automatic (maybe) depending on if your pages are able to provide their own. This would enable us to stitch multiple pages from multiple deploys together, providing SPA at runtime composed of separate MFES who are able to self-hydrate. Some questions come up around should we expose protected pages and so on. So if we have a sane way to opt in or out of sharing pages with some exclusions list - that would likely be helpful
SSR: SSR is a little tricky depending on your deploy method. By default, webpack reads disk, if it cannot reach modules, it wont work.
We can solve this with
We also need to consider chunk flushing so that you can render JS chunks from federated locations. This requires extending the MF api slightly, using startup code, we can attach the available client chunk mappings directly to the remote runtime.
Hot reloading production.
Client side, you just refresh, but server-side we have two challenges. The require cache and webpack internal cache.
I can handle the require cache, but webpack internal module cache is not as easy to correctly invalidate. Since we do not have cross container HMR (it'll show up after webpack 5 release, you can use live reload for federated chunks and i also have the code to get remotes talking to hosts on change.
The proposed solution i have is the render middleware that the host app uses, is actually imported using the hosts own remote. This lets us preform a uncached require of the hosts remote when needed, since the remote is a webpack runtime... we basically restart a very light version of the webpack container which only loads what you're asking for, in this case on the server, its own render entry point. Usually I'd restart the process with kill spawn argv, but i dont need to reboot node - i only need to have a way to "restart" webpack. Since webpack won't have any chunks loaded in its container, you can get clean, evergreen modules at runtime on the server.
Describe alternatives you've considered
5 years of spending millions of dollars in company funds on gargantuan CI pipelines that poorly attempt to "stitch" something together. There's no one line alternative to MF. Realistically there is no alternative to consider
Additional context
I'm the creator of Module Federation, happy to help get Nuxt ready.
Ive also been in touch with Next.js - next v10 will support MF natively (i use workarounds) but am not sure of the next 10 release.
Nuxt would be the first product of its kind to support Module Federation while the older projects play catchup.
Since you're already async, it probably wouldn't take more then a day or two to get the foundations laid - likely with a little extra time to consider the SSR implementation strategy.
Ive never written a line of Vue... so might need some help with any lifecycle integrations for stuff like async. I was able to apply federation between my react applications to that our legacy Vue apps could consume code from next.js - thats basically all my experience. Luckily this is webpack architecture primarily and I doubt we will have any real roadblocks.