Immediately after switching the page, it will work with CSR.
Please reload your browser to see how it works.
The reality is that these are somewhat niche usecases for very high scale orgs and/or very high-scale developer workforces which can afford to reinvent the wheel. The way the vast majority of companies should go about developing their systems is not new at all, its just to pragmatically apply tried and tested technologies, and transition to new shiny things where there is a demonstrable need.
Worth saying that I'm definitely a fan of team-scoped monorepos though. Being able to automate building and testing across all my apps, update dependencies across all apps, and deploy with a single merge/pull request is great.
For example, the Linux kernel works with its tens of millions of lines just fine, even though ownership is heavily distributed among many subsystem maintainers. Checking out a branch or pulling in changes rarely takes more than a few seconds.
On the other hand, some organizations abuse their VCS, using it as a repository for large immutable files such as build artifacts, software packages or similar non-source archives. Orgs who let this happen are of course going to have a hard time. But that's hardly the monorepo's fault.
Once an org becomes large enough you need lots of custom tooling to make working across a huge codebase smoother, and that tooling is similar for mono and poly repos, but you need an additional metric ton of tooling to make monorepos work
And please pray you didn't decide to go with bazel for builds
My least favourite monorepo experience: I want to update my dependency for my tiny service for a security patch -> Oh, 400 other services depend on it and dozens of tests break when I try to update it -> this isn't worth my time I'll do something else instead
We were promised a world where every dependency was kept up to date by necessity but ended up in a world where all dependencies atrophied due to the increased difficulty to update them
Moving to monorepo is often a win; also the name sucks, we have a a few "monorepos" at work, and I think it's the sweet spot. Rust and C firmware doesn't need to live with TypeScript frontend apps, but it's pretty wasteful to have apps of the same ecosystem unable to share any and all dependencies and utility code trivially.
(Where "trivially" means literally one line of code
and not one single step more.)