I am very interested in this topic and I want to know more about this. I have read about monorepos, and I understand the advantages, but I am more concerned about the disadvantages. More specifically, these four things:
In monorepos, how do you maintain a clean git history? For example, if you have backend + frontend in the monorepo, wouldn't the git history be a complete mess? Or you just don't mix these things?
Security. I have already seen that maybe this is impossible. If you want to restrict access to some "packages", then I believe this is imposibble with monorepos.
What happens when you have packages written in other programming languages other than Javascript? Can you still have them in the monorepo without conflicting with, for example, Yarn Workspaces or Lerna?
How do you run tests for only certain packages? How do you achieve CI/CD for certain packages?
Well, I find all of these things huge disadvantages of monorepos and I think these reasons are enough for not even trying them in real world projects. So trying to find a way to solve these problems, I thought about git submodules. To be honest I haven't worked too much with them (I barely know how to add them to a project and remove them).
Correct me if I am wrong, but with git submodules I think we do not have the capacity to generate "symlinks" like with monorepos. I was playing around with Yarn Workspaces, and when I make a change to one package, this change gets reflected in another package that uses it. This is cool! But I think this cannot be done with git submodules right?
I think that wit git submodules, we can say the following things about the points I just mentioned.
Independent repos have independent git histories, so I think this would get solved.
If I do not have access to one repo, then would running
git clone --recurse-submodulesjust wouldn't give me those repos, or would it throw an error saying that the clone cannot be made because there are repos that I cannot access?We can add submodules written in other languages. But I think they would be useful if, for example, I have some Flask app and the client in React, and if I make some change in the Flask app then I can test that change in the client immediately. Maybe this can be done with some kind of script that starts all the things inside each submodule? After
I think this point gets solved with independent repos.
I really need someone to clarify all of these things to me. I appreciate your opinions!
Discussion (5)
Usually i am doing monorepo approach only for
commonpackages.For example with my infrastructure
@gapi and @rxdi and @rhtml they all are monorepos
github.com/Stradivario/gapi
github.com/rxdi/rxdi-monorepo
github.com/r-html/rhtml
Then inside my application code i have separated repo for Backend and Frontend and all of the microservices that are used in this particular moment they are 10 so i got 12 Repositories
I have 1 more repository which combines all of the repositories as a git submodules
And i am using custom task management system so i can spin up all of the servers and client with single command.
If i am making a framework or a common packages i will use monorepo with lerna or yarn or latest npm
If i am making a business product i would like to have a separated github repositories which uses the packages from the monorepo
In simple words "If it is a framework or utility go with monorepo if it is a business product go with submodules"
Sayed by a guy which works also with
nxmonorepo using Angular and NestJS at one of my contracts. To be honest i don't like how slow it is to transpile and also the nx cache is a bit bigger so we have a big problems with CI/CD since we are caching the results from the build and in the next build we are running only affected packages.Cheers!
I've used submodules over monorepos at two companies, I would highly recommend it. I've usually seen the root repo contain things like onboarding docs, docker compose yaml files, master Makefile, bash scripts, env var and other config etc, and then all the code is in a submodule with a separate repo.
Yes, that sounds great! I think it is very convenient...
For strictly rooted revision control systems a mono-repo is more often a source of problems, than a solution. Most tooling cannot properly handle these kinds of mono-repos. Subversion is one of the few RCSs where any path can be a root, which solves most of the tooling issues.
What's the benefit of a mono-rope? Well, if you don't have to clean boundaries in your software components, a mono-repo is the way to go for your spaghetti.
My monorepo is just for convenience, and does have disadvantages as you listed.
It can contain multiple languages, and I don't usually use Yarn workspace, but even then, I believe you can what to include / not include as part of workspace.
As for clean submodule, I would create an org, and transfer the repo to org; then create multiple submodules in it.