Native federation v4 | RC3! 🎉

[Aukevanoost]

We are back!

Note: RC4 has also been included since it contains some small fixes of RC3

Now that the new orchestrator is available in the v4 repository, this RC is focussed on integrating the orchestrator fully in the new ecosystem! And that includes adding SSE. Furthermore we added some goodies to increase performance (fully opt-in of course).

What's Changed

Core library and Angular adapter

• Added shareScope property in Added shareScope property. #4
• feat: Added 'dense-chunk' feature in feat: Added 'dense-chunk' feature #6
• chore: Update-dependencies in chore: Update-dependencies #9
• chore: Updated artefact to artifact in chore: Updated artefact to artifact #10
• [RC4] Fix failing build caused by concurrent access to externals metadata. in Fix failing build caused by concurrent access to externals metadata. #14
• [RC4] feat: Added support for exposed-modules chunks in feat: Added support for exposed-modules chunks #13

Orchestrator

• SSE Support by in SSE Support orchestrator#2
• feat: Added 'dense-chunk' feature in feat: Store shared chunks in localStorage on init orchestrator#3
• [RC4] feat: Added support for exposed module chunks, and scoped chunks. in feat: Added support for exposed module chunks, and scoped chunks. orchestrator#4

New features

The dense chunking feature is allowing for more compact remoteEntry.json files. But it's more than that, dense chunking allows for more fine-grained control over code splitting in general. The new settings look a bit like this in your Angular.json:

