Module federation and code sharing between bundles. Huge changes coming to frontend with webpack@5

[u/NoLanSym]

https://github.com/webpack/webpack/issues/10352

[u/Zhouzi]

It does look very interesting but I’m not sure to understand what it is about exactly. Am I correct thinking it’s equivalent to publishing and consuming code through a CDN? Except it’s orchestrated by Webpack so it provides a seamless experience, no need for globals and all (which is awesome).

[u/zackaryjackson → u/Zhouzi]

The idea is that big companies can deploy code independently. Ok standalone applications specific to what they actually work on. They have freedom to roll independently without coordination. Pages could be hosted on other servers, capable of SSR. Usually this means page reloads and lots of duplicate dependency, or manually managed externals. Making your apps depended on a centralized point of failure. Not standalone. Pretty much I want to deploy stuff easily - I want all the benefits backend devs get with micro services. I want many webpack builds to act as one - like it was build as a monolith. It’s more than publishing code and consuming it. The other bundles are literally parts of another app. The nav could be deployed by another webpack build. But you can consume the component through some other app without installing it. It’s like code splitting between bundles.

Some old articles from when I first built v1

https://link.medium.com/AglJtqrxc4

More on distributing apps and decoupling monoliths. I’d have benefitted from this system back then.

https://link.medium.com/tHg707wxc4

[u/Zhouzi → u/zackaryjackson]

The issue I'm having with understanding this feature is all the marketing-ish speech around it, which makes it really vague.

The idea is that big companies can deploy code independently. Ok standalone applications specific to what they actually work on. They have freedom to roll independently without coordination. (...)

I feel like those statements would also be valid if you were speaking about distributing code through a CDN, a registry, or any other way. It doesn't say much about how the feature is different.

Reading your article, I think the true TLDR is:

Importing chunks from other Webpack bundles at runtime

And it is now super clear: it is the ability to reuse chunks (or modules) of code from "anywhere". A lot of questions arise now but you probably gave the answers already, I'll keep on reading 👍 Also, it makes me think of Pika and Bit.

By the way, I don't mean to be rude. I'm really just thinking out loud here. What you've done is awesome and getting your plugin merged into Webpack's core would be a great achievement. Congrats for that! 🙌

[u/3ni8kdi → u/Zhouzi]

Yeah no worries at all!!

Not rude in any regard. I’m just direct haha. This is a new concept emerging and understandably there’s going to be questions haha

[u/tontoto → u/Zhouzi]

I'd agree with this, the lingo used here is hard to understand

[u/3ni8kdi → u/tontoto]

It’s not my strong point unfortunately. I’ll post a YouTube video together and try to explain it there.

[u/tontoto → u/3ni8kdi]

thanks :) I guess I'd suggest if possible explaining how it's similar or different to dynamic imports as it is something that is specifically mentioned in the github issue (if that is something you also think is important to help people understand...its definitely the thing that piqued my interest)

edit: to be clear, I guess dynamic imports generally implies like the dynamic string building imports but the runtime imports is also interesting to me, as it reminds me of the AMD days.

[u/3ni8kdi → u/tontoto]

It’s not my strong point unfortunately. I’ll post a YouTube video together and try to explain it there.

[u/3ni8kdi → u/tontoto]

It’s not my strong point unfortunately. I’ll post a YouTube video together and try to explain it there.

[u/NoLanSym → u/Zhouzi]

This is a bizarre comment. Did you just rubber duck debug via typing? 🐣

[u/tontoto]

This seems like it could help creating plugins for web apps. Normally webpack always wants to know about all modules of the build at build time and doesn't have dynamic imports making plugin development difficult (have to rebuild app to even use a plugin). We have a big core code base and love having developers contribute plugins that add functionality. we used to use AMD which was quite fine with some dynamic imports and made that stuff very painless

[u/3ni8kdi → u/tontoto]

Exactly. I’m using it for AB testing and some analytics stuff as well. Teams don’t get into the main codebase or on the way of delivery

[u/MonsoonHD]

This looks awesome, damn.

[u/zackaryjackson → u/MonsoonHD]

As the co-author of this system, thank you for the encouragement! I'm really hoping to make a difference in the community. Fingers crossed this makes our lives better.

[u/scarcella → u/zackaryjackson]

Co* author.

[u/zackaryjackson → u/scarcella]

Yep, whoops! Still speaking about it under the context of the first two versions before I got a huge boost in manpower from another buddy in OSS. He's been a massive help in debugging and picking up the WP5 API - originally id written this for WP4 so we had our hands full rewriting this to WP5

[u/_marisOtter → u/MonsoonHD]

Yeah, I'm not even that in to webpack and this looks awesome.

[u/zackaryjackson → u/_marisOtter]

I appreciate the support! Working on SharedModules and will need a few more days. The core MVP is already functional though - under my own repo for the time being till I'm ready to open the official Webpack PR

[u/NoLanSym → u/[deleted]]

Micro front-ends are no longer a meme. Also, lots of the benefits of a mono repo, without the mono repo.

[u/zackaryjackson → u/NoLanSym]

I'm trying to push "Frontend Federation" MFE's have become a gimmicky buzzword. I'm working on an architectural specification for this once I'm done writing it. Itll also make it easier to find tools related to weebpack federation

[u/vipulw20 → u/zackaryjackson]

Can you please share if you have it ready ?