Evaluate and replace nx with an alternative

[brionmario]

Current Limitation

ThunderID currently uses Nx as the monorepo orchestration tool. While Nx provides a rich set of features, it also introduces a significant dependency footprint and maintenance overhead. Recent dependency audits have reported a growing number of vulnerabilities originating from Nx and its transitive dependencies, resulting in increased noise during security reviews and dependency management.

In addition, many of Nx's advanced features may not be fully utilized within the project, and we are just using it for build caching and affected commands.

The evaluation should consider:

• Dependency footprint and security posture (⚠️ !IMPORTANT)
• Build and task orchestration capabilities
• Caching support (⚠️ Local support is mandatory)
• Developer experience
• CI/CD integration
• Migration complexity
• Long-term maintenance costs

If a suitable alternative is identified, create a migration plan and replace Nx with the selected solution.

Suggestions

Evaluate alternative monorepo solutions and determine whether a lighter-weight or lower-maintenance approach would better suit ThunderID's requirements.

Potential alternatives

Turborepo

https://turborepo.dev

🟢 Pros

• Rust based

• Zero runtime JS dependencies

  

• Very fast incremental builds with remote caching

• Great DX for Next.js / Vercel ecosystems

• Simple configuration compared to older monorepo tools

• Strong caching model (local + remote)

🔴 Cons

• Opinionated around modern JS/TS workflows
• Advanced custom pipelines can feel limiting
• Best experience often tied to Vercel ecosystem
• Less control compared to lower-level task runners

Moonrepo

https://moonrepo.dev

🟢 Pros

• Highly flexible and modular architecture
• Strong task orchestration and caching model
• Good for large-scale monorepos with complex boundaries
• Supports polyglot setups (not just JS/TS)

🔴 Cons

• Has untime JS dependencies
  
• Smaller ecosystem and community compared to others
• Steeper learning curve
• Documentation still evolving in parts
• Fewer “batteries-included” presets

Rush

https://rushjs.io/

🟢 Pros

• Battle-tested in large enterprise codebases
• Strong dependency management and versioning workflows
• Very predictable and deterministic installs
• Excellent for governance-heavy environments

🔴 Cons

• Has untime JS dependencies
  
• Heavy configuration and conventions
• Slower onboarding for new contributors
• Less “modern DX” compared to newer tools
• Build experience can feel verbose and rigid

Open Questions

• Overall WDYT?
• Any other alternatives?

[RandithaK]

+1 for moonrepo as it supports a wider number of languages.

Flutter SDKs

Would need Dart Support

[brionmario]

I removed this section since we are moving SDKs out of the monorepo.

[pavinduLakshan]

Regarding rush.js, all of its core dependencies come from the RushJS ecosystem itself. After going through their docs, it feels more focused on open-source development, with comprehensive configuration guides, solid docs, an active community, and the advantage that we already have people (in cross functional teams) with prior Rush experience.

So, +1 for doing a PoC with Rush and evaluating how well it fits our requirements.

Also, if it's possible, maybe we could even vibe-code a dependency-free lightweight solution just for frontend build caching 😃?

[brionmario]

One of the main motivations for moving away from nx is the heavy dependency tree. Which resulted in a number of security incidents we had to rectify.

From what I can see, Rush seems to sit in a similar space. Even though it’s maintained by Microsoft, it may still introduce a fairly deep transitive dependency graph, which could mean that vulnerability fixes take time to propagate across the entire toolchain.

What are your thoughts on this?

[pavinduLakshan]

Even though it’s maintained by Microsoft, it may still introduce a fairly deep transitive dependency graph, which could mean that vulnerability fixes take time to propagate across the entire toolchain.

Agreed. However, what guarantees do we have that Turborepo won't introduce additional dependencies or tighter ecosystem coupling in the future? Based on its current dependency footprint, it appears to be a viable option today, but that could change over time.

RushJS, on the other hand, has been a community-driven project for many years, and Microsoft has not shown any significant effort to commercialize it or tie it to a broader platform strategy.

Also, since Turborepo is backed by Vercel[1], there's a possibility that its roadmap could become increasingly aligned with Vercel's platform interests, similar to concerns raised around Nx. If that happens, we may find ourselves facing the same problems again in the future.

[1] https://vercel.com/solutions/turborepo

[brionmario]

Agreed with your concerns. However, IMO, both are OSS projects backed by large corporations and supported by broader communities. Ultimately, there are no guarantees that any company will continue to invest in these project. And the expectation with OSS is that the community will continue the effort. This however is not a guarantee that anyone can give.

Additionally, one of the reasons we currently stick to only the caching capabilities of Nx is to minimize our coupling a one solution. We can always switch to a different one later.

I’m +1 to move forward with any solution that has had zero or minimal security incidents in the past. We can evaluate based on that criterion and pick one.

Whatever we choose shouldn’t end up costing us ongoing human hours or AI tokens on fixing security vulnerabilities since these are just monorepo management tools, and they don’t contribute directly to the product functionality we’re building, so the maintenance overhead should stay minimal by design.

[JayaShakthi97]

Rush

There are two big disadvantages we should consider;

1. Configuration overhead and migration overhead
   • Rush wants to own the whole monorepo, including install, linking, versioning, and caching. As per my findings, we can't take only the caching functionality.
   • Rush runs pnpm underneath but doesn't support catalog, and owns the lockfile.
2. Large JS dependency tree - this is the main concern we are trying to avoid.

One major feature in Rush is centralized dependency governance + coordinated multi-package publishing at scale.

Moon

Since we do not focus on GO caching, and we are moving SDKs out of the Monorepo, I do not recommend considering moon anymore. It is suitable if we want a single unified runner across the whole repo.

DIY tool

I am strongly against this, considering the maintenance overhead. And we may have questions like, which team should own and maintain the tool?

Turbo

1. zero runtime dependencies
2. Turbo's model lines up with our existing setup with content-hash caching.
3. Very low migration overhead.
   • The config maps closely from nx.json → to a root turbo.json
   • But we may need a turbo.json in each package, since Turbo's ^build follows only dependencies/devDependencies, not peerDependencies. turbo.json in each package will define its dependent internal packages.
4. Single-vendor governance risk is there. IMO, this is not something we can avoid unless we implement our own tool.

Considering the above points, I am +1 towards Turborepo.

[pavinduLakshan]

+1 to turborepo especially given that

Rush wants to own the whole monorepo, including install, linking, versioning, and caching. As per my findings, we can't take only the caching functionality.

[JayaShakthi97]

The conclusion is to go ahead with Turborepo.

• Tracked via: Replace Nx with a lighter-weight task runner (Turborepo) #3546