-
-
Couldn't load subscription status.
- Fork 1.8k
Issues with name in ModuleFederationPlugin #1493
-
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 ModuleFederationPluginwith 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
Beta Was this translation helpful? Give feedback.
All reactions
- remoteName@remoteUrl
- 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 usepromise new Promiseso I would be resolving my own global back to the interface. - 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.
- 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 web...
Replies: 4 comments 1 reply
-
- remoteName@remoteUrl
- 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 usepromise new Promiseso I would be resolving my own global back to the interface. - 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.
- 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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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)
Beta Was this translation helpful? Give feedback.
All reactions
-
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
Beta Was this translation helpful? Give feedback.
All reactions
-
The name conflicts that i'm having isn't the remote name, or module name. Instead it's the source code name:
new ModuleFederationPlugin({
name: "remotes",
filename: "remoteEntry.js",
exposes: {
"./PageB": "./src/PageB", // the source is the conflict!
},
shared: { react: { singleton: true }, "react-dom": { singleton: true } },
}),
For instance, remotes, ./PageB , they are all fine. But if i use ./src/App
exposes: {
"./PageB": "./src/App", // the source is the conflict!
},
This would create a confusion for the plugin, so it'll continue hit the cache even when the port number is entirely different. I have debugged and eventually i have to name the source code name to be different.
What is the best way we don't end up with the source code name conflicts?
Beta Was this translation helpful? Give feedback.
All reactions
-
Hash chunks?
Beta Was this translation helpful? Give feedback.