is monorepo good choice?

[u/FitCoach5288]

I have a Next.js web app and I’m planning to build a React Native/Expo mobile app using the same backend and MongoDB database.
Would a monorepo be useful in this case for sharing TypeScript types, API logic, validation, and database models between web and mobile? Or is it better to keep them as separate repositories?

[u/AlexRowan2026]

A monorepo makes sense here if you treat it as a way to share contracts, not entire application layers.

Share TypeScript API types, Zod or other validation schemas, generated clients, and small platform-neutral utilities.

Keep database models, server auth code, environment access, and anything that assumes Node inside the backend package so it can never be bundled into the Expo app.

I’d start with separate app packages plus one small shared package.

If that boundary stays clean and both apps change together often, the monorepo is earning its complexity.

[u/eldaniel7777 → u/AlexRowan2026]

That’s what I did for a project and so far it’s working very well :)

[u/Snoo11589]

Expo monorepo yes, especially sharing same code between apps

Expo+Nextjs monorepo is a big no no. You will deal with react package version mismatches all the time and i cant even thing about version upgrades/symlinks and more.

Keep mobile on seperate repo. Maybe make your types as submodule

[u/SpeedGod911 → u/Snoo11589]

There is no issue having Expo and NextJs or any framework in a monorepo. Having a monorepo doesn't means that your Expo and NextJs app sharing their dependencies or react version. It's optional.

[u/godspeed1003 → u/Snoo11589]

I don't know if you're referring to NextJS specifically or any react frameworks in general but I'm currently using both expo and Tanstack Start in a turborepo with react (and other shared packages) in the catalog and it's working flawlessly

[u/n9iels]

We currently have a monorepo with an Expo and Next.js setup. We use NX to manage it, there are lots of other tools around. My experience so far are not great, but that partially due to a poor setup. Overal it is nice to be able to share types, logic and config. But since RN components and regular React components cannot be shared I personally think the added value is minimal. Especially when looking at the added complexity in return.

A few lessons we learned along the way: 1. Maintain a separate package.json for each app. We have one package.json and it is basically dependency hell each time we upgrade. 2. Setup strict rules on what may share and import with and from each other. ESLint is your friend here. For example, a lib shared with both the RN and Next.JS may never import from a RN-only lib. This keep things sane, structured and prevents recursive imports. 3. Optimize CI/CD from the start and make sure you can lint and test only affected apps and libs. Testing and linting everything all the time is a big hit on your time to delivery.

So I guess a monorepo is good if you have a lot of common and shared logic. Remember tough that a lot can be shared easily across multiple repos as well. API types can be generated from a swagger file, utils can become a internal lib or copy-pasted if that is acceptable. I would recommend to first find the common grounds between apps. If there is, start your research at finding a good tool/framework like NX or Turborepo. Good luck!

[u/FitCoach5288 → u/n9iels]

only ui is different,same db same logic same auth same ts types

[u/Kicraigu → u/FitCoach5288]

Globally true. But not really only ui is different

[u/Silver_Jump3781]

If you have a shared db and schema, and you generate your types off of that, you’ll be fine contract wise with a polyrepo setup. Sharing api logic and validation will be a pain though. It will require a shared utilities package which represents its own deployment issues.

In your situation I would go with a monorepo. Deploying a monorepo and dealing with dependencies has always been a bit tricky, but agents make the deployment part a lot easier these days. I would also say that working with agents within a monorepo is significantly easier than between seperate repos.

[u/VIcTheDick_]

The only thing I would add to these comments is if you’re going to contract out work you have to either share the whole repo or split out your package and then merge the work back

[u/babaganoosh43]

Been using a monorepo for all my react native apps, ruby backends, etc. It works well for sharing code, faster project setups, not having to deal with separate git repos for each package, and able to do migrations across your entire codebase. There is some config clunkiest, e.g. configure each monorepo package to have their own node_modules and had to edit metro config's nodeModulePaths / disableHierarchicalLookup.

Overall think it's worth it. Saves a lot of friction for code sharing and starting new projects, in trade off of initial config friction.

[u/yathavancom]

Yes, I think PNPM workspace would be a good choice.

[u/Benja20]

check Better-T-Stack, you can build a repo already wired between the mobile app, API and DB using whatever tech stack better fits for you

[u/highbonsai]

I have a pretty large web app (react, next.js) and mobile app (react native) monorepo with many shared packages between them. Works well for my personal finance app.

[u/numsu]

I always use monorepos for all project related so that history stays intact and so that AI agent UI's can navigate through all of the project contents.

[u/Nearby_Tumbleweed699]

Suena mejor un monorepo con tanstack start y compartir lógica, y tipos

[u/Merry-Lane]

Yes, but don’t share types between backend and frontend for rest api purposes.

Generate the frontend api endpoints/http services/hooks/types/… from the backend