Every major version of Nx removes something, but most of the time the removal is small enough that a migration takes care of it while you are getting a coffee. Nx v24, which ships in a few weeks, is different. It removes the built-in executors that were deprecated in Nx v23, and for a lot of workspaces that means a real change in how tasks are defined. If your project.json files reference @nx/jest:jest, @nx/webpack:webpack, or any of their siblings, this affects you.
The change was announced in advance, and every affected executor has been printing a deprecation warning since Nx v23.0.0. Still, "we told you so" is not a migration strategy. For most workspaces the biggest difference after the switch is less configuration to maintain, along with a set of features that were never possible with executors. This post explains where executors came from, why inferred tasks replace them, and how to convert an entire workspace.
Executors are almost as old as Nx itself. They started as builders, a concept borrowed from Angular, and were renamed to executors with the introduction of Nx Devkit. Their purpose has not changed since: bake the custom behavior a specific tool needs into the workspace, behind a uniform contract. An executor receives a set of options from project configuration, does whatever the tool needs, and reports success or failure. Because every task goes through the same contract, Nx can collect its logs, cache it, orchestrate it, distribute it across machines, and retry it, without knowing anything about the tool used within.
Legora is the agentic operating system for legal work, supporting lawyers in research, review, and drafting across complex matters. It is used by more than 100,000 legal professionals at more than 1,800 leading law firms and in-house legal teams across over 50 markets. Engineering has kept pace. The monorepo nearly doubled in a year to over 600 projects and monthly CI runs grew sixfold – all supported by a platform team of three. Their monorepo is Nx-based, primarily in TypeScript, but also includes 43 Python projects, a Rust crate, a Java service, and protobuf checks, all run in a single Nx Agents pipeline.
Legora's growth outpaced the CI setup built to support it. Checks ran through a GitHub Actions matrix on Blacksmith, with fixed runner sizes per check and manually configured sharding (2x for functional tests, 6x for acceptance tests), a setup well suited to the team's size at the time. That workflow grew from 94 to 621 non-comment lines between March and May 2026. With distinct PRs up 35% in June alone, the static-matrix model wasn't just inconvenient – it was getting harder to maintain as the company scaled. Keeping it tuned by hand became a growing task for a three-person platform team, since nothing rebalanced automatically as new projects were added. The team's priority was stability first: making sure a fast-scaling engineering org could trust its pipeline before optimizing anything else.
Additionally, trust in the cache was a real blocker. By spring, the team had disabled caching for production builds and had written its own checker that rebuilt without the cache and compared output checksums, because cached and fresh builds occasionally disagreed.
Since the rise of AI agents, the number of PRs has skyrocketed and the pressure on CI has never been greater. Nx Agents is the counterforce that keeps CI from becoming the bottleneck: tasks distribute automatically, and large e2e tests get split up and rebalanced, which improves both speed and compute efficiency.
But when hundreds of tasks across hundreds of projects run on CI, it gets hard to keep track of which tasks were slow, which machine ran them, and what was blocking them.
That's why we're introducing the timeline view.
Consistency has become an even bigger problem now that a major part of the code is produced by AI agents. Nx generators were built for an era when writing code was hard, so you could argue they're now obsolete. Turns out they're even better in combination with AI agents.
In a nutshell, an Nx generator is a parameterized template you can invoke to scaffold code. Nx plugins usually ship them as part of the package so you can generate new plugin-specific packages that are properly wired up.
Built-in plugin generators are all good and nice, but the more powerful part is that you can create your own workspace plugins with their own, so-called "local generators". These live in your monorepo and are designed to automate recurring operations, mostly when it comes to code scaffolding.
Even when a coding agent scaffolds the frontend, API, and infrastructure code, you want the outcome to be predictable. The AWS PACE team (Prototyping and AI Customer Engineering) hit this on their customer engagements and packaged their setup as an Nx plugin.
So let's dive into how it works, why the Nx Devkit underneath it matters more now that agents can write this kind of automation, and where to start if you want to build your own plugin.
AWS announced the Nx Plugin for AWS v1.0 this week, and Jack Stevenson wrote up how it works on the AWS Open Source blog. I won't repeat everything here, so go read that blog post or check out my walkthrough:
I've been really looking forward to this release! This one brings a personal favorite: the Oxc toolchain arrived in Nx with @nx/oxlint and oxfmt. But there's more, let's dive in!
Like many of us, I've been a big fan of the Oxc toolchain and have been pushing it internally at Nx quite a bit.
In 23.2 we're landing Oxlint and Oxfmt.
This article is part of the Nx Polyglot Monorepos series:
When the backend is C# and the frontend is TypeScript, the same data gets described twice. If you change a property on your C# DTO, nothing tells you that the TypeScript interface is wrong now. You'll find out at runtime.
A monorepo can help close that gap. In this article we're going to dive into how you can expose your .NET API in a machine-readable format such that an Nx generator can read it and turn that description into TypeScript types. And in particular how to automate it by fully integrating it into the task graph.
This article is part of the Nx Polyglot Monorepos series:
Polyglot monorepos, that is, monorepos with multiple different tech stacks, are going to be more prevalent. The main driver is agentic development, where I've seen two main trends recently:
Nx has had multi-language support for a while: .NET, Java, Rust as well as Python. I'll have a series on these coming up soon, but for this one I'd like to focus on Rust.
In the previous post in this series, I argued that software factories aren't a product but a workflow you can implement in your organization. Once in place, you can use them to automate the parts of the work that need less human input. This makes them more practical, but for many organizations and many types of work, they are still too much. There is one part of the workflow, though, where every team and every developer can benefit from automation: code reviews.
In this article, I'll show how to assemble an interactive code review process out of the same building blocks. With it, you can get higher throughput without sacrificing quality.
This two-part series explores how to build practical agentic software workflows:
Configuring an Nx Cloud pipeline used to mean stringing flags onto a single command. At a small scale that's fine. Here's what it looks like in a more complex monorepo:
That's a single command holding seven tasks, seven environment variables, a reference to a distribution configuration file at .nx/workflows/distribution-config.yaml, and two behavioral toggles, all as comma-delimited strings, in a file owned by your CI provider, where nothing validates any of it.
Today we're shipping a new model: a .nx/ci-config.yaml file that lives in your repo, and a new npx nx-cloud start-nx-agents command that takes no configuration flags at all.
"Software factory" is a buzzword, but it doesn't have to be. Building software is a well-understood process: we know every activity involved and every tool required. A software factory just automates it.
In this post, we will describe the process and list the capabilities needed to automate it. Then we will build a software factory and discuss when using one is a good idea. We will also touch on why software factories fail in real organizations and how to make them work.
This two-part series explores how to build practical agentic software workflows:
Diagnosing CI performance problems is frustrating when you can't see what's happening on the machine. With the new resource usage feature, you can peer into exactly that: whether one build ballooned to 7GB, whether four tasks at 2GB each collectively pushed the box over the edge, or whether memory had been climbing since minute one.
Resource usage records CPU and memory while your tasks run and charts it back to you in Nx Cloud, down to the individual process.
Resource usage needs Nx 22.1 or later. Metrics are collected in CI only. Runs on your local machine don't report resource usage.
Despite the investment, many organizations don't see the expected return after adopting AI agents. In this post, we examine how monorepos can make AI agents more effective, especially in larger organizations.
Polyrepos isolate projects by having them in separate repos. Sharing code between projects is done by publishing packages and depending on them.
Monorepos have multiple projects inside a single repo. This enables projects to depend directly on one another rather than going through an external package manager.
One reason European art advanced so dramatically during the Renaissance was that paper became cheaper and more widely available.
Before paper, artists often worked on expensive surfaces (e.g., parchment), so the experimentation was constrained. More accessible paper changed that. Artists could make preparatory sketches, study anatomy, experiment with perspective before committing to a final work.
Paper was not the only reason for the increase in quality, but it gave artists something essential: more opportunities to practise. And practice makes perfect.
Nx 23.1 packs a lot into a focused release: support for Angular 22 and TypeScript 6, mouse support in the terminal UI, a more powerful way to define targetDefaults, and more than 90 bug fixes.
When we shipped the new Nx TUI, it split people in two: those who loved it, and those who missed mouse interactions like scrolling and copying. Well, we fixed that now!
The terminal UI now captures mouse events, which unlocks the interactions people kept asking for:
Agentic memory can mean many different things, and it is not easy to figure out what a particular product does. In this post we will look at a few core attributes of memory which can help with classifying different solutions. We will also see why code is fundamentally different from other domains.
Every memory type can be classified using two dimensions.
Your CI pipeline has a dependency you don't own and can't fix: Docker Hub. When it's down, rate-limited, or having a bad day, your builds fail. A read-through cache in front of Docker keeps them running through those failures.
Every docker pull in your pipeline is a live network call to infrastructure you don't control. Docker Hub has two failure modes, and a paid plan closes only one of them.
At 06:48 UTC on October 20, 2025, AWS us-east-1 degraded, and Docker Hub runs there. Image pulls broke across Docker Hub, Scout, Build Cloud, and Testcontainers Cloud, and didn't fully recover for about 12 hours. Docker's own incident report is blunt:
Once a decade, if you're lucky, you stumble onto a hard problem and crack it. Ten years ago, that was monorepos, solving integration problems for large teams. Last fall, we found another one.
The pain: agents can't work autonomously inside an organization. An agent can write a Rust compiler from scratch, but it can't update a button label and ship the change without several people unlocking the process. That makes time-horizon benchmarks basically irrelevant to most real work. We saw the barriers that keep agents from being autonomous.
Twelve years ago the JavaScript world fought a war over frameworks. The lesson took years to learn: the framework that did the least won. React beat the batteries-included contenders, and a layer grew on top to supply everything React left out. That layer was the meta framework. The same fight is starting over AI agents, and it will end the same way. The winning agents will be narrow, and a new layer will grow above them. Call it the meta harness.
Some readers are too young to remember the framework wars. It is worth looking back, because the shape of that fight maps onto where agents are now.
Start with jQuery. It took advantage of new browser capabilities and made one narrow job painless: manipulating the DOM and handling AJAX across browsers that all behaved differently.
Nx 23 is out: smarter agentic migrations, big performance improvements across the platform, shell tab-completion, finer-grained target configuration, native TypeScript support, and a big cleanup of deprecated APIs.
June 23
Half-day online event on Nx, monorepos, and AI, with talks from Kent C. Dodds, Jack Herrington, John Lindquist, and more.
Your remote build cache is one of the most important pieces of infrastructure you run, and likely one of the least audited. It is shared across branches and CI jobs in your organization. When a task gets a cache hit, the build task does not run. The cache hands back bytes that someone, somewhere, on some branch, produced earlier.
A shared cache is a trust boundary, and most teams have never treated it like one. Two things have to hold for a cached artifact to be trustworthy:
Break either one and a cache hit replays bytes that no one vetted.
Nx Cloud has always been pushing your workspace's CI performance forward behind the scenes. The past few months have been no different. We've recently released two huge updates at no cost to new or existing users: optimized resource classes and improvements to our task distribution system via Continuous Assignment. We benchmarked the results against a standard GitHub Actions setup, and the numbers are significant enough to share.
The benchmark operates on a large, realistic monorepo running its full affected pipeline with linting, typechecking, tests, builds, and e2e with Docker dependencies. We compare the new Nx Cloud features against a manually-sharded setup using the built-in features from the respective testing libraries.
Wall-clock time dropped 74%. Cost per run fell 30%. VM minutes used fell 24%. And the pipeline configuration is a lot easier to understand.
GitHub Security Advisory: GHSA-c9j4-9m59-847w
Tracking issue: nrwl/nx-console#3139
On 2026-05-18 between 12:30 and 13:09 UTC, an attacker published a malicious Nx Console v18.95.0 to the Visual Studio Marketplace and the Open VSX registry. The Visual Studio Marketplace package was live ~11 minutes until we patched it, the Open VSX one approximately 36 minutes. The attacker published the malicious version as a legitimate Nx core contributor. A credential-stealing payload that arrived through the TanStack supply-chain compromise had silently exfiltrated that contributor's GitHub CLI OAuth token seven days earlier. Between credential theft on May 11 and the marketplace publish on May 18, the attacker was active in our GitHub repos for seven days without detection.
"Give me six hours to chop down a tree and I will spend the first four sharpening the axe." Lincoln said that. We've known this for centuries.
The priority is always to deliver faster. So controls come after. More scanners. More gates. More reactive measures bolted on once the code already exists.
But what if you had those guardrails at the beginning? What if security, quality, and compliance were inputs to planning and building rather than reviews of the output?
Importing an existing project into a monorepo is not always as trivial as it might sound. There are conventions to align: project structure, build configs, package boundaries. There's the question of git history (you usually want to keep it for blame and debugging).
We shipped nx import last year to take care of the deterministic part of this. It clones a project, detects its tech stack, applies the right Nx plugin to wire it up, and preserves git history while it moves files around. That covers the common path well, but every workspace has its own edge cases (workspace-specific quirks, missing tools) that no generic tool can predict.
This is exactly where an AI agent comes in. So we made nx import agentic.
Ok, so this one is gonna be a bigger release post as I decided to catch you up on everything that landed across all the releases starting from 22.3 in December until now.
The biggest things to call out: task sandboxing (catch hidden cache dependencies via real I/O tracing), a 7x reduction in daemon memory, and worktree-aware caching.
Caching got meaningful upgrades across 22.6 and 22.7.
Self-Healing CI has had auto-apply for a while. You tell it which tasks are safe to fix automatically, and when CI fails on one of those, Self-Healing pushes the fix straight to your PR branch without waiting on you. The tricky part has always been figuring out which tasks in your workspace are actually good candidates.
We just shipped a feature to help with that: auto-apply suggestions. Nx Cloud now monitors your Self-Healing activity and recommends tasks that look safe to auto-apply, based on your actual CI history.
Self-Healing CI detects failing tasks on your PR, generates a fix with an agent, verifies it by re-running the broken task, and pushes the suggested fix back to your PR for review.
Deploying from a monorepo with multiple apps comes down to one requirement: only build and redeploy the apps that actually changed. Cloudflare Pages itself gives you fast static hosting with a global edge, custom domains, and a generous free tier. The trick is wiring it up so a push that only touches app1 doesn't rebuild and redeploy app2, app3, and everything else.
The setup in this post works for any pnpm or npm workspace. I use Nx as the task scheduler on top of the workspace because for the deployment setup it gives me an important thing: a project graph for computing what's affected by a change.
As a result I can declare a new deploy target on each deployable app, then let one generic GitHub Actions workflow run nx affected -t deploy and push results to Cloudflare Pages with wrangler.
When you have multiple apps in a monorepo, you want consistent design tokens: colors, typography, spacing, shadows. Copy-pasting a Tailwind config between apps doesn't scale. Every time you tweak a color, you have to update it everywhere.
Tailwind v4 makes this simpler. The new CSS-first configuration with @theme means your design tokens live in a plain CSS file. In a pnpm/npm workspaces based monorepo you can put that CSS file in its own package and share it just as you'd do with your TypeScript packages.
This article walks through the mechanics of how to set that up. We'll create a shared styles package, consume it from multiple apps, and automate the Tailwind content scanning so it all stays in sync.
SiriusXM is a leading audio entertainment company that delivers music, sports, talk, and podcasts to millions of subscribers. Behind the scenes, their commerce engineering team builds and maintains the digital experiences that power customer acquisition — from signing up for subscriptions to managing accounts. In a competitive streaming landscape, their ability to rapidly iterate on these checkout and conversion flows directly impacts the business.
For the past five years, that velocity has been powered by a monorepo managed with Nx. Today, that workspace has grown to over 1,400 projects — a composable architecture that enables the commerce team to assemble new customer experiences from modular libraries and get them to market fast.
SiriusXM's commerce team is always looking for new ways to capture sales and move customers through the subscription funnel more effectively. That means constantly shipping new variations of checkout experiences — taking the same core UI components and customer journeys, tweaking them, and testing what works.
Agentic experience (AX) is becoming just as important as traditional developer experience. The tools we build aren't just used by humans anymore. They're increasingly called by AI agents acting on behalf of developers, and if those agents struggle to interact with our software, we risk being left behind.
Instead of adding friction to developers and agents working with Nx, we're focused on expanding the scope at which agents can act autonomously: in your terminal, repository and beyond. We just shipped a major round of improvements to Nx's CLI commands (create-nx-workspace, nx init, nx import), all specifically designed to make them work well with AI agents. We wanted to use the opportunity to share how we think about AX and the principles behind the changes.
And what plays nicely into our hands: Agents love CLIs and Nx already has a pretty powerful one!
As AI agents become central to how developers build and scale software, the need for open standards, shared tooling, and transparent governance has never been greater. Today, we're excited to announce that Nx is now a member of the Linux Foundation and the Agentic AI Foundation (AAIF).
The software development landscape is shifting. Agentic AI — autonomous systems that can plan, coordinate, and act across tools and codebases — is quickly moving from research concept to production reality. The companies and communities that define the standards for this new era will shape how millions of developers work for years to come.
The Linux Foundation has long served as the neutral, trusted home for the open source projects that power global infrastructure. The Agentic AI Foundation, formed in December 2025 under the Linux Foundation umbrella, extends that mission into the age of AI agents. Anchored by foundational projects like Anthropic's Model Context Protocol (MCP), Block's goose, and OpenAI's AGENTS.md, the AAIF is where the open standards for agentic AI are being built.
I've been building dev tools for monorepos and helping companies use them for years. And I've been hearing similar objections to the monorepo idea from many teams:
Many of them arise from confusion, often after trying a basic workspace setup, seeing a bunch of problems, and concluding that it is not a viable approach for multi-project-multi-team scenarios.
In this article, I will show what a proper monorepo setup looks like and talk about common misconceptions related to monorepos.
Remember when MCP was the hot new thing? That was barely a year ago. We built MCP tools for Nx — surfacing project graphs, generator schemas, task pipelines directly into LLM conversations — and for the first time AI assistants could actually understand your workspace. We shipped integrations for Cursor, VS Code Copilot, and JetBrains, and it worked well.
MCPs still have their place. But for a lot of what they were doing, better solutions exist now.
No. But let me backtrack a little and explain why we deleted most of ours.
AI coding agents are powerful, but they don't understand your monorepo out of the box. They don't know how your workspace is structured, what naming conventions your team follows, or how to run tasks the Nx way. That's why we're shipping Nx agent skills: portable capabilities that teach your AI agent how to work effectively in monorepos, in particular in combination with Nx.
This single command sets up everything your AI agent needs: an MCP server for talking to CI, a set of skills for working with your monorepo, and a CLAUDE.md / AGENTS.md with guidelines. It works across major AI coding tools: Claude Code, Cursor, GitHub Copilot, Gemini, Codex, and OpenCode. All configurations are generated from a single source of truth, so every AI tool gets the same capabilities.
You can also run npx skills add nrwl/nx-ai-agents-config via skills.sh. Note that this won't configure the Nx MCP server or install the Claude plugin.
Broadcom is a global technology leader providing semiconductor, enterprise software, and security solutions to thousands of customers worldwide. Their engineering organization manages a wide portfolio of complex applications, including the VMware suite of products. Their frontend architecture team has spent nearly a decade figuring out how to manage this portfolio efficiently.
Managing software development at the enterprise scale can be an uphill battle requiring coordination and cohesion across multiple teams and products that each face their own unique challenges. They may serve very different user groups, or have to work with the constraints of legacy systems or a recent acquisition. Developers across the organization were losing time to infrastructure work: configuring builds, debugging CI pipelines, waiting for tests to run. Every hour spent on DevOps was an hour not spent building features. In order to consolidate and standardize these processes to boost efficiency, a monorepo was chosen as a logical place to start by combining multiple projects into a single repo. They faced not only technical challenges with this approach, but some internal resistance from teams used to working autonomously.
They reached a point where they wanted some outside help on effectively working with a monorepo, so they reached out to our co-founders Victor Savkin and Jeff Cross.
Feb 18, 2026 - 2pm ET/7pm UTC
Presented by Jeff Cross and Juri Strumpflohner
Monorepo architecture has evolved significantly in the past few years, yet the landscape remains confusing with inconsistent definitions, rapidly changing tooling, and implementation patterns that vary wildly across organizations. Meanwhile, teams adopting AI coding assistants are discovering that modern monorepo tooling is uniquely suited to solve the exact coordination challenges they're now facing. For engineering leaders navigating this rapidly transforming space, understanding the advantages of monorepo capabilities can unlock substantial velocity gains (even if a full migration is not in the cards).
In the last year Nx has grown. Monthly NPM downloads hit 36 million (up 63% from a year ago). We shipped first-party plugins for Docker, .NET, Maven, Angular rspack, and rsbuild. We released an entirely new Terminal UI with better support for Continuous Tasks, and the Nx MCP server.
On the platform side we released new analytics, optimized task distribution, resource tracking, and launched Self-Healing CI.
2026 is the year Nx becomes infrastructure for autonomous AI agents.
If 2025 was the year of agents, 2026 is the year of autonomous workflows. We started with AI Chats (copy and pasting), moved to agentic tools like Claude Code and Cursor (edit files, run commands, but still babysitting), and are now heading toward agents that perform large chunks of work completely autonomously.
AI agents no longer just autocomplete a line or a function body. They can operate independently across projects. This shift will change how we work. Organizations that adapt quickly, and have the right tooling in place, will have a significant advantage.
We wrote about autonomous AI Agents at scale and the potential barriers organizations might hit when adopting them. One such aspect where many current setups hit a wall is CI.
The bottleneck has shifted. As AI agents become more autonomous, writing code is no longer the constraint. Most organizations aren't ready for this. Their architectures still put humans in the middle to do the coordination, limiting what agents can accomplish.
For example:
The goal is autonomy: one continuous agent session that implements an entire feature. No handoffs. No re-explaining. No context lost. It updates all projects that need updating and iterates on CI until the build is green.
Caseware is a global leader in audit and analytics software, trusted by financial professionals in over 130 countries. Their platform engineering team maintains and modernizes the development infrastructure behind dozens of products, each with different technical stacks and histories.
Today, Caseware operates across four core platform teams, each one containing multiple squads building interconnected applications. The organization manages a unified monorepo containing roughly 700 projects alongside additional monorepos maintained by individual solution teams. This architecture enables them to maintain development velocity while ensuring code quality and system integration across their engineering organization.
It hasn't always been like this, though. Managing software development at this scale creates problems that become harder to ignore as organizations scale.
Tailwind CSS v4 brought significant simplifications: no more tailwind.config.js, minimal dependencies, and a simple CSS import to get started. But if you're using Angular with Tailwind v4 in an Nx monorepo, there's a catch: your production CSS might be larger than it needs to be.
This article explains how Tailwind v4's scanning works with Angular's PostCSS setup, why it can lead to bloated CSS output, and how to optimize it using @source directives and Nx Sync Generators.
If you're using Vite (React, Vue, etc.) rather than Angular, check out Tailwind v4 with Vite in an NPM Workspace instead.
AI agents have made massive inroads in enterprise software development in a short amount of time. With predictions that AI spend will continue to increase in 2026, has the return on investment materialized with increased budgets? Many organizations are saying “No,” with reports that only 25% of AI initiatives have delivered the expected ROI.
So why are AI initiatives lagging behind the massive investment being made into them? It’s not the agents, it’s the architecture. AI agents underperform because polyrepos blind them to cross-project context and force manual coordination. Nx fixes this, enabling major productivity gains and unlocking work teams previously avoided entirely.
Polyrepos isolate projects by having them in separate repos. Sharing code between projects is done by publishing packages and depending on them
Did you keep up with our monthly webinars in 2025? As we close out the year, we wanted to take a moment to look back at all discussions we've shared with the Nx community, from tackling CI bottlenecks to exploring the intersection of AI and monorepos to practical strategies for building better and shipping faster.
If you missed any of these sessions (or want to revisit the good stuff), all recordings are available through our webinar page. Here are some highlights from the year:
All too often we see Nx users setting up remote cache but never quite getting around to taking advantage of other Nx features. In The Compounding Effect: How Nx Features Multiply Performance Gains, Jeff Cross and Madeline Hennessy dig into the real gains you can get from addressing flaky tests, random failures, and the manual intervention that keeps developers waiting for green builds.
In 2025, we had a clear goal: help teams ship at AI velocity without the typical development interruptions. AI tools now let developers write more code than ever before, but what's the point if you can't actually get it merged and deployed?
This year, Nx grew into a Build Intelligence Platform combining build systems, CI orchestration, and AI integration all in one place — eliminating the things that most get in the way of pushing code to production. Self-Healing CI, enterprise analytics, and AI-powered workflows transformed how teams interact with their codebase. All this while keeping up with the latest tools and upgrades.
AI assistants are transforming development, but they're only as useful as the context you give them. LLMs need context from source code, CI pipeline, and terminal to unlock their full potential.
Nx 22.3 is here with Angular 21 support, experimental tsgo compiler integration, and long-awaited Prettier v3 compatibility. This release aligns Nx with Angular's latest defaults while continuing to improve the developer experience across the board.
Let's dive into what's new.
Quick check: how many of you have seen a commit like this before?
Did you ever actually fix that out-of-memory error? Do you even have the data to figure out what caused it?
Nx is an Integrated Build Platform, which combines an advanced build system with innovative continuous integration and AI features.
The core of the platform is the Nx CLI, an MIT-licensed build system used by millions of developers. It provides tremendous value to teams who manage to scale their Nx repos with DIY cache solutions.
This post compares using the full platform against using only the Nx CLI with a DIY cache.
Dec 17, 2025 - 2pm ET/7pm UTC
Presented by Nicole Oliver, Miroslav Jonas, and Victor Savkin
Join us for a special year-end webinar where we’ll take you on a journey through Nx’s past, present, and future to explore the evolution of Nx and what’s coming next.
Hot on the heels of our Nx 22 release, we're back with 22.1 packed with improvements that make your daily development experience even better. This release delivers on a long-awaited promise for Windows users, upgrades our testing ecosystem, and sets the stage for Angular 21 support.
When we launched the Terminal UI in Nx 21, we had to disable it on Windows due to compatibility issues. We know that was frustrating for Windows developers who watched their Mac and Linux colleagues enjoy the improved task running experience.
Nx 22.1 enables the Terminal UI by default on Windows. You now get the great TUI experience: a task list panel showing all running tasks, log output for your selected task in a separate panel, and smooth navigation between tasks using arrow keys or Vim-style h/j/k/l bindings.