Native federation is moving!

[Aukevanoost]

Hi all!

2025 marked an important milestone for Native Federation, the last couple of months have been dedicated to improving the performance and robustness of the native federation ecosystem. This year will be no different when we enter the maturing stage. Therefore we're proud to announce the moving of Native-federation to its own Github organization which can be found here: https://github.com/native-federation/

What does this mean?

This means that this repository (native federation v3) will transition to a maintenance state. It will only be used for security updates and patches, new features can be requested in the new v4 repositories.

What changed?

The v4 release allows us to do some (really needed) internal refactoring. We broke the ecosystem up into 3 repositories:

• https://github.com/native-federation/native-federation-core
• https://github.com/native-federation/orchestrator
• https://github.com/native-federation/angular

Secondly, the new major version allowed us to modernize the stack to a more up-to-date setup! So we moved some things around!

• The new orchestrator is now supported! It still needs a bit of love (no SSE yet) but it works flawless with the NF ecosystem. And it supports dependency sharing 🎉
• All packages are now fully ESM! This is a breaking change in the federation.config.js, check the new syntax here: https://github.com/Aukevanoost/native-federation-examples-ng/blob/nf-beta/projects/mfe1/federation.config.js
• We've moved around some types, They're all still there but some might be renamed:
  • BuildAdapterOptions -> NFBuildAdapterOptions
  • BuildAdapter -> NFBuildAdapter
  • BuildResult -> NFBuildAdapterResult
  • Renamed all config objects to be a bit clearer: Check the diff
  • We updated the runtime processRemoteInfos -> fetchAndRegisterRemotes
  • the core library is not dependent on the runtime anymore, but the other way around. Types from the runtime have been moved to core.
  • We added some fine-grained secondary entrypoints/barrel files to the core library like /domain for all interfaces and contracts and /config for all "config" related services.
  • All the renames and contract changes can be found in the commits native-federation@ce1f64c and native-federation@acbf811
• Removed the deprecated "transient" flag. native-federation@91a1040

We need feedback!

We uploaded some versions and new libraries to support the v4 ecosystem! Please play around with it, try different things. For now we only uploaded the core libraries but more will follow!

  "devDependencies": {
    "@angular-architects/native-federation-v4": "^21.1.0",   // To test the Angular builder
    "@softarc/native-federation-orchestrator": "4.0.0-RC1",  // The new orchestrator!
    "@softarc/native-federation-runtime": "4.0.0-RC1",      // The current runtime in v4
    "@softarc/native-federation": "4.0.0-RC1",               // Native federation v4
  }

However, you can also see an example pre-built repo here: https://github.com/Aukevanoost/native-federation-examples-ng/tree/nf-beta

When is the full release?

T.B.A.

Any other questions, findings and feedback would be great so we can make the migration as smooth as possible!

[rainerhahnekamp]

Great, my question would be, why do we put the Angular part into a separate repository?

I think it could be cumbersome in terms of DX. Most tasks in NF center around Angular so we will probably have some changes which require modification in both repos at the same time?

[Aukevanoost]

Hi @rainerhahnekamp ! Great question.
I do think that this doesn't have to be the case (being Angular-first). Having the Angular builder in the core repository opens the gates for an builder that is specifically for angular. Although we provide first-class support for Angular, this limits our ability to expand to other frameworks like React or Vue or even vanilla JS.

[rainerhahnekamp]

Having the Angular builder in the core repository opens the gates for an builder that is specifically for angular.

Sorry, I don't understand. With the native-federation, the Angular build would be outside of the core repo, right?

this limits our ability to expand to other frameworks like React or Vue or even vanilla JS.

Well, the mono repo would have a huge list of dependencies. That's for sure. I would give it a try and if it doesn't work, you can always do the split up.

Since you do most of the work, you will be the one who is most affected by it. And as I said, I think you are faster if you everything in one repo.

I guess it is up to you.

[Aukevanoost]

Thanks for the feedback, I suppose the amount of dependencies is not particularly the issue.

Sorry, I don't understand. With the native-federation, the Angular build would be outside of the core repo, right?

What I mean is that if the Angular adapter is next to the core library, it allows for easier creation of coupling and allows for incorporating Angular specific logic into the core library which might harm the overal architecture. (in my opinion). Separating the 2 components completely (the core builder and the Angular adapter) allows for a clear hard boundary that shows which part is Angular specific and which part the core. I know it's a high ambition but Angular changes should in fact not alter the core library.

Having this decoupled boundary allows for a core that is easier to manage and reuse for e.g. a React adapter which can be a separate repository. Because we see the 2 components completely separate from eachother.

I'm not saying that a monorepo is wrong, I think it's great for clustering domains. But I personally feel that this setup is more robust for the ecosystem. Just like how Angular has multiple monorepo's like "angular" and the "angular-cli".

Now I do believe that this is a matter of taste and this might be a bit more work in the long run. I personally believe that there is a strong correlation between code size, complexity and maintainability. I'm happy to expand your concerns in a separate Github discussion to see how the community feels about this. And I appreciate that you brought this up!

[rainerhahnekamp]

Because you mentioned Google... they actually have a monorepo internally...

But yeah, all good. As I said, you are doing the main work, so the decision should be yours.

[bh3605]

Is it too late for me to request @angular-architects/native-federation to support the sharescope option so I can utilize this property in the vanilla-native-federation package?

[Aukevanoost]

@bh3605 Actually! It's in the third release candidate of Native federation v4! (RC3) Have a look here:
https://github.com/orgs/native-federation/discussions/11

[bh3605]

Cool! One of our teams updated a patch version of Angular and that started hurting one of our other MFEs and I had read setting the sharescope to strict would help resolve this. Is the current RC set to be compatible w/ Angular 20 or 21?

[bh3605]

Also will this new native-federation package have feature parity with vanilla-native-federation? My root app uses vnf the loading MFEs while the MFEs use aa/nf for doing the module federation.

[Aukevanoost]

We're planning on providing some backwards compatibility. Currently the v4 Angular adapter is usable for ng20.3 and ng21:
https://www.npmjs.com/package/@angular-architects/native-federation-v4?activeTab=versions (Disclaimer: the v4 package is currently only for beta testing and not prod ready)

Parity with vnf is a partially yes. Once v4 is released, vnf will be deprecated and eventually EOL since the v4 orchestrator is a fork (and continuation) of vnf. This to keep all in the same ecosystem. Find it here: https://github.com/native-federation/orchestrator