Nx 22 Release: Expanding the build platform

Nx 22 represents six months of development focused on expanding our build platform that solves CI and amplifies AI-powered development. We've introduced new CI tools that fix PRs and report back to you, rewritten our graph visualization to handle repositories of any size, and added enterprise-ready support for .NET and Maven. Nx 22 delivers on our vision of making monorepo development better for everyone.

We talked about many of these changes and more in our livestream. Catch the replay here and subscribe to our channel so you're notified of the next opportunity to connect with our Nx engineers and get your questions answered!

Nx is much more than the open source package

Before we dive into all the greatness of Nx 22, let's talk about where we're headed. We want Nx to be more than just the fastest task orchestrator for monorepos. We want Nx to be a comprehensive build platform that provides solutions along every part of the software development lifecycle. Whether you're developing locally, running your PRs on CI, or using AI-assisted software development, we want to make you more efficient at every step.

All of this is achieved while keeping the Nx platform modular, allowing you to start lightweight and only add more features as you need them.

Self-Healing CI reduces Time to Green

For several years, Nx Cloud has solved the pure speed challenges of CI pipelines through remote caching and distributed task execution. While speeding up CI is a fundamental part of improving performance, it is not the whole story of making you productive. A lot of time is lost attending to broken PRs, iterating on fixes, and trying to get them to a green state. Solving this challenge has been a big focus for us in the last six months.

Self-Healing CI analyzes your failing PRs and suggests fixes automatically. You can review the fix, apply it locally, or accept it and have it pushed directly to your PR. This saves a lot of time as it doesn't require you to context switch between your IDE, browser, and other tools. Everything comes right to you inside your IDE, so you can continue working while Self-Healing CI is working in the background.

Nx is uniquely positioned for this challenge: it has knowledge of the workspace structure and dependencies, the exact tasks that failed on CI, their inputs, and all the detailed logs of the actual error. All this context allows Nx to generate the best possible fix for your PR.

GitHub support is already available and GitLab is being tested right now.

You can enable Self-Healing CI for free. Learn more here.

Nx Console stops context switching by keeping you in your IDE

Your editor is your home, and we want you to stay focused there. A deep integration with Nx there is invaluable, enabling you to see status updates like CI errors or Self-Healing CI fixes without having to leave your IDE.

Nx Console is how we integrate with your editor. It works for Visual Studio Code and JetBrains IDEs, and we've steadily made it a more and more valuable part of your development toolkit:

• To help you stay in the flow, it notifies you of the status of PRs and Self-Healing CI fixes right in your IDE.
• To help integrate your AI assistants, it can add agent instructions to make the most of Nx and keep those instructions up-to-date.
• To help you migrate to newer versions, it has Migrate UI, a visual interface for running and approving migrations.

Learn more about Nx Console CI features

Polygraph: Enterprise workspace management

We strongly believe in monorepos, but we also learned one important thing when working with a lot of our enterprise customers: sometimes you just can't migrate certain projects into the monorepo. You still want some of the visibility and consistency benefits, and this is exactly what Polygraph is about.

Polygraph is the enterprise solution for managing workspaces across your organization. You can automate consistency and visualize dependencies across all of your repositories, whether they're using Nx or not. This gives large organizations visibility into their entire development ecosystem, helping identify duplicate dependencies, enforce architectural patterns, and understand cross-repository impacts.

Explore Polygraph

Nx Graph can now handle the largest repos

We've always believed in the need for visualizations of workspaces. In bigger repositories, interactive visual representations become indispensable for understanding how everything fits together. This belief in multimodality—viewing your workspace in the terminal when appropriate, but switching to rich visual interfaces for complex questions—drives how we design Nx.

The graph rewrite has been many months in the making. It's hard to arrive at something that works intuitively for repositories with a dozen projects while also handling workspaces with thousands. But that's exactly what we've accomplished.

The graph now renders in composite mode by default, providing two key benefits: it looks cleaner and prevents crashes when visualizing large workspaces. For workspaces with thousands of projects, the composite mode makes the graph usable again.

We've significantly improved the graph experience with a redesigned control panel and interface. So not only can the graph render the largest repos, navigating them is simpler. Take a look by running nx graph and read the documentation for more details.

Explore the project graph documentation

