Critical Limitation in Native Federation for Resolving Shared Dependencies

[victoraf-11]

For which library do you need help?

native-federation

Question

We are experiencing a significant limitation when using @angular-architects/native-federation in a microfrontend environment where the same remote (microfrontend) is reused across multiple host applications.

In our setup, we use reusable microfrontends. The same microfrontend is integrated into different host applications within the company, and these applications may have different Angular 19 (19.x) versions.
When migrating to Native Module Federation, we have encountered a critical limitation in the resolution of shared dependencies between the host and the microfrontend. This affects all libraries or dependencies that the microfrontend may require, not just specific cases.

This issue is critical because it restricts the reuse of microfrontends in independently evolving applications and could become a blocker in real integration scenarios.

In this PR, there is a suggestion to temporarily use a library as a workaround: PR-645 comment

Within our team, the following question arises: is reusing microfrontends across applications considered a bad practice?
We understand that there is a strong relationship between Angular version and a microfrontend, which is why we only reuse a microfrontend among applications with the same Angular version. However, other dependencies may still conflict.
Not having the ability to negotiate a shared dependency using requiredVersion, strictVersion, etc., is a major limitation for our current use of microfrontends as shared components across applications.

[Aukevanoost]

Hi @victoraf-11

I read multiple questions here, and I'll try my best to answer them:

Within our team, the following question arises: is reusing microfrontends across applications considered a bad practice?

Yes but also no, it really depends on your architectural setup. The most important part is organizational. I think Luca had a nice article about it in his newsletter. The real question is, can you isolate the functional (ddd) logic of the mfe in a way that it has little coupling with the other parts of the app? so that you can deploy and maintain it independently without too much struggle? then in my humble opinion you're good.

Not having the ability to negotiate a shared dependency using requiredVersion, strictVersion, etc., is a major limitation for our current use of microfrontends as shared components across applications.

I understand and my current advice is here.

In our setup, we use reusable microfrontends. The same microfrontend is integrated into different host applications within the company, and these applications may have different Angular 19 (19.x) versions.

This is fine, but do note that Angular can add breaking changes to patch versions. So, if your hosts have different Angular versions and you share the Angular from the host, technically the remote can behave differently in the hosts since every host gives a different angular build to the remote. If that makes any sense.

Hope this helps with your questions.

[victoraf-11]

Thanks a lot, @Aukevanoost. That was very clarifying.

The real question is, can you isolate the functional (ddd) logic of the mfe in a way that it has little coupling with the other parts of the app? so that you can deploy and maintain it independently without too much struggle? then in my humble opinion you're good.

Regarding your point about isolating the functional logic of each MFE: in our case, we actually try to follow that principle as much as possible. That said, we’re aware of the risks involved in using libraries with different versions, but we’re willing to assume that responsibility, as long as the architecture allows it and remains sustainable.

Otherwise, as I mentioned earlier, perhaps our current approach isn’t conceptually correct and we may need to reconsider it. But we’d like to make sure we’re heading in the right direction before making such a major change to our architectural design.

I understand and my current advice is here.

After reviewing the solution you suggested (and let me take the opportunity to congratulate you on the impressive work you’ve done), I must say it looks like a very robust approach to the problem we described.

Still, after going through the documentation and several articles, one doubt remains.
As far as I understand, the vanilla-native-federation library acts as an extension on top of native-federation, providing a more flexible orchestration of dependencies, similar to how Webpack’s Module Federation handled this back in the day.

However, there seems to be a deeper issue related to the generation of the remoteEntry.json.
In a polirepo setup, everything works perfectly. But in a polyrepo or a monorepo setup where some libraries are part of the same workspace (at least during the development stage) we’re facing versioning issues.

It seems that native-federation or esbuild (I’m not entirely sure which) when it doesn’t find the dependency in package.json, or when custom paths are defined in tsconfig.base.json ends up overwriting any configuration defined in federation.config.js, setting empty strings ("") as requiredVersion and version for those internal libraries.

