My 2 cents: monorepos try to solve what is actually a series of devops problems, by essentially abusing the way an organization or individual uses git (or VCS of your choice). These tools that were never designed for devops in the first place.
To elaborate: I think you are much better off, whether as a team or solo developer, developing small, isolated, and tested / reliable libraries and / or packages that can be combined as needed. Ideally, each package or library can build, test, and ship itself at the CI/CD level. Trying to encapsulate all that into one giant conglomerate of potentially different languages, file types, frameworks and much more sounds exactly what it is: a mess!
Developing components like this puts a lot of pressure on the components to each look like a piece of Real Software.
Versioning, stability, changelogs, coordinating new features as beta releases followed by deprecation announcements and finally deprecation. None of this is unreasonable, technically — my Linux OS is made of many small stable projects after all, none of whom communicate with each other beyond broadcasting NEWS.md etc with each release.
It’s also exhausting. Do your competitors hamper themselves by cosplaying a bazaar of open source projects coordinated by whatever your internal equivalent of the Debian project is? No! Move everything under one roof to truly reflect your org structure and take advantage of the fact that you all report to one CTO, you all have real-time communication between each other, and you probably know where everyone else is sat for eight hours a day. Move fast.
> take advantage of the fact that you all report to one CTO
How many companies even have a CTO that knows or cares about version control? In most companies version control is managed by IT if at all, and code for different products is split across different lines of business.
> These tools that were never designed for devops in the first place.
No. Git was specifically developed to manage the Linux kernel project, a famous example of a monorepo.
Every instance of polyrepo architecture I have seen in the wild, comes with some kind of bolt on system which emulates a monorepo. Such as: a top-level manifest file which pins the versions of every repo to a known-good value. With the understanding that if you were to pick any other combination of versions, You Are On Your Own.
My current company does this and it's quite unpleasant. I call it "monorepo as a service".
> Git was specifically developed to manage the Linux kernel project, a famous example of a monorepo.
Is Linux a monorepo? It's one project with a single release artifact. To me, Linux just looks like a big project. I'd define a monorepo as containing more than one project (e.g., if Linux and Git shared the same repo).
Huh? Monorepo refers to storing your source code, regardle5 of how many binaries you build and run, not shipping your system as one giant monolithic binary.
To elaborate: I think you are much better off, whether as a team or solo developer, developing small, isolated, and tested / reliable libraries and / or packages that can be combined as needed. Ideally, each package or library can build, test, and ship itself at the CI/CD level. Trying to encapsulate all that into one giant conglomerate of potentially different languages, file types, frameworks and much more sounds exactly what it is: a mess!