Module Federation Support

[zackarychapple]

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)

[martamoc]

@Esemesek

[ScriptedAlchemy]

Main areas of consideration.

1. shared modules

when sharing a module, all imports resolve to a "virtual" module who then calls our runtimes loadShare() method

so import "react" => loadShareSync("react")

The system is async, so if the module is not preloaded, in order to make eager module consumption work - we usually make end users have a import() somewhere in the codebase before shared modules are used, then we will hoist all async requirements to that boundary and await the requirements there.

There is however a loadShareSync as well. But you'd still need to first call preload to ensure you await the async task somewhere that a async boundary can be tolerated.

2. remote modules

follow same construct as shared modules, they are async and we create a virtual module that initializes the containers upfront, then pulls the exposed module from the container as needed or at the async boundary

import 'remote/button' => loadRemote('remote/button')

3. initialization of containers

We loop over the plugin configs to find all remotes associated in the build and build up the configuration, then call init({name, remotes,shared}); this must happen at application startup

[banerjeesouvik]

This will be very helpful. In one of our native expo projects, we are trying to create the web build a an MFE, which we will import in another web app. This solves our use case.

[zackarychapple]

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).

@ScriptedAlchemy any feedback on this part?

[zackarychapple]

Initial prototype has been created and has been uploaded to the module federation organization.

[crherman7]

I love that module federation is becoming more of conversation with respect to metro-bundler! Great progress 👌

I’ve been working on ReChunk, a system for dynamically loading React Native components and functions at runtime. It uses a custom runtime resolver I built called metro-requirex, which taps into Metro’s module ID system to require modules on the fly.

One major challenge has been the lack of a public API for resolving module IDs outside of Metro’s internal bundling phase. Right now, I’m relying on internal behavior to make it work, which isn’t ideal. A stable, documented way to access Metro’s module resolution or generate a runtime-consumable manifest would go a long way toward enabling dynamic delivery patterns like this.

Excited about the future improvements and updates!

[ElielC]

Our team has come to rely on Expo's packages and the Expo CLI`s CNG. We are looking into creating micro-apps, so this would be extremely helpful.

Really looking forward to this!

[jbroma]

Hey 👋

Module Federation in Metro prototype update:

Since we have no access to top level await in Metro, this felt like the biggest obstacle to deal with right now. Module Federation sometimes requires an an async startup - especially when version-first sharing strategy is used (essentially it fetches all remote containers upfront and determines the highest versions of dependencies that can be used in the setup)

I've managed to get around this by creating a wrapper for the main RN entrypoint component and we can wait for MF runtime to finish initialising. We simply wrap the main entrypoint in React.Suspense and import the entrypoint inside React.lazy in which we also await MF initialisation to finish. Since React.Suspense can accommodate a fallback component to display in the meantime, the wrapper optionally accepts a fallback component as well. The only limitation is that no shared dependency except for React and React Native can be used before this point. Here's how it looks in the app that acts as a host:

import {name as appName} from './app.json';
import {AppRegistry} from 'react-native';
import {withAsyncStartup} from 'module-federation-metro/bootstrap';

// create async boundary through withAsyncStartup helper
// and pass the getter function for the app component
// optionally a getter function for the fallback component
AppRegistry.registerComponent(
  appName,
  withAsyncStartup(
    () => require('./src/App'),
    () => require('./src/Fallback'),
  ),
);

here is a more detailed list of things accomplished this week (all merged):

• async boundary HOC wrapper for the main entrypoint
• support for non-singleton shared dependencies
• support for version-first share strategy
• support for import: false in shared dependency config
• support for shareStrategy configuration option

[Esemesek]

Hey 👋,

Here's some update on the Module Federation with Metro prototype:

1. Code-splitting - we are now able to split the exposed modules of a remote, reusing the lazy bundling from Metro. Currently, the remote bundle is split based on the exposes field in the plugin configuration. To enable this, we introduced some necessary modifications to Metro itself in our fork which we will try to upstream.
2. We're now generating and consuming mf-manifest.json files as remote entry points, aligning with Module Federation conventions.
3. Custom RNC CLI bundling command: bundle-mf-remote – this command was introduced to bundle remote modules and output the split chunks into a directory. This enables us to produce production bundles and prepare them to be hosted externally, without relying on the Metro dev server - thus emulating target CDN environments.
4. E2E suite & github workflows (mostly done). Currently we have simple test cases written but we plan to support a wide variety of matrix testing for iOS and Android with Maestro. Our focus is to add more MF examples with tests.
5. Miscellaneous changes - we did a bunch of other changes to the prototype that contributed to fixing Android and release modes on both iOS and Android.

Current focus:

1. Usage examples with E2E - the plan here is to create multiple apps and mini-apps that will serve as examples for users but they will also have Maestro tests to make sure we don't break any MF use-cases.
2. Supporting sync and async import syntax for remote modules (and shared dependencies) - right now the remote modules can only be loaded through loadRemote from @module-federation/runtime and for full feature parity with the MF spec, we need to handle the following scenarios:

import Button from 'remote/button';
React.lazy(() ⇒ import('remote/button'));
export { default as Button } from 'remote/button';
export { Button } from 'remote/button';

[zackarychapple]

Two packages have now been merged into Module Federation Core that are for Metro usage.

https://www.npmjs.com/package/@module-federation/metro
https://www.npmjs.com/package/@module-federation/metro-plugin-rnef

Huge thanks to everyone involved already.

[jbroma]

Two packages have now been merged into Module Federation Core that are for Metro usage.

npmjs.com/package/@module-federation/metro npmjs.com/package/@module-federation/metro-plugin-rnef

Huge thanks to everyone involved already.

Happy to say that we have shipped everything initially planned and more:

• HMR is supported & working
• dynamic imports of remotes & shared are supported
• static imports of remotes & shared are supported
• RNC CLI integration
• Rock integration

While we still have few PRs to merge into Metro, we've shipped with Babel plugins that bridge the gaps and allow for earlier testing / adoption of Module Federation in Metro (those are scheduled for removal in the future when the stable version of MF integration will be released).

Docs should become available soon, showing how to use it in React Native projects 💡

Thank you everyone involved, especially @zackarychapple @robhogan @Esemesek & @ScriptedAlchemy 🚀