Time moves fast, and so do Nx releases. Let's catch up with the latest development on Nx since our last release post for 20.3.
LLM improvements galore
We think that monorepos are the solution to better AI-assisted development, and we're doing the work to support that. We've recently released updates that enhance the LLM experience for both Copilot and Cursor.
AI-powered coding assistants can edit files, but they're blind to the bigger picture – they don't understand how your entire codebase fits together. Nx changes that. With full visibility into your monorepo's project relationships, dependencies, and ownership, Nx enables your LLM to move beyond local file changes by providing this essential monorepo context.
Take each of these for a spin and then sign up for our webinar on Nx and AI-assisted development.
TypeScript project references improvements
ICYMI, we announced a new experience for TypeScript monorepos in January. The new setup is faster, more efficient in memory use, and fixes common issues with TypeScript editor support for large monorepos. Since then, we've steadily improved this experience with many performance and quality-of-life improvements.
One of the significant improvements is that you can now run tasks with a partial match of the project name rather than needing to use the full name every time. Say you have these projects:
@org/foo
@org/barYou can run the lint task for @org/foo with nx lint foo rather than nx build @org/foo every time. A keystroke saved is time saved. 🧠
By default, Nx will use the name property from the package.json for a project to determine its name. For more flexibility, you can also define a name as part of the nx properties:
{
"name": "@org/foo",
"nx": {
"name": "foo"
}
}We have also made projects inferred by @nx/js more efficient by eliminating the duplicate typechecks that were occurring. Previously, when @nx/js inferred tasks in a workspace using TypeScript project references, buildable libraries would have both a build and typecheck target inferred. However, since typechecking occurs as part of build, this resulted in typechecking being run twice. Now, buildable projects will only have the build target, saving time.
See more details on how @nx/js infers tasks
Migration docs
When nx migrate is run, Nx determines what migrations need to be run, but it hasn't been easy for users to understand what the migrations do. The first step we're taking to address this is providing migrations docs for each plugin, going back to version 20 of Nx. See the Angular plugin migration for an example.
Additionally, when running migrations, the terminal will provide links for each migration with richer information about what is actually happening. This is just our first step in addressing confusion during migrations, keep an eye out for more development here.
ESM support for eslint config
@nx/eslint now uses ESM for configuration by default. This means that new workspaces will use ESM. Existing workspaces will continue to use CommonJS. We don't currently have a migration path between CommonJS and ESM because of the possibility to break something in your lint rules. Both CommonJS and ESM will be supported for the near future.
React 19 support for new workspaces
New Nx workspaces now default to React 19. Note that due to the extent of breaking changes coming with React 19, we will not be providing an automated migration to React 19 via nx migrate. If you're ready to make this migration on your own, see our docs about using the new reactCompiler
Angular 19.2 support
@nx/angular now supports up to Angular 19.2 Time to give their new experimental Resources API a try! If you're not quite ready to upgrade your version of Angular, remember that you can migrate to the latest Nx while keeping your current version of Angular using the --interactive flag during migration. See our docs for more details.
Vite 6 + Vitest 3 support
@nx/vite now supports Vite 6 and Vitest 3. This allows you to use the latest features in Vite like the experimental Environment API and brings us up-to-date with the latest in the Vite ecosystem!
Update on Infinite Tasks/Continuous Tasks
In our 20.3 release post, we introduced an RFC for "Infinite Tasks" (now called Continuous Tasks). Nx will add the concept of Continuous tasks which Nx will orchestrate as part of the task graph. This will allow for tasks to depend on other running tasks in addition how it already allows depending on other completed tasks. This will allow for better support of long-running tasks like backend servers for frontend applications that depend on them, or tools that run in a watch mode. We've been hard at work implementing this feature, and you can look forward to a beta version before the release of Nx 21.
Fixes and improvements
As always, there are many fixes and improvements being added to Nx every day like:
- Calculating project graph speed has been significantly improved
- Improved stability of the daemon
Be sure to check out the full release notes for all the details.
Automatically Update Nx
As always - updating Nx and its plugins is easy as we ship an automated migration command.
npx nx migrate latestAfter updating your dependencies, run any necessary migrations.
npx nx migrate --run-migrations