Pros: some tooling features just don't work across repos (e.g. npm dependency resolution). A monorepo works around these limitations.
Cons: un-separation of concerns.
Ask HN: What are the pros / cons of using monorepos?
21–30 of 100 posts
Re: Ask HN: What are the pros / cons of using monorepos?
#22It usually begins as
let’s split our project into multiple libraries so it can be reused within the company or even better if we put it on GitHub everyone can use it.
After a few months you notice nobody within the company cares about your nicely versioned libraries and on GitHub you get more and more complaints that the libraries are very limited and need more features.
After that you merge everything back into your monorepo and try to forget all the time wasted on git bureaucracy, versioning, dependency handling and syncing changes between repos.
Re: Ask HN: What are the pros / cons of using monorepos?
#23[deleted]
Re: Ask HN: What are the pros / cons of using monorepos?
#24Tangentially: How does one manage a monorepo based on git?
Re: Ask HN: What are the pros / cons of using monorepos?
#25We are breaking our monorepo into 3 kind-of mono repos based on release cadence. A repo for each of two large applications plus a third repo for shared library code. We import the share library code onto the app repos using a git sub module. Has anyone else used git sub-repos to import common code?
Git submodules have a comically bad user interface imho but they work really well so I use them despite this. As with git in general the core functionality is solid. There is also something to be said for making as much of core functionality without resorting to another piece of infrastructure. People can use whatever front end they prefer on their machine but in a pinch the core git package is all you need.
Re: Ask HN: What are the pros / cons of using monorepos?
#26Pros: * 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 a…
> Churn from other dev's stuff gets in your merge/rebase work
Wouldn't other people' work only cause issues if they are changing the same files, in which case conflicts would happen even if the work is spread in multiple repos?
Re: Ask HN: What are the pros / cons of using monorepos?
#27Pros: * 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 a…
> Churn from other dev's stuff gets in your merge/rebase work Wouldn't other people' work only cause issues if they are changing the same files, in which case conflicts would happen even if the work is spread in multiple repos?
yes, this isn't really an objection.
Re: Ask HN: What are the pros / cons of using monorepos?
#28code reviews and ownership boundaries are less clear on a large code base in a mono-repo. Depending on your team culture, this will either be a pro or a con. While careful design of the build system can mitigate build times, there is likely to be some disagreement on basic practices such as "how to launch a service" or when to use spring vs. guice vs. rails that will be tougher than simply letting everyone go their own way.
Refactors and cross-service deployments can become much simpler in a MonoRepo.
Re: Ask HN: What are the pros / cons of using monorepos?
#29Use them whenever things are one project, only split them up when it's legitimately separate projects.
At work I set up a repo with our back-end code in one directory, the front-end in a directory, and the ansible playbooks/other deploy stuff in another..
This allows us to automatically create servers for every branch because we know that everything goes together. Working on other projects where they have all of these separate is a nightmare. Especially when they use microservices and each service has its own repo and each library has a repo... I want to smack anyone who ever thinks that is a good idea
Re: Ask HN: What are the pros / cons of using monorepos?
#30I 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…
If you don't publish packages anywhere, wouldn't that mean that if you update some library with a breaking change, you have to update all call sites?
Maybe the fix for that is to never make breaking changes, but that has drawbacks as well...