
Ask if you're good enough for a monorepo - skybrian
http://yosefk.com/blog/dont-ask-if-a-monorepo-is-good-for-you-ask-if-youre-good-enough-for-a-monorepo.html
======
ungzd
Described problems are not unique to monorepos.

If changes in some component's repo cause this component to break iOS, but you
absolutely must use this change right now for Android, you will be left with
branching too. Or, maybe, specifying different versions, if you use more
complex packaging than git submodules, and only if android and ios apps are
not built from single codebase.

Modularity is when APIs are well-defined and there's no unnecessary coupling.
For example you don't know where public API of your component ends. Monorepos
help here: it can make it clearer because tests will fail sooner when you
break API contract because as soon as you make changes to component, these
changes will be tested against users of this component.

I regularly have all described issues (except large number of files) without
monorepos.

The real stopper is that to introduce monorepo you need advanced build system
with dependencies between targets, which include tests (if tests already ran
in previous build, and nothing is changed, don't run tests for that piece of
code again), and that requires hermeticity. Almost impossible with e.g. Rails
app and regular CI.