The graph isn't just a standalone tool: it's integrated directly into Nx Console, giving you quick access to visualizations right from your IDE. This seamless integration between terminal, IDE, and browser-based tools represents our commitment to meeting developers where they work. We've worked hard to improve the stability of Nx Console for VS Code, Cursor, and JetBrains IDEs (like IntelliJ and WebStorm). Compared to a year ago, the error rate has dropped significantly, making these integrations more reliable for daily development work.

Much improved Terminal UI

We're not just focusing on buzzy new features like AI integration. We know developers choose Nx because we continually improve the core product: the tools you use every day to build, test, and deploy your applications.

The Terminal UI (TUI) introduced in Nx 21 fundamentally changed how you interact with Nx. Rather than just seeing an output of logs, you now see currently running tasks in one panel with log outputs for the selected task appearing in a separate panel.

Since Nx 21, we've continued refining the Terminal UI experience. We've replaced pagination with smooth scrolling in the tasks list, making it easier to navigate through multiple running tasks. We've also refined the visual experience with improved title styling when panels are focused, better handling of placeholder entries when filtering tasks, and preventing unwanted scrolling when interacting with the task list. These are small tweaks, but they add up to a much more polished experience when you're running continuous tasks or managing complex pipelines.

And we're not done yet: we're currently working on better searching of logs, as well as easier copying and pasting.

Polyglot workspaces grow with first-class Maven & .NET support

The value proposition of monorepos increases dramatically when you can bring backends and frontends together in a single workspace. The combination of comprehensive project understanding and polyglot support makes both developers and AI agents more effective. Developers can now make atomic changes that cross the frontend/backend boundary: if a payload or model changes from the backend, that change can also be made in the frontend in the same commit. Your entire project stays in a working state in each commit, rather than getting surprised when things break between deployments. When your AI assistant can see how your React frontend connects to your .NET backend, it can provide better suggestions and catch potential issues across the entire stack.

Maven support: Fleshing out Java Support

Following our success with the Nx plugin for Gradle, we're now bringing Maven support to Nx. Using Nx together with Maven provides Nx's caching and task distribution to your Maven workspaces.

Adding Nx to an existing Maven project adds an nx.json, some nx wrapper binaries, and our Maven Plugin (dev.nx.maven.nx-maven-plugin) to the root pom.xml. The @nx/maven plugin automatically reflects Maven's modules and lifecycle into Nx's project graph. As your Maven modules and goals evolve, Nx automatically picks them up without maintaining any additional configuration.

Like our other plugins, Maven support includes intelligent caching and distributed execution. Your Maven builds benefit from Nx's computation caching, which skips unnecessary rebuilds when nothing has changed. For teams using Nx Cloud, this means dramatically faster CI pipelines for your Java projects.

Maven support is experimental for now. This is an initial set of features that users can start to adopt; more features will be coming soon. We will be listening closely for feedback and continue making the Maven support better.

Combined with our existing Gradle support (which saw massive performance improvements in Nx 21), Nx now offers comprehensive support for the Java ecosystem.

Learn more about the Maven plugin

@nx/dotnet: Enterprise-ready .NET development

We're bringing Nx to the .NET ecosystem! The new @nx/dotnet plugin automatically discovers your .NET projects and infers common targets like build, test, and watch. This means you can start working with your existing .NET solutions immediately without extra configuration.

The plugin uses your existing .csproj, .fsproj, or .vbproj files while integrating with Nx's task graph. This means you get intelligent caching for your .NET builds, distributed task execution on Nx Cloud, and accurate dependency tracking between your .NET projects and any JavaScript projects in your workspace.

This also opens up .NET to all of the CI performance gains offered by Nx Cloud, including remote caching, distributed task execution, flaky task retries, and self-healing CI.

Our @nx/dotnet plugin started life as a community plugin named @nx-dotnet/core, and we recommend all users migrate to @nx/dotnet. This plugin was created by our own Craigory Coppola and reached npm downloads of over 25k/week. During its life as a community plugin, multiple contributors like Ben Callaghan, Christopher Leigh, and Paulo Oliveira (among others) helped build and support it. Visit the repo and see how a community can come together to build something big.

Explore the .NET plugin documentation

Gradle performance improvements

In Nx 21, we introduced massive performance improvements to @nx/gradle. We brought a Gradle plugin that provides Nx with project graph information and started sending tasks to Gradle in batches rather than one by one. To test the improvements, we forked the Spring Boot repo and converted it to use Nx. With the latest version of our plugin, we reduced CI times from 1 hour 44 minutes to 42 minutes—a 59.6% reduction in time.

Check out the docs for more details.

Nx amplifies the effectiveness of AI

