Nx 2025 Roadmap

[jaysoo]

Nx 2025 Roadmap

As an open source project, Nx's commits and PRs are fully visible on GitHub. To provide more insight into the project's vision and direction, this roadmap highlights the key areas that the Nx team will focus on throughout 2025.

Note that this is a high-level roadmap, with features not tied to any specific future version of Nx. We may also update this roadmap as needed to make any course corrections.

Nx Core in Rust

Back in 2023, we started rewriting performance-critical parts of Nx core in Rust, such as caching and hashing. The move to Rust already shown speed benefits when running tasks in Nx, but we can go even further.

In 2025, we will bring the Rust story to its logical conclusion and port the rest of Nx core (i.e. thenx package itself, including the CLI) into Rust. This means that if you don't use any Nx plugins, then Nx itself will no longer require Node. Node is a fantastic platform, however there are fixed costs of invoking Node and importing modules that cannot be optimized further.

This move also enables easier adoption of Nx into non-JavaScript monorepos. And I also want to reiterate that we will continue to use TypeScript for extensibility, as we believe this to be better for contributions to our various plugins.

New Terminal UI

With Nx being a CLI tool, the terminal is our main interface with developers, so we want to make it as intuitive and efficient as possible. To this end, we will be exploring improvements to the terminal experience, especially when it comes to nx run-many and nx affected. This work is also a part of our migration of Nx core to Rust. There are Rust crates that we think will enable us to provide a more powerful and interactive terminal experience.

Better and Faster TypeScript Monorepos

We will continue to invest time to make Nx the best tool for large TypeScript monorepos.

In Nx 20, we collaborated with the TypeScript Team and updated our TypeScript monorepo setup to align with best practices in modern monorepos. We now use TypeScript project references to provide faster builds and typechecks. It also allows editors, such as VSCode, to better understand the monorepo and pick up code references more accurately. Additionally, we also enable npm/pnpm/yarn/bun workspaces for new Nx workspaces. This feature is used by many monorepos, and provides a standard way to link and manage versions of packages.

We've already started extending this new setup to other official Nx plugins, such as @nx/react and @nx/angular, and should complete this work before 2025. The next step is to iterate on this new setup based on real-world usage and user feedback.

Node.js Backend Deployments

Previously, we provided basic features to support Node.js backend development within Nx monorepos. We want to improve on this experience to offer more built-in capabilities, especially when it comes to deployments.

We will be looking at improved Docker support, including lockfile pruning for a subset of the workspace lockfile to build and run backend applications.

We also want to explore deployments of backend applications via nx release. Currently, the release feature is primarily used for publishing libraries/packages/crates to a relevant registry, but its API is generic and can be used for application deployments as well.

We will also look into other Node.js backend features, such as HMR for server code.

Smarter Monorepos with AI

Generative AI can be a huge time-saver, especially in large code bases. We will explore using AI to write migrations and generators. These features can save hours, if not days, of work for large monorepos, especially within enterprise organizations.

Expanded Java Support

We released @nx/gradle in Nx 19, which allows Nx to run Gradle tasks. We saw good results with using task splitting to distribute tests across multiple agents in CI.

The next step is to iterate on our Gradle support based on user feedback. We want more Gradle users to use Nx to speed up their CI. We are also looking into Maven support in order to support even more Java projects.

Module Federation 2.0

We want to make Nx the defacto tool for managing projects using Module Federation, which has been invaluable to many enterprise teams that we've closely collaborated with.

The Nx team has worked closely with the Module Federation team to integrate new features from Module Federation 2.0, such as Federation Runtime to manage dynamic remotes. This means that the older dynamic remote feature is no longer necessary and will be deprecated in 2025.

From 2023 to 2024, we've seen a lot of success with the adoption of our module federation tooling within enterprise organizations, and we will continue to iterate on this based on both user feedback and feedback from the Module Federation team.

[jame-earnin]

What about the nx release for multiple apps with integrated-base monorepo (Single package.json)?

[jaysoo]

There will be features and enhancements outside of what's on this roadmap. This roadmap provides key focus areas. If you have any feature requests, we recommend starting a discussion.

[EelcoLos]

I recall @vsavkin saying MonoRepo World that NX itself should be language agnostic, ie: any type of application should be add-able to NX. The latest announcement of Gradle first party support would be part of this, I guess.
However, I see no roadmap for first party support in 2025.
For example, I'd suggest integrating dotnet with first party support.
What is the vision there?

[JamesHenry]

@EelcoLos Nx is already language agnostic and can be used with any stack. With our agnostic core moving to be fully written in rust, the requirement for Node is completely removed, which further strengthens this.

The experience of using different stacks becomes much better if dedicated plugins are written for them, so that the agnostic core can be informed on how to discover projects, build the dependency graph etc.

It does not, however, mean that the Nx Team themselves will directly provide plugins for every stack. As you said, Gradle is already provided by the Nx Team, but there are other great community plugins out there already for other languages/ecosystems:

Golang: https://github.com/nx-go/nx-go
Rust: https://github.com/Cammisuli/monodon/blob/main/packages/rust/README.md (Nx Employee in their spare time)
Dotnet: https://github.com/nx-dotnet/nx-dotnet (Nx Employee in their spare time)
Python: https://github.com/lucasvieirasilva/nx-plugins/tree/main/packages/nx-python

You can discover these and many more in the plugin registry: https://nx.dev/plugin-registry

If there is super strong demand from our enterprise customers for a particular toolchain then we will of course prioritize that, and that is how our Gradle plugin came to be in the first place.

Hope that helps!

[pumano]

Would love if nx move dependency graph logic to rust too, it's open possibility to you guys port your nx/enforce-module-boundaries to oxlint / biome too

[lppedd]

And I also want to reiterate that we will continue to use TypeScript for extensibility, as we believe this to be better for contributions to our various plugins.

Just want to be sure about current extensibility. We have more than 20 custom plugins, and many more to come, should I keep going or will the plugin/executor/generator API change with the migration to Rust? I don't really like the idea of having to rewrite thousands of lines of code. Thanks! 😄