It’s an imperfect analogy but it’s useful to think of an umbrella as a monorepo, because you can assemble a release that only has one or a few of the umbrella children included. It’s a natively supported concept. In order for that to hold true, each umbrella child need to comprehensively list its runtime and compile-time dependencies in its own mix.exs file to be semantically correct, or you might produce non-viable releases for that subset of the umbrella.
If you only ever run/test/release from the root of the umbrella you’ll eventually find that you’ve been shadowing important concerns. If you never ever intend to deploy the components in a modular way, I’d posit that your umbrella structure is largely ceremonial and producing low to no value as an architectural choice.
With the exception of in_umbrella deps and some relative paths in mix.exs I highly highly encourage writing your umbrella apps with zero awareness that they are in fact a member of an umbrella. You’ll have better chances of success at runtime/deploy time and cleaner boundaries between the siblings. Elixir 1.11 will bring some small benefits with regards to circular dependencies and ignoring those boundaries.