As a result, vanilla-native-federation cannot properly resolve those dependencies.
I’m not sure if you’re already aware of this limitation, or if we might be missing something in our setup.

Lastly, given your expertise, I’d like to ask whether you see any feasible way to make Webpack-based microfrontends interoperable within an esbuild-based host application.
I’ve read a few things about it but haven’t explored it in depth yet.

Thanks again for your time and insights!

[Aukevanoost]

Hi @victoraf-11,

Appreciate the feedback! I'm glad you like it.

Otherwise, as I mentioned earlier, perhaps our current approach isn’t conceptually correct and we may need to reconsider it. But we’d like to make sure we’re heading in the right direction before making such a major change to our architectural design.

I completely understand, but on the bright side, the answer is never absolute. It really depends on your personal usecase. Loads of people would prefer a polyrepo setup since it provides more guarantees for isolation and less chance of accidentally creating coupling between the micro frontends.

Still, after going through the documentation and several articles, one doubt remains.
As far as I understand, the vanilla-native-federation library acts as an extension on top of native-federation,

Yes! to clarify, modern micro frontend solutions contain an orchestrator and a builder. The vanilla-native-federation library is a complete rebuild of the default native federation orchestrator (called native-federation-runtime).

It seems that native-federation or esbuild (I’m not entirely sure which) when it doesn’t find the dependency in package.json, or when custom paths are defined in tsconfig.base.json ends up overwriting any configuration defined in federation.config.js, setting empty strings ("") as requiredVersion and version for those internal libraries.

Yes that's true, vanilla-native-federation does convert the empty versions to "0.0.0" if I recall correctly but I can double check.

Lastly, given your expertise, I’d like to ask whether you see any feasible way to make Webpack-based microfrontends interoperable within an esbuild-based host application.
I’ve read a few things about it but haven’t explored it in depth yet.

This is an "it depends" answer, the short answer would be yes! but with some drawbacks. Manfred demonstrated in his article how you can combine native federation and module federation in 1 setup, but note that this works because they work fundamentally differently. That way, they don't touch eachother and can co-exist. This is no different with vanilla-native-federation.

Piral created an orchestrator called Picard.js which can actually combine the paradigms, however they work with systemJS which again is fundamentally different than our import-map setup. Besides they re-integrated the default native-federation-runtime logic so you're losing the dependency resolver of vanilla-native-federation.

Now, again, I can't make any promises but recently I've received the role as collaborator to help a bit where I can around native federation, and we're trying to bring the 2 projects together. I could see if it's possible to append versions to sharedMappings to make them work similar to externals, but I'm not quite sure yet how to implement requiredVersion.

[Aukevanoost]

Update!

It seems that native-federation or esbuild (I’m not entirely sure which) when it doesn’t find the dependency in package.json, or when custom paths are defined in tsconfig.base.json ends up overwriting any configuration defined in federation.config.js, setting empty strings ("") as requiredVersion and version for those internal libraries.

I checked the versioning thing and actually there is apparently a feature in native-federation that allows nf to take the version from the internal library's package.json as version for the library.
here: https://github.com/angular-architects/module-federation-plugin/blob/2bc88a0567994a1a7879e417f546467c157c9e89/libs/native-federation-core/src/lib/config/federation-config.ts#L20C1-L31C2

It would look a bit like this:

const {
  withNativeFederation,
  shareAll,
} = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: true,
      requiredVersion: 'auto',
    }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
  ],
  sharedMappings: ['@my/internal-lib' ],

  // Please read our FAQ about sharing libs:
  // https://shorturl.at/jmzH0

  features: {
    mappingVersion: true,
    ignoreUnusedDeps: true,
  },
});

Now I did find out that vnf assumes that the requiredVersion is always set, what I can do is infer the requiredVersion from the version just like the version can be inferred from the requiredVersion!
https://github.com/topicusonderwijs/vanilla-native-federation/blob/face99b6fede8044f3db49e21d42952cfeaa0d54/src/lib/2.app/flows/init/process-remote-entries.ts#L93C1-L94C92

