Replies: 2 comments 21 replies
-
Yeah this is what id had in mind and tried with v2, but ran into issues of ChunkManager never resolving a promise even though the script did inject into RN. Support of the @ syntax would enable pretty much universal use of MFP across any environment with more or less the same syntax for all - just different implementations of the "last mile" interconnections. We have this for node.js, next.js which gives us server side MFP capabilities. RN will be the last env to achieve the trifecta. What eager issues do you run into? Meta suggestion - what i usually do is create a new plugin wrapper. like RNModuleFederationPlugin, where my remotes are just the normal "browser" synax options. like a straight string - then in the plugin i parse options and convert it to promise new promise. That way the user only needs to pass one syntax all the time and the plugin takes the standard options and can convert it on demand. so regardless of my envs, user only needs to read webpack docs and pass a remote in one of the valid formats, i then wrap the real MF plugin in the converted options. See: Configuration Options https://app.privjs.com/buy/packageDetail?pkg=@module-federation/nextjs-ssr Next is powered by promise new promise, but users only ever pass known ways of working with standard api. That said, i am working on this: https://github.com/module-federation/enhanced |
Beta Was this translation helpful? Give feedback.
-
IMO the ideal is that RePack would support The reason I think this is ideal is that I believe module federation in react native should work as identically as possible to module federation on the web. On the web ModuleFederationPlugin must transform the |
Beta Was this translation helpful? Give feedback.
-
Having a
app@remoteUrl
syntax support when declaring remotes, for example:essentially boils down to passing the
remoteUrl
into theScriptManager
.By introducing concept of multiple resolvers to
ScriptManager
this can be easily achieved:This will allow not only to support
@
syntax in remotes but also add an ability for containers to dynamically provide resolves inside the code:cc: @ScriptedAlchemy @tom-sherman
Beta Was this translation helpful? Give feedback.
All reactions