You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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:
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!
Beta Was this translation helpful? Give feedback.
All reactions