DEV Community

Discussion on: From Spaghetti to Scalable: How I Modularized a Growing Frontend Codebase

Collapse
 
_arpy profile image
Arpy Vanyan

Good question! We actually never considered Git submodules for our project, and here’s why.

While submodules offer a way to manage separate repositories within a parent repo, they come with their own challenges. We ultimately went with an NX monorepo because it provided a more seamless development workflow for our modular frontend.

Here’s a quick pros & cons:

✅ Pros of Git Submodules:

  • Keeps repositories independent – Each module can have its own history & contributors.
  • Useful when projects are truly separate – If teams work on completely unrelated parts, submodules can help.
  • Granular access control – You can give access to only specific repos instead of everything.

❌ Cons of Git Submodules for us (Why we didn't use them):

  • Versioning headaches – Each submodule has its own commit history, so keeping everything in sync is a manual process.
  • Complex local development – Developers need to initialize, pull, and update submodules separately.
  • Harder dependency management – If multiple submodules depend on the same package, it’s difficult to coordinate updates.
  • Not ideal for tightly integrated projects – Our frontend app needed shared dependencies and consistent CI/CD, which submodules don’t handle well.

🎯 Why We Chose a Monorepo Instead (NX):

  • Easier dependency sharing – Every package/module is in the same repo, reducing version conflicts.
  • Faster local development – No need to manage multiple repo states manually.
  • Consistent CI/CD pipelines – We can run tests, builds, and deployments across all modules efficiently.
  • Built-in tooling for modularization – NX understands dependencies and only rebuilds what’s necessary.

In short: Git submodules can work well for truly independent projects, but for our case—where modules were tightly coupled and shared dependencies—a monorepo with NX was the better choice.