module-federation-examples: Dynamic remote throwing Container initialization failed as it has already been initialized with a different share scope
Hi, First thanks a lot for giving us module federation. It is working really well for me. I was inspired by the dynamic remote example and I tried to implement that because i have 22 mfe and loading 22 remoteEntry.js file at once increases the initial render time. I followed the same approach as mentioned in the example but facing the above issue. My scenario also bit weird such that one mfe is library kind of thing. So all other 21 mfe use that library mfe.
Config for shell:
new ModuleFederationPlugin({
name: 'shell',
remotes: {
app_library: app_library@app_library/remoteEntry.js,
},
.......
})
Config for remaning MFEs:
new ModuleFederationPlugin({
name: <respective name>,
filename: 'remoteEntry.js',
library: { type: 'var', name: <respective name>},
exposes: {
...exposedPaths,
},
remotes: {
app_library: 'app_library',
},
},
})
Config for app_library:
new ModuleFederationPlugin({
name: app_library,
filename: 'remoteEntry.js',
library: { type: 'var', name: 'app_library' },
exposes: {
...exposedPaths,
},
})
Low level api’s used:
await __webpack_init_sharing__('default')
const container = (window as any)[remoteName] as Container
await container.init(__webpack_share_scopes__.default)
const factory = await container.get(exposedModule)
const Module = factory()
return Module as T
Issue Facing:
On loading Shell alone things (which loads app_library mfe too) works fine. But when I try to load other mfe through lazy routing it is throwing below error because app_library is already loaded. And stops there without navigating further.
sharing:17 Initialization of sharing external failed: Error: Container initialization failed as it has already been initialized with a different share scope
Expectation:
Instead of trying to initialize again it should use already initialized with or without warning and proceed.
Note:
Not sure it is a bug or feature request or question for stack overflow. Since I don’t find any example for my scenario posting here.
Thanks in advance
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 35 (13 by maintainers)
Have similar problem, where dependencies: HOST(MAIN) <- HOST/REMOTE(A) <- REMOTE© HOST(MAIN) <- HOST/REMOTE(B) <- REMOTE©
HOST/REMOTE uses webpack config. REMOTE uses webpack config. HOST uses vite config.
When component C called second time from different remote, then error is thrown.
Dynamic remote throwing Container initialization failed as it has already been initialized with a different share scope
Hi! We have MF applications: HOST, A, B, C
Where dependencies:
HOST <- A
HOST <- B
A <- C
B <- C
So, when we load
HOST <- A <- C
, all is ok. After that when we change router (for example) and loadHOST <- B <- C
then we catch errorBecause module
C
was initialized before. But I don’t understand, why do we think that these are different scopes? Do Module Federation support this case from a plugin?So, please, can you help find a solution to how I can resolve it?
P.s. my vision: it is should support by the MF plugin. We have one URL for bundle module
C
, and we have one scope (maybe need to deep check, but not equal link to object?).@ScriptedAlchemy shouldn’t this be a default behavior, or at least configured via plugin flag instead of an internal api configuration? That is, if a container was already initialized on an old scope, console warn that an old scope was already present and utilize this existing scope instead of creating a new one. Do you think there would be any side effects with this behavior?
Moreover, this really complicates the use of module federation containers inside library exports or module federation containers since reloading the container on a different route it’s a fairly common scenario and most developers like myself don’t know yet how to use the internal api and where to adjust this container.init call.
To expand more on my scenario:
I have a container project App1 that is not a module federation container, and that consumes a secondary App2 project via UMD export on a Shadow Dom. This App2 provides three routes to be consumed, and in one of those it consumes an App3 project via module federation, that is, App1 (host) -> App2 (umd build) -> App3 (module federation). When the host app re-loads App2 on a different route, if this route imports App3, then it will throw the aforementioned error. This feels like a fairly common gotcha, to reload the App2 if a route changes on App1, and while I do realize reloading the App2 is not ideal, that is the reality on many projects I work with and changing would require a huge effort.
Hello, I am currently bumping into this issue from times to times and I really can’t figure out why. I have created a repository to reproduce : https://github.com/aplanchamp/poc-mfe
Context :
A next 13 shell application integrating 3 react components as microfrontends.
When running the shell application I get this inconsistent issue during navigation. When that occurs, the application reloads automatically and everything works fine, but still, I would like to prevent this issue.
Versions :
“next”: “13.5.6”, “react”: “18.2.0”, “react-dom”: “18.2.0” “@module-federation/nextjs-mf”: “^8.0.1-4” (needed to use next/router package)
Getting started :
Steps are described in the readme file to run MFEs on client side only.
Also, if you have time, there is also the steps to launch everything on server side in order to use “dynamic” rather than “lazy” to load the components. This actually works well and prevent having to use effect to run on client only (effect that is needed when using react.lazy otherwise you get a mismatch error, error that is also present on your ‘next-react’ example when you refresh the page by the way). For what reasons shouldn’t we use dynamic (cause you specify to use lazy in readme) ? Also, would it be ok to handle server side rendering of the react component using dynamic and { ssr: true } (meaning handling SSR even if MFEs are not next but react) ? Right now I am getting issues with this strategy IF I use hooks on MFEs.
Sorry, I realize that this last paragraph asks a lot of questions, should I create a new issue for this matter ?
Thank you very much
yes, the component name:
HomeView
HomeView.vue
: https://github.com/AndreiSoroka/mf-reproduce-collision-names/blob/master/service-a/src/views/HomeView.vueb3/HomeView.vue':
https://github.com/AndreiSoroka/mf-reproduce-collision-names/blob/master/service-a/src/views/B3View.vueNo
What do you mean? Unique component name? ModuleFederationPlugin > name ? ModuleFederationPlugin > exposes > component Name?
Is it possible to have some kind of basic example as i feel really lost in this 😿 The way i fetch remotes is in the webpack with the plugin:
I also checked the function of getOrLoadRemote (I assume it takes care to check if remote is already fetched) in https://gist.github.com/ScriptedAlchemy/3a24008ef60adc47fad1af7d3299a063
But i don’t understand where to trigger this function exactly. Ive tried to use it in the
remotes:{}
object but seems that its not the place for it. Application is in React.Edit: We managed to mostly fix this issue for our enterprise context by creating a federated app loader, I will be commenting the solution here later if others are interested, but I still have an issue. On a scenario where a host App1 loads a UMD library App2, which in turn loads App3 as MF container, if App2 is destroyed and then reconstructed, then App3 no longer loads styles. This is probably an intended behavior as the module has already been loaded previously (and is now available at window[‘app-name’]), but we need a way to force the reload of styles again since they were previously inserted on a Shadow Dom (via style-loader) but that was destroyed when the app was initially destroyed. This behavior prevents the usage of Module Federation inside Shadow Dom containers.
Original post: I see, unfortunately I have a complex scenario where the app could be rendered as a UMD library or a module federation container, and this complicates the build process by quite a bit. I was trying to avoid loading the module federation via URL directly and load it as the plugin’s alias, but it doesn’t really work 😕
I believe the module’s entrypoint is loaded by default and the function init is called by webpack’s ensure function if it identifies the module might be loaded somewhere as an async import, because we define a map of app names and module federation definition names to import it using the alias provided by the ModuleFederation remotes property and the file is clearly downloaded on the Network window even if there was no call for it to load.
Scenarios:
Host App1 loads -> UMD App2 loads -> Module Federation App3 Host App1 loads -> Module Federation App2 -> Module Federation App3
I’m not sure i can clearly explain my context, but it’s something like this:
Webpack config:
Code that loads the module federation
It feels like our problem is similar to Andrey’s, in that this happens mostly when we change routes on the Host parent and that triggers a re-instantiation of the App3, either because another App4 utilizes the same container or the same App2 is re-instantiated (routing happens on host and that completely reload the App2)