Hey, I see this happening in my app in the future and was doing some research on some tooling like Nx etc, but I’m contemplating just managing this stuff using mise and it’s Monorepo support which is experimental:

Benefits like detecting affected files etc may not come out of the box with this approach, but it seems simpler to get started with.

I have used elixir and other languages in a single monorepo. We choose to separate the tooling for elixir projects to the other languages for the same reason you mentioned: The generic tools that handles monorepos doesn’t seem mature enough for elixir.

We used the elixir workspace and it was good for my use case. This project have mix tasks that can identify automatically elixir projects and dependencies, build only changed projects and print the project dependency graph for better visualization of your projects.
Then on our other tools to manage other languages inside the monorepo, we would just ignore elixir projects.

We were using trunk based development, merge to main would release the application. If a dependency was changed, it would build and test app projects that are using the dependency (elixir workspace can identify/track this). We were not versioning the dependencies, since we didn’t want to handle different versions of a dependency inside the same monorepo. This is similar to the Facebook monorepo approach, no versioning to avoid inconsistencies.

For us it worked quite well, I would say better than expected even. It also would depend on the engineers, company development culture and project’s ownership.
One thing we could have done is to have the elixir codebase in a separated monorepo, since we were not reusing anything from the other languages and packages there. I guess this would depend more on your use case, but overall I was happy with the setup.
Atomic changes are great because in a single merge I could deploy multiple projects but you need a good tooling, automated tests, etc on your projects since a single commit can also break multiple projects. In general needs strategy for rollbacks, deployment (blue/green, canary, feature flags, etc) so you are confident whenever you merge/deploy your code.