My take on the monorepo argument after seeing it play out on a few different teams. These experiences are with having 2 - 50 projects in a monorepo, spanning web and mobile dev.
While monorepos make sharing modules, updating dependencies, and working on FE/BE a lot easier, you trade that inconvenience for tooling around your CI/CD system. For example,
you'll have to make sure you only run the builds for the parts of the projects that have actually changed. No one wants to sit there and wait while you loop over every folder running the build command. Yes, I have seen a project starting with Z takes 1.5 hours before CI starts building it (alphabetical sorting).
you're at the mercy of your CI system for how you can split up the builds into separate pieces when they're all in the same repo. (Jenkins was quite annoying about this but this was before Jenkinsfile)
as another user mentioned, git tags and git related things get really wonky depending on how you've scripted it. Multiple projects can't create the same git tag since it'll just move the tag around.
I can't share anything between js, ruby, java, and terraform files so I get no value there if they're all in the same repo.
if a dependency is updated, you still have to test and release all the services that depend on it alll at once, lest you have projects sitting in the repo accidentally broken. You can make this a lot easier by investing more in automated testing though.
all teams using the repo need to follow the same branching strategy. Some teams might want to use git-flow, cut release branches, and others want to ship from master.
the argument that all you need is one git clone doesn't provide THAT much value. I hand new devs a Google doc with a repo(s) to clone and it takes them 10 minutes to clone multiple repos. Saving them 5 minutes here by using a monorepo gets me nothing.
at any given time, I only use 10% or less of all company repos so I don't quite care about having the remaining 90% of them up to date.
A good implemention I saw had the back end, front end, deployment scripts, and infrastructure in the same repo but this was limited to one product so it was just 4 subfolders. That was a pleasant experience. It would have gotten annoying if multiple products were also in this repo though.
Anyway, my 2 cents.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My take on the monorepo argument after seeing it play out on a few different teams. These experiences are with having 2 - 50 projects in a monorepo, spanning web and mobile dev.
While monorepos make sharing modules, updating dependencies, and working on FE/BE a lot easier, you trade that inconvenience for tooling around your CI/CD system. For example,
A good implemention I saw had the back end, front end, deployment scripts, and infrastructure in the same repo but this was limited to one product so it was just 4 subfolders. That was a pleasant experience. It would have gotten annoying if multiple products were also in this repo though.
Anyway, my 2 cents.