Once upon a time I was working with a company that had a large number of repos (probably ~60 in total; 20 or so in regular use). This was a bit painful. Especially for the SRE team (which I was working closely with), as making otherwise simple changes to a deployment pipeline might mean updating 20 or 30 repositories.
One of the SRE team members proposed a migration to a monorepo, as it would allow us to make these types of changes once and only once. He had also had a good experience with monorepos at a prevoius company.
My honest reply was: “I’m happy to consider this. We need to identify what problems it solves, as well as which problems it will introduce, so that we can either mitigate or accept those new problems.”
He never brought it up again.
So multiple repos for the win? No so fast. I would have said the same thing if the situation had been reversed.
The thing is, each model (monorepo, or multiple repos) has its own strengths and its own weaknesses. Switching from one to the other mid-stream is going to be painful, and I expect not worth it in most cases. Making such a drastic change only makes sense if you’re facing a lot of pain.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (2)
I am working for a client with a few repos, eventually everything is bundled together and the amount of complexity is HUGE. This is a HUGE system with TONS of components and scenarios, and a team-member suggested switching to monorepo because of all the shared dependencies in
package.jsonbut i'm not sure it's worth the messI'd ask them the same question: "What problems will it solve? And what new problems will it introduce?"
You're probably right that it's not worth the change. But there are times when it is.