feat(expo): add first-class Re.Pack integration by whydidoo · Pull Request #1425 · callstack/repack

whydidoo · 2026-07-30T10:24:23Z

Summary

This PR introduces first-class Expo support for Re.Pack through a new @callstack/repack-expo package.

It allows Expo SDK 56 applications using prebuild/CNG to use Rspack and the existing Re.Pack runtime, including ScriptManager and Module Federation v2, without changing the core Re.Pack packages.

The package remains private while we validate the initial integration contract.

What’s included

An Expo Config Plugin that configures generated iOS and Android projects for Re.Pack.
An ExpoPlugin for Rspack that owns the required Expo/Re.Pack defaults:
- Expo Router and plain entry resolution
- Babel configuration
- React Native and monorepo module resolution
- images, density variants, fonts and XML assets
- EXPO_PUBLIC_* environment variables
- source maps and symbolication
- packaged local chunks through ScriptManager
CLI commands for initial setup and diagnostics:
- npx @callstack/repack-expo init
- npx @callstack/repack-expo doctor
Development, native Release and EAS Build integration.
Expo Router support without importing Metro runtime behavior.
Module Federation v2 support using the existing public Re.Pack plugin and ScriptManager.
Expo host and Expo widget validation applications for iOS and Android.

Module Federation v2

Module Federation remains explicit and application-owned, matching regular Re.Pack behavior.

The implementation supports:

Expo host → Expo widget
Expo host → regular Re.Pack MF v2 widget
packaged local React.lazy() chunks alongside remote widgets
remotely deployed widget chunks, assets and fonts
platform-specific iOS and Android manifests
the existing ScriptManager resolver, storage and security mechanisms

Remote widgets cannot provide native dependencies. Native modules must already be installed and linked in the host application.

Native integration

@callstack/repack-expo init only updates application-owned configuration.

Native changes are applied through the Expo Config Plugin during expo prebuild. The integration does not require users to maintain custom Swift, Kotlin, Gradle or Xcode changes manually.

Development applications are launched with:

npm run repack:start
npm run repack:ios
# or
npm run repack:android

changeset-bot · 2026-07-30T10:24:26Z

⚠️ No Changeset found

Latest commit: 96636f0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

vercel · 2026-07-30T10:24:30Z

@whydidoo is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

dannyhw · 2026-07-30T13:41:11Z

@whydidoo can you check the merge conflicts?

dannyhw · 2026-07-30T14:01:52Z

+    "expo-router": "~56.2.7",
+    "expo-status-bar": "~56.0.4",
+    "react": "19.2.3",
+    "react-native": "0.85.3",


I recently updated our react native version to "0.86.0"
also note that we have some of our package versions in catalogs in pnpm workspace
would be good to keep react native versions in sync across projects I think

Expo SDK 57 currently expects React Native 0.86.2 and React 19.2.3.
I’ve kept both Expo examples on the same Expo-compatible versions rather than forcing the default catalog versions. We could add a dedicated Expo SDK 57 catalog later to keep those versions centralized as well.

dannyhw · 2026-08-03T13:31:35Z

lets try and align the Expo package and examples with the workspace catalogs

At the moment the new Expo projects use direct pins for React, React Native, Community CLI packages, the React Native Babel preset, React types, TypeScript, and Module Federation, while existing testers use the shared catalog entries. In particular, the Expo apps use React Native 0.86.2 while the catalog is 0.86.0; if 0.86.2 is the Expo 57-compatible version, please update the shared React Native catalog to 0.86.2 and have the relevant examples consume it through the catalog.

The Expo SDK packages themselves can live in a dedicated Expo 57 catalog, shared by both Expo fixtures, so their versions do not drift. The same applies to any Expo-specific React, CLI, or Babel compatibility pins that genuinely cannot use the default catalog.

regarding typescript version I have a separate pr that updates typescript to v7 which we could merge before this and then update those expo projects to be on v7 as well

- align Expo 57 fixtures with workspace catalogs and React Native 0.86.2 - tolerate whitespace changes in generated Android and iOS config anchors - stop package manager lookup at package.json workspaces - use Rspack RuleSetRules for Expo Router configuration - add regression coverage for config anchors and workspace detection

MikitasK

excellent work overall 👏 👍
just 2 comments about forwarding custom Expo entry & supporting Rspack 2 cache invalidation, plus 2 non-blocking edge-cases related suggestions:

MikitasK · 2026-08-07T12:31:46Z

