My concern would be introducing the complexities of inheritance (and even multiple inheritance) into an otherwise simple configuration. One of the key things I learned from years of Java was to avoid these approaches and use composition, which provided much greater flexibility.
Would using tools.build be a simpler approach to addressing this issue with mono-repos?
In the example posed in the original question, would there be a mechanism to guard against or at least warn of a situation of
:dev/all-projects or another alias that grouped aliases? How many levels down could this grouping go ?
Would there be well defined precedence rules?
Would there be tools to diagnose where the conflicts are - perhaps -Stree is enough, but I am not sure
Would aliases grouping be limited to aliases defined in the project deps.edn or would the user level deps.edn be also included (I assume it would add more complexity to exclude the user level config)
Perhaps a way to avoid this would be to have something like a
:meta-aliases that could only include alases and not other
:meta-aliases, but then that still seems to be adding complexity.
I would hope that the issue specific to mono-repls could be solved without adding complexity to the
deps.edn configuration (especially avoiding inheritance or even multiple inheritance).