{
	"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
	"version": 1,
	"newProjectRoot": "projects",
	"projects": {
		"mfe1": {
            // [..] other settings
			"architect": {
				"build": {
					"builder": "@angular-architects/native-federation-v4:build",
					"options": {
                        "cacheExternalArtifacts": false, 
						"chunks": { "enable": true, "dense": true }    // <-- Allows for disabling/enabling chunks and switching to dense mode
                    },
					"configurations": {
						"production": {
							"target": "mfe1:esbuild:production"
						},
						"development": {
							"target": "mfe1:esbuild:development",
							"dev": true
						}
					},
					"defaultConfiguration": "production"
				},
				"serve": {
					"builder": "@angular-architects/native-federation-v4:build",
					"options": {
						"target": "mfe1:serve-original:development",
						"cacheExternalArtifacts": true,
						"rebuildDelay": 0,
						"chunks": { "enable": true, "dense": true },    // <-- Allows for disabling/enabling chunks and switching to dense mode
						"dev": true,
						"port": 0
					}
				},
				// [...] Other builders
			}
		},

More info can be found in issue #5.

ShareScope is a feature that allows for shared scopes instead of 1 single global scope. This can be handy if you want to scope your shared externals per framework major as can be seen in the federation.config.js:

import {withNativeFederation, shareAll} from '@softarc/native-federation/config';

export default withNativeFederation({

  name: 'team/mfe1',

  exposes: {
    './Component': './projects/mfe1/src/bootstrap.ts',
  },

  shareScope: "ng20", // set a global shareScope

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' , shareScope: "ng20" }), // also possible per dependency
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
    // Add further packages you don't need at runtime
  ],

  features: {
    ignoreUnusedDeps: true
  }
});

read more on it in isssue #3.

Feedback

This community lives on feedback! Feel free to try out and experiment with the RC3 setup in your MFE ecosystem! An example for a small setup can be found here: https://github.com/Aukevanoost/native-federation-examples-ng/tree/v4

The future

What do you miss in native-federation? The next months you can expect a finalization and refinement of v4 to be prod-ready. We're planning on a big v4 release together with Angular 22. We will also start a central docs website where all (new) features will be explained like dense chunking.

❤️ The native-federation team

[jmleep]

I really love the example you have put together. I'm also very excited for your official documentation site (this will be a huge convenience instead of pointing folks at articles).

A couple of questions:

• A lot of us enterprise users integrate MFEs with mulitple URLs (such as qa or dev environments). This involved me having to build a script that mapped different MFE urls to the environment I was building for. Can you include examples that show how we might achieve this or provide a recommended method in the doc site?
• I have recommended a pattern for my enterprise that involved wrapping the NF remotes with an custom element in order to provide graceful fallback to versions that don't match. Can you include examples of how this will work with v4? Will we still need to wrap with web components?
• Can you also provide examples for where NF remotes are rendered at the route level and then have their own functional (but nested) routing?
• It would also be amazing to have examples that show more of a widget based approach where NF Remotes expose components that are mounted.
• Finally, I would love seeing official recommendations from native federation on how data sharing and event sharing between the host and remotes could/should work. I have a method that involves a generic event bus and typing, but would love to see something more official, especially if applications are using different versions of Angular.

[Aukevanoost]

Hi @jmleep

Great questions! Yeah we're working on a full website with guides, inner working and specs. I hope it will remove some pressure of the Github issues and remove some frustrations for the people implementing the federation!

Most of your questions are actually answered in this series: https://medium.com/@auke997/migrating-a-stateful-monolith-to-micro-frontends-using-native-federation-0572a1e181b4

• This is no paid ad or something, but to answer this personally, we just use the Piral feed service! It does have some quirks but it's pretty robust for this kind of work. https://docs.piral.cloud/general/01-introduction Check out some ideas about this in part II of the article.
• Yes sir! I have some basic basic examples here: Im planning on creating a full-on website example after the v4 migration is done: https://github.com/Aukevanoost/native-federation-examples-ng/tree/v4
• Also kinda in the previous point, let me know if you need anymore examples! Or have specific questions.
• Yess! This is not here yet but I'll definitely put it on the list.
• Right, this is the 4th part of the article series. A little advice to make this fully robust: Use RxJs streams instead of this simple example, you can use the nf-registry as a base though, but then with RxJs streams. Use ESbuild to build all of it in a native ESM js file and load that in your host.

Hope this helps!

[jmleep]

Thanks so much for your fast response, @Aukevanoost!

I read through your four part series and I learned a lot. One thing I noticed was that all of your examples were for vanilla (I can generally determine how to apply this to Angular specifically), but I hope that you can also provide Angular specific guidelines that suggest best practices.

The Piral callout is good, but I doubt my enterprise will have any desire to work with an additional vendor (and pay). It sounds like I might have to continue to maintain my manual scripts for generating the federation manifest entries per env for the host.

Going through your v4 examples, it looks like you still suggest wrapping the MFEs as web components? I notice you have overrides and shareScope as well? I'm not super familiar with theses. Maybe they aren't needed today due to the import maps being keyed to exact versions? I'm assuming that these changes will be thoroughly described/documented. I don't love the idea of the MFE remote having to specifically say they have a different angular version they want to override from the host, when the current implementation just will pull the correct one if it isn't found (no manual override needed), but maybe this isn't possible with v4?

I ended up following a very similar pattern to the loading-shell component you built where mine acts as a remote injection wrapper that takes inputs and loads the remote depending on what is provided. This works well when you have multiple remotes on the same page. This would be a really good pattern to document or provide a component for. Mine takes in the remote MFE name and the remote file (exposed component) then calls loadRemoteModule in the onInit and mounts the custom element to a viewChild. I also inject some dev tools to trigger borders of MFEs (and other stuff like that).

After reading your 4th article, it looks like we basically came to the same conclusion. You called it a registry and I called it an event bus, but it's a window object that allows the host/remotes to subscribe to and publish typed events. Internally mine uses RxJS, but it is a framework agnostic event bus the same as yours. Glad to know I am on the right path!

Thank you again and I hope some one else's perspective helps a little as you build things out!

P.S. are you still on track for a release that aligns with Angular v22?

Jordan

[Aukevanoost]

Glad you liked it! Yeah the series was initially for vanilla js hosts, not SPA's too show the techniques and possibilities as agnostic as possible. But it's also very well possible with an Angular host (as native-federation-examples-ng shows). But we're planning on adding more examples. Manfred also has loads of examples: https://github.com/manfredsteyer/nf-test/tree/main/projects

The Piral callout is good, but I doubt my enterprise will have any desire to work with an additional vendor (

About Piral, yeah there is no good and bad here so whatever works! They did nail the distribution of micro frontends very well so maybe this article from Florian might help?

Going through your v4 examples, it looks like you still suggest wrapping the MFEs as web components?

I really do, a core mechanic of micro frontends is separation of concerns and independent deployability. You want your micro frontends to be as agnostic and independent as possible.

Overrides are really easy actually, they allow you to set specific settings for a specific dependency, e.g. a big feature of native-federation is ignoreUnusedDeps which removes all dependencies and secondary entrypoints that your micro frontend doesnt need. with Angular/core you might not want to remove secondary entrypoints since you want to share 1 version of Angular, otherwise you get the possibility of angular/core being loaded from mfe1 and angular/core/rxjs-interop being loaded from mfe2. This creates a "scope tear" where 2 angular/core's are loaded. We can easily avoid this with a small fix in the federation.config.js, only for angular/core:

  shared: {
    ...shareAll(
      { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
      {
        overrides: {
          // includeSecondaries is an opt-out of ignoreUnusedDeps, so all of
          // @angular/core is shared to prevent mismatches.
          '@angular/core': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package', includeSecondaries: { keepAll: true } },
        },
      },
    ),
  },
  features: {
    // ignoreUnusedDeps is enabled by default now
    // ignoreUnusedDeps: true,
  }

And shareScope is a bit of an advanced feature but soo cool. It creates a bucket of dependencies in the browser, so every micro frontend that matches that shareScope, will share the dependencies of that shareScope. Like this: When you have 20 micro frontends, and you want to gradually migrate from ng20 to ng21, you can start by adding shareScope: "ng20" to all micro frontends, then migrate them one by one. Whenever you migrate a mfe, you change the shareScope to shareScope: "ng21". This way, all 21 micro frontends share dependencies with eachother and all 20 mfe's share dependencies with themselves, avoiding that mfe's get the wrong shared dependencies. We totally stole that from module federation.

I'm assuming that these changes will be thoroughly described/documented. I don't love the idea of the MFE remote having to specifically say they have a different angular version they want to override from the host, when the current implementation just will pull the correct one if it isn't found (no manual override needed), but maybe this isn't possible with v4?

Yessir, here are the docs: https://github.com/native-federation/orchestrator/blob/main/docs/version-resolver.md. I dont really get what you mean with the second sentence though. You can easily get the classic behavior or stay with the classic runtime if you prefer! Or just use shareScope: "strict" to get the same behavior. The only reason why we share dependencies among acceptable semver ranges is for performance, this way you have to download less JavaScript. How liberal you want to share your dependencies is entirely up to you 🎉

I ended up following a very similar pattern to the loading-shell component you built where mine acts as a remote injection wrapper..

That sounds great! I am working on an angular-examples repo, feel free to share whatever you're comfortable with! We're a community! I'm glad you reached out and if you ever want to discuss something, you're more than welcome to in this space!

P.S. are you still on track for a release that aligns with Angular v22?

Yes! The orchestrator and core are already stable. Angular is technically also stable, but we want to release it together with ng22 so that we release it in a time where people already expect big changes, this way everyone can upgrade the whole setup all at once :). The only big todo's in the Angular adapter are "SSR" which doesnt work yet, and I am experimenting with a new more performant slim builder. But both are IMHO not a deal-breaker for the v4 release.

So we are good to go! Feel free to try the last version and see what you think! All feedback is welcome.

Update!
Docs are live! https://native-federation.com/index.html