Webpack 5 Module Federation API will be a game changer to the web.
So bringing support to Angular CLI once Webpack 5 is released and supported will also be a game changer to Angular projects using the CLI.
x
)
Once Angular CLI support Webpack 5 #17555 it is important to also support its new API called Module Federation that allow sharing modules in runtime among applications.
Support Webpack 5 Module Federation.
No alternative considered.
Let me know if there is any assistance needed on Module Federation
Any news about Webpack 5 in the CLI?
@jpchavat #17555 tracks specifically the support to WebPack 5, this issue is only related to Module Federation.
But I don't believe we will see support to WebPack 5 in Angular CLI before it is released. https://github.com/webpack/webpack/releases
Should we make progress towards it, perhaps on a pre-release branch. While maybe not a stable release to the public, I鈥檝e been working with other large projects who are working on the upgrade paths and if any issues are uncovered, we are able to address them at webpack ahead of the full release. Feedback from large projects is very valuable - W5 has been very stable.
Can anyone please share what specific impact and improvements it can bring in case of Angular applications?
I can weigh in here after being part of a POC for an Angular upgrade on a massive group of applications (which most of us probably use regularly).
Regarding module sharing, several contacts have confirmed that they are lazy-loading their feature modules by referencing their import statements. A huge list of them... (import mapping)
When it comes to architecting shared modules _federation_ is not trivial, it is the correct tool for the job. Now when you extend this architectural need to sharing ACROSS applications we require specific tooling for this, not just a "bag of tricks".
Additionally, the way WP5 "shares" packages across these modules is super pro.
For large-enormous projects WP5 is not a nice-to-have, it will be a difference-maker. I implore the Angular team to make this happen ASAP even asking the community for help if needed.
It stretches beyond angular apps to the JS ecosystem.
Attempts to split up applications but still share resources has always been cumbersome and clunky.
Angular apps would be able to scale beyond organization and deploy limitations. Since Angular is a framework, you're well positioned to leverage the new architecture for the best benefit of users.
Many large companies are crippled by scale issues and the overhead of trying to manually manage some form of organizational scalability around their codebases.
The capabilities that module federation brings to the table are an absolute must for any organization with a lot of code that wants to reduce management complexity and improve user experience while maintaining team autonomy.
I too am willing to help with the integration. It opens doors to build much bigger apps and the sharing mechanics is top tier.
The scale I typically with within is dozens to hundreds of teams or apps that all need to share or work together. Some of my largest systems I designed module Federation to cater towards have a header bar that consists of 15 separate teams with about 20 devs per team.
At any given point I can have 5-30 micro-frontends powering a given view.
The key point here is that module federation enables us to require code from independently deployed apps at runtime. And it's something we need
Zack, I'm glad we are having the same experience(s) architecting modules/components across apps @ScriptedAlchemy.
I hope this is not a debate but rather community interest in how engineers will utilize WP5's federation tools. That being said I must insist that small projects who setup for lazy-loading (without the router) are being forced to use import mapping, that is listing the paths and import statements for each module the app may lazy-load.
import mapping our modules is painfully antiquated and as Zack Jackson brought out it needs to be remedied for all JS usage. But here we bring our experience to the Angular community/team.
Any news on branch or official fork with webpack 5 ?
@clydin has been working on adding initial support for Webpack 5.
Unfortunately, supporting Webpack 5 is not a trivial feat as there are a lot of breaking changes that we need to address while still maintain comparability with Webpack 4.
Soon as a branch is up. Even broken, I can provide some guidance. I've upgraded several community projects to webpack 5 and have rewritten many plugins over the past several months.
Upgrading is complex. But we were able to do so with next js, through a lot of updating. Next still remains WP4 and WP5 compatible.
Hi, thanks a lot for your work, I would like to ask if there's any news about the module federation support or if there's any workaround to work with WP4?
@AbdoDabbas workaround is to use this fork https://github.com/clydin/angular-cli , build it and use built version as a dependency
You may need to do the same with https://github.com/just-jeb/angular-builders/tree/master/packages/custom-webpack , there need few fixes
Then add ModuleFederation in extra webpack config
@clydin has been working on adding initial support for Webpack 5.
Unfortunately, supporting Webpack 5 is not a trivial feat as there are a lot of breaking changes that we need to address while still maintain comparability with Webpack 4.
I'm too noob to understand. why would the new version of angular / angular ClI need to be retro-compatible with Webpack 4?
I understand that that's a nice to have but isn't the implication with a user upgrading to the new angularCLI that he's not personally depending something that depends Webpack 4 and if he is it's up to him to fix that and until then stick with the old version of Angular CLI ?
The reverse problem arises from holding back an angular-cli release because it breaks retro-compatibility with an external dependency (that, I'm pretty sure no typical use-case dev will directly depend in their package.json)
Again I'm fine with if we do support retro compatibility. If it holds Angular-CLI back for months on end, though then I find that motive unjustifiable.
Dual support isn't really hard to provide. It's more the work to update loaders. Then parse current installed version of webpack. If it's v5, have conditional require statements that either import the v4 loader or the v5 update.
Next runs like this, almost every loader or plugin I've upgraded has v4 support. Only real work is updating internal code to support the v5 hook api.
Experimental opt-in support for Webpack version 5 have been added since v11.0.0-next.3.
See https://github.com/angular/angular-cli/pull/18820 for more information.
At the moment this is still opt-in and shouldn鈥檛 be used for production builds, as certain Webpack plugins and loaders don鈥檛 yet work properly with Webpack 5.
That said, this issue is not about Webpack 5, but rather provide module federation support which does require Webpack 5 but is a different topic, so let鈥檚 please keep the discussion in this thread on module federation.
Got it will do!
I'm also working on a update to the webpack runtime. Which changes how apps start up. This would remove the async broundary required by mobile federation. And move it into the startup module direct in webpack
For anybody who are interested, created an example of Angular 11, Webpack 5 Module Federation and @angular-builders/custom-webpack
(to opt-in with this one - need more resolutions
):
https://github.com/ydmitry/angular11-webpack-module-federation-custom-webpack-builder
We also have one under module federation examples. Consider PRing yours into it as well. We do need more non react examples for users
@ScriptedAlchemy didn't see it before, it's a new one, thanks! https://github.com/module-federation/module-federation-examples/tree/master/angular11-microfrontends
@ScriptedAlchemy Hi! May I ask, did u experience serious performance degradation on serve after switching to W5?
My app takes 20-30 sec in hmr mode on any change to rebuild and serve using webpack 5... Remove it from the resolutions and its back to 2-3s...
Thanks in advance!
I could see lots of potential problems coming out of attempting to support this on the angular side.... (I'm by no means an expert on its inner workings), but I think if angular supported module federation, that could potentially revolutionize building and sharing components, and would definitely breathe new life into a code base.
Most helpful comment
Soon as a branch is up. Even broken, I can provide some guidance. I've upgraded several community projects to webpack 5 and have rewritten many plugins over the past several months.
Upgrading is complex. But we were able to do so with next js, through a lot of updating. Next still remains WP4 and WP5 compatible.