4 ms·
> How does a "monorepo" differ from, say, using a master project containing many git submodules[1], perhaps recursively One fundamental way it differs is atomi
by dmoy 3y ago
> How does a "monorepo" differ from, say, using a master project containing many git submodules[1], perhaps recursively
One fundamental way it differs is atomic commits. You can't change something in repo A and subsubrepo XYZ in a single pull.
A monorepo allows you to do things like atomic commits to arbitrary pairs of files in the repo, which among other things opens up the possibility of enforcing single-version of libraries, which in turn removes a whole class of diamond dependency issues.
There's other benefits, but imo it's probably not worth it for most companies because of the staggering number of things it breaks in the developer toolspace once it gets large enough. Eventually you need teams of people that do nothing but make tooling to support monorepo scaling, because everything off the shelf explodes (what do you do when even perforce can't handle your repo?)
For example, at Google we have a team of people who do nothing but, effectively, recreate the cross referencing and jump-to-def everyone else gets for "free" from IntelliJ / VS intellisence, etc. (We do other stuff too, but that's a fair paraphrase). And on top of that the team really only exists because Steve Yegge is a Force to be Reckoned With, otherwise we might still be flailing around without jump to def, idk.
- jeffbee 3y agoThe ability of Google's internal code search to jump between declaration, definition, override, and call site is miles ahead of what Intellisense can do.
- HdS84 3y agoOne Major Point for monorepos is the ability to eschew packages. In most languages creating, publishing and consuming a package is a lot of work, while in a monorepo you just add a reference to the code and are ready to go (except in react native...gaah that was pure horror). That's especially valuable if you need to refactor something and need to adjust it's dependencies. Doing that via packages is slow and painful. Via project references it's mich easier and has a tight feature loop, change+build+fix instead of of change+build+publish+consume+fix
- dmoy 3y agoYup, agree completely. That's a natural extension of the same thing that enables atomic commits - suddenly just having direct library dependencies instead of packages isn't that big of a problem if you push everything into the monorepo. > That's especially valuable if you need to refactor something and need to adjust it's dependencies. And yes exactly, being able to change a library and all of its callers at the same time is pretty handy.