asinghbrar

Any tips or advice for monorepository tooling?

Hi everyone,

We’re in the process of moving our organization toward a monorepo and I’d love to hear from folks who’ve done this with Elixir in the mix.

Right now our primary codebase is an Elixir monolith, but we also run essential services in Java, Go, and Python, and our frontend is in TypeScript. As we continue to scale, parts of the Elixir system will be split out into separate services, and some of that functionality will likely be reimplemented in Java.

We’re evaluating build/test tooling for the monorepo and are currently looking at Bazel. The challenge is that Bazel’s Elixir ecosystem still feels pretty early, so we’re trying to figure out whether to invest there or consider other approaches.

If you’re running Elixir in a polyglot monorepo (especially alongside JVM services), I’d really appreciate any lessons learned:

What build / test / packaging tooling are you using?
How are you handling dependency isolation and release management?
Any gotchas with cross-language CI or incremental builds?

Happy to share more context if helpful, and open to DMs if you’ve been down this path and wouldn’t mind a quick chat.

3 comments

#monorepo

2 268 3

2025-11-04 18:35:43 UTC

Most Liked

Arsenalist

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.

Post #1

phcurado

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.

Post #2

Last Post!

asinghbrar

This is super helpful, thank you. We also lean on mise-en-place as a first-class tool for dependency management, and I briefly looked at its experimental monorepo support. That said, it still feels a bit early for our use case, we’d really like to take advantage of the CI, caching, and packaging benefits you get from more mature monorepo tooling, especially since we already manage a frontend monorepo with Nx.

Post #3