Ahh, I bet that’s it! I’ve had to work with team sizes at my last job that are way way larger than they ever should have been. My current job has like 4 people that have access, and they still put everything through me regardless. ^.^;

I can see mono-repo’s being fine for very very few programmers on the project, but honestly just keep them as different namespaces in the same thing then, no need for the umbrella overhead. Even for projects by myself I still like to pull the pieces out a lot because it forces me to keep the bounds that I know belong there so I don’t accidentally (and I will otherwise) cross those bounds unless they are enforced.

The thing is that they don’t do that, rather they combine lots of code into a single repository that shouldn’t be touching. Its far easier to just have each part be its own testable library then merge them at the end via the normal built-in elixir dependency system, which is all of a single line added to the mix.exs file each. o.O

Is it though? How about big corporate gardens? Also some CTOs cannot be convinced to self-host a private Hex repo. And they don’t want their stuff on the public Hex.

I believe the idea of a mono-repo being easier to work with – at least when you use GIT – is quite proven but am open to the other point of view.