Singleton behavior in Federation Runtime

[atamike]

Hi,
I have a question regarding the behavior of Federation Runtime when using singleton: true for shared dependency.

I’m using dynamic remotes, and after upgrading to Module Federation V2, I switched to the Federation Runtime. One of my internal libraries, common-services, is configured as a singleton. Everything works fine unless there is a version bump in the library and the remote app is rolled out before the host app.

Example

Host App → Uses common-services v2.4.0
Remote App → Uses common-services v2.5.0

The host app loads first and uses common-services v2.4.0. Later, when the remote app is loaded via Federation Runtime, the singleton option appears to be ignored, and the remote app ends up using its own instance of the library instead of sharing the one from the host.

I’ve read the documentation multiple times but still can’t determine what I might be doing wrong. I’m concerned that this could be a bug in Module Federation itself.

In the documentation (Shared Module Configuration), it states:

If singleton mode is enabled, the shared dependencies between the remote application components and the host application will only be loaded once, and a higher version will be loaded if the versions are inconsistent. A warning will be given for the party with the lower version.

However, this behavior doesn’t seem to apply to dynamic remotes. Since a dynamic remote may not be available when the host application initializes, the host app doesn’t know about the higher version used by the remote. Based on this, I would expect the host’s lower version to be used, but that’s not what happens.

Is this the expected behavior, or could this be a bug?

Thanks in advance for your insights!

[ScriptedAlchemy]

Do you usare you loading them dybnamically? try loaded-first as shareStrategy instead of version-first