edit, check PR: topicusonderwijs/vanilla-native-federation#120

[Aukevanoost]

Closing this issue for now, feel free to create a new one or reopen if you have anymore issues/questions

[victoraf-11]

Thanks again, @Aukevanoost. All the information you’ve shared has been incredibly helpful.

I checked the versioning thing and actually there is apparently a feature in native-federation that allows nf to take the version from the internal library's package.json as version for the library.

Honestly, I don’t know how I missed that detail about retrieving the version from the internal library’s package.json. I checked it, and it works. Thank you so much for pointing it out!

Your explanations have really helped me understand the internal behavior of native-federation and vanilla-native-federation much better. It’s great to see how both projects are evolving, and I appreciate the time you’ve taken to explain everything in such depth.

Wishing you all the best in your new role as a collaborator on native-federation. I’m sure your contributions will make a great difference to the community.

[victoraf-11]

Hi @Aukevanoost,

Sorry for reopening this issue, and please let me know if this question would be more appropriate to open in the vanilla-native-federation repository instead.

I have one more question related to dependency resolution in vanilla-native-federation.

Is it possible to give priority to the version of a library that comes from the remote (microfrontend), so that the host uses that version instead of its own?

The goal would be to have only one shared instance of that library, but with the version coming from the remote.
That way, when the microfrontend is updated (for example, with a newer version of that library), the host could automatically use it without needing to be rebuilt.

I’m not sure if this kind of “remote-first” dependency resolution is currently supported or could be achieved through configuration.

Thanks again for your time and help.

[Aukevanoost]

Hi @victoraf-11

No worries, and this is unfortunately not possible but by design.

Remotes are volatile by design, you should be able to disable, hotswap, or remove remotes without the application breaking. Which ties into the whole "as little coupling as possible between remotes". Now it is true that this creates some kind of non-determinism since you can't really know which dependency is loaded. My advice? try to share as little state as possible between micro frontends and stick to event-based communication like an event-bus for inter-micro-frontend communication:
src: https://medium.com/@auke997/part-iv-robust-communication-between-micro-frontends-within-native-federation-5f9282ecc727 (me)
src: https://lucamezzalira.com/category/micro-frontends/#micro-frontends-communication (luca)

Now to deal with the non-determinism, there are some tricks. If you want to enforce a certain version being used, you can leave it up to the host docs. If you define a hostRemoteEntry, that external will take precedence over all other dependencies, guaranteeing that (as long as the requiredVersion is compatible and the version is "singleton"), the micro frontend will receive that particular external, allowing state sharing.

Why? Because this allows the host to be in control of cross-cutting concerns, the host is way less volatile and more consistent , hence it makes more sense that the host is in control of state. Do note that the "as little coupling as possible" is still relevant here to provide autonomy to your development teams. You dont want your host to break because it's missing state from the remote or because random distributed pieces of code are altering your state. In this architecture, the remote is a "guest" on the host's page.

Hope this clarifies the matter. I do understand the question though.
Manfred also had a nice video about the boundaries concept: https://www.youtube.com/watch?v=FQ4noDp_AGI

[victoraf-11]

Thanks a lot, @Aukevanoost. That makes perfect sense.
In the end, ensuring the stability and consistency of the host is definitely the most important thing.

My question came up mainly because, in Webpack Module Federation, it was possible to resolve dependencies in the “remote-first” way I mentioned. But this design choice in vanilla-native-federation actually clarifies a lot for our team. It helps us understand the architectural direction we should follow moving forward.

I really appreciate all the information you’ve shared, along with the links and Manfred´s video.
Your responses have been incredibly detailed and quick, and they’ve helped me a lot in understanding how things work under the hood.

Thanks again for all your help, and I wish you the best in your work with native-federation and the community!