docs(nx-dev): add 20.5 release post (#30310)

This commit is contained in:
Philip Fulcher 2025-03-10 09:30:35 -07:00 committed by GitHub
parent a95a60cfe5
commit 02e29ac4ed
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 108 additions and 1 deletions

View File

@ -2,7 +2,7 @@
title: 'Nx Update: 20.3!'
slug: nx-update-20-3
authors: [Zack DeRose]
tags: [nx]
tags: [nx, release]
cover_image: /blog/images/2025-01-06/nx-20-3.png
description: Discover the latest in Nx 20.3, featuring TypeScript project references, enhanced Rspack support, Nx Console improvements, and powerful Nx Cloud updates.
---

View File

@ -0,0 +1,107 @@
---
title: 'Nx Update: 20.5'
slug: nx-update-20-5
authors: [Philip Fulcher]
tags: [nx, release]
cover_image: /blog/images/2025-03-07/header.png
description: Discover the latest in Nx 20.5, featuring TypeScript project references improvements, migration docs, and tool updates like Angular 19.2, React 19, and Vite 6.
---
Time moves fast, and so do Nx releases. Lets catch up with the latest development on Nx since our [last release post for 20.3](/blog/nx-update-20-3#rfc-for-infinite-tasks).
{% toc /%}
## LLM improvements galore
We think that monorepos are the solution to better AI-assisted development, and were doing the work to support that. Weve recently released updates that enhance the LLM experience for both [Copilot](/blog/nx-just-made-your-llm-smarter) and [Cursor](/blog/nx-made-cursor-smarter).
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](/blog/are-monorepos-the-answer-to-better-aiassisted-development) on Nx and AI-assisted development.
{% youtube src="https://www.youtube.com/watch?v=V2W94Sq_v6A" /%}
## TypeScript project references improvements
ICYMI, we announced a [new experience for TypeScript monorepos](/blog/new-nx-experience-for-typescript-monorepos) in January. The new setup is [faster, more efficient in memory use](/blog/new-nx-experience-for-typescript-monorepos#key-highlight-performance), and fixes common issues with TypeScript editor support for large monorepos. Since then, weve 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:
```text
@org/foo
@org/bar
```
You 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:
```jsx
{
"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](/nx-api/js#how-nxjs-infers-tasks)
{% youtube src="https://www.youtube.com/watch?v=O2xBQJMTs9E" /%}
## 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](/nx-api/angular/migrations).
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 dont 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`**](/nx-api/nx/documents/migrate). If youre ready to make this migration on your own, [see our docs about using the new `reactCompiler`](/recipes/react/react-compiler#react-compiler-with-nx)
## Angular 19.2 support
`@nx/angular` now supports up to Angular 19.2 Time to give their new experimental [Resources API](https://angular.dev/guide/signals/resource) a try! If youre 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](/recipes/tips-n-tricks/advanced-update#choosing-optional-package-updates-to-apply).
## Vite 6 + Vitest 3 support
`@nx/vite` now supports [Vite 6](https://vite.dev/blog/announcing-vite6) and [Vitest 3](https://vitest.dev/blog/vitest-3.html). This allows you to use the latest features in Vite like the [experimental Environment API](https://main.vite.dev/guide/api-environment) 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](/blog/nx-update-20-3#rfc-for-infinite-tasks), we introduced an RFC for “Infinite Tasks” (now called [Continuous Tasks](https://github.com/nrwl/nx/discussions/29025)). 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. Weve 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](https://github.com/nrwl/nx/releases/tag/20.5.0) for all the details.
## Automatically Update Nx
As always - updating Nx and its plugins is easy as we ship an [automated migration command](https://www.notion.so/features/automate-updating-dependencies).
```bash
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```bash
npx nx migrate --run-migrations
```
## Learn more
- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 966 KiB