Module Federation Support

@thymikee

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)

@Esemesek

@Esemesek

Main areas of consideration.

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.

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

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

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.

@ScriptedAlchemy

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?

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

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!

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!

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

Hey 👋,

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

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.
We're now generating and consuming mf-manifest.json files as remote entry points, aligning with Module Federation conventions.
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.
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.
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:

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.
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';

refactor: prevent reinitializing `global.$RefreshReg$` (#1510)

feat: process HMR `registerBundle` calls from same origin only (#51821)

feat: allow reuse of `ReactRefresh` instance (#1513)

refactor: prevent reinitializing `global.$RefreshReg$` (react#1510)

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.

@zackarychapple

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 🚀

🚀

Hi and huge thanks for this initiative!

I've just tried this out with RN 0.81.4, but got a weird error regarding setImmediate being undefined..

Also, the latest metro version you get from a fresh RN project, is different to the expected 82.3 that module federation libs seem to need.

I was wondering if:
There is a suggested RN version ?
Will Expo be supported?
Do you need to use RNEF?

Many thanks for your awesome work!

@jbroma

Thank you for the love! I can answer these two quick.

Will Expo be supported?
Do you need to use RNEF?

Expo support is already landing. I saw @jbroma has a branch testing it already, so just waiting for that to wrap up.
RNEF is not required

@HigorAlves, @Nsttt what versions are y'all using?

super!
I've had to go down to RN 0.80.0
Awaiting the expo suport with great expectation.

Hiya, I've been battling with getting my host to read a producer manifest.
It's kind of resulted in me having to install:
"react-native-polyfill-globals": "^3.1.0",
"web-streams-polyfill": "^3.3.3"

Which module federations seems to require for fetching?

Why?

Having done this it still doesn't fetch the manifest. The manifest is being served.
I've written a little script that reads and verifies it.

So why wouldn't the host app be able to fetch the manifest??

If I remove the polyfill stuff I get the following

console.js:656 Warning: Error: [ Federation Runtime ]: remoteEntryExports is undefined 
 {
  "alias": "todos",
  "name": "UnifyTodos",
  "entry": "http://localhost:8082/todos.bundle",
  "entryGlobalName": "UnifyTodos",
  "type": "global",
  "shareScope": "default",
  "version": "http://localhost:8082/mf-manifest.json",
  "buildVersion": "1.0.0"
}

The bundle is being served ...

Any ideas?

@maitriyogin

Hey @maitriyogin are you able to jump into either the Zephyr discord or the Module Federation discord and post the question there ?

Probably easy to debug there and we can talk about making a reproduction :)

Apart from that, remoteEntryExports is usually that it fetched the manifest but it's having issues with one of the following calls after that.

of course apologies

Thank you for the love! I can answer these two quick.

Will Expo be supported?
Do you need to use RNEF?
1. Expo support is already landing. I saw [@jbroma](https://github.com/jbroma) has a branch testing it already, so just waiting for that to wrap up.

2. RNEF is not required
@HigorAlves, @Nsttt what versions are y'all using?

Any news on Expo support?

Thank you for the love! I can answer these two quick.

Will Expo be supported?
Do you need to use RNEF?
1. Expo support is already landing. I saw [@jbroma](https://github.com/jbroma) has a branch testing it already, so just waiting for that to wrap up.

2. RNEF is not required
@HigorAlves, @Nsttt what versions are y'all using?
Any news on Expo support?

Hey! The Expo support is in the works here: module-federation/core#4080

What's left to do is the CLI integration, and thats still in progress at this moment

Thank you for the love! I can answer these two quick.

Will Expo be supported?
Do you need to use RNEF?
1. Expo support is already landing. I saw [@jbroma](https://github.com/jbroma) has a branch testing it already, so just waiting for that to wrap up.

2. RNEF is not required
@HigorAlves, @Nsttt what versions are y'all using?
Any news on Expo support?
Hey! The Expo support is in the works here: module-federation/core#4080

What's left to do is the CLI integration, and thats still in progress at this moment

Hi, the PR seems to have been closed due to being stale. Is there any expectation of this being released soon?

Any ETA for when this PR will be reopened and handled?

Navigation Menu

Repository navigation

Module Federation Support #1480

Update April 17, 2025

Update April 15, 2025

Initial Roadmap

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Module Federation Support #1480

Description

Update April 17, 2025

Update April 15, 2025

Initial Roadmap

Activity

martamoc commented on Mar 31, 2025

ScriptedAlchemy commented on Mar 31, 2025

banerjeesouvik commented on Apr 14, 2025

zackarychapple commented on Apr 15, 2025

zackarychapple commented on Apr 17, 2025

crherman7 commented on Apr 24, 2025

ElielC commented on Apr 24, 2025

jbroma commented on Apr 25, 2025

Esemesek commented on May 16, 2025

zackarychapple commented on Sep 1, 2025

jbroma commented on Sep 2, 2025

Nsttt commented on Sep 2, 2025

maitriyogin commented on Sep 25, 2025

zackarychapple commented on Sep 25, 2025

maitriyogin commented on Sep 26, 2025

maitriyogin commented on Sep 26, 2025

Nsttt commented on Sep 26, 2025

maitriyogin commented on Sep 29, 2025

ElielC commented on Oct 28, 2025

jbroma commented on Nov 3, 2025

raffidahmad commented on Jan 16, 2026

drodmun commented on Jan 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions