Module Federation Support

This issue serves as a central place to track the support of Module Federation in Metro.

Module Federation has become the standard for decomposing large web-based applications. Through Re.Pack and Module Federation, we've seen growing excitement around the potential for federated mobile applications and a standards-based approach to building mini-apps in React Native. For long-term stability, we believe it would be ideal for Module Federation to be supported directly within Metro. This would align Metro with other bundlers that support Module Federation natively, such as webpack, Rspack, and Rolldown, as well as Vite via a community plugin.

Enabling this may require adding new capabilities to Metro and making some adjustments on the Module Federation side. A single tracking issue helps consolidate discussions and progress around these changes.

We’re excited to see this move forward!

cc @thymikee @robhogan @scriptedalchemy @valorkin

Update April 17, 2025

Example created and moved to the Module Federation organization here

Update April 15, 2025

@jbroma and @Esemesek did some preliminary research together and taking into account the insights from @ScriptedAlchemy, have pinpointed few areas that would need tackling in order to get the Module Federation working:

• - virtual modules support for the runtime modules & shared dependencies - currently there is no support for that (can be emulated by creating modules on the filesystem)
• - bundle splitting - looks like the biggest issue to enable this seems to be a system of deterministic module ids, since right now the numbers are just assigned based on order of usage
• - scoping of module system in remote containers - in webpack/rspack the containers ship with their own module system to isolate the non-shared parts - this could be as easy as wrapping the remote in IIFE but needs more research
• - async boundary support - any async actions before the first render will cause a runtime error, therefore

We're currently working on a basic prototype to uncover the other requirements, but it seems like we could skip code-splitting altogether for the time being and package everything into the remote container (remoteEntry.js).

Initial Roadmap

• finish the minimal prototype of connecting 2 apps built with metro together - Updated: April 17, 2025
• extend the range of supported MF options (like non-singleton shared deps or version-first share startegy)
• develop the official MF plugin in the mf core repo based on the prototype implementation (or simply move it)
• ship the necessary PRs to metro & react-native core packages (like community-cli-plugin)

No Metro files or tests are named. Start by reviewing the prototype moved to the Module Federation organization at module-federation/metro-mf and the completed roadmap items, then identify the remaining changes needed in Metro and React Native core packages. Done means the necessary PRs are shipped.