A monorepo is for a second app, and one Expo project already builds for the web.

Do you need a monorepo, or does one project already do this?

Expo names two situations where a monorepo is useful. Multiple apps living in one repository and sharing code, and colocating native modules with your app. Neither describes an app with a website attached. If the website is your app rendered in a browser, you are in the web documentation, not the monorepo documentation: install react-dom, react-native-web and @expo/metro-runtime, run the dev server with the web flag, export with npx expo export --platform web. Expo adds that React Native for web is optional, since you can use React DOM directly, but recommends it when building across platforms because it maximises code reuse.

If the website is a different thing with different pages, a landing page or a blog, then it shares a logo with your app and nothing else. There is no reuse to collect, so a monorepo collects only the dependency conflicts. The case that does justify one is narrower than people assume: a second app, a real shared package such as a design system or an API client, or a native module of your own that you want to test inside the app before publishing it.

This matters more when you did not write the project. A codebase you inherited has one property worth protecting, which is that it currently works, and a repository restructure touches every path in every build script at once. If the project arrived out of a builder rather than a tutorial, the shape of what you were handed is covered in building React Native apps without coding, and it is worth reading before you move a single directory.

Expo, work with monorepos, last updated 16 October 2026, read 17 October 2026

What does Expo say a monorepo requires?

Less than you would think, and the list is short. A package manager with workspace support, and Expo says it has first-class support for Bun, npm, pnpm and Yarn, including both v1 Classic and Berry. A root package.json marked private with a workspaces property holding glob patterns, the example being apps/* and packages/*. For pnpm, a pnpm-workspace.yaml with the same two patterns instead. Your app moves into a subdirectory such as apps/cool-app. A local package goes in packages/ and is added to the app as a dependency with a version of * or workspace:*. Expo detects the monorepo from that workspace configuration on its own.

Then the instruction that reverses most of what is written about this. Since SDK 52, Expo configures Metro automatically for monorepos as long as you use expo/metro-config. If your metro.config.js modifies watchFolders, resolver.nodeModulesPath, resolver.extraNodeModules or resolver.disableHierarchicalLookup, the documentation tells you to delete them, then run npx expo start --clear once to erase the outdated Metro cache. If the app still works afterwards, in Expo's words, it is a regular Node monorepo that will need no special configuration going forward. The hand-written config in every tutorial is now the thing to remove, and which SDK you are on decides whether that applies, which is one reason to keep the Expo SDK release notes open while you do this.

One honest note about that page. It keeps the pre SDK 52 snippet for people on older versions, and the snippet as printed does not run: it assigns config.resolver.nodeModulesPaths while the delete list above it says nodeModulesPath, and it uses a projectRoot variable it never defines. If you are on an older SDK and copying it, you will be fixing both. On SDK 52 and later you should not be copying it at all.

The rest of the requirements are about duplicates, and Expo states them as rules rather than suggestions. Duplicate React Native versions in a single monorepo are not supported. Duplicate React versions in a single app will cause runtime errors. Duplicate versions of Turbo and Expo modules may cause runtime or build errors. You find them with npm why, yarn why, pnpm why --depth=10 or bun pm why, and you force one version with resolutions in Yarn and pnpm or overrides in npm. Isolated installs, which are the default for pnpm, are supported from SDK 54, and Expo still warns that not all packages you install will work with them. The documented escape is nodeLinker set to hoisted in pnpm-workspace.yaml. For native modules, setting experiments.autolinkingModuleResolution to true in app.json from SDK 54 forces Metro to resolve what autolinking actually built, and from SDK 55 that is on by default for apps in a monorepo.

Expo, work with monorepos, read 17 October 2026

How does code get shared between the app and the web?

Through the bundler, at the level of individual files. React Native documents two mechanisms and you will use both. The Platform module is for small differences: Platform.OS is ios on iOS and android on Android, and Platform.select takes an object whose keys can be ios, android, native or default, returning the most fitting value, with native used when no specific platform key matches and default last. Web arrives through that default branch, and the comment labelling it in React Native's own example reads: other platforms, web for example.

For anything larger than a style, you split the file. React Native detects a .ios. or .android. extension and loads the right one when the module is required from another component, and you import it without the suffix. The extension aimed exactly at this page is .native.js, which the documentation describes as for a module that needs to be shared between NodeJS or web and React Native but has no Android or iOS difference, and calls especially useful for projects with common code shared among React Native and ReactJS. Its own example is a plain Container.js picked up by a web bundler and a Container.native.js picked up by Metro for both Android and iOS.

Expo adds .web.tsx to that set and one rule worth knowing before you move route files around. Inside the app directory, a platform specific route is used only if a non platform version also exists, which Expo says keeps routes universal across platforms for deep linking. So _layout.web.tsx works because _layout.tsx is beside it. Outside the app directory there is no such rule: you can keep about.tsx, about.ios.tsx and about.web.tsx in a components folder and re-export one of them as the route in a single line.

Read that list again and notice what is missing from it. Not one of those mechanisms mentions a repository, a workspace or a package manager. They are resolver features, and they work identically in a single project. A monorepo is what you reach for when the code to share has to cross a project boundary, because there is a second project. Until there is, the boundary you would be paying for does not exist.

React Native, platform-specific code, read 17 October 2026

What does the split cost you once it exists?

Three things, and the first one costs an afternoon the first time it happens. Platform resolution is silent. Edit Container.js, reload the app, and the app does not change, because Container.native.js exists and won. Nothing logs a warning, because from the bundler's side nothing went wrong. The habit that saves you is to search for the base filename before debugging anything else, and to keep the number of split files small enough that you can hold them in your head.

Second, dead code ships. React Native's own tip is to configure your web bundler to ignore .native.js extensions so unused code stays out of your production bundle. Expo handles the platform side of this for you when it builds, by stripping code for platforms you are not targeting. A separate web app with its own bundler is your own problem, and nobody ever notices a bundle quietly carrying code that cannot run in a browser.

Third, and this is the one people sign up for without reading: your upgrades stop being independent. Duplicate React versions in a single app cause runtime errors, so in a monorepo every workspace runs one React version. The day the website wants a React upgrade the app is not ready for, you are negotiating with yourself. That is a recurring tax, not a setup cost, and it belongs in the same column as what an app costs to maintain rather than in the migration ticket.

There is a fourth, smaller one that bites at build time. Tools assume the app is the repository root until you tell them otherwise. Expo's own build reference says to run its build commands from the root of the app directory, and to keep the build configuration files there, one copy per app. Native build files have the same habit: a hardcoded path to react-native inside android/app/build.gradle or the iOS Podfile breaks once hoisting moves node_modules, and the documented fix is to let Node resolve the path instead of typing it. Expo says its own SDK modules and templates already use the dynamic form. Third-party packages are where you will find the hardcoded ones.

React Native, platform-specific code, native-specific extensions, read 17 October 2026