+module.exports = (env) => createConfig(env, projectRoot);
+
+function createConfig(env, projectRoot) {
+  const { mode = 'development', platform = process.env.PLATFORM, devServer } = env;


could we pass env.entry to ExpoPlugin in both generated config variants?
the thing is that native release builds provide Config Plugin’s custom entry through env.entry, but generated config currently drops it. ExpoPlugin therefore bundles default entry from package.json instead of custom entry

const { entry, mode = 'development', platform = process.env.PLATFORM, devServer, } = env; ... plugins: [new ExpoPlugin({ entry, platform })],

Good point - entry needs to be forwarded here because ExpoPlugin owns the final compiler entry and prepends the ScriptManager runtime. Without forwarding env.entry, a CLI-provided --entry-file would be silently replaced by package.json#main.

I’ve updated both generated CJS and ESM configs to pass entry to ExpoPlugin and added regression coverage.
package.json#main remains the default source of truth. The following config was only used locally to validate a custom native entry through expo prebuild and an iOS Release build:

app.json [ "@callstack/repack-expo", { "entry": "custom-entry.prototype.tsx" } ]

It is not required for normal usage and won’t be included in the example. The regular setup remains:

{ "main": "expo-router/entry", "plugins": ["@callstack/repack-expo"] }

It won't be part of the example. Normally the entry comes from package.json#main, and the plugin config stays simple:

"plugins": ["@callstack/repack-expo"]

The config plugin entry option is there for cases where the native entry intentionally differs from package.json#main. --entry-file is still available for a single bundle command.

MikitasK · 2026-08-07T12:33:14Z

+);
+
+export default (env) => {
+  const { mode = 'development', platform = process.env.PLATFORM, devServer } = env;


same suggestion here

MikitasK · 2026-08-07T13:05:08Z

+  compiler: Compiler,
+  digest: string
+): void {
+  const cache = compiler.options.experiments?.cache;


could we read persistent-cache configuration from both compiler.options.cache & compiler.options.experiments?.cache?
rspack 2 moved experiments.cache to the top-level cache option (source), so expo env digest is currently not added to rspack 2 cache version

Suggested change

const cache = compiler.options.experiments?.cache;

const cache = compiler.options.cache || compiler.options.experiments?.cache;

MikitasK · 2026-08-07T13:29:06Z

+    /@callstack\/repack-expo\/rspack/.test(contents) &&
+    /new\s+(?:\w+\.)?ExpoPlugin\s*\(/.test(contents) &&
+    !/new\s+(?:Repack\.)?RepackPlugin\s*\(/.test(contents) &&


[nit] could we ignore comments when checking for ExpoPlugin & RepackPlugin usage? for example, this config is currently reported as compatible even though the plugin is never instantiated:

import { ExpoPlugin } from '@callstack/repack-expo/rspack'; // new ExpoPlugin(); export default {};

could we strip comments before running these checks & add this examples as a regression test?

MikitasK · 2026-08-07T13:37:08Z

+    const version = match[1] === 'ModuleFederationPluginV2' ? 'v2' : 'v1';
+    aliases[version].add(match[2] as string);


[nit] could we ensure that aliased ModuleFederationPluginV2 is still detected as v2? here's the case:

import { ModuleFederationPluginV2 as ModuleFederationPlugin } from '@callstack/repack'; new ModuleFederationPlugin({});

this will be classified as v1 in current implementation, which is incorrect.
we can fix it like that:

Suggested change

const version = match[1] === 'ModuleFederationPluginV2' ? 'v2' : 'v1';

aliases[version].add(match[2] as string);

const importedName = match[1];

const alias = match[2];

const version = importedName === 'ModuleFederationPluginV2' ? 'v2' : 'v1';

const otherVersion = version === 'v2' ? 'v1' : 'v2';

aliases[otherVersion].delete(alias);

aliases[version].add(alias);

feat(expo): add first-class Re.Pack integration

b57cbb3

whydidoo requested a review from dannyhw July 30, 2026 10:24

whydidoo added the area:3rd-party The issue is about 3rd party package or library. label Jul 30, 2026

This was linked to issues Jul 30, 2026

[TRACKING] Enhanced Expo support #1413

Open

Re.pack and its Module Federation / Micro-frontends is not working with expo #1396

Open

dannyhw reviewed Jul 30, 2026

View reviewed changes

whydidoo added 4 commits July 30, 2026 19:25

feat(expo): support SDK 56 and newer

98ca23d

Merge branch 'main' into feat/expo-repack-support

e2c2c3c

fix(expo): declare worklets Babel dependencies

922aca7

fix(expo): configure tester remote assets

f0d1727

bartekkrok reviewed Aug 5, 2026

View reviewed changes

Comment thread packages/repack-expo/src/rspack/router/configureExpoRouterEntry.ts Outdated

bartekkrok reviewed Aug 5, 2026

View reviewed changes

Comment thread packages/repack-expo/src/rspack/ExpoPlugin.ts

Merge branch 'main' into feat/expo-repack-support

70db013

bartekkrok reviewed Aug 5, 2026

View reviewed changes

Comment thread packages/repack-expo/src/config/android.ts Outdated

bartekkrok reviewed Aug 5, 2026

View reviewed changes

Comment thread packages/repack-expo/src/cli/project.ts Outdated

whydidoo mentioned this pull request Aug 6, 2026

Re.pack and its Module Federation / Micro-frontends is not working with expo #1396

Open

whydidoo added 4 commits August 6, 2026 23:33

Merge branch 'main' into feat/expo-repack-support

4b8be2f

Merge branch 'main' into feat/expo-repack-support

2d07164

test: increase timeout for bundle command test

8c05acc

bartekkrok approved these changes Aug 7, 2026

View reviewed changes

MikitasK reviewed Aug 7, 2026

View reviewed changes

fix(repack-expo): handle custom entries and Rspack config variants

96636f0

	const cache = compiler.options.experiments?.cache;
	const cache = compiler.options.cache \|\| compiler.options.experiments?.cache;

		const version = match[1] === 'ModuleFederationPluginV2' ? 'v2' : 'v1';
		aliases[version].add(match[2] as string);

-    const version = match[1] === 'ModuleFederationPluginV2' ? 'v2' : 'v1';
-    aliases[version].add(match[2] as string);
+    const importedName = match[1];
+    const alias = match[2];
+    const version = importedName === 'ModuleFederationPluginV2' ? 'v2' : 'v1';
+    const otherVersion = version === 'v2' ? 'v1' : 'v2';
+    aliases[otherVersion].delete(alias);
+    aliases[version].add(alias);

Uh oh!

Conversation

whydidoo commented Jul 30, 2026

Summary

What’s included

Module Federation v2

Native integration

Uh oh!

changeset-bot Bot commented Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

vercel Bot commented Jul 30, 2026

Uh oh!

dannyhw commented Jul 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dannyhw commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MikitasK left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

changeset-bot Bot commented Jul 30, 2026 •

edited

Loading

dannyhw commented Aug 3, 2026 •

edited

Loading