Runtime init and loadRemote methods are contain different remote (FederationInstance) when trying load exposed module

[satheesh66]

Describe the bug

Hi,
I have using module-federation/runtime ,

I am trying to load the remote and then trying access the exposed module , here my host is main

when invoke loadRemote method the FederationInstance is not holding main instead it holds other remote that is previously loaded because of the condition in @module-federation/runtime's init method in line number 1684, since we declared the FederationInstance variable outside of the init and loadRemote method's scope, so it holding previous remote.

if i change the condition to if(FederationInstance !== instance) it's working as expected,

Reproduction

Used Package Manager

npm

System Info

Os : Mac os sonoma 14.1.2,
Browser : Brave

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[ScriptedAlchemy]

@2heal1 any comments about this?

[zhoushaw]

@satheesh66 Can you describe the problem with reusing a global instance？

[satheesh66]

@satheesh66 Can you describe the problem with reusing a global instance？

we trying to use runtime plugin as hybrid mode
we are injecting promises(promise based dynamic imports) for some services in build time and loading some services using runtime plugin

in this approach when i trying to invoke init with host for some remote service the federation instance already holding previously loaded remote(via promise) instead host

@zhoushaw

[satheesh66]

I need some clarification
when i invoke init method from service remote1 the FederationInstance is holding remote1 service options, i am only able to call init from host service , is this expected?

I am triggering init and loadRemote from other services(not from host) in this scenario FederationInstance is not taking up the host instance, it holds remote container instance which is where we triggering init. so that loadRemote unable to return the module.

@zhoushaw @ScriptedAlchemy

[satheesh66]

any update on this? @zhoushaw @ScriptedAlchemy

[zhoushaw]

@satheesh66 I'm sorry I didn't understand what you meant. Can you provide a warehouse? How should the normal performance be

[ScriptedAlchemy]

Ahh i see, @2heal1 @zhoushaw i think what he means is re-init with new options does not merge the options together

[satheesh66]

Ahh i see, @2heal1 @zhoushaw i think what he means is re-init with new options does not merge the options together

yes, when i trying to invoke init from remote services i can't get the FederationInstance as host instead i get the remote service's instance which is were i call init from

@2heal1 @zhoushaw @ScriptedAlchemy

[2heal1]

Yes , currently , if you invoke init many times , it will merge all options except remotes and plugins .

remotes and plugins will check whether it has been registered by the identifier name .

[2heal1]

In this case , you want to update the remote entry which has been registered before ?

@zhoushaw @ScriptedAlchemy Should we allow users to merge remote instead of skip ? And how about adding registerRemotes api to help users register remotes quickly instead of calling init again ?

[2heal1]

registerRemotes can allow override existed remote .

registerRemotes: (remotes: Remote[], override?:boolean) => void;

interface Remote {
  name:string;
  entry:string;
  override?: boolean
}

But I'm not sure if we are allowed to control whether a single remote can be override.

Maybe it's enought that we just add override to all remotes.

@ScriptedAlchemy What do you think?

[ScriptedAlchemy]

{init,registerRemote} from runtime?

something like that could work, but be warned - sideloading remotes after federation is already initalized the "initial" remotes it had, if you add more remotes later, the already initalized containers from app startup cannot "see" updated share scopes as they are already running and using shared modules.

So i agree we need a way to add more remotes to federation, BUT be warned that there are race conditions that can occur.

For example

You have 3 remotes. A, B, C

A is the host
You start on /home, Home (A) import B/button.
You go to /about, A imports C (lazy / dynamic remote injection(, C imports someting else that needs Redux - singleton
You go to /other, which uses B again, and this page also needs redux singleton.

App will fail because B was init() with share scope that existed, A's share scope, B cannot see what new shared modules C added because B was "sealed" already

When you loaded C, it added redux but B cannot see that because it was already inialized with the share scope known at that point in time. So it will load another redux copy.

[ScriptedAlchemy]

Okay we are adding a new api for addRemote

It should do what you want.

[2heal1]

Okay we are adding a new api for addRemote

It should do what you want.

Yes , the conclude as follows:

• init can not merge remote , even if the remote not loaded . Because we want to make data track more easier.
• add new api called registerRemotes , it is used for add new remotes , and it will have a param called force , if users set force: true, it will merge remote(include loaded remote) , and console.error to tell users this action may have risks

I will open a pr for this feature during the following days

cc @zhoushaw

[ScriptedAlchemy]

Console warn not error.