@module-federation/runtime init method not executing as expected about core HOT 13 OPEN

please provide a repo to debug

@ScriptedAlchemy

here is the repo, thank you

https://stackblitz.com/~/github.com/xiaoYuanDun/module-federation-demo?file=README.md

from core.

please provide a repo to debug

from core.

Hello @xiaoYuanDun. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with need reproduction will be closed if they have no activity within 5 days.

from core.

@xiaoYuanDun according to the source code, this is correct. builder id is the ID of the host.

from core.

@xiaoYuanDun according to the source code, this is correct. builder id is the ID of the host.

yeah, it work, but i wonder why the buildId is the highest priority

in this case, can I only use the init from @module-federation/runtime ?（because i import this from @module-federation/runtime in app1 and save it on window. i dont want do it again）

i dont know if The purpose of providing name to the Developer is to resolve this case here.

if so, when i defined the name = app2, actually i want init the app2, but it stopped by buildId, Is it more reasonable to first judge by the name passed in from the outside?

from core.

@ScriptedAlchemy

If this is a meaningful question, Could you please take a look at this when you have a moment ?I will continue to follow it. THX

from core.

So you are trying to init the same app as two different names?

from core.

So you are trying to init the same app as two different names?

@ScriptedAlchemy

no, not the same app, different app has their own mf_instance in window.__FEDERATION__.__INSTANCES__ ，right ?

in my case ,the app1 is the main app, it provides a global function, like init, loadRemote, so that the subApp do not need import { init } from "@module-federation/runtime" in their code again, just use the global function providered by app1 on window.

i want manage all the instances in window.__FEDERATION__.__INSTANCES__ with the global method provided by app1, the new api init input parameter requires the name parameter, i guess it's to find the different mf_instance ?

Dose the init can only work with their own scope ? (beacuse init can only find their own mf_instance)

from core.

and , according to the source code, if the app is not built via new MF plugin, they will not has buildId, so the getGlobalFederationInstance will work just as i expected.

i can fix my case by this way, it need move my config in MF_Plugin to fully dynamic runtime, but I feel like this is not a good solution.

if the getGlobalFederationInstance find the mf_instance by name first, no matter whether the buildId exists, that would be nice.

I haven’t seen any special logic related to FEDERATION_BUILD_IDENTIFIER yet. wonder what is the meaning of distinguishing whether it contains buildId?

from core.

are you trying to recycle the runtime code from the host?
Each instance is unique and during compile, data is encoded into the runtime for that specific host.

By setting a global instance, you are communicating with the host instance only, not the remote instances.

there should be 1 instance of federation per remote, you should have 3 instances created.

By using the global host instance, you are just communicating as the host, dispatching commands in the host who is encoded as app1

from core.

@ScriptedAlchemy

I wrote a new repo here to see if it can be clearer, the steps is in the readme.md

from core.

You would need to expose a global function that executes init and returns a instance. You cannot execute init and make the return global

from core.

You would need to expose a global function that executes init and returns a instance. You cannot execute init and make the return global

@ScriptedAlchemy

Please excuse me, I don't think I fully grasped what you said. has there been a similar issue that has had my problem before?

Let's focus back here repo , is there any way to make the execution of app1-via-build and app1 behave the same way ?

And yes, I'm able to get my project working for now by switching between app1-via-build and app1 like this, but will you consider unifying the behavior of the two in the future?

from core.