Understanding monorepos

Originally published at: Understanding monorepos - Ionic Blog

When we think about building apps, we’re typically talking about one app, one git repo, and one build output. However, this one-app-one-repo setup is not always reflective of the real world experience of developers. Oftentimes, organizations will make use of a single repository with every app, component, library that could be used being developed there.…


That’s an interesting post and a good reminder that monorepos have benefits.
The problem is that it also comes with complexity especially for peeps like me who don’t have much or (only bad) experiences with it (in my case using git submodules where deadlines were roaming).

This also comes at a good time as I (and I’m sure I may not be the only one) am trying to figure out what would be the best way of having an Ionic Vue app and a Node.js backend work together from a deployment perspective (tools like Lerna might help) in a way I can get them to be deployed in sync (in transient/staging environments) but getting the CI/CD to not have a hard time running the NPM scripts for each.

I’m looking forward to the next post.

1 Like

Thanks for sharing, what do you think about Yarn Workspaces vs Lerna vs Bit vs Nx? Nx looks interesting but let me know!

1 Like

If you like the “batteries included” approach that angular provides, NX is the next closest thing. Vs all the other tools which you need to wire up how your app gets built, how deps are managed, etc.

NX forces all your sub-packages to be on the same version of everything, which is very nice.


I came here from the blog post and gave NX way of managing a monorepo a shot. However, faced issues with --livereload, which prompted me to try and wire up an extensible project template just for this. You can find it here. HTH.