September 2026 Summaries

Nx v24 will remove deprecated built-in executors from core plugins, requiring workspaces that use executors such as `@nx/jest:jest`, `@nx/webpack:webpack`, or related integrations to migrate to inferred tasks before upgrading. Introduced in Nx v18, inferred tasks use plugins to read existing tool configuration files and generate targets that run native CLIs through `nx:run-commands`, reducing duplicated configuration, improving compatibility with upstream tools, and enabling capabilities such as per-file test splitting and more accurate caching. The removal does not affect the executor API, custom executors, community-plugin executors, several JavaScript, Angular, Gradle, and Maven executors, or `nx:run-commands`; it primarily targets duplicated first-party integrations for tools including Jest, Vite, Cypress, Playwright, ESLint, Webpack, and Storybook. Migration involves upgrading to the latest Nx v23 release, running `nx g infer-targets`, reviewing inferred and retained target settings with `nx show project`, and ensuring inference plugins are enabled in `nx.json`. Some cases, including package scripts and legacy Webpack configurations using `composePlugins` and `withNx`, need manual attention, while Nx says graph-computation overhead from inference is largely mitigated by daemon caching and recent performance improvements.

Legora, a legal-work platform used by more than 100,000 professionals across 1,800 firms and legal teams, expanded its Nx-based monorepo to more than 600 projects while relying on a three-person platform team. Its previous GitHub Actions matrix workflow on Blacksmith required fixed runner sizes and manually maintained test sharding, becoming increasingly complex as CI activity and pull requests grew. To improve reliability, Legora adopted Nx Cloud task sandboxing, which identified undeclared file dependencies and helped the team eliminate 811 initial sandbox violations, enabling stricter execution and improving cache-hit rates from about 50% to 73%. The company then moved builds, typechecks, linting, and several testing stages to Nx Agents, whose continuous task distribution dynamically assigns work to available machines, handles resource-intensive tasks, and retries flaky jobs. Legora reports that the change roughly halved CI configuration for migrated checks, removed manual sharding and runner tuning, and allowed 16 targets across TypeScript, Python, Rust, and Java, along with seven repository-wide guardrails, to operate with less workflow configuration.

Nx Cloud has introduced a live timeline view for Nx Agents to help teams analyze increasingly complex CI runs involving large numbers of distributed tasks. The view visualizes task scheduling, idle periods, failed attempts, dependency bottlenecks, and work distribution across individual agents, making it easier to identify inefficient CI scripts, unbalanced workloads, and tasks that finish late. Users can inspect task metadata, retry output, historical performance and file changes, dependency chains, and agent-level CPU and memory usage, while filtering tasks by project or agent to observe features such as Atomizer-based end-to-end test splitting. The feature is available to Nx Cloud users and is expected to become the default run view.

Nx generators, originally designed to reduce manual coding effort through parameterized scaffolding templates, can help maintain consistency in monorepos as AI agents produce more code. While Nx plugins include built-in generators, teams can create local generators within workspace plugins to automate organization-specific tasks such as creating standardized packages, configuring language support, and applying recurring conventions. The approach combines deterministic generators, which reduce token costs and reliably enforce patterns, with AI agents that can invoke CLI commands, interpret generated output, and make context-specific adjustments. AI agents can also create and maintain the generators themselves by analyzing an existing exemplar project and encoding its configurations, such as Vite, TypeScript, and package exports, into reusable Nx Devkit-based scaffolding tools.

AWS has released the Nx Plugin for AWS v1.0, developed by its Prototyping and AI Customer Engineering team to help teams rapidly scaffold predictable, production-oriented full-stack AWS projects containing infrastructure, backend services, and frontends. Users can create a workspace through commands such as `pnpm create @aws/nx-workspace my-project`, then use deterministic Nx generators to add self-contained components that agents or developers can assemble and later modify as ordinary workspace code. Unlike static templates or dependency-based libraries, generators let teams retain ownership of generated code while Nx migrations can deliver later improvements to previously scaffolded workspaces. The plugin is built on the Nx Devkit, which supports install packages, code generators, executors, and project graph plugins for integrating languages and tools into Nx task graphs. As coding agents reduce the effort required to create such automation, organizations can use the Devkit to develop local generators, custom lint rules, language integrations, and organization-specific plugins that standardize internal libraries, deployment configurations, and approved technology choices.

Nx 23.2 introduces experimental Oxc toolchain integration through the new @nx/oxlint plugin, which provides inferred cacheable lint tasks, configuration generation, and Nx module-boundary enforcement, alongside built-in Oxfmt detection and formatting support that can substantially improve performance over existing tools. The release reduces successful task log output for clearer terminal and CI results and lower AI-agent token use, while preserving full failure logs, and enhances the terminal UI with a progress status bar, searchable task logs, and better interactive-process behavior. It also improves support for polyglot monorepos by recognizing .NET-generated OpenAPI files as cacheable build outputs, enables Nx to work more reliably in restricted coding-agent sandboxes, and moves local cache and workspace data to ~/.nx for reuse across worktrees, clones, and sandboxes. Additional updates include individual migration execution, Angular 22.1 compatibility, broader Vitest generator support, improved Bun dependency catalog, lockfile, and module federation handling, more flexible project selectors for nx release, much faster convert-to-inferred migrations, and a simplified repository-based Nx Cloud configuration for distributed CI agents.

Nx can provide end-to-end type safety between a C# backend and TypeScript frontend in a polyglot monorepo by generating TypeScript types from a .NET API’s OpenAPI specification and incorporating the process into its task graph. Using the @nx/dotnet plugin, Nx infers .NET project builds and dependencies, while ASP.NET Core produces an OpenAPI JSON document during the API build; the @hey-api/openapi-ts generator then converts that document into TypeScript types, including API field descriptions as JSDoc. By declaring an implicit dependency from the types library to the API, configuring code generation to depend on the API build, and hashing dependent task output files, Nx ensures regenerated types reflect API-contract changes while preserving cache efficiency when outputs are unchanged. Target defaults further make build, serve, and typecheck tasks run code generation before consuming projects compile, so changes such as renaming a C# DTO property automatically cause affected TypeScript code to fail type checking. Although the example uses OpenAPI, the same build-schema-generate-task-graph pattern can support protobuf, GraphQL, or database schemas, and several community Nx plugins can automate parts of the OpenAPI workflow.