It has been 4 months since DayOne has decided to switch from a multi-repo workflow to mono-repo. It wasn’t an overnight decision to make, in fact, while we were deciding on it, there was also pressure on roadmap delivery. And at the point of time the team is pretty lean. Still, the team bite the bullet and decided to be bold and transited our tech stack from Multi-Repo to Mono-Repo.
Our stack is pretty straightforward, we have a website and we have mobile app on both iOS and Android. Our web is running on ReactJS, our mobile is using React Native with a managed workflow in Expo.io. Our backend is mainly running on firebase - our serverless solution and the rest of the services are running in Containers in Cloud Run. We are big fans of Google Cloud Platform and we keep our stack to google’s ecosystem.
We are big fans of Google Cloud Platform
Why we decided to move to mono-repo?
- We are using Redux Toolkit and we want to maintain a common State Object between both ReactJS and React Native.
- Having a multi-repo means we are re-writing our State Management between ReactJS and React Native + any future solution, like NextJS.
- We want to move our Hooks and Reducer and Selector libraries to be shared among the application.
- Our Firebase SDK, Types and Interfaces (we are using typescript for both), UI Libraries, Helper Libraries and other common libraries are synced in both app and web.
- Our team structure is Feature Driven. Meaning, an engineer or a squad takes ownership of a feature. Owning a feature means taking care of the Web version and the App version as well, thus having a mono-repo, the team owning the feature can have access to both App and Web codebase, while at the same time, can be given the foresight to write common libraries or component to be shared between them. 2 different platform, 1 common function — DRY.
Our team structure is Feature Driven. Meaning, an engineer or a squad takes ownership of a feature.
Of course having said that, there are some cons of using Mono-repo, but to us, it is more of inconveniences.
- You might have more code conflict, since there’s no separation of concern. And that is why our team is pretty much disciplined in rebasing their code.
- Build times — some times you have to rebuild all the libraries but it is not really an issue since we have our CI/CD pipeline.
- Security — Now your full codebase is in 1 single repo. Putting all your eggs into one basket. As currently our team is small, we believe our IP is still guarded, but that would be a future concern when the team gets bigger and more features and codebase are exposed. BUT, if you have external vendors or contract engineers, make sure they are trusted.
You might have more code conflict, since there’s no separation of concern.
If you are still on the fence wondering if you should move your codebase to a mono-repo, here’s a Charlie Munger exercise — instead of asking Why? Ask Why Not. Why do you think multi-repo is the default while mono-repo is an alternative.
If you are exploring, here’s some resources to get you started
Workspaces are a new way to set up your package architecture that's available by default starting from Yarn 1.0. It…
expo/packages/expo-yarn-workspaces at master · expo/expo
This is a package that provides support for Yarn workspaces within monorepos like the Expo repository. It finesses Yarn…
Thanks for reading. Here’s the song Life in mono for your enjoyment.