Scope router store per ExpoRoot to enable concurrent multi-instance rendering (e.g. multi-user testing)

[HerrNiklasRaab]

Summary

renderRouter (and ExpoRoot more broadly) cannot be used to render two concurrent app instances in a single Jest test, because the global router state is held in a module-level closure and last-mount-wins. I'd like to propose scoping the store per ExpoRoot so multiple instances can coexist on the same JS heap.

Where the singleton lives

On main, in packages/expo-router/src/global-state:

• store.ts (L32) defines storeRef = { current: {} as StoreRef } as a module-level closure.
• store.ts (L51+) exports store, whose every getter reads storeRef.current (state, navigationRef, routeNode, linking, redirects, routeInfo, …).
• useStore.ts (L99) overwrites storeRef.current = { navigationRef, routeNode, config, rootComponent, linking, redirects, state, context } on every mount.

ExpoRoot → ContextNavigator calls useStore(...) and wires the inner <NavigationContainer ref={store.navigationRef}>. The StoreContext provider passes the module-level store as the context value — so even though consumers go through React context, the value behind it is global.

The imperative API (router.push / replace / back, etc.) reaches through store and therefore also targets storeRef.current — i.e. the most recently mounted ExpoRoot.

Concrete failure mode

Calling renderRouter('app', ...) twice in one test:

1. First mount: storeRef.current.navigationRef = containerA's ref.
2. Second mount: storeRef.current.navigationRef = containerB's ref (containerA's ref is now unreachable from store).
3. Any router.replace('/x') triggered from app A's _layout effect (e.g. post-auth redirect) dispatches against containerB.
4. onStateChange from either container writes to the same storeRef.current.state and notifies the shared routeInfoSubscribers Set — both rendered trees re-render against the latest path, even if the action originated in only one of them.

Use case

We have a real-backend integration test for a 1v1 matching flow. We want to drive two users' onboarding + invitation creation flows through real UI inside one Jest test and assert each side sees the post-match state. Per-app dependencies (auth client, InstantDB client, store) are already clean to inject via React context — the router is the only piece that forces sequential rendering.

Approaches I've ruled out

• jest.isolateModules around the two renderRouter requires: also isolates React / MobX / app code, which corrupts cross-instance shared state.
• Two JSDOM windows in one process: doesn't help — expo-router is a single module instance across both.
• Worker threads / child processes: heavy enough that it's a separate test-infra project (cross-process coordination, no shared DOM).
• Sequential rendering + unmount/remount: works (and is what I shipped), but only because each user's flow happens to be independent. Doesn't cover concurrent races.

Proposal

Move storeRef (and splashScreenAnimationFrame / hasAttemptedToHideSplash) off the module into the React tree:

• useStore returns a fresh RouterStore instance per ExpoRoot (the hook already builds the right shape — it just needs to stop writing to a module-level slot).
• StoreContext carries the instance (already exists; just needs the value to be the per-tree store rather than the shared one).
• The exported store object becomes a thin proxy that reads from a context-set "active store" — falling back to the most-recently-mounted one for the imperative router.x() calls that have no React context (preserves today's behaviour for everyone outside React, e.g. deep link handlers and tests that only mount one root).
• useRouteInfo and the imperative API used inside React reach for the context-scoped store, not the global.

Question for maintainers

Is there appetite for this direction? Happy to put up a PR if so. The trickiest design call is the imperative-API fallback for non-React callers — I'd lean on "last-mounted wins, with a warning in dev when there's more than one mounted root," but want a steer before I write it.

Environment: expo-router@55.0.14, expo@55.0.23.