Hey, thanks for the video! Federated types are interesting. However, if you have bi-directional remotes and hosts, the app has to download types on the starting dev server. Let’s say app A uses app B, and app B uses modules form app A as well, both apps will not start locally because they require types. And even if they are not bi-directional, it can be a race condition on which app dev server should start first to serve types, those problems that I found with federated types.
Thanks for pointing that out! I typically don't use bi-directional remotes but it is indeed a problem in this scenario. I think NX may solve the race condition on startup, I could be wrong though - if you are using concurrently yes that is absolutely true. For me I usually rely on monorepo types via project references, and when I have to start consuming modules with different contracts via versioning, then I just use that module url in my federated types plugin so that I am no longer bound to the other process locally. It's a tricky problem to solve and the types plugin could probably be improved down the road.
Have you tried the latest federated types package as well? I was just testing it in NX, and both apps start but the types do fail to download. I'll look into adding maybe a retry loop that is configurable.
I tried it 6 months ago. Retry might be an option! So I think what you can do just use typescript paths + NX for local types and federated types when you use some app`s moduels from CDN. That should work as well.
@@oleksandrkhivrych6349 - exactly, I will try to experiment with retry/backoff logic in the federated types plugin :) but it looks like the latest version makes this scenario worse actually.
@@oleksandrkhivrych6349 I have 2 draft PRs up for the @mf/typescript package, one enables retry by default which can help race conditions, the second hosts the types in a small node http server during bundling. Together they fix bi-directional type sharing running locally. Will keep testing :)
I really enjoy all your videos thanks for sharing all your knowledge. I do have a question that I am hoping you can give me some guidance. How will you handle dynamic runtime imports and typescript with two different bundlers? Lets say the host uses Webpack but the remote uses Vite/esbuild? I know Vite has a plugin for module federation but I dont think it has one for dynamic remotes or typescript generator.
Thanks! So I don’t think vite/esbuild have official federation support but there is another package called native federation typescript that should work for the typescript portion github.com/module-federation/universe/tree/main/packages/native-federation-typescript
This is an older version, here is a newer video which I believe is v19 Micro frontends - NX, Rspack, Module Federation with new Federated Types! ruclips.net/video/oJY92rZV8NE/видео.html
How to load a remote that is outside the nx mono repo app, I created a mfe react app outside the nx mono repo app and try to load it using module fed inside thenx monorepo host app.
You can either configure the URL in webpack/rspack or you can load dynamically through something like loadRemote in the utilities package. I do need to update this video with rspack and MF v1.5
@@russellcanfield the same package you are showing in this video right? I am really struggling with it for last 2 days. if it helps that would be great. subscribed.
@@vipinvijayan6034 yes the same package in the video, really module federation needs to know where to fetch the code from. It will always need a URL pointing to the “remote entry” js file that is output from your remote’s build
Sorry, I wanted to ask one more question. So the error I was getting is fn is not a function. I am exposing a simple react component. what could be the reason? is that the reason, you are setting the ecm boolean in the loadModule method?
Hey, thanks for the video! Federated types are interesting. However, if you have bi-directional remotes and hosts, the app has to download types on the starting dev server. Let’s say app A uses app B, and app B uses modules form app A as well, both apps will not start locally because they require types. And even if they are not bi-directional, it can be a race condition on which app dev server should start first to serve types, those problems that I found with federated types.
Thanks for pointing that out! I typically don't use bi-directional remotes but it is indeed a problem in this scenario. I think NX may solve the race condition on startup, I could be wrong though - if you are using concurrently yes that is absolutely true.
For me I usually rely on monorepo types via project references, and when I have to start consuming modules with different contracts via versioning, then I just use that module url in my federated types plugin so that I am no longer bound to the other process locally. It's a tricky problem to solve and the types plugin could probably be improved down the road.
Have you tried the latest federated types package as well? I was just testing it in NX, and both apps start but the types do fail to download. I'll look into adding maybe a retry loop that is configurable.
I tried it 6 months ago. Retry might be an option! So I think what you can do just use typescript paths + NX for local types and federated types when you use some app`s moduels from CDN. That should work as well.
@@oleksandrkhivrych6349 - exactly, I will try to experiment with retry/backoff logic in the federated types plugin :) but it looks like the latest version makes this scenario worse actually.
@@oleksandrkhivrych6349 I have 2 draft PRs up for the @mf/typescript package, one enables retry by default which can help race conditions, the second hosts the types in a small node http server during bundling. Together they fix bi-directional type sharing running locally. Will keep testing :)
I really enjoy all your videos thanks for sharing all your knowledge. I do have a question that I am hoping you can give me some guidance. How will you handle dynamic runtime imports and typescript with two different bundlers? Lets say the host uses Webpack but the remote uses Vite/esbuild? I know Vite has a plugin for module federation but I dont think it has one for dynamic remotes or typescript generator.
Thanks! So I don’t think vite/esbuild have official federation support but there is another package called native federation typescript that should work for the typescript portion
github.com/module-federation/universe/tree/main/packages/native-federation-typescript
Awesome
Thanks for watching!
Which version of NX library are you using?
This is an older version, here is a newer video which I believe is v19
Micro frontends - NX, Rspack, Module Federation with new Federated Types!
ruclips.net/video/oJY92rZV8NE/видео.html
How to load a remote that is outside the nx mono repo app, I created a mfe react app outside the nx mono repo app and try to load it using module fed inside thenx monorepo host app.
You can either configure the URL in webpack/rspack or you can load dynamically through something like loadRemote in the utilities package. I do need to update this video with rspack and MF v1.5
@@russellcanfield the same package you are showing in this video right? I am really struggling with it for last 2 days. if it helps that would be great. subscribed.
@@vipinvijayan6034 yes the same package in the video, really module federation needs to know where to fetch the code from. It will always need a URL pointing to the “remote entry” js file that is output from your remote’s build
Sorry, I wanted to ask one more question. So the error I was getting is fn is not a function. I am exposing a simple react component. what could be the reason? is that the reason, you are setting the ecm boolean in the loadModule method?
Your all videos are in small font, please make future videos or remake these videos with zoom in fonta