Issues with name in ModuleFederationPlugin

[sidorares]

As far as I understand, during the loading of remote module ( say pointing to federatedModuleName@http://localhost/remoteEntry its content is set to window[federatedModuleName].

A bunch of questions for me to clarify this behaviour and potential issues with it.

• what's terminology here? Is name a container name, module name or something else?
• what's the purpose of having it? Would remote entry js url be enough? Can you have more than one of a "name" ( container? ) to be part of a single entry js file? If I try to use two new ModuleFederationPlugin with different names and exports but same filename webpack complains about generating code into the same file and overwriting it
• if in the process of loading it creates a reference to window[federatedModuleName] - I'm worried about 1) accidentally clashing with standard top level window properties 2) accidentally other module from a different url but same name overwriting module loaded earlier

[ScriptedAlchemy]

1. remoteName@remoteUrl
2. Yes the name could be something else, like remote:remote_v1_0@http://somePinnedRemoteGlobal - so the alias you refer to it in your application (remote) isn't always where its located in memory. I might also use promise new Promise so I would be resolving my own global back to the interface.
3. yeah you can have collisions. So it's up to you to make sure you use remote namespaces that won't clash, also if you want nested remotes at different versions. you'd want to make sure you have the right namespace.
4. You won't have modules from other URLs overridden as long as they are not called the global name, the internal module references are all inside a closure in separate webpack graphs.

[sidorares]

Are you sure remote:remote_v1_0@http://somepinnedremoteglobal/ is a possibility? My understanding that the whole part before @ must be a valid js identifier, just tried that and got syntax error because of the :

Scenario for 4: host app consuming remoteName@http://modulHost/v1.0.1/remoteEntry.js and remoteName@http://modulHost/v1.1.1/remoteEntry.js - depending on which one is loaded first the host ends up having 2 identical modules (random 1.1.1 vs 1.0.1)

[ScriptedAlchemy]

No the string is "someglobal_v@http" I'm representing a key value pair when configuring the remote

{name: remote_v1}

Consuming

{remotes:{remoteName:"remote_1@http"}}

You're loading two remotes, with the same global namespace. As represented by the global@url syntax. So the last remote will overwrite the first because the containers are both named the same. Name needs to be unique and you need to reference that name on the global @

Yes I'm sure. I have deployed examples and versioned remotes powered by GUIs that let me interchange any deployed remote with anything else