I know it's hard to believe but Nx 20 is here! There's a lot to cover in this release, so let's just dive right in.
@nx All The Things!
If you've been around the Nx ecosystem for any amount of time, you're probably aware that our plugins were published originally under the @nrwl npm scope. Since version 16, we've provided backwards compatibility by reexporting @nx scoped packages from @nrwl. With Nx 20 though, we'll be officially dropping support for the @nrwl scoped packages and they will no longer be published to npm. For projects that still have the older packages in them, our migration docs can guide you to what the new packages are in order for you to update any impacted dependencies.
TypeScript Project References For Monorepos
Project References allows TypeScript to process individual projects rather than the entire monorepo as whole. This is a huge improvement in terms of build times and developer experience. However, Project References comes with a maintenance cost, as it is up to you to update these references. In a large monorepo, this cost is prohibitive.
With Nx 20, when using create-nx-workspace --preset=ts, workspaces will use Project References out of the box. Nx removes the maintenance cost of this feature by automatically updating the references for you when you run build or typecheck targets. You can also run nx sync to update references, and nx sync:check in CI to validate the workspace.
In addition to adopting Project References, we're also changing the way we link projects in a TypeScript monorepos. Workspaces is the standard way to link packages in monorepos. This is a feature that all modern package managers support, such as npm, yarn, pnpm, and bun, so taking advantage of it is a no-brainer. Now we have a proper way to provide type information and have your packages available in a way developers are used to.
Note that we've enabled Project References and Workspaces for the TS preset (i.e. --preset=ts), and we're working on extending this support for all other presets soon (Angular, React, Vue, Node). If you are an existing Nx user and want to create an empty workspace in the previous "integrated" style, you can use create-nx-workspace --preset=apps.
@nx/rspack Graduates From Labs 🎓
Rspack has become one of the most exciting new bundlers in recent years. With a webpack-compatible API, it's a painless migration for folks who want faster builds without having to rewrite their entire build process. At Nx, we're big fans of Rspack and have been working on a plugin for folks who would like to migrate. With that in mind, the @nx/rspack plugin has officially been merged into the main Nx repository and will become a fully supported plugin for the ecosystem.
In addition to this, Nx core team member Colum Ferry has taken the work he's done on the Rspack plugin and brought it to the Angular ecosystem! He's recently released @ng-rspack/nx to bring Rspack support to your Angular projects. Simply install the plugin and generate a new app in your workspace to try it out!
1# In an Nx Workspace (npx create-nx-workspace)
2# Install Package
3npm install @ng-rspack/nx
4
5# Run the app generator
6npx nx g @ng-rspack/nx: app apps/myapp
7
8# Serve the app
9npx nx serve myapp
10
11# Build the app
12npx nx build myapp
13
14# Run the e2es
15npx nx e2e myapp-e2e
16Nx Release: More Powerful And Flexible Versioning
nx release has added many powerful versioning capabilities since it was first made public as part of Nx 19. We are super excited about an in progress ground-up reworking of our versioning logic that powers nx release and the programmatic API releaseVersion() that will continue to support all these features, and allow for even more complex and large scale workspaces to be supported.
For example, release groups have existed as a concept from the very beginning, but their effectiveness is currently not maximized because it is not supported to have project dependencies that span across release group boundaries. The new version coming in a later Nx v20 minor release makes it possible for any number of dependency relationships to exist across any number of release group boundaries.
Additionally, for workspaces that contain multiple different programming languages, extending the versioning logic within nx release can currently be quite verbose, with maintenance being quite a burden due to the business logic that lives within the version generator abstraction, and this is what gets implemented per language/ecosystem.
The Nx Team provides the JavaScript version generator out of the box, so for many users, this is not a concern. But for those working with Go, Rust, Dotnet, Java etc, currently a lot of logic needs to be reimplemented and kept up to date with the latest features. In the upcoming versioning rework, the abstraction required for each new language/ecosystem is tiny and purely deals with interacting with the relevant manifest file and registry, if applicable. All feature capabilities are maintained on the Nx core side. Once this new versioning implementation is available in an Nx v20 minor release we will update our documentation to provide guidance on how to opt in, before it ultimately becomes the primary implementation in Nx v21.
So Long Derived Directories 👋
Generating apps and libraries in a monorepo is something folks do quite regularly and part of that is telling Nx where it should put things. So you've probably seen this prompt before:
This is where the concept of derived directories comes in. It will try to inspect your project and put things where it makes sense. But with Nx 20, we're moving away from using derived directories for generators. Now, you'll need to provide the directory where you want your apps or libraries to be generated to.
Wrapping Up
There's a lot more in Nx 20, so be sure to check the full changelog for all the details on everything in this major release.