Typescript with Module Federation || TypeScript Tutorial
Вставка
- Опубліковано 5 жов 2024
- Let's try out Typescript with Module Federation. Turns out it's not hard. But do you have a better way than me to do this? Let's find out!
Code: github.com/jhe...
Starter kit: github.com/jhe...
If you liked this video, buy me a coffee! www.buymeacoff...
Hope you folks enjoy this!
👉 If you enjoy this video, please like it and share it.
👉 Don't forget to subscribe to this channel for more updates.
👉 Subscribe now: bit.ly/2E7drfJ
👉 Discord server signup: / discord
💢 Watch our other videos:
💟 Flexible Forms with React Hook Form LIVE! :bit.ly/3g60Feb
💟Flexible Forms with React Hook Form: • Flexible Forms with Re...
Thank you for watching this video, click the "SUBSCRIBE" button for stay connected with this channel.
Subscription Link: bit.ly/2E7drfJ
#javascript #react #module-federation
Having worked with Zack in the past, I’m super excited to see this. Great video and great solution
Wow man, this video was exactly what I needed. Thank you so much! Keep up with videos like this!
You explained everything seriously obscured to me with Next.js! Thank you.
Brilliant, as usual, Jack. Thank you so much.
Really loving this TS starter! Would love to see the next levels too :). Just did this end to end ... wow, that was packed ... i think that was excellent. QQ: instead of shared-types being linked workspace via npm linking ... could it be its own federateModule that's remoted into the other federatedModules? In a bigger system, would this be an okay option? As opposed to having the host define a types tsremote-mf-decl.d.ts ? I supposed you would still need the decl.d.ts.
It would be great but from what I see it will all compile to remoteEntry.js anyway and lose the types... But bundled packages have the d.ts definitions inside... It should work the same with Module Federation packages IMHO, but it doesn't?
Hey Jack,
first of I love your Videos about Module Federation an Micro Frontends.
But one thing you mentioned. When you at least using an IDE wich has Typescript running in the Background and respects tsconfig.json files you can do it much more easier without the "shared-types" module.
Take a look here: github.com/42tg/mf-typescript
You can even Shift + Click on the tsremote-mf imports and jump directly to the implementation. Sure you have to add all Federated Modules but since you have to do the work anyway in the webpack config it should be not the biggest problem.
Is there an IDE that you recommend that would show this off? I'd love to have that lined up for Friday's livestream at Noon PST on this channel.
Vscode does this out of the Box
Tobias Graf ah, gotcha.
Have fun, I will take a look if I can join your stream at friday 👍
Doesn't having this as a mono-repo sort of defeat the point of module federation? I feel like I'm missing something here.
You can deploy a new remote without needing to rebuild the host.
I'm curious about this too. Not sure if he decided to just demo this as a mono-repo for the sake of a more stream lined video though.
Thanks Jack. You are a star........
Super good tutorial
super helpful ty ty
You do point out the fundamental problem (build / runtime). Unfortunately this doesn't solve for any of the use cases a large company will benefit from module federation. Since this is a year old, I'm curious if you've come up with anything that scales for companies with several teams owning pieces of a user experience on a single page (eg micro-frontends). Best I've been able to do is publish types to their own registry and use some script to pull down the latest types during builds. Optionally developers consuming another remote can sync types with a cli command.
Many thoughts about this. First, I don't think my position has changed that architecturally what you want is to share type "contracts" for the MFEs. As for how to get that done, it would be great to see more support from NX for Module Federation since they have TypeScript type sharing between libraries and applications down to a science. Alternatively, or maybe in addition to that, it would be cool if we could get `.d.ts` files created as part of the files in the bundle. And then, at the very least we could pull them down before building. And if we could get that it would be awesome to see some integration into tsc for type files deployed as URLs.
@@jherr thanks for your reply and yeah, “contract” is the word I should have used. I also have many thoughts (as is typical with mfe conversations). I’ve been researching this problem space for the last couple years internally at amzn and spoken with many teams tackling it for various products (the .com teams are particularly interesting btw-not many scenarios in the world with that level of scope and complexity). Would you be interested in having a spoken conversation sometime?
@@_blank_3677 sure. Hit me up on either my discord or Twitter DMs, both are open and I’d be happy to talk.
@@jherr will do, also speaking of contracts-I’d love to talk testing strategies too. We’re vending/consuming user experiences here, which are unquestionably much more complex than the data typically being consumed in backend SOA.
@@_blank_3677 funny you should mention that. I’m just wrapping up content for a 90+ minute micro-fe video for freeCodeCamp and I was just writing up testing strategies today. :)
Awesome as usual. Thanks
But does it scale? What about the internals of the exports, for example i export a state object as remote module and it has complex structure it would still show that the attribute is unknown.
I cant imagine that we would need to create each declaration in the host application instead finding a way loading it from the remote?
Module Federation shares JavaScript code, and that JavaScript, compiled from TypeScript lacks and details on the types.
Is this still an up-to-date solution or is there something better?
There has been some work recently where folks are zipping .d.ts files and packaging them along with the libraries. Then grabbing them and unzipping them at compile time.
@Rodrigo Lima Batista Nothing has been released yet that I know of.
Could we not simply rely on tsconfig path (alias) mapping instead of npm / yarn linking to the shared types library ?
For e.g:
"paths": {
"@types/app1/*": ["./packages/types-app1/src/types.ts"]
}
Then import the required types in the host/remote apps like:
import type { Pokemon } from "@types/app1" ?
For some context, the reason why I am unable to use npm / yarn linking is because I have a React-Native-For-Web monorepo setup (with Nx). Converting the monorepo into a "workspace" (adding the workspace property in package.json) starts breaking my Android/iOS ReactNative builds in the micro-apps; because in Android for example, gradle builds start looking for modules within the micro-app's node_modules directory but the modules are actually installed at the root of the monorepo (due to npm workspace).
Without converting my monorepo to a "workspace", things work fine for me. And although I haven't tried it yet, I think using tsconfig path mapping as I suggested above should work.
Do you see any problems with this approach ?
Btw, I'm a big fan of your work. Thanks for all the videos!
Thanks for sharing this video. When I have tried with next js, I couldn't call the getList("Bulb") in the receiver application. Since it showing getList is not a function. Thanks Jack and awaiting your response
You'd have to point me to the project. Next.js has compatibility issues with Module Federation currently.
@@singaravelann3671 There is an issue with how NextJS manages `react` and how it shares components. @scriptedAlchmemy on Twitter (Zack Jackson) found a workaround for this and is working with the team on adding true Module Federation support to NextJS. So I'd contact them to see if they can help or if they have options for you.
Jack, I've watched all your Module Federation videos. Thanks for introducing it! I found them by searching Google about micro frontend. I've been thinking about proposing an architecture based on MF for my work. One question I've had is it possible to version the remoteEntry.js files? Or dynamically reach for different apps? I'm reminded of the A/B video you did, but that requires a loader... Maybe that would be the right approach.
You could version the publicPath, something like `assets.mycompany.com///remoteEntry.js` and then the hosts would specify their remotes with the versions. You could always build for `assets.mycompany.com//HEAD/remoteEntry.js` and then deploy to `assets.mycompany.com///remoteEntry.js` and alias it as the last deploy step.
That's a good idea, I like it and straightforward. I'm going to chew on this. Thanks for the suggestion and all the content!
Is there a way to achieve this without monorepo? my boss doesn't like monorepo :(
There has been some work done to package the .d.ts files as a zip file and publish them along with the compiled JS bundle. Then during compile time to download and unpack the zips locally. I don't think any of that has been packaged up cleanly yet though. It's still a DIY job.
Thank you so much
Hello guys, thank you for the great video.
What do you think about using module federation alongside web components.
No problem. Module Federation just gets the code from one app into another. What that type of code that is, is completely up to you.
hi, is it possible to add/remove plugins modules at runtime (instead of opening 2 servers like your example) so say i can upload a bundle on location /Plugins/PluginA, /Plugins/PluginB and it gets pickedand be available in my application next request... thanks
You can certainly add them dynamically. Removing them is a bit more tricky.
I still dont understand why you wanna use module federation on a dependency like this. İf anything changes you need to adapt that change. Why should i use module federation and import on runtime instead of import on dev time.
The scenario that was critical to me was a large company setting where we wanted to share code and have it all update at the same time without requiring each app to re-build and re-deploy. A good example is a header. If you do the header as an NPM module then to get all the consuming apps to update means a build and a redeploy of each application. With a runtime dependency then all the apps update at the same time.
And yes, there is the downside of possible issues with that new code. But if a run-time dependency is an architectural requirement then that kinda comes with the territory.
@@jherr Thanks that sums up the real need
why do we have to declare the modules?
Because Typescript is running at compile time and this is a runtime dependency. So if you need Typescript to know about the modules then you have to declare them at build time.
One of the biggest problem is that I am unable to use SSR with mod fed when I am not using next.js
Could you please a video of that 🙏
It's definitely on the list of Module Federation topics for videos.
@@jherrThanks Jack🙏. esp. without next.js.
Since most of industry is not using next.js. My company is'nt 😅
@@EE-yv7xg My plan was to riff on the SSR example in the Module Federation examples repo.
@@jherr Yes !!
How would this work after ts compilation/build? My expose is aiming towards a tsx file instead of the compiled version
It won't work. TypeScript support is still an issue with Module Federation.
Ah bollocks! Thanks for the info though bud!@@jherr
I have been trying it some more today and after recreating the test-case and running the npm run build and npm run build:start it actually automatically refers to the ./dest/XXX.js instead of the ./src/components/Widget.tsx. Not sure whether I've just messed up yesterday or whether something changed, but it is now referring to the correct file after compilation/build
@@XFretX Look at the output file, it's JavaScript. That's because the browser can't run TypeScript natively. The only things that can natively run TS are Deno and Bun, AFAIK. So the modules have to be JavaScript.
Indeed, last time they didn't get tossed to the output, now they did. Most be a PICNIC (Problem In Chair Not In Computer) :') Thanks for the tip@@jherr
Has anyone ever told you that you look like the good guy version of Donald Trump?
Not really.
That is exactly what I tought.
lol i think i have a better way by avioding it all togather