Having to update multiple repositories (version bumps) for a change on a single package breaks the atomicity
If 2 people need to work on the same file they will need to work on the same file even if it is on a separate package.
We don’t apply any privilege control and I am not of the philosophy that employees should have limited visibility. All our employees get access to all our gitlab repos (>100). Also scaling is not an issue, even Google, Microsoft Facebook have mostly monorepos and their codebases are huge. A good read on monorepos: https://monorepo.tools
That’s correct
I agree and that is the reason I want to avoid an umbrella. And this is also the reason I don’t want to split it into multiple services on their own repos. With path dependencies on the same repo and independent mix projects you solve all of these issues. With the proper tooling you can also speed up the CI pipelines no matter how big the codebase is.
