Monorepo is not particularly new, but if you want to be like the big organizations that routinely discontinue their products then what you should be doing is throw out all your CI/CD configurations and shove all your repositories into one.
The idea is that it will be easier for cross-project collaboration since everyone is set up in the same repository, minimizing the setup needed for permissions but without losing the benefits of code ownership if configured correctly. It will be easier to share and reuse code without any complex dependency management, and keeping a consistent version of your projects across the organization will be easier (because everyone may update in the same commit).
As far as I’ve investigated, this does not bring any tangible benefits whatsoever. You will have to customize your build tools to support the fact that your repository now contains multiple projects, which may need their own 3rd party dependencies. Any basic VCS operations such as fetching, merging, checking out branches, needs specialized software on your servers to not take absolutely forever (a basic git configuration would take minutes at best for the most basic operations), while merge conflicts, as wonderful they are traditionally, would become even more wonderful in a monorepo.
Why settle with a monorepo? It’s annoying to have multiple files, and since we are specializing our software to be able to build multiple projects from one repository, spanning different languages, why not be one more hip and go with monofile? That’s right, just cat every single source file under your organization into one, huge, monolithic file.
You can use find/replace across your whole codebase from your editor of choice! Nice! No need to worry about dependencies anymore - it’s all built at the same time anyway! Remember how easy it was to reuse code using monorepo? Now we even reuse variables! Global variables have never been so global! The benefits are absolutely endless. If there’s a bug you can count on your whole organization being on top of it! Never again do we rgrep to find the file where something is at - we’re already in it! Never again do we need to configure code ownership or pesky permissions. Backups are easy.
My hyperbole above was rebutted with the hypothetical organization that instead of having multiple repositories per project, divides their projects up in a way that each file is kept in a separate repository, built as separately as possible as libraries and then tied together that way. The argument was that any argument for keeping files together in a repository, could also be used for keeping repositories together in a monorepository.
However, I invite any readers to create their next project using this methodology, or to migrate their current project. Please comment below with a link to your repositories and I’ll follow with great interest how this goes for you.