Multiple industry reports show massive AI adoption across development teams. We're starting to see "vibe coding" being replaced by AI-assisted development: smart engineers whose efforts are multiplied by AI. AI coding assistants are transforming how developers work, but their effectiveness depends on understanding your codebase's structure and relationships. Monorepos and AI enhance each other: monorepos provide the comprehensive context AI agents need to move beyond simple file edits, while AI agents can perform atomic cross-project changes that monorepos need.

We're designing every API twice now: once for developers and once for AI agents. This dual approach ensures that both you and your AI assistant can work effectively with your Nx workspace.

We've made it even easier to configure AI coding assistants to understand your Nx workspace. The configure-ai-agents command now validates your existing AI configuration files, ensuring tools like Cursor, GitHub Copilot, and other AI assistants have everything they need. If one of your agents isn't up-to-date, you can rerun npx nx configure-ai-agents to update your config. If you're using Nx Console, it will also check these automatically and suggest updates.

This feature becomes increasingly valuable as your workspace grows and includes projects across multiple technologies. Your AI assistant now understands not only your JavaScript projects, but also your .NET services, Maven applications, and how they all connect. We've written more about this aspect of monorepos and AI over at monorepos.tools/ai

We're actively working on even deeper AI integration. Expect to see support for Claude's Skills feature, agentic migrations that can help update your codebase automatically, and more innovative ways for AI to understand and work with your Nx workspace.

Learn more about AI integration with Nx

But wait, there's more!

Beyond our main priorities, Nx 22 includes several important improvements that make everyday development better.

pnpm catalog support: Simplified dependency management

Managing dependencies across a large monorepo can present challenges. Different projects might drift to different versions of the same package, creating inconsistencies and potential bugs. pnpm catalogs solve this by providing a centralized way to define and reference dependency versions.

Nx 22 now supports pnpm catalogs, automatically recognizing and formatting your catalog definitions during migrations. When you run nx migrate, Nx will now properly update versions defined in your catalogs and format the pnpm-workspace.yaml file to keep everything consistent.

Your projects can then reference these versions using the catalog: protocol:

This makes upgrading dependencies across your entire workspace much simpler. Update the version in one place, and all projects using that catalog entry automatically reference the new version. This pairs perfectly with Nx's migration system, ensuring your entire monorepo stays in sync.

But this isn't just for migrations: anything that handles dependencies in package.json files now supports catalogs. That means generators, @nx/eslint rules, module federation utilities, and lockfile pruning all support catalogs in your workspace.

Please note: while plugins maintained by the Nx team have been updated to support catalogs, community plugins that modify package.json files will still need to be updated to support pnpm catalogs. If you're a plugin author, see the documentation for two helper functions to make this easy: addDependenciesToPackageJson and getDependencyVersionFromPackageJson

Learn more about dependency management with Nx

Enhanced release workflows

We've significantly improved nx release based on feedback from teams using it in production. These changes make the release process more intuitive and flexible, advancing our support for application releases alongside library releases.

• Graph-aware dependent updates and filtering - nx release now constructs a dedicated ReleaseGraph to map relationships between release groups. This enables graph-aware filtering using --projects/-p or --groups/-g and allows updateDependents to handle complex group configurations. The updateDependents option now supports "always" as a value, which updates dependency references in dependents across any group. For example, if projectA in group1 depends on projectB in group2, running nx release -p projectB or nx release -g group2 will update the dependent projectA reference on projectB, even though projectA is outside the filter. This became the default in this major release, while "auto" and "never" remain available options.

  See our guides on Release Groups and Update Dependents for more details.

• Cleaner configuration for releaseTag* options - Configuration for git tags has been restructured. Options previously prefixed with releaseTag* are now nested under a releaseTag object with unprefixed properties. For example, in Nx 21 configuration might look like:

  1{ 2 "releaseTagPattern": "{projectName}@{version}", 3 "releaseTagPatternCheckAllBranchesWhen": ["main", "develop"], 4 "releaseTagPatternRequireSemver": false, 5 "releaseTagPatternPreferDockerVersion": "both", 6 "releaseTagPatternStrictPreid": true 7} 8

  In Nx 22, this configuration is automatically migrated to:

  1{ 2 "releaseTag": { 3 "pattern": "{projectName}@{version}", 4 "checkAllBranchesWhen": ["main", "develop"], 5 "requireSemver": false, 6 "preferDockerVersion": "both", 7 "strictPreid": true 8 } 9} 10

  The previous properties will be supported until Nx 23, with the new ones taking priority.

