fix(bundler-metro): run InitializeCore from the react-native copy in the bundle

[V3RON]

What is this?

Harness no longer skips React Native's InitializeCore when a monorepo has more than one copy of react-native. In that setup the app crashed at startup with ReferenceError: Property 'window' doesn't exist, HMRClient.setup() was never registered, and Harness timed out with "did not become ready within 120000ms". The playground hit this after apps/playground-vega added React Native 0.83.0 to the workspace, which gave apps/playground its own nested copy of react-native.

How does it work?

@react-native/metro-config resolves InitializeCore from the project root and lists it in serializer.getModulesRunBeforeMainModule. The bundle, however, gets react-native through the Harness runtime, which can resolve to a different copy. Metro only emits a run-before-main call for paths that are in the module graph and silently drops the rest, so InitializeCore was bundled but never executed.

Harness now wraps getModulesRunBeforeMainModule and replaces any react-native/Libraries/Core/InitializeCore.js path with the one resolved from @react-native-harness/runtime, which is the copy in the bundle. Other run-before-main modules, such as the Vega fork's InitializeCore, are left unchanged.

Why is this useful?

Harness works in monorepos with mixed React Native versions instead of failing with a timeout that gives no hint of the cause. On the playground's Android emulator, hooks.harness.ts went from failing at startup to 14 of 14 tests passing, both in a plain run and in a --watch rerun, and the bundle now calls InitializeCore before the Harness entry point.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
react-native-harness	Ready	Preview	Oct 16, 2026 11:06am UTC