Or in other words, when would you recommend using them, and when would you avoid them?
Ask HN: What are the pros / cons of using monorepos?
1–10 of 100 posts
Re: Ask HN: What are the pros / cons of using monorepos?
#2Pros:
* Single version / branching for everything
* Commits that go across components/apps are atomic.
Cons:
* When it gets big, those features matter less
* Churn from other dev's stuff gets in your merge/rebase work.
* 'git log' and other commands can be painfully slow
* Mistakes in the repo (e.g., committing a password) now affect many more people.
Use for highly-coupled source bases. Where releases together and atomic commits are very useful. Every other time, you're probably better off splitting early and taking a little time to build the coordination facilities needed for handling dependency versioning across your different repos.
Note: I used to really prefer monorepos, but I've had some time away now to take a better look at it. Now they feel like megaclasses where small things are easier (because everything is in one place) but large things are way harder (because there's no good split point).
Re: Ask HN: What are the pros / cons of using monorepos?
#3[deleted]
Re: Ask HN: What are the pros / cons of using monorepos?
#4The big advantage of a monorepo is that dependency on changes to a "library" or component that gets reused in multiple places can be made explicit. A user can commit a change that safely modifies a library or component in a non-backward-compatible fashion AND changes all the places that use it. This is far simpler than the alternative of releasing a non-compatible version of the library/component and maintaining both in parallel for a period while the users transition.
The big advantage of separate repositories is that the work done on them is very clearly marked as independent. It becomes easier to take one component out and utilize it elsewhere... but at the cost of having to deal with dependency management. Dependency management is simple and automatic in easy cases and really terrible in hard cases (like when two components you use mandate mutually exclusive versions of a third component).
So I think the driving factor in the decision is the tradeoff between the degree to which you are willing to invest in careful packaging of each component (and the corresponding dependency management), versus your willingness to force everyone and everything to utilize the monorepo.
(Notice I didn't mention performance issues. I really don't think they are important enough the control the decision.)
Re: Ask HN: What are the pros / cons of using monorepos?
#5Reduced overhead for ci/cd, code review, code syncing and branching.
No need to sync multiple repos and have complicated dependency versioning for in house libraries.
In house libraries are easier to refactor as dependent code can be updated in a single PR.
Code tends to be more reusable and you tend to make more reusable libraries as it is as easy as creating a new directory in the repo.
Services and tools can still have separation of control with all the monorepo advantages.
The only reason to not monorepo is if you are thinking of open sourcing the lib/tool you’re building but even then you can cut it out of the monorepo.
Re: Ask HN: What are the pros / cons of using monorepos?
#6I don't have a lot of experience with monorepos but I've found them very useful for:
- Simple projects with a server and an SPA component - frontend and backend code for the same feature is on the same feature branch, can be tested and reviewed together.
- Projects with a couple of microservices that share some common libraries - these libs can be directly referenced by the microservices instead of being published on an internal package server. This of course has its drawbacks too but overall, the benefits have outweighed them.
Re: Ask HN: What are the pros / cons of using monorepos?
#7It would also be interesting to hear about the tooling available/recommended for maintaining monorepos.(ideally FOSS tooling, but good proprietary ones as well)
Re: Ask HN: What are the pros / cons of using monorepos?
#8Google posted a paper detailing their reasons for choosing monorepo: https://research.google/pubs/pub45424/
Caveat: your company probably isn't Google, so your challenges may be different.
Re: Ask HN: What are the pros / cons of using monorepos?
#9Mono repos can be useful if you have different services that are highly dependent on each other. This lets you package releases in a simple way by just tagging the repo. That tag/release gives you the exact version of all the components that you need.
But CI becomes substantially more complicated. You have to figure out with every commit what actually changed and based on that change what needs to be tested and built. You don’t want to run a build of all components if you only changed a small piece of one component.
Re: Ask HN: What are the pros / cons of using monorepos?
#10For me the biggest pro and con are the same thing. With a monorepo your respective projects' codebases become tightly coupled.
Why that can be a bad thing? Good software engineering practices tend to be associated with loose coupling, modularity and small, well-defined interface boundaries. Putting each project into its own repo, encourages developers to think of it as a standalone product that will be consumed by third-party users at arms length. That's going to engender better design, more careful documentation, and less exposed surface area than the informal cross-chatter that happens when separate projects live in the same codebase.
Why that can be a good thing? The cost of that is that each project has to be treated as a standalone project with its own release schedule, lifecycle support, and backwards compatibility considerations. Let's say you want to deprecate an internal API in a monorepo? Just find all the instances where it's called and replace accordingly. With a multi-repo it's nowhere near as easy. You'll find yourself having to support old-style calling conventions well past the point you'd prefer to avoid breaking the build for downstream consumers.