• New programmatic API guide and enhancements for changelogs - The programmatic API includes several enhancements. The releaseChangelog function now offers a replaceExistingContents option to overwrite existing CHANGELOG.md files. The ReleaseClient constructor accepts a second parameter to use provided config as the sole source of truth, overwriting nx.json. You can also provide a custom changelog renderer directly in custom config rather than via file path. These features are particularly useful when writing focused changelog generation scripts for specific applications.

  See the new programmatic API guide for implementation details.

• Better conventional commit handling - Nx now determines relevant conventional commits using the same behavior as nx affected. This provides more control over what changes impact releases beyond just changed files within commits, supporting features like implicitDependencies.

Explore the updated Nx Release documentation

Module Federation updates

For teams using Module Federation, we've enhanced support for both TypeScript solution-style projects and package manager workspace paradigms. This means Module Federation works whether you're using TypeScript project references, traditional path mappings, and/or package manager workspaces.

This means we can follow best practices when working within TypeScript monorepos and configuring workspace dependencies for our Module Federation projects. We can also ensure type safety via standard Node resolution rather than relying on TypeScript path mappings, which can impact build/typecheck performance.

An example of a package.json for a host/consumer application would look like the following:

The corresponding remote application's package.json would contain:

We've also improved support for Angular applications using Rspack with Module Federation, allowing ESM with Module Federation (previously forced to CJS), which should help keep bundles smaller and improve live-reload support to prevent hot-update loops, making the development experience smoother and faster.

Learn more about Module Federation

Storybook enhancements

The @nx/storybook plugin now automatically infers watch-deps and build-deps targets. This makes it easier to keep your Storybook in sync with your buildable libraries during development. When you're working on a component library, your Storybook automatically rebuilds when dependencies change.

Explore Storybook with Nx

Breaking Changes

Nx 22 isn't just about the new, it's also about stability and cleanup. We've removed several previously deprecated features to streamline the codebase and improve maintainability:

• Database-backed caching is now standard - The NX_DISABLE_DB environment variable has been removed. All workspaces now use the database-backed caching system (migration happens automatically).

• CreateNodes V1 removed - Plugin authors must migrate custom plugins to createNodesV2 for better performance and flexibility. See our compatibility guide for details.

• Legacy TypeScript plugin behavior changed - useLegacyTypescriptPlugin now defaults to false for more efficient TypeScript handling. Existing workspaces can keep the legacy behavior if needed.

• Webpack and Rspack options cleanup - Removed deprecated options: deleteOutputPath (use native build tool option) and sassImplementation (configure in build tool config). The @nx/rspack:application generator is removed—use framework-specific generators like @nx/react:app or @nx/vue:app with --bundler=rspack instead.

• Nx Release legacy versioning removed - The deprecated legacy versioning implementation is completely removed. If you used release.version.useLegacyVersioning: true in Nx 21, migrate to the new versioning APIs before upgrading.

• Inlining feature removed from tsc and swc executors - The experimental inlining feature is removed from @nx/js:tsc and @nx/js:swc. Use a bundler like esbuild or webpack instead.

• npm legacy peer deps behavior changed - Nx no longer forces --legacy-peer-deps. Configure this in your .npmrc file if needed.

• Deprecated simpleName option removed - The simpleName option is removed from library generators. All libraries use consistent naming based on workspace configuration.

There have also been some other removals:

• The long-deprecated decorate-cli script has been removed
• Migrations prior to Nx 20 have been removed to reduce package size
• Deprecated Storybook generators have been removed: Use @nx/storybook:configuration instead of the old framework-specific generators

Migrating to Nx 22

As always, updating to the latest version of Nx is straightforward:

This command analyzes your workspace and creates a migration file with all necessary updates. Review the changes, then apply them:

For a more visual migration experience, use the Migrate UI in Nx Console, which lets you review and approve each migration individually.

Learn more about the migration process

The nitty gritty

As always, there are many more improvements and fixes we couldn't cover in detail. See our full release notes on GitHub for all the details.

Keep an eye on our socials and subscribe to our YouTube channel for what's coming next.

Learn more:

• 🧠 Nx AI Docs
• 🌩️ Nx Cloud
• 👩‍💻 Nx GitHub
• 👩‍💻 Nx Console GitHub
• 💬 Nx Official Discord Server
• 📹 Nx Youtube Channel