Monorepo: please do
medium.com
Monorepo: please do
1–10 of 166 posts
Re: Monorepo: please do
#2In my experience, this discussion gets convoluted by confusing modularity with monorepo. They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo.
Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.
Re: Monorepo: please do
#3Please don't. It's just too slow and not efficient. Instead use common open source best practices of shared library architecture. Problem solved!
Putting everything into one repo is just lack of organization and creates a huge mess.
Re: Monorepo: please do
#4In my experience, this discussion gets convoluted by confusing modularity with monorepo . They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo. Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.
It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?
Re: Monorepo: please do
#5In my experience, this discussion gets convoluted by confusing modularity with monorepo . They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo. Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.
It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?
Chances are you will end up downloading a lot of dependencies anyways, why not have git deliver it all?
Re: Monorepo: please do
#6In my experience, this discussion gets convoluted by confusing modularity with monorepo . They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo. Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.
It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?
If a mono-repo has a terabyte of code, or if 10 small repos have 1/10th a terabyte each, what have you really gained? In any case, git LFS solves large file storage effectively, as do a number of other artifact storage solutions, and a repo with a terabyte of code is _not_ going to be trivially split apart, since it would be by a factor of thousands, the biggest codebase ever created by humankind.
Re: Monorepo: please do
#7In my experience, this discussion gets convoluted by confusing modularity with monorepo . They are orthogonal to each other; you can have a very modular codebase in a monorepo but also a very coupled (non-modular) codebase with polyrepo. Though it's true that monorepos without proper discipline can tend towards coupling. Yet, when discussing mono vs poly, we should keep this in mind.
It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?
A terabyte of code ? jesus.
Re: Monorepo: please do
#8Earlier quoted context omitted.
It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?
Chances are you will end up downloading a lot of dependencies anyways, why not have git deliver it all?
Huh? You'd download dependencies for the repos you need, not the code and dependencies for the entire company.
It could be several orders of magnitude larger and with a larger organization could be a lot of unnecessary code that any given Dev may never touch.
Re: Monorepo: please do
#9Earlier quoted context omitted.
It's not, why do I have to checkout terabyte of code that I don't need, even if the code is modularized?
If a mono-repo has a terabyte of code, or if 10 small repos have 1/10th a terabyte each, what have you really gained? In any case, git LFS solves large file storage effectively, as do a number of other artifact storage solutions, and a repo with a terabyte of code is _not_ going to be trivially split apart, since it would be by a factor of thousands, the biggest codebase ever created by humankind.
If I only need to check out one of the smaller repos then I've gained quite a lot in terms of download speed, storage size, etc. Git LFS adds a lot of complexity I'd rather avoid.
Re: Monorepo: please do
#10Please don't. It's just too slow and not efficient. Instead use common open source best practices of shared library architecture. Problem solved! Putting everything into one repo is just lack of organization and creates a huge mess.
Too slow as in "to do it" or too slow as in "to use it". In either case I think if that were true there wouldn't be monorepo's at Google, Facebook, and Microsoft. I will say it's true that didn't come for free, e.g. Microsoft had to make GVFS due to the sheer enormity of their codebase but that's already done and works pretty well.
I agree share library style makes more sense in most cases though. The main problem with it is forcing everyone to use the latest library versions but that isn't insurmountable by any means.