## Current Behavior
When running a task graph with continuous tasks and one of them is
terminated, the reverse continuous task deps that have no other tasks
that depend on them are also automatically terminated. This is fine in a
non-DTE context, but when running in a DTE context, the DTE task runner
must own the lifecycle of the continuous tasks, and Nx shouldn't
automatically terminate them.
## Expected Behavior
Nx shouldn't automatically terminate continuous tasks when running in a
DTE context.
## Current Behavior
The `create-nx-workspace` incorrectly offers `Vitest & Angular` as a
valid unit test runner choice when the bundler is something other than
`esbuild`.
## Expected Behavior
The `create-nx-workspace` should only offer `Vitest & Angular` as a
valid unit test runner choice when the bundler is `esbuild`.
## Related Issue(s)
Fixes#34014
## Current Behavior
On systems under heavy load, plugin loading can fail with:
```bash
Plugin Worker exited because no plugin was loaded within 10 seconds of starting up.
```
The initialization of the process metrics collection could potentially
cause this by blocking the loading of the plugin.
## Expected Behavior
Process metrics initialization no longer blocks critical startup paths,
allowing plugin loading to succeed regardless of system load.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Shared running tasks (tasks running in another process) do not appear in
the In Progress section of the TUI. They show the throbber as being in
progress, but are located in the Pending/Completed section.
## Expected Behavior
Shared running tasks (tasks running in another process) should appear in
the In Progress section of the TUI.
## Current Behavior
package installation does not set `windowsHide` so it flashes a terminal
window
## Expected Behavior
there should be no flashing terminal window
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Adds a sm utility script to ease quickly checking changes against local
repos. Not a replacement for local registry + install, but good for
quick checks
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump gradle project graph plugin version to 0.1.11
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We have a hard coded list of task targets to not exclude depends on.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We resolve a gradle task such that we can identify if there are provider
dependency relationships involved. If there are, then do not exclude
depends on since Gradle needs the dependsOn tasks to fulfill providers.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When processing Kotlin Multiplatform (KMP) projects, the Nx Gradle
plugin encounters ConcurrentModificationException errors because KMP
dynamically modifies the Gradle project's task and configuration
containers during dependency resolution. The plugin was resolving
configuration dependencies before processing tasks, which triggered
KMP's hierarchy finalization and dynamic task creation while the plugin
was still iterating over these collections.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Gradle plugin should handle Kotlin Multiplatform projects without
errors by:
1. Processing tasks before resolving configuration dependencies,
preventing KMP from modifying task containers during iteration
2. Creating immutable snapshots of task and configuration collections
before iteration to avoid concurrent modification issues
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3633
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The Nx Plugin uses Nx as the backing mechanism, but Gradle still does
some caching behind the scenes. When using Nx and Gradle's caching at
the same time, there can be times where Gradle does not recognize input
changes and will not execute tasks that it mistakenly deems unchanged.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure that the batch executor always reruns tasks and is not impacted
by the Gradle build cache.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3649
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
For 0.x versions, shift semver bump types down to follow the common
convention where breaking changes bump minor, and new features bump
patch:
- major -> minor
- premajor -> preminor
- minor -> patch
- preminor -> prepatch
- patch -> patch (unchanged)
This ensures that `nx release` with a breaking change on a 0.x package
(e.g., 0.1.0) bumps to 0.2.0 instead of 1.0.0.
Fixes NXC-3638
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
The migration generator (`@nx/plugin:migration`) fails when due to
ESLint flat config not being parsed correctly, leading to an error.
This happens because `replaceOverride` uses `parseTextToJson` to parse
the config, which fails for non-JSON-serializable JavaScript
expressions.
This PR fixes the issue by using AST parsing, like we did for
`hasOverrides` here https://github.com/nrwl/nx/pull/33548.
Fixes#34010
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
When adding a non-buildable JS library (`bundler: 'none'`) to a
workspace with an existing `@nx/js/typescript` plugin registration that
has build options configured, a duplicate plugin entry is unnecessarily
created in `nx.json`.
## Expected Behavior
Non-buildable libraries reuse the existing plugin registration when
`skipBuildCheck: true` is not specified, thereby avoiding duplicate
entries in `nx.json`. The `@nx/js/typescript` plugin will infer the
project as non-buildable because the library's `package.json` will have
entry points pointing to source files, so there's no need for a separate
plugin registration.
## Related Issue(s)
Fixes#33981
## Current Behavior
Rspack 1.7.0 is failing to create factories for internals with Module
Federation.
## Expected Behavior
Pin Rspack to 1.6.8 for now to ensure continued functioning of Module
Federation
## Current Behavior
PR #32915 changed how conventional commits determine version, making
them rely on commit scope:
commits with types configured to bump minor / major version bumps only
patch if commit scope exists and it does not include project name
## Expected Behavior
In our project we do not use projectName as commit scope, so we would
like to bring back old behavior, this can be achieved by adding option
to opt-out such behavior
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
- The `skipTypeChecking` option is a simple boolean that only allows
enabling/disabling type checking
- Rspack executor is missing the `runtimeDependencies` option that
webpack has
- The `cache` configuration is hardcoded and cannot be overridden by
users
## Expected Behavior
- New `typeCheckOptions` option allows configuring type checking with `{
async: true }` to run type checking in a separate process without
blocking the build
- The deprecated `skipTypeChecking` option is maintained for backward
compatibility
- Rspack now supports `runtimeDependencies` option for adding runtime
dependencies to generated `package.json` (useful for Docker installs)
- New `cache` option allows users to override webpack/rspack caching
behavior while maintaining backward-compatible defaults
## Related Issue(s)
N/A - Standalone feature
## Changes Made
### typeCheckOptions (webpack & rspack)
- Added `TypeCheckOptions` interface with `async` property
- Added `typeCheckOptions` option to plugin options interfaces
- Updated `apply-base-config.ts` to normalize `typeCheckOptions` from
deprecated `skipTypeChecking` for backward compatibility
- Added schema definitions to `schema.json` and `schema.d.ts`
### runtimeDependencies (webpack & rspack)
- Added `runtimeDependencies` option to `NxAppRspackPluginOptions`
- Updated `GeneratePackageJsonPlugin` to resolve and include runtime
dependencies
- Added schema definitions to `schema.json` and `schema.d.ts`
### cache (webpack & rspack)
- Added `cache` option to plugin options interfaces
- Updated `apply-base-config.ts` to check `'cache' in options` before
applying defaults
- Allows explicit `cache: undefined` to force cache to be disabled
- Maintains backward-compatible defaults:
- Webpack: `{ type: 'memory' }` for Node targets in watch mode
- Rspack: `true` for Node targets in watch mode, `true` in dependent
config
## Files Changed
**Webpack:**
-
`packages/webpack/src/plugins/nx-webpack-plugin/nx-app-webpack-plugin-options.ts`
-
`packages/webpack/src/plugins/nx-webpack-plugin/lib/apply-base-config.ts`
- `packages/webpack/src/executors/webpack/schema.json`
- `packages/webpack/src/executors/webpack/schema.d.ts`
- `packages/webpack/src/plugins/generate-package-json-plugin.ts`
**Rspack:**
- `packages/rspack/src/plugins/utils/models.ts`
- `packages/rspack/src/plugins/utils/apply-base-config.ts`
-
`packages/rspack/src/plugins/utils/plugins/generate-package-json-plugin.ts`
- `packages/rspack/src/executors/rspack/schema.json`
- `packages/rspack/src/executors/rspack/schema.d.ts`
**Documentation:**
- `astro-docs/.../webpack/Guides/webpack-plugins.mdoc`
- `packages/webpack/docs/webpack-build-executor-examples.md`
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
When generating Cypress component testing in Angular workspaces, the
base tsconfig sets moduleResolution to 'bundler' which causes TS5095
errors because 'bundler' requires module to be 'preserve' or 'es2015+'.
Cypress runs in Node.js and should use Node.js module resolution
instead. This fix sets moduleResolution to 'node' for Cypress
tsconfig.json templates.
## Current Behavior
When generating Cypress component testing configuration in Angular
workspaces, the generated `cypress/tsconfig.json` inherits
`moduleResolution: "bundler"` from the workspace base config. Since
Cypress uses `module: "commonjs"` for Node.js runtime, this causes
TypeScript compiler error TS5095: "Option 'bundler' can only be used
when 'module' is set to 'preserve' or to 'es2015' or later."
## Expected Behavior
The generated `cypress/tsconfig.json` should explicitly set
`moduleResolution: "node"` to match the `module: "commonjs"` setting,
preventing TS5095 errors. This aligns with how NestJS applications
handle the same issue (see #33607).
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Summary
Adds comprehensive Docker development guidance to the Nx Daemon
documentation.
Related to #33263, #30359, #14126
## What's included
This PR expands the existing Nx Daemon docs with a new "Running Nx in
Docker" section that covers:
- **Why the daemon often fails in Docker** - ephemeral filesystems,
inode/mtime changes from volume mounts, container restarts, IPC issues
- **Recommended approach** - disable daemon with `NX_DAEMON=false`
- **Example docker-compose setup** - minimal reproducible configuration
for local development
- **CI/CD best practices** - when to prefer stateless builds over daemon
caching
## Context
Several issues have been opened around daemon behavior in containers,
but the existing docs only briefly mention socket location
customization. Users are left wondering:
- Why doesn't the daemon work reliably in Docker?
- What's the recommended workflow for containerized development?
- How should CI pipelines handle this?
Issue #33263 specifically describes daemon crashes when running nx
between Docker and non-docker environments - this PR documents the
recommended workaround (`NX_DAEMON=false`) and explains why.
## Preview
The new section appears under the existing "Customizing the socket
location" heading and includes:
- Explanation of Docker-specific challenges
- Code examples for Dockerfile, docker-compose, and CLI
- Rule of thumb callout for quick reference
Open to feedback on structure or placement.
---------
Co-authored-by: kazuki <kazuki@kazukinoMacBook-Air.local>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Adds a new peerDepsVersionStrategy option that allows configuring how
peer dependencies versions are set when auto-fixing. When set to
'workspace', peer dependencies will use 'workspace:*' instead of the
installed or root package version. Defaults to 'installed' to maintain
backward compatibility.
## Current Behavior
A concrete peer dependency version is being fixed.
## Expected Behavior
User can choose between `installed` and `workspace` version strategies.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Plan to Fix Inputs Documentation
Based on the issue, I need to correct the inputs documentation at
`/astro-docs/src/content/docs/reference/inputs.mdoc`. The problems are:
- [x] Fix the invalid syntax in "Source Files" section - currently shows
inputs as an object instead of an array
- [x] Document the `{ input: someNamedInput, projects: [] }` format for
referencing named inputs from specific projects
- [x] Document the `{ input: someNamedInput, dependencies: true }`
format for referencing named inputs from dependencies
- [x] Document the object form for fileset inputs (e.g., `{ fileset:
string }`)
- [x] Ensure all documented formats match the TypeScript type definition
- [x] Fix typo found in code review (to to -> to)
- [x] Remove targetDefaults wrapper from examples (per review feedback)
- [x] Use string syntactic sugar forms in examples and explain
equivalence to object forms
- [x] Fix comment to show object form equivalence instead of repeating
string form
## Changes Made
1. **Fixed Source Files section syntax**:
- Changed from invalid object syntax to correct array syntax
- Removed unnecessary targetDefaults wrapper per review feedback
- Added documentation for the object format with fileset property
2. **Added new section "Named Inputs from Other Projects"**:
- Documents `{ input: "production", projects: "mylib" }` format
- Documents `{ input: "production", projects: ["mylib", "myapp"] }`
format for multiple projects
- Uses string syntactic sugar `"production"` and `"^production"` in
examples
- Explains equivalence: `"production"` is shorthand for `{ "input":
"production" }`, `"^production"` is shorthand for `{ "input":
"production", "dependencies": true }`
3. **Fixed typo**: Changed "to to not invalidate" to "to not invalidate"
All changes validated with prettier formatting checks.
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Issue Title: Docs: correct inputs syntax and document missing formats
> Issue Description: The inputs docs appear inaccurate at
[nx.dev/docs/reference/inputs#source-files](https://nx.dev/docs/reference/inputs#source-files).
>
> * The shown inputs syntax isn’t valid; it should be an array.
> * The page doesn’t mention the `{ input: someNamedInput, projects: [\]
}` format.
> * It also doesn’t cover the object form for `deps`/`self` inputs.
>
> Valid types reference:
[https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206](https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206)
>
> Working with \[GitHub
Copilot\](User:d484ef82-7f7d-4a95-be09-9d82ca3905dc) on this.
> Fixes
https://linear.app/nxdev/issue/NXC-3369/docs-correct-inputs-syntax-and-document-missing-formats
>
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> [https://github.com/nrwl/nx](https://github.com/nrwl/nx)
>
> Comment by User d484ef82-7f7d-4a95-be09-9d82ca3905dc:
> 📋 I wasn't able to determine which GitHub repository to work in.
>
> I think it's one of these, but can you tell me which one is right?
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Side not, copilot assignment didn't work. Would have been neat 🙂
>
> Comment by User d484ef82-7f7d-4a95-be09-9d82ca3905dc:
> Waiting for https://linear.app/nxdev/profiles/craigory to link their
GitHub account. [Click to authorize
→](https://linear.business.githubcopilot.com/linear/auth)
>
> Comment by User :
> This thread is for an agent session with githubcopilot.
>
> Comment by User :
> Created issue
[NXC-3369](https://linear.app/nxdev/issue/NXC-3369/docs-correct-inputs-syntax-and-document-missing-formats)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> This comment thread is synced to a corresponding [thread in
Slack](https://nrwl.slack.com/archives/CT3CQ2F0D/p1761762896195989?thread_ts=1761762896.195989&cid=CT3CQ2F0D).
All replies are displayed in both locations.
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> @Linear create a docs issue, assign it to me and copilot
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> Send a PR? 🙏
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> See these valid types:
[https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206](https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Also on the same page, I don't see any mention of the `{ input:
someNamedInput, projects: [] }` format, nor the object form for deps /
self inputs
>
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
## Current Behavior
The GitHub Actions DTE example includes a redundant conditional checkout
step that has separate configurations for pull request and default
branch events, both performing the same checkout operation.
## Expected Behavior
The GitHub Actions example should use a single, simpler checkout
configuration that works for both pull request and default branch
events, removing redundant code.
## Related Issue(s)
This change simplifies the documentation example by removing redundant
checkout steps while maintaining the same functionality.
Updated Turborepo section to include robust browser-based graph
visualizations and Graphviz image exports.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
TypeScript’s module resolution stop at project's root when resolving
modules.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
TypeScript’s module resolution will walk up to the workspace root when
resolving modules
## Changes Made
Convert the filePath to an absolute path inside findProjectFromImport
before calling resolveImportWithTypescript, because TypeScript’s module
resolution will not correctly traverse up the directory tree toward the
workspace root when given a relative path.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33985
When a vitest config file is at the workspace root and contains a
`projects` property in the test configuration, the plugin now skips
inferring test targets for that config. This is because root workspace
configs act as orchestrators - the actual tests live in the individual
project configs referenced by `projects`.
Fixes#32471
## Current Behavior
The dev-server builder throws an error about the "define" option not
being supported in Angular < 21, even when users don't configure it. The
validation uses a truthy check that treats empty objects `{}` as true.
## Expected Behavior
The error should only throw when users explicitly configure define with
actual keys.
## Related Issues
Fixes#33964
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: leosvelperez <12051310+leosvelperez@users.noreply.github.com>
## Current Behavior
There is no straight-forward way to use the cwd as part of a tasks hash
## Expected Behavior
You can use `{workingDirectory: 'absolute'}` to factor the working
directory into the hash
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33684
On test repo, the
`package-json:createNodes:isInPackageManagerWorkspacesTime` takes:
- Before the PR: 2356ms
- With PR: 23ms
This is achieved by avoiding unnecessary use of `minimatch` when a
direct string comparison is sufficient.
It also makes creation and logging of entire graph come down from
`23.6s` down to `18.5s`
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: meeroslav <meeroslav@users.noreply.github.com>
Add support for ESLint's new bulk suppression features introduced in
v9.24.0.
- Add `suppressAll` option to suppress all existing violations
- Add `suppressRule` option to suppress specific rule(s)
- Added `suppressionsLocation` option to specify custom location for the
suppressions file (defaults to eslint-suppressions.json)
- Include proper version checking for ESLint v9.24.0+
- Add related tests and documentation
- Update schema and TypeScript types
This allows teams to incrementally adopt stricter lint rules without
being overwhelmed by legacy violations.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The `@nx/eslint` package currently doesn't support ESLint's bulk
suppression features. When teams want to enable new lint rules, they
must fix all existing violations first, which can be a significant
barrier to adopting stricter linting standards.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The @nx/eslint package now supports ESLint v9.24.0+'s bulk suppression
features through new flags:
- `suppressAll`: Suppresses all existing violations
- `suppressRule`: Suppresses specific rules
- `suppressionsLocation`: specifies a custom location for the
suppressions file (defaults to eslint-suppressions.json)
```json
{
"lint": {
"executor": "@nx/eslint:lint",
"options": {
"suppressAll": true
}
}
}
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/discussions/30620
This PR removes the variant check for deciding whether to use GitHub
templates for CNW. Moving forward, the first-level options are all
`nrwl/*` templates. The `Custom` option allows users to go back to the
previous presets.
Explains how to configure Tailwind CSS so that classes used in remote
applications are properly compiled by the host application. Covers both
Tailwind v3 (content array) and v4 (@source directive) configurations.
This PR fixes the `/changelog` page.
With `getStaticProps`, files were read at build time when copy-docs had
already copied them. With `getServerSideProps`, files are read at
request time on serverless functions where those files don't exist.
This PR reverts the changes to use `getServerSideProps` and uses a
middleware instead. This also has the benefit of keeping the pages
static, so we do not need edge functions to run their server function.
Fixed: https://nx-dev-git-doc-372-nrwl.vercel.app/changelog
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
Cypress Component Testing for zoneless Angular projects is not
supported.
## Expected Behavior
Cypress Component Testing for zoneless Angular projects should be
supported.
## Current Behavior
When generating Angular apps/libs with `setParserOptionsProject`, the
ESLint flat config output did not include the project-level
`parserOptions.project`, so type-aware lint rules still fail unless
users edit the config manually.
## Expected Behavior
Enabling `setParserOptionsProject` produces the appropriate
project-level `parserOptions.project` configuration in both flat ESLint
config and legacy `.eslintrc.json`, so type-aware linting works out of
the box.
## Related Issue(s)
Fixes#33944
## Current Behavior
When migrating Angular packages the `@angular/cli` package is not
updated as part of the `nx migrate` initial package updates to the
`package.json` file. Instead, it's updated at a later stage with a
migration generator. This happens for a couple of reasons:
- Angular CLI package group will update all the packages using a `^`,
which can result in workspaces getting a minor version of the packages
installed before Nx adds support for that minor version.
- Angular CLI migrations can error due to some assumptions that are not
always correct in Nx workspaces.
- The `nx migrate` command currently doesn't have the ability to ignore
the package group or migrations of a given package.
This is why the `@angular/cli` package is migrated "manually" in a
migration generator.
## Expected Behavior
The `@angular/cli` package should be updated as part of the package
updates performed by the `nx migrate` command while ignoring its package
group and migrations. The `@nx/angular` package already provides the
same set of migrations and more.
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Current Behavior
Creating a new Angular workspace with Vitest results in no test setup
being generated. This happens because the `vitest` option is no longer
available, and instead, there are two options: `vitest-angular` and
`vitest-analog`.
## Expected Behavior
Creating a new Angular workspace should prompt for Vitest with Angular
or Vitest with Analog to set up the tests.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: leosvelperez <leosvelperez@users.noreply.github.com>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
The getDependentPackagesForProject function was crashing when processing
projects with non-npm external nodes (e.g., cargo: prefixed nodes from
@monodon/rust plugin). The code only handled npm: prefixed externals and
treated everything else as workspace libraries, causing undefined access
errors when cargo externals were encountered.
This fix adds a check to skip external nodes that aren't npm-prefixed by
detecting the presence of a colon in the dependency target. Only npm:
prefixed externals are processed as npm packages, and other external
prefixes (cargo:, maven:, etc.) are now properly skipped.
Fixes#32819
## Current Behaviour
The ignorePatternsForPlanCheck configuration option in nx.json for
version plans lacks
documentation about the pattern syntax. Users attempting to use negation
patterns (e.g.,
["*", "!src/"]) may experience unexpected behavior because gitignore
semantics don't work
as intuitively expected with such patterns.
## Expected Behaviour
The documentation and JSDoc comments now clearly explain:
- That ignorePatternsForPlanCheck follows gitignore semantics
- Working patterns like ["**/*.spec.ts"] and ["**/*.ts", "!**/src/**"]
- Non-working patterns like ["*", "!src/"] and why they don't work as
expected
- Recommended approach of using file extension patterns instead of
wildcards when trying to
ignore all files except those in specific directories
## Related Issues
Fixes#30324
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
When running single tasks we have a "minimal" tui, but that minimal tui
still makes it really hard / impossible to use some of the terminals
built in features... like:
- Find (can only find what's currently rendered by tui)
- Text select + copy (can only select what's rendered to screen, copied
text includes the frame around the tui / scrollbar)
## Expected Behavior
When running single tasks we can use an inline viewport to render some
tui widgets at the bottom of the viewport, and terminal output can be
printed above.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Disabling Maven e2e tests since something with e2e setup breaks when we
try to update the spring boot version.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
make sure canonical always points to nx.dev and not a subdomain preview
incase they're index.
<img width="1728" height="863" alt="image"
src="https://github.com/user-attachments/assets/8e7d91c1-277b-4a2a-91ec-732f7f4f37ae"
/>
also confirm that robots.txt still has deny for non prod builds.
this is done via middleware since canonical url is controlled via astro
config 'site' property. which is used to control other aspects that we
do want to be preview URL domains (like navigation). so we have a
middleware to always override the url to match prod.
also nextjs side was already overriding this in `_app.tsx`
This PR adds the ability to consumer banner data for nx.dev (both astro
and next.js) from a remote JSON file. This is only enabled if
`BANNER_URL` environment variable is set.
The `banner-config.json` files are committed for both astro and next.js,
so before we consume banner JSON from Framer, we can use this as the
source of truth rather than update the component code.
Once we switch completely to Framer CMS, we can remove the committed
JSON files.
Note: A redeploy is required for banner changes to take effect. In the
future we may be able to do this dynamically in Astro.
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Maven plugin was complaining about Spring-boot version being behind 3.5
when running e2e suite. Also bumped down maven plugin version since
version 0.0.12 could not be found at the time of this PR.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The inferred tasks documentation at
https://nx.dev/docs/concepts/inferred-tasks does not mention the
`include` or `exclude` options on plugins, even though this is a common
and useful feature for scoping plugins to specific projects.
## Expected Behavior
The inferred tasks documentation now includes a new section called
"Scope Plugins to Specific Projects" that explains:
- How to use `include` and `exclude` properties in plugin configuration
- What the glob patterns match against
- Use cases for this feature (scoping plugins, applying different
options to different projects)
This aligns with the existing documentation in the nx.json reference
guide.
## Related Issue(s)
Fixes DOC-367
## Current Behavior
When generating a React Module Federation remote with webpack bundler in
a TypeScript
Solution setup, the generator incorrectly sets the production webpack
config path in the
project configuration. Additionally, the sourceRoot property is not
being set in
package.json for TS Solution setups, which causes issues with module
federation's ability
to locate source files correctly.
## Expected Behavior
When using a TypeScript Solution setup:
- The production webpack config should not be explicitly set in the
build target's
production configuration (it will be inferred correctly)
- The sourceRoot property should be set in package.json under the nx
configuration to
properly identify the project's source directory
- The typecheck target should be added as a dependency for both build
and serve targets
## Related Issue(s)
Fixes#31029
## Current Behavior
The `replace-removed-matcher-aliases` migration from `@nx/jest` is not
run when migrating to Angular v21 (and updating Jest to v30). That
migration targets the original package update for Jest v30 (Nx 21.3.0),
which was incompatible with Angular < 21, so it wouldn't have run for
Angular workspaces at the time. Now that Angular is being updated to
v21, Jest is updated to v30, but the migration generator is not running.
## Expected Behavior
The `replace-removed-matcher-aliases` migration from `@nx/jest` should
run when migrating to Angular v21 (and updating Jest to v30).
## Current Behavior
The Maven version used for development dependencies is currently set to
3.9.11 in both pom.xml and mise.toml.
## Expected Behavior
The Maven version should be updated to 4.0.0-rc-5 to align with the
Maven 4 version already used in the batch-runner component.
## Related Issue(s)
N/A - This is a dependency version update to ensure consistency across
the Maven plugin ecosystem.
## Changes
- Updated `maven.version` property in pom.xml from 3.9.11 to 4.0.0-rc-5
- Updated maven tool version in mise.toml from 3.9.11 to 4.0.0-rc-5
This ensures that developers working on the Nx Maven plugin use the same
Maven 4.0.0-rc-5 version across all components.
## Current Behavior
The Maven plugin version is currently at 0.0.11.
## Expected Behavior
This PR bumps the Maven plugin version to 0.0.12 and creates a migration
for Nx 22.4.0-beta.0. This allows users to automatically update their
pom.xml files when they upgrade to the next version of Nx.
## Related Issue(s)
N/A - Version bump
## Current Behavior
The daemon currently depends on client requests failing with a
`LOCK_FILES_CHANGED` error to trigger a restart. This creates several
issues:
- The daemon may stay running with stale dependencies if no requests
come in
- The client must wait for a request to fail to trigger reconnection
- Special-case error handling is scattered across the client code
## Expected Behavior
The daemon should proactively restart itself when lock files change, and
the client should gracefully reconnect with exponential backoff for any
server shutdown scenario.
## Changes
### Client-Side: Exponential Backoff Reconnection
- Add `handleConnectionError()` method that retries with exponential
backoff (10ms → 5000ms, 30 attempts max)
- Preserve pending messages during reconnection and resend them once the
new daemon is available
- Remove special-case handling for `LOCK_FILES_CHANGED` and
`NX_VERSION_CHANGED` errors
- Remove `retryMessageAfterNewDaemonStarts()` method as it's no longer
needed
### Server-Side: Self-Restart on Lock File Changes
- Add `startNewDaemonInBackground()` to spawn a replacement daemon
before shutdown
- Add `handleServerProcessTerminationWithRestart()` for restartable
shutdown scenarios
- Detect lock file changes and proactively start a new daemon before
responding with an error
- Keep version change handling simple (just exit, no restart)
## Benefits
- **More Resilient**: Client recovers from any server shutdown, not just
specific errors
- **Cleaner Architecture**: Server manages its own lifecycle, client
doesn't need special cases
- **No Request Dependency**: Daemon doesn't wait for requests to detect
changes
- **Reduced Error Spam**: Exponential backoff prevents connection error
floods
- **Future-Proof**: Foundation for other restart scenarios (plugins,
config changes)
## Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/30514
Fixes https://github.com/nrwl/nx/issues/29118
## Summary
Adds a batch executor for Nx Maven that enables parallel multi-task
execution with significant performance improvements. The batch runner
keeps Maven resident in memory, avoiding cold start overhead for each
task.
## Changes
### 1. Batch Runner JAR (`packages/maven/batch-runner`)
- **ResidentMavenExecutor**: Uses Maven 4.x's `ResidentMavenInvoker` to
keep Maven in memory
- **NxMaven**: Custom Maven wrapper that caches project graphs and
sessions across invocations
- **CachingResidentMavenInvoker**: Preserves session state so artifacts
from `jar:jar` are visible to `install:install`
- **BuildStateManager**: Applies/records build states for
cross-invocation caching
- Maven 4.x dependencies are shaded into the JAR for standalone
execution
### 2. TypeScript Executors (`packages/maven/src/executors/maven`)
- **maven.impl.ts**: Single-task executor using `mvnw`/`mvn`
- **maven-batch.impl.ts**: Batch executor that invokes the batch runner
JAR
- Automatic Maven version detection and executable resolution
### 3. Shared Utilities (`packages/maven/shared`)
- `BuildState`, `BuildStateApplier`, `BuildStateRecorder` for
cross-invocation state
- `MavenCommandResolver` for detecting Maven executable
- Reusable across batch-runner and maven-plugin modules
### 4. Maven Plugin Updates (`packages/maven/maven-plugin`)
- Updated to use `@nx/maven:maven` executor (batch-aware)
- Improved `GitIgnoreClassifier` for nested .gitignore handling
- Cache config tweaks for compiler inputs
## Performance
| Scenario | Before | After |
|----------|--------|-------|
| Cold start per task | 100-500ms | N/A (one-time init) |
| Per-task execution | 100-500ms | ~1.3ms (cached) |
| Improvement | - | **75-385x faster** |
## Version Support
- **Maven 4.x**: Full support with ResidentMavenExecutor (optimized)
- **Maven 3.x**: Falls back to ProcessBasedMavenExecutor (subprocess)
## Testing
- E2E tests for Maven 4.0.0-rc-4, 4.0.0-rc-5
- Unit tests for TypeScript executors
- Tests for GitIgnoreClassifier
## Current Behavior
Uses subprocess execution via `mvnw`/`mvn` for each task.
## Expected Behavior
Batch execution keeps Maven resident, dramatically reducing per-task
overhead.
## Related Issue(s)
Part of Maven integration improvements.
---------
Co-authored-by: Max Kless <maxk@nrwl.io>
## Current Behavior
The tui shouldn't show for single tasks
## Expected Behavior
The tui isn't shown for single tasks
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Two issues with the .NET dependency graph:
1. Issue #33653: When a .NET project uses multi-targeting
(<TargetFrameworks> plural), its project reference dependencies
disappear from the Nx graph.
2. Issue #33397: Transitive dependencies are incorrectly shown as direct
dependencies. For example, if A → B → C, the graph shows A depending on
both B and C, when it should only show A → B.
## Expected Behavior
1. Multi-targeting projects should correctly show their dependencies in
the graph.
2. Only direct dependencies should be shown, not transitive ones. Nx
handles transitive dependencies through the dependency chain.
### Solution
Multi-targeting fix (#33653)
MSBuild creates multiple nodes for multi-targeting projects:
- An "outer build" with TargetFrameworks set but TargetFramework empty
- "Inner builds" for each target framework with TargetFramework set
The fix groups nodes by project file path and prefers inner builds
(which have properly resolved references) over outer builds.
### Transitive dependency fix (#33397)
Changed from using ProjectGraphNode.ProjectReferences (which includes
transitive dependencies in multi-targeting scenarios) to
ProjectInstance.GetItems("ProjectReference") which returns only direct
references defined in the project file.
## Related Issue(s)
Fixes#33653Fixes#33397
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Templates use `"*"` for workspace dependencies in individual
package.json files. This works for npm but breaks pnpm, yarn, and bun
which require the `workspace:` protocol for proper symlinking.
For pnpm, yarn, and bun: automatically convert `"*"` dependencies to
`"workspace:*"` in all workspace package.json files. npm is left
unchanged since it handles `"*"` natively.
Also adds support for 2-level nested projects (e.g.,
`libs/shared/models/package.json`).
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
Sync generators are processed in the background by the daemon server.
Their results are cached and reprocessed when the project graph is
recomputed. There are currently two issues:
- The cache is only invalidated after the project graph finishes
recomputing, which means that there's an interval between files changed
(triggering the project graph recomputation) and the recomputation
finishes, where the cache is not invalidated, and it's stale. During
that interval, any request to get the sync generator changes will use
the stale cache.
- Sync generators are scheduled to be processed after the project graph
is recomputed, so a quick succession of recomputations can be coalesced.
The problem is that the scheduled closure uses the project graph from
the initial scheduling, rather than the latest available project graph
at the time it runs. This results in the usage of stale data to process
the sync generators.
## Expected Behavior
Getting sync generators changes should always return up-to-date
information.
## Current Behavior
When database initialization fails due to filesystem issues, permission
problems, or environment incompatibilities (like WAL mode not being
supported), Nx shows generic error messages that don't provide
actionable guidance to users. For example:
- "Unable to create db lock file: PermissionDenied"
- "Unable to set journal_mode: <sqlite error>"
This makes it difficult for users to diagnose and resolve issues,
especially in restricted environments like Docker containers, network
filesystems, or WSL1.
## Expected Behavior
With this PR, database initialization errors now provide:
1. **Context-specific error messages** - Different guidance based on the
error type:
- Permission denied: Instructions about file ownership, Docker volume
permissions, and read-only filesystems
- Storage full: Suggestions to free disk space
- Already exists: Guidance about stale files from crashed processes
2. **Automatic WAL mode fallback** - When WAL journal mode is not
supported by the filesystem, Nx now automatically falls back to DELETE
journal mode instead of failing. This improves compatibility with:
- Network filesystems (NFS, CIFS)
- Some Docker volume configurations
- Other environments with limited locking support
3. **WSL1 detection** - Proactively detects WSL1 environments (which
have known WAL incompatibilities) and uses DELETE mode from the start,
avoiding failed attempts and retries.
4. **Better cleanup on retry** - When database initialization fails and
needs to retry, all auxiliary files (WAL and SHM files) are also cleaned
up, not just the main database file.
5. **Actionable reporting instructions** - All error messages now
include:
- How to capture detailed logs
(`NX_NATIVE_FILE_LOGGING=nx::native::db=trace`)
- Link to create an issue
- Suggestion to run `nx reset`
## Current Behavior
When users press unhandled keys in the TUI (e.g., pressing `i` on a
completed task, or typing in a non-interactive terminal pane), nothing
happens and there's no feedback explaining why.
Similarly, when users press certain key bindings like `c` to copy
output, the action succeeds but there's no visual confirmation.
## Expected Behavior
### Hint Popups for Unhandled Keys
Users now see helpful hint popups when pressing keys that don't work in
the current context:
- Pressing `i`, `c`, or `Ctrl+A` in the dependency view (task hasn't
started yet)
- Pressing `i` on a task that doesn't support interactive mode
- Pressing character keys in a terminal pane that's not in interactive
mode
The hints explain what's happening and guide users on how to proceed.
### Status Messages for "Invisible" Actions
When users perform actions without obvious visual feedback, a status
message now appears in the terminal pane's bottom border:
- `Output copied` when pressing `c` to copy
- `Sent to assistant` when pressing `Ctrl+A`
### Configuration Option
Users who prefer not to see hint popups can disable them in `nx.json`:
```json
{
"tui": {
"suppressHints": true
}
}
```
Current Behavior
When using pnpm catalogs to manage dependency versions, the Storybook
utilities and ESLint version-utils read package.json directly using
readJson() or readJsonFile(). This approach doesn't resolve catalog
references like catalog:default, causing version detection to fail or
return incorrect values.
For example, if package.json contains:
{
"devDependencies": {
"storybook": "catalog:default"
}
}
The current code would return "catalog:default" as the version string
instead of resolving it to the actual version (e.g., "8.5.0").
Expected Behavior
Use the getDependencyVersionFromPackageJson() helper from @nx/devkit
which properly handles pnpm catalog resolution. This ensures that
version detection works correctly regardless of whether dependencies are
specified directly or via pnpm catalogs.
The helper:
- Resolves catalog: references to their actual versions
- Falls back gracefully when catalogs aren't in use
- Maintains consistent behavior across different package managers
Related Issue(s)
Fixes issues with pnpm catalog compatibility in Storybook generators and
ESLint utilities.
Related to #29772
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Nx doesn't generate projects with Prettier v3.
## Expected Behavior
Nx should generate projects with Prettier v3.
## Related Issue(s)
Fixes#30801
## Current Behavior
There's a deadlock between the Angular and Jest package updates
requirements (`requires` and `incompatibleWith`) that prevents updating
Jest to v30 and `jest-preset-angular` to v16.
## Expected Behavior
Updating to Angular v21 should result in updating Jest to v30 and
`jest-preset-angular` to v16.
This is ensured by moving the `jest-preset-angular` package update
definition to the `@nx/jest` package and processing the `@nx/angular`
package updates before `@nx/jest`. That way, by the time `@nx/jest` is
processed, the migrator would have collected the Angular v21 updates,
and the requirements will be met.
## Current Behavior
The nx-dev Next.js app can only serve pages from its own codebase or
proxy to Astro docs.
## Expected Behavior
Support proxying specific pages to a Framer site via environment
variables:
- `NEXT_PUBLIC_FRAMER_URL`: Base URL of the Framer site
- `NEXT_PUBLIC_FRAMER_REWRITES`: Comma-separated paths for new pages
For existing pages like `/ai`, the proxy is handled in
`getServerSideProps`.
## Related Issue(s)
Closes DOC-349
Co-authored-by: Claude <noreply@anthropic.com>
Removed 'node_modules' from the ignore list for asset copying.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Updating Nx to v22 breaks my app. Some projects use generated Prisma
clients which, because of how Prisma binaries work, have to be generated
to `node_modules` in order to work both locally and in Docker context.
With Nx v22 Prisma client is not copied when project is built using
`@nx/esbuild:esbuild` (or any other executor supporting `assets`
property) without any error or warning. It took mi couple of hours to
pinpoint the exact line of code responsible for this. `node_modules` dir
is hardcoded there without any possibility to be overridden.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Prisma client can be copied from `node_modules` to project output
directory when building.
Ignoring `node_modules` is removed **or can be overridden**. I'm open to
any solution which will let me update Nx in my repository.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
This PR adds a validation to the directory prompt, so users should not
hit the error as often. Only possible now if they pass the arg from CLI
_and_ they are in non-interactive mode.
We also added some more data to help debug problems, such as node
version, template/preset chosen, etc. And updated the message in
"custom" preset prompt to align with the more effective "full platform"
prompt.
Note: Also update the error message (if it hits) to be the same in new
flow and old flow.
## Related Issue(s)
Closes NXC-3624
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
The `argv` field was already implemented in `PreTasksExecutionContext`
and `PostTasksExecutionContext` but lacked tests and documentation for
plugin authors to discover and use it.
## Changes
- **Added unit tests**
(`packages/nx/src/daemon/server/handle-tasks-execution-hooks.spec.ts`)
validating that `argv` flows correctly through hook handlers for
different command patterns (direct, affected, run-many)
- **Enhanced existing documentation** in
`astro-docs/src/content/docs/extending-nx/task-running-lifecycle.mdoc`
with a new section covering:
- Context property definitions showing the `argv` field
- Examples showing how to detect command types (direct execution,
affected, run-many)
- Example demonstrating conditional analytics based on the original
command
- Common command patterns reference
- Best practices for defensive argv parsing
## Usage
```typescript
import type { NxPlugin, PostTasksExecutionContext } from '@nx/devkit';
export const myPlugin: NxPlugin = {
name: 'my-plugin',
postTasksExecution: async (options, context: PostTasksExecutionContext) => {
// Distinguish between nx build my-app vs nx affected -t build
if (context.argv.includes('affected')) {
console.log('Running in affected mode');
}
}
};
```
Fixes
https://linear.app/nxdev/issue/NXC-3382/add-contextargv-to-task-execution-hook-contexts
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Issue Title: Add context.argv to task execution hook contexts
> Issue Description: Expose the original CLI arguments on the plugin
worker so hooks can distinguish how execution was started (e.g., `nx
build nx-api` vs `nx affected -t build`). Proposal: include the invoking
argv on the hook context (e.g., `context.argv`).
> Fixes
https://linear.app/nxdev/issue/NXC-3382/add-contextargv-to-task-execution-hook-contexts
>
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> [https://github.com/nrwl/nx](https://github.com/nrwl/nx)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Aha! that worked - so you can tell it to assign to copilot instead of
"me and copilot"
>
> Comment by User d484ef82-7f7d-4a95-be09-9d82ca3905dc:
> 📋 I wasn't able to determine which GitHub repository to work in.
>
> I think it's one of these, but can you tell me which one is right?
>
> Comment by User :
> Created issue
[NXC-3382](https://linear.app/nxdev/issue/NXC-3382/add-contextargv-to-task-execution-hook-contexts)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> This comment thread is synced to a corresponding [thread in
Slack](https://nrwl.slack.com/archives/C070BJ2JYLW/p1761928859857989?thread_ts=1761928859.857989&cid=C070BJ2JYLW).
All replies are displayed in both locations.
>
> Comment by User :
> This thread is for an agent session with githubcopilot.
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> @Linear make a ticket and assign it to copilot
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> Makes sense to me
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Sure, context.argv?
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> We can add them as `argv`?
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> Yeah they would run on the plugin worker so it's not there
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> @jason we could add `originalArgv` to the contexts?
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Eh, probably not... they run on the plugin worker
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Yeah, I don't think the hooks know.... I'd be curious if process.argv
would just have that info though
>
> Comment by User 439b15a6-827b-4258-971a-d86133ad59de:
> payfit does
>
> Comment by User 74901385-a023-4825-8470-fe68b1b55664:
> I can’t see anything about that in the docs - so I would assume the
hooks are agnostic to how the tasks were triggered?
>
> Comment by User 74901385-a023-4825-8470-fe68b1b55664:
> so they’re asking is there’s a way to tell the difference between `nx
build nx-api` or `nx affected -t build` in the task hook?
>
> Comment by User 74901385-a023-4825-8470-fe68b1b55664:
> > I’ve been playing around with the Task Execution Hooks, specifically
the postTasksExecution hook, and I think it will be really useful for me
to grab some detailed metrics for our specific use cases.
> > What I feel like it’s missing is a way to see what command actually
started the task execution, whether it was a specific target or an
affected command. As long as it was a specific target, I think the tasks
are sorted in order so the last taskResult will probably be the actual
target of the command but for affected it seems a bit more random what
the last result will be.
> > Is there a way to know exactly which command kicked off the ‘task
execution’?
>
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Copilot <Copilot@users.noreply.github.com>
## Current Behavior
The same task can be pinned in multiple terminal panes of the TUI. This
causes one pane to scroll the other because they share the same data.
## Expected Behavior
The same task can only be pinned in a single terminal pane of the TUI.
## Current Behavior
The e2e test `should emit decorator metadata when using --compiler=swc`
fails because the regex `/Foo=.*?_decorate/` expects the old transpiled
output format where classes were assigned to variables.
## Expected Behavior
The test should pass by matching the current SWC output format which
uses native ES class syntax.
## Solution
Updated the regex from `/Foo=.*?_decorate/` to `/class
Foo.*_ts_metadata/` which:
- Matches `class Foo` (native ES class syntax)
- Verifies `_ts_metadata` is present (decorator metadata)
## Current Behavior
When `NX_NATIVE_COMMAND_RUNNER=false` is set, tasks running in the TUI
don't display any output in the terminal pane. The pane remains empty
even though the task is running.
## Expected Behavior
Task output is displayed in the TUI terminal pane regardless of the
`NX_NATIVE_COMMAND_RUNNER` setting.
## Related Issues
Fixes#32803
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When upgrading to Angular 21 with Jest, users may encounter TypeScript
compilation issues because their `tsconfig.spec.json` files don't have
`isolatedModules: true` set, which is required for compatibility with
Jest and `jest-preset-angular`.
## Expected Behavior
After running `nx migrate`, Angular projects using Jest will
automatically have `isolatedModules: true` added to their
`tsconfig.spec.json` files (or custom test tsconfig files referenced by
`@nx/jest:jest` tasks) if not already set or inherited from a parent
tsconfig.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Update references to disablement variable for metrics collection for Nx
Cloud enterprise users.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
When using `@nx/node:library` generator with `--compiler=swc`, the
generator
was incorrectly adding `tslib` as a dependency instead of
`@swc/helpers`.
This change fixes two issues:
1. Pass the correct bundler (matching the compiler) to
jsLibraryGenerator
so it adds the correct helper dependency to the project's package.json
2. Update ensureDependencies to only add tslib when compiler is tsc
Fixes#31202
Fixes#32069
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
The Azure Pipelines schema requires fetchDepth to be a string, but the
generator was outputting a number.
This fix changes the value to a string to match the official schema
specification.
## Current Behavior
The generator creates `azure-pipelines.yml` with `fetchDepth: 0`
(number), which causes YAML schema validation error because the Azure
Pipelines schema expects `fetchDepth` to be a string.
According to the [Azure Pipelines
schema](https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/master/service-schema.json),
`fetchDepth` is defined as:
```json
"fetchDepth": {
"description": "Depth of Git graph to fetch",
"$ref": "#/definitions/string"
}
```
## Expected Behavior
The generator should output `fetchDepth: '0'` (string) to match the
schema specification and prevent validation errors.
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
If a workspace uses pnpm and adds a local patch to a dependency (e.g.
`vitest`), this patch is not taken into account when computing that
dependency's hash for purposes of determining cache changes. In
practice, you could patch vitest locally, and tests would pull from the
cache.
## Expected Behavior
Patches can alter behavior in the same way that updating the version
could, it's just that the version is not created and the patch is
applied locally.
This updates the pnpm lockfile parsing functionality to read the patches
field into a map and then combine the patch hash with the integrity
hash. The integrity hash ONLY represents the remote / tarball
intergrity, so these have to be combined in order to create a proper
key.
## Related Issue(s)
(Could not find any, but saw this in my work today)
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Due to this PR https://github.com/swc-project/pkgs/pull/53 at SWC, it is
not possible to use the latest version of @swc/cli in NX.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
stdout and stderr are now handled more precisely, allowing you to update
to the latest version of @swc/cli.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
When a project has a `project.json` file but no `name` field, the
`addBuildAndWatchDepsTargets` function in
`packages/js/src/plugins/typescript/util.ts` returns early without
creating build and watch deps targets, even if the project has a valid
name in its `package.json`.
## Expected Behavior
The function should fall back to checking `package.json` for the project
name when `project.json` exists but has no `name` field, allowing the
build and watch deps targets to be created properly.
## Related Issue(s)
This fixes an issue where projects with `project.json` files missing the
`name` field would not get proper build and watch dependency targets
generated.
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
`getProjectPathsAffectedByDependencyUpdates` in
`@packages/nx/src/plugins/js/project-graph/affected/lock-file-changes.ts`
doesn't return projects affected when updating `pnpm.overrides` or
`overrides` in package.json.
## Expected Behavior
When `overrides`, `resolutions`, or `pnpm.overrides` fields are changed
in package.json, the affected projects should be properly detected and
returned.
## Related Issue(s)
This addresses reports that affected project detection isn't working
properly when package manager override configurations are changed.
## Changes Made
- Enhanced `getTouchedNpmPackages` function to detect changes to
`overrides`, `resolutions`, and `pnpm.overrides` fields
- When a known package is changed in overrides, only that specific
package is marked as affected
- When an unknown package is changed in overrides, all projects are
marked as affected (since overrides can affect transitive dependencies)
- Added comprehensive tests for all override scenarios
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
### Summary:
This PR updates the Nx documentation for the Storybook migration
generator to ensure clear and accurate guidance for migrating to
Storybook version 9. It replaces outdated references to version 8,
corrects migration links, and updates example configurations for Angular
and React (Vite) projects to reflect Storybook v9. These improvements
help users follow the correct steps and avoid confusion when upgrading
their workspace to the latest major release.
### Key Updates:
- Updated all migration documentation links and text to target Storybook
v9 resources.
- Corrected example .storybook/main.js|ts file descriptions for Angular
and React projects to reference version 9.
[[1]](diffhunk://#diff-2bd0403b5cc6e0c92d83a89400b36d55ad50eb0f82688aa976ecb3c93ff69eceL44-R44)
[[2]](diffhunk://#diff-2bd0403b5cc6e0c92d83a89400b36d55ad50eb0f82688aa976ecb3c93ff69eceL61-R61)
- Ensured users will be directed to the right guides and migration steps
for a smoother upgrade experience.
### Type of Change:
Documentation only; no changes to code or functionality.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
N/A - Docs update
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
N/A - Docs update
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A
## Current Behavior
The `pageGenerator` has the option `fileName`, but it is not affecting
anything.
## Expected Behavior
The `pageGenerator` has the option `fileName`, it will define the page
file name.
## Current Behavior
The `recordStat` telemetry for `create-nx-workspace` and
`create-nx-plugin` completion events does not include the Nx Cloud
connect URL.
## Expected Behavior
The connect URL (e.g., `https://cloud.nx.app/connect/{shortlinkId}`) is
now included in the completion metadata sent to `/nx-cloud/stats`.
## Related Issue(s)
N/A - Internal telemetry enhancement
NODE_VERSION was set only on the mise-action step, so subsequent steps
defaulted to the wrong node version and corepack couldn't create the
pnpm shim.
Also update corepack first, otherwise you might run into intermittent
integrity check issues:
- https://github.com/nodejs/corepack/issues/612
- https://vercel.com/kb/guide/corepack-errors-github-actions
---
Before (NODE_VERSION at step-level):
1. mise-action runs with NODE_VERSION=20
- mise installs Node 20
- mise adds /home/runner/.local/share/mise/installs/node/20.x.x/bin/ to
PATH
2. corepack enable runs - NODE_VERSION is NOT set anymore (step env is
gone)
- corepack shim calls mise
- mise reads mise.toml template: node = "{{ env['NODE_VERSION'] |
default(value='24.11.0') }}"
- NODE_VERSION is unset → defaults to 24.11.0
- mise runs corepack from Node 24's install
- corepack creates pnpm shim in Node 24's bin directory
3. pnpm install runs
- PATH has Node 20's bin (from step 1)
- pnpm is in Node 24's bin (from step 2)
- pnpm not found!
After (NODE_VERSION at job-level):
1. mise-action runs with NODE_VERSION=20 (from job env)
- mise installs Node 20, adds its bin to PATH
2. corepack enable runs - NODE_VERSION=20 is still set
- corepack shim calls mise
- mise sees NODE_VERSION=20
- corepack runs from Node 20's install
- pnpm shim created in Node 20's bin
3. pnpm install runs
- PATH has Node 20's bin ✓
- pnpm is in Node 20's bin ✓
- Works!
---
Closes NXC-3620
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
The `linkTaskDetails` parameter was removed from the `NxCache`
constructor in #33843, which broke Nx Cloud since it still passes this
parameter.
## Expected Behavior
The `NxCache` constructor should accept the `linkTaskDetails` parameter
(even if unused) to maintain backwards compatibility with Nx Cloud.
## Related Issue(s)
Fixes
https://github.com/nrwl/nx/commit/ed09ee1daed597b7be60255f0cebe52efdd1ae69#r172894152
Updates CNW messages and removes `cancel` event from being recorded in
SIGINT handler, since it didn't work.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
When multiple MF dev servers run concurrently and share the same remote,
they would both attempt to start proxies on the same port, causing
EADDRINUSE errors.
This fix checks if a port is already in use before attempting to start
a proxy. If the port is occupied (likely by another MF dev server that
started earlier), the proxy is skipped for that remote since it's
already being served.
Uses the existing `waitForPortOpen` utility with retries: 0 to perform
an immediate check.
Fixes#33470
Update the programmatic API documentation to clarify that the dryRun
option for releasePublish does not prevent the underlying commands
from being executed. Instead, it forwards the flag to the executor
and sets the NX_DRY_RUN environment variable.
This makes it clear that:
- The built-in @nx/js:release-publish executor handles dryRun correctly
- Custom nx-release-publish executors must implement dryRun support
themselves
Fixes#33443
The publish workflow template was designed for fixed versioning strategy
(where all packages share the same version). This commit adds:
- A callout explaining that the template works best with fixed
versioning
- A new section covering considerations for independent versioning
- Documentation of GitHub's 3-tag event limitation
- Alternative approaches: workflow_dispatch, branch-based triggers, or
batch tag pushing
Fixes#33502
## Current Behavior
The `printTaskTerminalOutput` callback in the TUI summary life cycle
overwrites terminal output for all tasks when output is provided. This
causes the command line information (the actual command that was run) to
be lost for non-cached tasks because non-cached tasks stream their
output via `appendTaskOutput`, which includes the command information.
## Expected Behavior
For non-cached tasks (those with 'failure' or 'success' status), the
output should be preserved from the streaming via `appendTaskOutput`
which includes the complete command line that was executed. Only cached
tasks should have their output overwritten by `printTaskTerminalOutput`
since they don't go through the streaming path.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
## Current Behavior
NestJs libraries are generated with output path pointing to workspace
level dist folder. With TS Soln setups, we expect the dist folder to be
local to the project.
## Expected Behavior
Ensure the outputPath generated is correct
## Related Issue(s)
Fixes#32060
## Current Behavior
`nx format:write` fails with Prettier 4+ (and Prettier 3.6+ with the
experimental CLI enabled) with the error:
```bash
Incompatible options: "write" and "list-different" cannot be used together
```
## Expected Behavior
`nx format:write` works seamlessly across all Prettier versions (2.x,
3.x, and 4.x).
## Related Issue(s)
Fixes#33658Fixes#31951
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Root Maven and Gradle build files (pom.xml, build.gradle.kts,
settings.gradle.kts) are not explicitly assigned to the Java reviewers
in CODEOWNERS.
## Expected Behavior
With this PR, the Java reviewers (@FrozenPandaz @MaxKless @lourw) will
be automatically added as reviewers when changes are made to:
- `/pom.xml` - Root Maven build file
- `/build.gradle.kts` - Root Gradle build file
- `/settings.gradle.kts` - Gradle settings file
This ensures the Java team has visibility into changes affecting the
root Java build configuration.
## Related Issue(s)
N/A - Maintenance improvement to CODEOWNERS
## Current Behavior
The `/ci/recipes/enterprise/on-premise/auth-single-admin` and
`/ci/recipes/on-premise/auth-single-admin` paths redirect to
`https://github.com/nrwl/nx-cloud-helm`, but the documentation that
should exist at these paths no longer has a target location.
## Expected Behavior
These redirect rules are removed so the broken links don't mislead users
with incorrect redirects.
## Related Issue(s)
Fixes CLOUD-4007
#### Current Behavior
When creating a new Nx workspace with Angular v20 and selecting Vitest
as the unit test runner, the installation fails with an npm peer
dependency conflict:
```bash
npm error ERESOLVE could not resolve
npm error peerOptional vitest@"^3.1.1" from @angular/build@20.3.13
npm error Found: vitest@4.0.15
```
## Expected Behavior
Workspace creation completes successfully when selecting Angular with
Vitest as the unit test runner.
## Related Issue(s)
Fixes#33770
## Current Behavior
The publish workflow was installing `aarch64-apple-darwin` Rust target
but attempting to build for `x86_64-apple-darwin`, causing the build to
fail with:
```
error[E0463]: can't find crate for `core`
= note: the `x86_64-apple-darwin` target may not be installed
= help: consider downloading the target with `rustup target add x86_64-apple-darwin`
```
## Expected Behavior
The workflow should install the correct Rust target
(`x86_64-apple-darwin`) before attempting to build for it.
## Related Issue(s)
N/A - Bug found during publish workflow debugging
## Current Behavior
When running `nx g @nx/angular:cypress-component-configuration` on an
Angular project that uses esbuild (the default bundler since Angular
17), users receive a confusing error message:
```bash
Unable to find a valid build configuration. Try passing in a target for an Angular app.
```
This doesn't explain why the configuration fails or what the actual
limitation is.
## Expected Behavior
Users now receive a clear, informative error message that explains:
- Cypress Component Testing for Angular requires a webpack-based build
target
- Their project uses an esbuild-based executor (and which one)
- Cypress only supports webpack as the bundler for Angular component
testing
This helps users understand the limitation and make informed decisions
about how to proceed.
## Related Issue(s)
Fixes#33329
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The `//` comment in the styled template [is not valid
css](https://stackoverflow.com/questions/12298890/is-it-bad-practice-to-prefix-single-lines-of-css-with-as-a-personal-comment-s/20192639#20192639)
and is causing [stylelint](https://stylelint.io/) to throw errors upon
creating new apps
## Expected Behavior
It should be valid css
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/issues/33579
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
When running `nx serve` with a NestJS project (and other node apps using
`runBuildTargetDependencies`), the node executor attempts to resolve the
`nx` binary using `require.resolve('nx')`. This fails with because
`nx/package.json` does no longer has a `main` field.
## Expected Behavior
The node executor should correctly resolve and use the `nx` binary from
the workspace where it's always installed.
This is fixed by using `nx/bin/nx.js` instead of just `nx` -- as we do
in other places.
## Related Issue(s)
Fixes#33776
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
<!-- This is the behavior we have today -->
When a workspace library has a `name` field set in its `nx`
configuration (e.g., `"nx": { "name": "buildable" }`), the
`@nx/js:prune-lockfile` executor fails to include transitive
dependencies from that library in the pruned lockfile.
The issue occurs because `addNodesAndDependencies` attempts to retrieve
workspace nodes using `graph.nodes[name]` where `name` is the package
name from `package.json`, but `graph.nodes` is keyed by the project name
(from `nx.name`). When these differ, the lookup fails and transitive
dependencies are not traversed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/js:prune-lockfile` executor should include all transitive
dependencies from workspace libraries regardless of whether the library
has a `name` field set in its `nx` configuration.
The fix uses the workspace node from the `workspacePackages` map (which
is keyed by package name) instead of attempting to look it up in
`graph.nodes` (which is keyed by project name).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33582
## Current Behavior
When terminating a task using the `@nx/js:swc` executor before it ever
got to execute its post-compilation logic, a `TypeError: disposeFn is
not a function` error is thrown.
## Expected Behavior
Terminating a task using the `@nx/js:swc` executor should not error.
## Related Issue(s)
Fixes#31938
## Current Behavior
The `update-21-2-0/update-module-resolution migration` doesn't process
any tsconfig files of non-buildable libraries.
## Expected Behavior
The `update-21-2-0/update-module-resolution migration` should process
common/known tsconfig files of non-buildable libraries.
## Related Issue(s)
Fixes#33705
Currently, when SWC compilation fails, Nx logs only a generic message:
"SWC compilation failed"
There is no `error.message`, no `stderr` and no `stdout` printed.
In many cases the actual cause of failure is completely hidden, which
makes debugging very difficult, especially in CI.
This PR improves the logging by printing:
- error.message (or the error itself)
- stderr if available
- stdout if available
This makes SWC failures visible and debuggable again.
## Current Behavior
Only a generic "SWC compilation failed" message is logged. No error
message or stdout are shown.
## Expected Behavior
Include error.message, stderr, and stdout (when available) so developers
can understand and debug failures.
We're missing messages and variant when errors happen during CNW. This
will help us track down potential problems.
We also want to know when CNW is cancelled in order to know that we're
not missing any events.
Description update for @berenddeboer/nx-aws-cdk plugin: this has become
self-inferring.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
The `getModuleFederationConfig` function is implemented separately in 4
places with 70-80% duplicate code:
- `with-module-federation/webpack/utils.ts` (161 lines)
- `with-module-federation/rspack/utils.ts` (150 lines)
- `with-module-federation/angular/utils.ts` - async version (~80 lines)
- `with-module-federation/angular/utils.ts` - sync version (~80 lines)
Each implementation repeats the same core logic:
1. Get project from graph
2. Get and filter dependencies
3. Share workspace libraries and npm packages
4. Apply eager packages
5. Map remotes
## Expected Behavior
A single shared implementation with framework-specific configuration via
a `FrameworkConfig` interface. Each bundler utility becomes a thin
wrapper that provides its specific configuration.
### Changes
| File | Before | After | Change |
|------|--------|-------|--------|
| `webpack/utils.ts` | 161 lines | 54 lines | -107 lines |
| `rspack/utils.ts` | 150 lines | 51 lines | -99 lines |
| `angular/utils.ts` | 273 lines | 119 lines | -154 lines |
| **NEW** `module-federation-config.ts` | - | 289 lines | +289 lines |
**Net reduction**: 41 lines, with significantly improved maintainability
### New Shared Utility
Created
`packages/module-federation/src/utils/module-federation-config.ts` with:
- `FrameworkConfig` interface for bundler-specific customization
- `ModuleFederationConfigResult` interface for type-safe return values
- `getModuleFederationConfigAsync()` - for webpack/angular async configs
- `getModuleFederationConfigSync()` - for rspack/angular sync configs
- `createDefaultRemoteUrlResolver()` - shared remote URL generation
- Caching for `NX_MF_DEV_SERVER_STATIC_REMOTES` env variable parsing
(performance)
### Benefits
1. **Single source of truth**: Bug fixes and improvements only need to
be made once
2. **Better maintainability**: Framework-specific behavior is clearly
separated via config
3. **Performance**: Added caching for env variable parsing
4. **Type safety**: New interfaces provide better IntelliSense and
compile-time checks
5. **Backward compatible**: All existing exports and behavior preserved
## Related Issue(s)
N/A - This is a refactoring for improved code maintainability and
performance.
## Merge Dependencies
**Must be merged AFTER:** #33734
---
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
With the new tsgo `baseUrl` has been completely removed, this breaks
compilation of plugins using swc when calling them with nx due to swc
needing the baseUrl. I patched my company workspace with this fix and it
did resolve it, not sure if its the right fix or what the ramifications
are so happy to discuss that more. Since `baseUrl` is removed in tsgo
(and recommended against in general), we need to find a way to provide
it to swc (potentially through an `.swcrc` alternatively, I tried adding
that to my workspace though and it didn't do anything).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Expo CLI 54.0.12+ changed how originModulePath is determined in Metro
resolvers - from workspace root to project root. This caused the Nx
custom resolver to double-path modules when resolving workspace
libraries.
This fix:
- Adds projectRoot: workspaceRoot to the Metro config to ensure
originModulePath remains workspace-relative
- Adds defensive path normalization in pnpmResolver to handle edge cases
Fixes#33597
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Self-healing docs only reference being supported for GitHub.
<!-- This is the behavior we have today -->
## Expected Behavior
We should show instructions for all currently supported vcs providers,
including GitLab and Azure Devops.
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Replace process.exit(1) calls with typed CnwError exceptions for
structured error reporting and telemetry tracking. Update recordStat
meta to use typed JSON objects with named keys instead of arrays.
Examples of what's sent as `meta`.
```
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-remote-cache-visit","nxCloudArg":"skip","nxCloudArgRaw":"","pushedToVcs":"SkippedGit","template":"nrwl/empty-template"}
{"type":"start","flowVariant":"1"}
{"type":"start","flowVariant":"0"}
{"type":"complete","flowVariant":"0","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"enable-caching2","nxCloudArg":"skip","nxCloudArgRaw":"","pushedToVcs":"SkippedGit","template":"custom"}
{"type":"start","flowVariant":"1"}
{"type":"error","errorCode":"DIRECTORY_EXISTS"}
{"type":"start","flowVariant":"1"}
{"type":"error","errorCode":"DIRECTORY_EXISTS"}
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-green-prs-visit","nxCloudArg":"yes","nxCloudArgRaw":"","pushedToVcs":"FailedToPushToVcs","template":"nrwl/empty-template"}
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-fast-ci-visit","nxCloudArg":"yes","nxCloudArgRaw":"","pushedToVcs":"FailedToPushToVcs","template":"nrwl/empty-template"}
{"type":"start","flowVariant":"1"}
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-green-prs-visit","nxCloudArg":"skip","nxCloudArgRaw":"","pushedToVcs":"SkippedGit","template":"nrwl/typescript-template"}
{"type":"start","flowVariant":"1"}
{"type":"error","errorCode":"WORKSPACE_CREATION_FAILED"}
```
Known errors like "directory exists" does not print stack trace:
<img width="1061" height="362" alt="image"
src="https://github.com/user-attachments/assets/8f29f303-3839-4297-b789-d23ac3af6d52"
/>
Another known error (invalid custom preset):
<img width="1091" height="391" alt="image"
src="https://github.com/user-attachments/assets/c7f6e586-42a8-493b-b595-f7d77743683f"
/>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When using Nx React Module Federation with Rspack, running `nx run-many
-t e2e` before `nx run-many -t typecheck`, it causes typecheck to fail.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx run-many -t typecheck` should succeed regardless of whether Rspack
(via `nx preview`) was executed before it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/33445
The CopyAssetsHandler was logging every copied file to the console,
causing noisy output when a project copies many files. This could
cause build errors to be cut off in terminals with scroll limits.
Change logger.log() to logger.verbose() so per-file logging only
appears when --verbose is passed or NX_VERBOSE_LOGGING=true.
Fixes#33521
The release-publish executor was only displaying npm-style errors
(error.summary
and error.detail), but pnpm returns errors with a different format
(error.code
and error.message). This caused pnpm publish errors to be invisible
unless users
passed the --verbose flag.
This fix adds handling for pnpm's error format so that error messages
are
properly displayed to users without requiring --verbose.
Fixes 33537
Adds a 'compiler' option to the @nx/js/typescript plugin configuration,
with options 'tsc' and 'tsgo'. Affects both typecheck and build targets.
## Current Behavior
The `@nx/js/typescript` plugin always uses `tsc` as the compiler, with
no way to use the native `tsgo` preview.
## Expected Behavior
The `@nx/js/typescript` plugin can be configured to use `tsgo` for
building and typechecking.
## Related Issue(s)
Related discussion #32591.
This pull request introduces a new option to the Nx Webpack plugin that
allows users to control whether the plugin should merge its external
dependencies configuration with any existing Webpack externals
configuration. This provides greater flexibility when customizing how
external dependencies are handled during the build process.
Configuration enhancements:
* Added a new `mergeExternals` boolean option to the
`NxAppWebpackPluginOptions` interface, allowing users to specify whether
to combine the plugin's externals configuration with the existing
Webpack config.
* Updated the logic in `apply-base-config.ts` so that the `externals`
array is set based on the new `mergeExternals` option, defaulting to not
merging unless specified.
---------
Co-authored-by: David Antoon <davidmantoon@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Currently the template flow will only set up `npm`, even if you run
`yarn create` or `pnpx create-nx-workspace`. This PR adds support back
for other package managers.
## Current Behavior
When we prepare ENVs for the DefinePlugin, we are creating the
`process.env` object.
For example:
```
// .env
NX_PUBLIC_VALUE1=1
NX_PUBLIC_VALUE2=2
NX_PUBLIC_VALUE3=3
```
As result we will have:
```js
{
'process.env': {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}
}
```
As a result, in the final bundle, we will replace process.env with this
object.
The issue:
If I use all 3 values in my application DefinePlugin will inject this
object 3 times, instead of injecting it once.
It will look like that:
```js
const a = {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}.NX_PUBLIC_VALUE1
const b = {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}.NX_PUBLIC_VALUE2
const c = {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}.NX_PUBLIC_VALUE3
```
## Expected Behavior
DefinePlugin injects values instead of env object in each place
```js
const a = "1"
const b = "2"
const c = "3"
```
## Fixes
- fixed this issue for webpack
- fixed this issue for storybook
- fixed this issue for rspack
TLDR:
now we have object like so:
```js
{
"process.env.NX_PUBLIC_VALUE1": "1",
"process.env.NX_PUBLIC_VALUE2": "2",
"process.env.NX_PUBLIC_VALUE3": "3"
}
```
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
NodeNext is not recognized as ESM. This causes this warning message to
be logged, even when you have `"type": "module",` in the `package.json`
file and are compile TypeScript to `"module": "NodeNext"`.
```
Package type is set to "module" but "cjs" format is included. Going to use "esm" format instead. You can change the package type to "commonjs" or remove type in the package.json file.
```
## Expected Behavior
Don't log this message. It is incorrect.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
This pull request refactors the `dependsOn` configuration for Jest
targets in the Nx plugin to improve flexibility and maintainability. The
changes replace string-based dependencies with structured objects,
ensuring better alignment with Nx's target configuration standards.
This PR updates the `dependsOn` configuration for Jest `ciTarget` to
ensure that top-level args are passed on if the parent target has a
dependsOn for other targets.
For example if i pass `nx run-many e2e-ci -- --json
--outputFile=my-test-results.json` the options:
- `--json`
- `--outputFile`
Should be forwarded to the dependent targets.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
The check should be for `GITHUB_ACTIONS` since that is the intention.
The token may not be set due to Trusted Publisher flow.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
…new convention
## Current Behavior
Currently, the @nx/vite plugin generates a `vite.config.ts` file where
the worker configuration is commented out, but uses the old format:
```ts
// worker: {
// plugins: [ nxViteTsPaths() ],
// }
```
If uncomment, this format triggers a warning from Vite, as the worker
configuration should now be a function that returns an array of plugins.
While Vite automatically converts the old format for compatibility, it
is not ideal to rely on this behavior.
## Expected Behavior
With the changes in this PR, the @nx/vite plugin will generate a Vite
configuration where the worker configuration follows the new convention,
avoiding warnings and ensuring compatibility with future versions of
Vite. The updated configuration will look like this:
```ts
// worker: {
// plugins: () => [ nxViteTsPaths() ],
// }
```
This change ensures that the generated configuration aligns with Vite's
recommended practices and eliminates unnecessary warnings.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
The NxAppWebpackPlugin option 'verbose' should show chunk output during
webpack build when true, and hide them when false. It's currently the
reverse, causing a lot of console spam during dev, and the hiding the
info during ci/cd.
## Current Behavior
Setting the NxAppWebpackPlugin option 'verbose' to false shows chunk
output.
<img width="848" alt="chunky"
src="https://github.com/user-attachments/assets/4cd5502d-d059-4ace-9e42-28eb160bc1d0"
/>
## Expected Behavior
Setting the NxAppWebpackPlugin option 'verbose' to false hides chunk
output.
Resolve issue when
projectRoot was created from
join workspaceRoot and projectNode.data.root
but method createTmpTsConfig also make join
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
```
method withNx create
const projectRoot = join(workspaceRoot, projectNode.data.root);
```
method createTmpTsConfig
apply also join
```
const tmpTsConfigPath = join(
workspaceRoot,
'tmp',
projectRoot,
process.env.NX_TASK_TARGET_TARGET ?? 'build',
`tsconfig.generated.${randomUUID()}.json`
);
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31522
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
No option to manage opening html report after run.
## Expected Behavior
Added option to manage opening html report after run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
The nightly-2025-12-10 Rust version removed `mtim()` from the WASI
`MetadataExt` trait, causing the WASM build to fail with:
```
error[E0599]: no method named `mtim` found for reference `&std::fs::Metadata` in the current scope
```
## Expected Behavior
WASM builds should compile successfully.
## Solution
Revert to `nightly-2025-05-09` which still has the `mtim()` API
available in the WASI `MetadataExt` trait.
## Current Behavior
The `build:wasm` script uses `rustup override set nightly-2025-12-10` to
set the Rust toolchain. However, when mise is configured to manage Rust
(e.g., `rust = "1.90.0"` in `mise.toml`), it sets the `RUSTUP_TOOLCHAIN`
environment variable which has higher precedence than directory
overrides.
This causes the WASM build to fail with:
```
error[E0554]: `#![feature]` may not be used on the stable release channel
```
## Expected Behavior
WASM builds should use nightly Rust regardless of mise configuration.
## Solution
Set `RUSTUP_TOOLCHAIN=nightly-2025-12-10` directly in the script, which
overrides any existing env var from mise or other sources.
## Current Behavior
The Nx Console settings reference lacks explanation of VSCode's user vs
workspace settings and incorrectly states that Project Viewing Style is
unavailable in JetBrains IDEs.
## Expected Behavior
Nx consoles are documented for vscode/jetbrains editors
https://deploy-preview-33363--nx-docs.netlify.app/docs/reference/nx-console-settings
fixes: DOC-315
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
After the mise migration (#33772), the `publish.yml` workflow fails
during the "Build Wasm" step with:
```
error[E0554]: `#![feature]` may not be used on the stable release channel
--> packages/nx/src/lib.rs:2:33
|
2 | #![cfg_attr(target_os = "wasi", feature(wasi_ext))]
```
The WASM build requires nightly Rust because it uses the unstable
`wasi_ext` feature. The `build:wasm` script attempts to switch to
nightly via `rustup override set`, but after the mise migration, the
nightly toolchain is no longer pre-installed, causing the build to fail
with the stable compiler.
## Expected Behavior
The WASM build should successfully compile using nightly Rust with the
`wasi_ext` feature.
## Related Issue(s)
Fixes the publish workflow regression introduced in #33772
| | Before | After |
| ---- | ----- | ---- |
| Total createNodes | 812 | 104 |
| Total matchPropValue | 672 | 2 |
## Current Behavior
The `createNode` function is slow for pnpm due to suboptimal
`matchPropValue` function.
## Expected Behavior
The `createNode` function should be fast and not slowdown the graph
creation.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When some tasks fail during execution, it can result in a cryptic:
```bash
Failed to convert JavaScript value 'Undefined' into rust type 'String'
```
This happens because the reported `terminalOutput` for the errored tasks
can be `undefined`, and it hides the actual error that occurred.
## Expected Behavior
Error handling paths should always provide a valid string for
`terminalOutput`, using the error stack/message, or an empty string as a
fallback.
## Related Issue(s)
Fixes#32675
## Current Behavior
The inline `mise_toml` config in `e2e-matrix.yml` was overwriting the
entire `mise.toml` file, causing rust, dotnet, bun, and java to NOT be
installed by mise. This resulted in slow package installs as these tools
were downloaded during `pnpm install` instead.
## Expected Behavior
All tools from `mise.toml` (rust, dotnet, bun, java) should be installed
by mise, with only the node version varying based on the matrix.
## Solution
Use mise's template syntax to make node version configurable via
`NODE_VERSION` env var while preserving all other tools from
`mise.toml`:
```toml
node = "{{ env['NODE_VERSION'] | default(value='24') }}"
```
Then in the workflow, set the env var instead of overriding the entire
config:
```yaml
- name: Setup dev tools with mise
uses: jdx/mise-action@v3
env:
NODE_VERSION: ${{ matrix.node_version }}
```
## Related Issue(s)
Fixes slow install times in nightly e2e-matrix workflow after #33772.
## Current Behavior
The mise vfox-dotnet plugin fails on Windows with:
```
mise ERROR Failed to install vfox:mise-plugins/vfox-dotnet@9:
0: error converting Lua table to PreInstall (no version returned from vfox plugin)
```
This prevents dotnet from being installed via mise on Windows CI
runners.
## Expected Behavior
Dotnet should install successfully on all platforms including Windows.
## Related Issue(s)
Related upstream issue: https://github.com/jdx/mise/discussions/4738
## Solution
1. **mise.toml** - Made dotnet installation conditional on Linux/macOS
only using the `os` option
2. **.github/workflows/publish.yml** - Added `winget install` to install
.NET SDK 9 on Windows CI runners
This approach works around the buggy vfox plugin by using the native
Windows package manager instead.
## Current Behavior
When building Angular libraries with `ng-packagr` >20.3.0, the build
fails with:
```bash
TypeError: Cannot read properties of undefined (reading 'outputCache')
```
This occurs because `ng-packagr` v20.3.1 introduced a memory
optimization
([ng-packagr#3172](https://github.com/ng-packagr/ng-packagr/pull/3172))
that calls `dispose()` on entry points after they're processed, setting
`entry.cache = undefined`.
Nx's custom `writeBundlesTransform` was iterating over **all** entries
in the graph, including already-disposed entry points, causing the crash
when accessing their cache.
## Expected Behavior
Angular library builds should succeed with `ng-packagr` >20.3.0,
including libraries with secondary entry points. Workspaces using lower
versions of `ng-packagr` should remain unaffected.
## Solution
Align with `ng-packagr`'s own pattern by using
`graph.find(isEntryPointInProgress())` to process only the currently
in-progress entry point, rather than iterating over all graph entries.
**Key changes:**
- Use `isEntryPointInProgress()` instead of iterating all entries with
`isEntryPoint()`
- Remove unused `BuildGraph` import (no longer creating a new graph)
- Update package node only when processing the primary entry point (more
efficient)
- Return nothing from the transform (original graph passes through, same
as ng-packagr)
This approach:
- Matches `ng-packagr`'s `writeBundlesTransform` implementation pattern
- Only accesses cache of the in-progress entry point (guaranteed not to
be disposed)
- Works with all supported `ng-packagr` versions (v19+) since
`isEntryPointInProgress()` has been available since v19
## Related Issue(s)
Fixes#33560
This PR fixes an issue with CNW where the initial `recordStat` call is
not working due to a logic error on passing `directory` that isn't
initialized yet.
## Current Behavior
If there are issues with values passed to generators via prompt, we
still see a green output and exit code 0.
A colleague found out about this by pressing `Ctrl+C` when being
prompted for parameters for a generator, and this led to the CLI simply
continuing execution and showing no issue.
## Expected Behavior
CLI fails.
Allows setting a default output style instead of having to include it on
every command
Closes#27490
## Current Behavior
We must specify --outputStyle on every command
## Expected Behavior
Should allow overriding the default with an environment variable
## Related Issue(s)
#27490Fixes#27490
When 8+ dependent tasks exist, each adds an `exit` listener to track
completion. This listener attaches to `process`. So we apply the same
fix that worked for `stdout` and `stderr`, and was merged through [PR
16693](https://github.com/nrwl/nx/pull/16993)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
For `nx` targets with 8+ dependent targets, we encounter
`maxListenersExceededWarning`:
```
(node: 22553) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit.
(node: 22553) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit.
(node: 22553) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGHUP listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit.
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
No `MaxListenersExceededWarning` should be thrown on account of the nx
run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32439
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
In `filterAffectedProjects`, a **new visited Set is created for each
touched project**:
```typescript
ctx.touchedProjects.forEach((p) => {
addAffectedNodes(p, reversed, result, new Set()); // NEW Set per project!
});
ctx.touchedProjects.forEach((p) => {
addAffectedDependencies(p, reversed, result, new Set()); // NEW Set per project!
});
```
This defeats the purpose of the visited Set for deduplication. If
projects A and B both depend on shared project C, then C gets visited
**twice**.
## Expected Behavior
Share a single visited Set across all touched projects:
```typescript
const visitedNodes = new Set<string>();
const visitedDeps = new Set<string>();
for (const p of ctx.touchedProjects) {
addAffectedNodes(p, reversed, result, visitedNodes); // SHARED Set
}
for (const p of ctx.touchedProjects) {
addAffectedDependencies(p, reversed, result, visitedDeps); // SHARED Set
}
```
## Performance Impact
```
Before (separate Sets): After (shared Sets):
┌─────────────────────────┐ ┌─────────────────────────┐
│ touchedProjects: [A,B] │ │ touchedProjects: [A,B] │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
┌───────┴───────┐ ┌───────┴───────┐
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ A │ │ B │ │ A │ │ B │
│visited│ │visited│ │ │ │ │
│= {} │ │= {} │ │ shared visitedNodes │
└───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘
│ │ │ │
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────────────────────┐
│visit C│ │visit C│ │ visit C (ONCE) │
│(dup!) │ │(dup!) │ │ skip C from B │
└───────┘ └───────┘ └───────────────────────┘
Complexity: Complexity:
O(touched × shared_deps) O(total_nodes)
```
**Example**: With 50 touched projects sharing 100 common dependencies:
- Before: 50 × 100 = 5,000 node visits
- After: ~150 node visits (each node visited once)
## Why Accept This PR
1. **Bug-like behavior**: The current code defeats the purpose of the
visited Set
2. **Significant impact**: Affects every `nx affected` command
3. **Zero risk**: Same traversal logic, just shared deduplication
4. **Common scenario**: Monorepos often have shared dependencies (utils,
types, etc.)
## Related Issue(s)
Contributes to #32265
## Merge Dependencies
This PR has no dependencies and can be merged independently.
---
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: khalilou88 <32600911+khalilou88@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Summary
Migrates GitHub workflows to use [mise](https://mise.jdx.dev/) for
managing development tool installations instead of individual setup
actions.
## Changes
- **mise.toml**: Added pnpm@10.11.1 to tool configuration
- **ci.yml**: Replaced pnpm, node, rust, and java setup actions with
`mise-action@v3` in both Linux and macOS jobs
- **e2e-matrix.yml**: Replaced all tool setup actions with mise-action
in preinstall and e2e jobs
- **publish.yml**: Replaced tool setup actions with mise-action in build
and publish jobs
- **codeql workflows**: Updated to use `mise-action@v3`
## Benefits
- **Single source of truth**: All tool versions defined in `mise.toml`
- **Faster CI setup**: Mise provides better caching than individual
actions
- **Consistency**: Same tool versions across local dev and CI
- **Easier maintenance**: Update versions in one place
## Test Plan
- [ ] CI workflow passes on Linux
- [ ] CI workflow passes on macOS
- [ ] E2E matrix builds successfully
- [ ] Publish workflow can run (test with dry-run if possible)
- [ ] CodeQL scans complete successfully
Fixes #ISSUE_NUMBER
## Current Behavior
We do not have a guide showing how to use Vitest with custom conditions
## Expected Behavior
Add a guide showing how to use Vitest with custom conditions
The Plugin Registry page in astro-docs displays a static grid of plugins
without any search or filtering capabilities, making it hard to find
specific plugins.
Users can search plugins by name or description, and sort by release
date, npm downloads, GitHub stars, or Nx version compatibility.
<img width="975" height="1059" alt="image"
src="https://github.com/user-attachments/assets/a08e2a12-697e-4e3b-b9c0-2983d50fdad8"
/>
Closes DOC-343
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
The fileURLToPath and dirname imports are only used in the
getAbsolutePath function, which is only generated for non-Angular
Storybook projects.
## Expected Behavior
This change prevents unnecessary imports from being added to Angular
Storybook configurations.
## Current Behavior
When using pnpm with workspace protocol (`workspace:*`, `workspace:^`,
etc.), module federation sets `requiredVersion` to the raw protocol
string (e.g., `workspace:*`) instead of resolving it to the actual
semver version from the library's package.json.
This causes issues like:
- `requiredVersion: "workspace:*"` which is not a valid semver
- Module federation failing to properly share workspace libraries
- Warnings about unable to find required versions
Example of the broken output:
```json
{
"version": "*",
"singleton": true,
"requiredVersion": "^*"
}
```
## Expected Behavior
When a workspace protocol version is detected, it should be resolved to
the actual version from the library's package.json:
```json
{
"version": "2.0.0",
"singleton": true,
"requiredVersion": "2.0.0"
}
```
## Changes Made
1. **Added helper functions** in `share.ts`:
- `isWorkspaceProtocolVersion()` - Detects workspace protocol versions
(`workspace:*`, `workspace:^`, `*`, `file:`)
- `normalizeWorkspaceProtocolVersion()` - Resolves protocol versions to
actual semver by looking up the library's package.json
2. **Applied normalization in `shareWorkspaceLibraries()`**:
- After getting version from `getDependencyVersionFromPackageJson`,
normalize it if it's a workspace protocol
- Simplified the `workspaceLibrariesAsDeps` loop by using the helper
function (removed duplicated logic)
3. **Updated `getNpmPackageSharedConfig()`**:
- Added a check to warn and return undefined when workspace protocol
versions are passed
- Helps users understand that workspace libraries should be configured
properly
4. **Added comprehensive tests** (13 new tests):
- 6 tests for workspace protocol version normalization in
`shareWorkspaceLibraries`
- 7 tests for `getNpmPackageSharedConfig` handling workspace protocol
versions
## Related Issue(s)
Fixes#31397
## Merge Dependencies
This PR has no dependencies and can be merged independently.
**Must be merged BEFORE:** #33734
---
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We would add the gradle project graph plugin to your build.gradle files
if we did not already detect it. However, this did mechanism did not
recognize aliases for the project graph plugin that came from version
catalogs.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When adding the project graph plugin to build.gradle.kts, we check if a
version catalogue exists, and if it does we add the alias for the
project graph plugin.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
The `hasPath` function in `graph.ts` uses an array with `indexOf()` for
tracking visited nodes during recursive graph traversal:
```typescript
function hasPath(graph, target, node, visited: string[]) {
for (let d of graph.dependencies[node] || []) {
if (visited.indexOf(d.target) > -1) continue; // O(n) lookup
visited.push(d.target);
// recursive call...
}
}
```
This results in O(n) lookups per node visited, making worst-case
traversal O(n²).
## Expected Behavior
Use `Set` for O(1) visited node tracking:
```typescript
function hasPath(graph, target, node, visited: Set<string>) {
for (const d of graph.dependencies[node] || []) {
if (visited.has(d.target)) continue; // O(1) lookup
visited.add(d.target);
// recursive call...
}
}
```
## Performance Impact
```
Before (Array + indexOf): After (Set + has):
┌─────────────────────────┐ ┌─────────────────────────┐
│ hasPath() called │ │ hasPath() called │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐
│ visited.indexOf(target) │ │ visited.has(target) │
│ O(n) lookup │ │ O(1) lookup │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐
│ visited.push(target) │ │ visited.add(target) │
│ O(1) │ │ O(1) │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
▼ ▼
Complexity: O(n²) Complexity: O(n)
for full traversal for full traversal
```
**Example with 500 nodes:**
- Before: 500 nodes × avg 250 indexOf lookups = ~125,000 comparisons
- After: 500 nodes × 1 Set lookup each = 500 operations
## Why Accept This PR
1. **Zero risk**: Same semantics, just faster data structure
2. **Standard pattern**: Set is the idiomatic choice for visited
tracking in graph algorithms
3. **Measurable impact**: Graph filtering with `--focus` flag will be
significantly faster on large monorepos
## Related Issue(s)
Contributes to #32265
## Merge Dependencies
This PR has no dependencies and can be merged independently.
---
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Correcting docs to mention that resource collection on Nx Cloud will be
availabe from 22.2 onwards.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When using `nx release version --preid=alpha`, the version determination
now correctly considers both prerelease tags AND stable release tags to
determine the "latest" version. Previously, it would only look at
prerelease tags matching the preid, ignoring stable releases that should
have become the new baseline.
For example, with tags: 1.1.0, 1.1.0-alpha.0, 1.1.0-alpha.1, 1.1.1
- Before: Would return 1.1.0-alpha.1 → bump to 1.1.0-alpha.2
- After: Returns 1.1.1 (stable >= preid base) → bump to 1.1.2-alpha.0
Fixes#33343
## Current Behavior
The Maven plugin version is currently at 0.0.10 across all pom.xml files
in the repository.
## Expected Behavior
With this PR, the Maven plugin version will be updated to 0.0.11. This
includes:
- Updating the version in the root pom.xml
- Updating the version in packages/maven/maven-plugin/pom.xml
- Updating the mavenPluginVersion constant in
packages/maven/src/utils/versions.ts
- Adding a migration script to automatically update user pom.xml files
from 0.0.10 to 0.0.11
## Related Issue(s)
N/A - Version bump for the Maven plugin
Webpack e2e tests occasionally hang in CI without clear indication of
where the test gets stuck.
Debug logs will help identify which step the test hangs at, making it
easier to diagnose and fix the root cause.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Current gradle plugin version is at 0.1.9
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Take gradle plugin to 0.1.10
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Pressing Cmd+K (or Ctrl+K) on non-docs pages does nothing. The Pagefind
search is only accessible when already on the documentation pages.
Pressing Cmd+K on any non-docs page redirects to the docs and
automatically opens the search modal with focus on the input field.
https://www.loom.com/share/72fcee74620640cab28639e9ad33d962
Closes DOC-314
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The `tools/update-repos/config/repos.json` configuration has the ocean
repository set to use `npm` as its package manager.
## Expected Behavior
The ocean repository should be configured to use `pnpm` as its package
manager, reflecting the actual package manager used by the repository.
## Related Issue(s)
N/A - Configuration update to reflect actual repository state.
This PR adds `SIGINT` handling when user kills the process via `Ctrl+C`
during CNW. This only prints when the workspace setup is complete, and
we also print the Cloud onboarding URL if it has been set up.
Also fixes an issue where `selectedRepositoryName` is never sent during
CNW.
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
you can mark some targets generated by gradle by specifying options.
## Expected Behavior
you can apply a prefix to all targets generated by gradle. This is
useful for targetDefaults, for example.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds a Gradle option to prefix all generated Nx target names
(including dependencies and CI targets) with tests to avoid
double-prefixing.
>
> - **Gradle project graph**:
> - Apply optional `targetNamePrefix` to all target names and dependency
rewrites in `createNodeForProject`, `processTargetsForProject`, and
`getDependsOnForTask`.
> - Wire prefix through plugin/task: read in
`NxProjectGraphReportPlugin`, expose on `NxProjectReportTask`, and pass
to processing functions.
> - Ensure CI targets (`ciTestTargetName`, `check-ci`, `build-ci`) are
correctly prefixed and not double-prefixed; update dependency
replacement logic accordingly.
> - Add logging for prefix usage.
> - **Plugin options (TS)**:
> - Extend `GradlePluginOptions` with `targetNamePrefix` in
`packages/gradle/src/plugin/utils/gradle-plugin-options.ts`.
> - **E2E tests**:
> - Add tests validating prefixed targets exist and run, and that CI
test targets are not double-prefixed in `e2e/gradle/src/gradle.test.ts`.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
9a5160b8855a32d6c13c33c97379e7aa143a0737. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Key optimisations:
1. Pre-computed PackageIndex - Built once during lockfile parsing:
- byName: Map from package name → array of versions (O(1) lookup)
- workspaceNames: Set of workspace package names (O(1) lookup)
- workspacePaths: Set of workspace paths (O(1) lookup)
- packagesWithWorkspaceVariants: Set of packages with workspace-specific
variants (O(1) lookup)
- patchedPackages: Set of patched package names (O(1) lookup)
2. findResolvedVersion: Changed from O(n) scan through all packages to
O(1) map lookup + O(k) where k = number of versions for that package
(typically 1-3)
3. isWorkspacePackage: Changed from O(n) scan to O(1) set lookup
4. hasWorkspaceSpecificVariant: Changed from O(n) scan to O(1) set
lookup
5. isNestedPackageKey: Now uses pre-computed workspace paths/names sets
instead of computing them each call
On my 40 project typescript monorepo my time goes from about 30 seconds
to 4.5s, a speed-up of 6-7x.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
This PR simplifies the CNW process so we only prompt for a starter (TS,
NPM Packages, React, Angular) and we clone a full example to showcase Nx
monorepo for the given starter. This speeds up CNW drastically and
allows users to get the workspace in 5-10 seconds vs 1-3 minutes.
Users can choose `Custom` to fall back to the previous prompts, which
will ask framework, unit test runner, e2e runner, etc.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Gradle multi-module projects have project names with colons (e.g.,
`:common:iam-client`)
which are invalid in git tag names. This adds a
`sanitizeProjectNameForGitTag()` function
that replaces colons with slashes and other invalid git ref characters
with hyphens.
The sanitization is applied when:
- Creating git tags in `createGitTagValues()`
- Creating the `ReleaseVersion` class gitTag property
- Matching existing tags in `getLatestGitTagForPattern()`
Fixes#33262
## Current Behavior
We only support Expo 53
## Expected Behavior
Add support for Expo 54
Allow existing workspaces wishing to remain on Expo 53 to continue to be
supported
Add migrations allowing LLMs to handle migrating from Expo 53 to Expo 54
## Related Issue(s)
Closes NXC-3526
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Rebuild logs during serve of Angular Rspack applications are logged an
exponential number of times with each change.
## Expected Behavior
Log only once
## Current Behavior
We currently install an outdated version of `@emotion/styled` that
causes Typecheck issues.
## Expected Behavior
Use latest version of Emotion
## Related Issue(s)
Fixes#31252
## Current Behavior
Angular Rspack outputs ESM for build and serve. However, with serve, it
causes issue for HMR.
## Expected Behavior
Use CJS for serve to allow HMR to work correctly
## Related Issue(s)
Fixes#33106
## Expected Behavior
Generate only `vitest.config.mts` file when not bundling with Vite
Use `vite.config` file if it exists already
Add `testMode` option to the `@nx/vitest` Inference Plugin to allow
easier switching between `vitest` and `vitest run`.
## Related Issue(s)
Fixes NXC-3334
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Removes legacy additions of `.cursor/rules/nx-rules.mdc` and
`.github/instructions/nx.instructions.md` to `.gitignore` across code,
templates, and migrations.
>
> - **.gitignore behavior**:
> - Remove logic in
`packages/nx/src/command-line/init/implementation/utils.ts` that
appended `.cursor/rules/nx-rules.mdc` and
`.github/instructions/nx.instructions.md`.
> - Clean up root `.gitignore` to exclude those entries.
> - Update new workspace templates
(`packages/workspace/.../__dot__gitignore`) to omit those entries.
> - **Migrations**:
> - Remove migration `21-1-0-add-ignore-entries-for-nx-rule-files` from
`packages/nx/migrations.json` and delete its implementation and spec.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
7863fa5beee127777f819a5155ae17239c5b16cd. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## Current Behavior
Trying to create a new workspace is failing on npm peer dep conflicts
when trying to use Vitest with Angular.
The version of `@analogjs/vitest-angular` only supports Vitest <4.
## Expected Behavior
Update to latest version of `@analogjs/vitest-angular` to support Vitest
4
## Related Issue(s)
Fixes#33602
## Current Behavior
`buildLibsFromSource` defaults to true only in the `@nx/rollup:rollup`
executor.
In the normalize options helper for the executor, it is not handled at
all. Programmatic usage would therefore result in `undefined`.
For pure Inference Plugin usage, `buildLibsFromSource` is also not
handled in normalize options.
Therefore, it always defaults to `undefined`.
## Expected Behavior
To reduce breaking changes, force `buildLibsFromSource` to be false for
Inference Plugin usage.
Explicitly set it in executor's normalize options helper to true to
match the schema default.
## Related Issue(s)
Fixes NXC-3537
# Fix: Pass releaseGroupName to getLatestGitTagForPattern for proper tag
resolution
## Problem
When using `releaseTag.pattern: "{releaseGroupName}@{version}"`, Nx
fails to resolve versions from git tags because the `{releaseGroupName}`
placeholder is not interpolated.
For example, with git tag `my-group@2.9.0`:
- **Expected**: Extract version `2.9.0`
- **Actual**: Extracts `"my-group"` → Error: `Invalid semver version
'my-group' provided`
## Root Cause
In `release-graph.ts:627-631`, only `projectName` is passed to
`getLatestGitTagForPattern()`, missing `releaseGroupName` needed for
interpolation.
## Solution
Pass `releaseGroupName` to the interpolation data (1-line change at
`release-graph.ts:631`):
```typescript
latestMatchingGitTag = await getLatestGitTagForPattern(
releaseTagPattern,
{
projectName: projectGraphNode.name,
releaseGroupName: releaseGroupNode.group.name, // ✅ Added
},
{ ... }
);
```
## Backward Compatibility
✅ Fully backward compatible:
- `releaseGroupNode.group.name` is always defined (user-defined or
`"__default__"`)
- Unused interpolation data is safely ignored
- Existing patterns (`v{version}`, `{projectName}@{version}`) continue
to work
## Tests
Added test case in `git.spec.ts` for `{releaseGroupName}@{version}`
pattern that verifies correct tag matching and version extraction.
## Files Changed
- `packages/nx/src/command-line/release/utils/release-graph.ts` (1 line)
- `packages/nx/src/command-line/release/utils/git.spec.ts` (1 test case)
Co-authored-by: James Henry <james@henry.sc>
## Current Behavior
The arboard crate is used without the `wayland-data-control` feature,
which means clipboard operations may not work properly on Wayland-based
Linux systems.
## Expected Behavior
With the `wayland-data-control` feature enabled, arboard can interact
with the clipboard on Wayland systems using the wlr-data-control
protocol.
## Related Issue(s)
N/A - Enhancement for better Wayland support
## Current Behavior
The Maven plugin incorrectly maps Maven's `isThreadSafe` mojo property
to Nx's `parallelism` target property. Maven's `isThreadSafe` indicates
whether a mojo can safely run in parallel with other mojos of the same
type within the same Maven build (multi-threaded Maven builds).
## Expected Behavior
Nx's `parallelism` controls whether the target can run in parallel
alongside anything else - a fundamentally different concept. All Maven
targets now default to `parallelism: true`, letting Nx handle
parallelism based on its own task graph analysis rather than using
Maven's unrelated thread-safety concept.
## Related Issue(s)
N/A - Internal cleanup based on code review feedback.
## Current Behavior
On Node.js v24+, the `@nx/jest/plugin` sets
`--no-experimental-strip-types` in NODE_OPTIONS which causes an error:
"node: --no-experimental-strip-types is not allowed in NODE_OPTIONS".
Additionally, `jest.config.ts` files using ESM syntax (`export default`,
`import`) fail to load correctly under Node.js type-stripping when the
project is configured for CommonJS.
## Expected Behavior
- Remove the NODE_OPTIONS manipulation that adds
`--no-experimental-strip-types`
- Add a migration (22.2.0-beta.2) that converts `jest.config.ts` files
from ESM to CJS syntax for projects using `@nx/jest/plugin`
- The migration only runs when `@nx/jest/plugin` is registered in
`nx.json`
- Projects with `type: module` are warned as they're incompatible with
the plugin
- Files using ESM-only features (import.meta, top-level await) are
skipped with a warning for manual conversion
## Demo
https://www.loom.com/share/8a157a0b01d144ae8d6ae48b9b0cd0e4
## Related Issue(s)
Closes NXC-3541
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
We don't have a migration to migrate users to use the new @nx/vitest
package if they're currently using @nx/vite
Given that we have Vitest-related operations marked as deprecated when
used via @nx/vite, we should have a migration.
## Expected Behavior
Add a migration that:
1. Installs @nx/vitest
2. Switches @nx/vite:test executor usage to use @nx/vitest:test executor
usage
3. Splits `@nx/vite/plugin` in nx.json that sets up vitest test targets
to use `@nx/vitest` instead
## Current Behavior
The `@nx/vite:test` executor is not returning the async iterable. This
causes a destructuring issue.
## Expected Behavior
Ensure the `@nx/vite:test` executor returns the async iterable.
## Related Issue(s)
Fixes#33588
This PR updates the `workspace-rule` generator so use ESLint v9 by
default. It currently forces the unsupported ESLint v8.
In theory this is only useful if not using workspaces and you need
tsconfig paths to be mapped and resolved correctly. For workspaces, you
can easily just generate any library to be used to contain custom rules.
Closes NXC-3500
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Blog posts contain broken links pointing to old `/powerpack` and
`/docs/enterprise/powerpack/*` paths that no longer exist.
## Expected Behavior
Links should point to the new enterprise documentation paths:
- `/powerpack` → `/enterprise`
- `/docs/enterprise/powerpack/*` → `/docs/enterprise/*`
- `/docs/reference/powerpack/*` → `/docs/reference/*`
## Related Issue(s)
Closes DOC-354
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When running `NX_PERF_LOGGING=true nx graph --file graph.json`, many
performance logs are missing (e.g., `create-project-graph-async`,
`retrieve-project-configurations`).
Only plugin-specific logs like `createDependencies` appear.
## Expected Behavior
All performance timing logs should appear, matching the output of
`NX_PERF_LOGGING=true nx show projects`.
## Related Issue(s)
N/A - Internal improvement for debugging/profiling.
## Solution
The `graph.ts` file had `process.exit(0)` calls that terminated the
process immediately, not giving the async `PerformanceObserver` callback
time to fire.
Added `await new Promise((res) => setImmediate(res))` before
`process.exit(0)` to give the event loop one tick to process pending
callbacks. This follows the existing
pattern in `show/projects.ts` and `show/project.ts`.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The Nx Console installation prompt blocks commands when run in
non-interactive contexts such as:
- CI environments
- AI agents
- Piped commands
The prompt only checked `process.stdout.isTTY` but not
`process.stdin.isTTY`, causing it to wait indefinitely for input that
would never arrive.
## Expected Behavior
Commands should complete without prompting when run in non-interactive
environments.
## Related Issue(s)
Fixes#33552
## Solution
Updated the check to verify:
1. Both `stdin` and `stdout` are TTY (truly interactive terminal)
2. Not running in a CI environment (using existing `isCI()` utility)
This ensures the prompt only appears when the user can actually provide
input.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Since Nx 21.6.1, running `nx graph` or other commands that calculate
affected projects prints git errors to stderr when the default branch is
not fetched:
```
fatal: ambiguous argument 'main': unknown revision or path not in the working tree.
```
This causes CI pipelines with strict stderr checking to fail, even
though the nx commands succeed.
## Expected Behavior
Git error messages should not be printed to stderr. The errors are
already caught and handled gracefully - they just shouldn't be visible
to the user.
## Related Issue(s)
Fixes#33330
## Solution
Added `stdio: 'pipe'` to the `execSync` call in `parseGitOutput()`. This
suppresses stderr output while still allowing the command to throw on
failure (which is already caught by the try-catch in `graph.ts`).
This matches the pattern used in `getMergeBase()` which already uses
`stdio: 'pipe'`.
## Current Behavior
When running `nx migrate latest`, the `create-nx-workspace` package is
not updated along with other Nx packages, even though it's a core part
of the Nx ecosystem that users may have as a dependency (especially when
extending the install package pattern).
## Expected Behavior
The `create-nx-workspace` package should be updated to the same version
as `nx` and other `@nx/*` packages when running migrations.
## Related Issue(s)
Fixes#33585
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The nuxt preset test was checking for `apps/${name}/src/app.vue`, but
since the generator now defaults to Nuxt v4 which uses the app directory
structure, this file is no longer created at that path.
## Expected Behavior
Tests should pass on master.
## Solution
Updated the test to check for `apps/${name}/app/app.vue` which is the
correct path for Nuxt v4's app directory structure.
## Current Behavior
When Nx commands finish or receive termination signals (SIGINT, SIGTERM,
SIGHUP), child processes spawned by continuous tasks (such as `nx
serve`) can remain orphaned in certain scenarios. This happens because
only the direct child process is killed using `childProcess.kill()`,
leaving grandchild processes running.
## Expected Behavior
When Nx terminates, all processes in the spawned process tree should be
properly terminated and no orphaned processes should remain.
## Related Issue(s)
Fixes#32438Fixes#33460
## Changes
- Updated signal handlers in `RunningNodeProcess` to use `this.kill()`
instead of `this.childProcess.kill()`, leveraging the existing
`tree-kill` implementation
- Added `tree-kill` to `NodeChildProcessWithNonDirectOutput` and
`NodeChildProcessWithDirectOutput` kill methods to ensure entire process
trees are terminated
We missed a peer dep error in the Nuxt 4 PR since CI allowed install to
go through, but in a real repo it would have failed.
We _may_ need to still have the `prefer-frozen-lockfile=false` option,
but let's let CI run with this first.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
We currently do not support Nuxt 4. We still generate Nuxt 3.
## Expected Behavior
Support Nuxt 4.
New workspaces will get Nuxt 4.
Existing Workspaces that use Nuxt 3 intentionally will continue to use
Nuxt 3.
Add a migration to update users to Nuxt 4
Handle ESLint flat config
## Related Issue(s)
Closes NXC-3525
Closes NXC-3497
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
The base `eslint` config will ignore `**/dist` but not `**/out-tsc`.
This can cause issues if lint is run after a `typecheck` which has
placed `.d.ts` files into an `out-tsc` directory.
## Expected Behavior
Base eslint config should ignore `**/out-tsc`
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Storybook support is not explicitly set to 10.1 which has just been
released.
## Expected Behavior
Explicitly set storybook version to 10.1 to ensure support for Angular
21
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
- E2E nightly tests only run on Node 20 and 22.
- E2E nightly tests now also run on Node 24, 22, and 20 for linux. For
Windows and Mac run only 24.
Did a test run from this branch, and Node 24 passes where other versions
pass, and fails where other versions fail. It shouldn't make any golden
tests fail just due to Node 24, but it's possible that things will flake
more since the matrix has expanded. We just have to make them more
robust.
<img width="920" height="1089" alt="image"
src="https://github.com/user-attachments/assets/90ee4d04-68d5-4d0d-9729-60cacfbc99db"
/>
Close NXC-3491
## Current Behavior
The Next 16 AI Migration Instructions are always created, regardless of
existing Next version
## Expected Behavior
Make the Next 16 Migration optional
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
There is no documentation on how to create and use custom ESLint rules
in Nx workspaces.
Users can follow a guide to create custom ESLint rules using either:
1. Package Manager Workspaces (npm/yarn/pnpm/bun) - create a dedicated
ESLint plugin package that's symlinked via the package manager
2. `loadWorkspaceRules` utility from `@nx/eslint-plugin` - load rules
from any directory with automatic TypeScript transpilation
The guide includes:
- Comparison table for choosing the right approach
- Step-by-step instructions for both approaches
- TypeScript execution options (build first, Node.js native support,
tsx)
- Rule testing with `@typescript-eslint/rule-tester`
- Best practices and troubleshooting tips
Page:
https://deploy-preview-33618--nx-docs.netlify.app/docs/technologies/eslint/guides/custom-workspace-rules
Closes DOC-339
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Despite @nx/vite depending on @nx/vitest it only does so in the same
version that introduces the migration for Vitest 4.
This means the user does not get any migrations for Vitest 4
## Expected Behavior
Add the Vitest 4 migrations to the @nx/vite package to allow users to
migrate.
There's a problem when `@nx/rollup` is installed with yarn@1.22, and
typechecks.
This is caused by the transitive dependency chain:
```
rollup-plugin-copy@3.5.0 -> globby@10.0.1 -> @types/glob@7.2.0 -> @types/minimatch
```
When users run tsc without explicit `types` configuration, TypeScript
auto-discovers `@types/minimatch` from `node_modules` but can't properly
resolve it.
Note: This doesn't happen with NPM and PNPM, nor newer yarn versions.
Verified fix with this repro: https://github.com/jaysoo/rollup-251124Fixes#32398
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
- Storybook generator docs banner says "Nx uses Storybook 7"
- Separate storybook-9-setup.mdoc page exists
- No documentation for migrate-10 generator
## Expected Behavior
- Update banner to "Nx uses Storybook 10"
- Consolidate storybook-9-setup into upgrading-storybook guide
- Add migrate-10-generator-examples.md with AI-assisted migration docs
- Update all references to point to new consolidated guide
---
Main content is here:
https://deploy-preview-33619--nx-docs.netlify.app/docs/technologies/test-tools/storybook/guides/upgrading-storybook
Need to follow-up on the sidebar ordering as it doesn't seem to take it
into account for technologies section.
Fixes DOC-347
## Current Behavior
When a continuous task depends on another continuous task and the
dependent task exits with an error, the parent task continues running
indefinitely. The task execution never terminates, leaving processes
running in the background.
For example, if task `a` (continuous) depends on task `b` (continuous),
and task `b` exits with error code 1, task `a` will continue running
even though its dependency failed.
## Expected Behavior
When a continuous task exits (with any exit code), the failure should be
propagated to dependent tasks:
1. The failed continuous task should be marked as failed
2. Dependent continuous tasks should be marked as skipped
3. All affected continuous tasks should be killed
4. Task execution should terminate with an error
---
## Changes Made
### 1. Restore Error Handling in Continuous Task Exit Handlers
- Re-added the `cleaningUp` flag that was removed in a previous
TUI-related commit
- Modified `onExit` handlers for both regular and shared continuous
tasks to:
- Check if the task exited during normal cleanup vs. unexpectedly
- Call `complete()` with 'failure' status for unexpected exits
- Log error messages for debugging
### 2. Fix `cleanUpUnneededContinuousTasks()` Logic
The previous implementation always added `initializingTaskIds` to the
needed set, even when those tasks were already completed. This prevented
dependency tasks from being killed when the top-level task exited.
Fixed by:
- Only adding tasks from `initializingTaskIds` if they are still
incomplete
- Keeping dependencies of incomplete tasks alive
- This ensures continuous tasks are killed when no longer needed,
whether a dependency fails or a top-level task exits
### 3. Prevent Status Overwrites
Added a check in `onExit` handlers to only set status to `Stopped` if
the task hasn't already been completed. This prevents the async `onExit`
callback from overwriting the correct status (like 'skipped' or
'failure') with 'Stopped'.
### 4. Fix Signal Handling in `PseudoTtyProcess.kill()`
The Rust pseudo-terminal defaults to SIGINT when no signal is provided,
which does not reliably terminate child processes in PTY sessions.
Fixed by:
- Defaulting to SIGTERM in the JavaScript wrapper (rather than changing
the Rust default)
- The JS wrapper is the API boundary that should match Node.js
semantics, where `childProcess.kill(undefined)` defaults to SIGTERM
- The Rust default of SIGINT is appropriate for interactive use
(Ctrl-C), while programmatic cleanup needs SIGTERM
- This ensures child processes are properly killed when
`runningTask.kill()` is called
**File:** `packages/nx/src/tasks-runner/pseudo-terminal.ts`
## Technical Details
The fix leverages the existing task failure propagation mechanism in
`complete()` instead of using `process.exit(1)`, which:
- Allows proper cleanup through normal execution flow
- Respects the `--bail` flag configuration
- Works correctly with both TUI and non-TUI modes
- Maintains consistency with how other task failures are handled
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Older versions don't support the `nx mcp` command yet - but they CAN use
the `nx-mcp` package via npx
## Expected Behavior
We generatee the proper command into their MCP config by matching on
their version
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When multiple versions of the `nx` package are installed in a workspace
(e.g., due to a third-party package incorrectly depending on nx), users
have no visibility into
this issue through `nx report`.
## Expected Behavior
The `nx report` command now detects when other packages depend on a
different version of nx than the workspace version and reports this
clearly:
⚠️ Multiple Nx versions detected
Your workspace uses nx@20.0.0, but other packages depend on a different
version:
- some-package → @scope/tool → nx@19.0.0
These packages should not have nx as a dependency. Please report this
issue to the package maintainers.
Run pnpm why nx@19.0.0 for more details.
This helps users identify and report problematic packages that bundle
their own version of nx.
## Related Issue(s)
N/A - This is a proactive improvement to help users diagnose workspace
issues.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
nightly tests fail on gradle because of gradle parsing
## Expected Behavior
nightly tests should pass
## Current Behavior
We do not generate AI Instructions to aid with upgrading from Next 15 to
Next 16
## Expected Behavior
Add a migration generator to create a file containing instructions for
an LLM to upgrade Next 15 to Next 16
## Related Issue(s)
Closes NXC-3418
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
In TS Solution setups, we generate webpack config with
`generatePackageJson: true`. This is confusing and unneeded.
It should be set to false in TS Solution repos.
## Expected Behavior
Set `generatePackageJson: false` in webpack config for TS Solution
Setups
Closes NXC-3521
When generating NestJS applications in Angular workspaces, the base
tsconfig sets moduleResolution to 'bundler' which causes TS5095 errors
because 'bundler' requires module to be 'preserve' or 'es2015+'.
NestJS applications should use Node.js module resolution instead. This
fix sets moduleResolution to 'node' for NestJS applications (except when
using TS solution setup, which uses 'nodenext').
Fixes#33589
## Current Behavior
The ⚠️ emoji at the beginning of bc commits is duplicated in the bc
section of the changelog.
This is unneeded.
## Expected Behavior
Ensure the ⚠️ is not repeated in the bc section of the changelog
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
Close NXC-3516
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
1. **Socket Race Condition**: All daemon servers listen on the same
socket path, causing a race condition where shutting down daemons remove
sockets that newly started
daemons are listening on.
2. **Daemon Console Check Blocks**: The daemon availability check runs
synchronously and blocks the main thread.
3. **Version Mismatch Issues**: Packages using a different nx version
than what's installed in the workspace could still use the daemon,
leading to potential issues.
## Expected Behavior
1. Each daemon server creates a unique socket path based on its process
ID, preventing race conditions.
2. The daemon console check runs in the background without blocking.
3. The daemon is disabled when there's a version mismatch between the
running nx and the workspace's installed version.
## Changes
### 1. Unique Daemon Socket Paths
- Include `process.pid` in the socket directory hash to make each
daemon's path unique
- Store the socket path in `server-process.json` so clients know where
to connect
- Clients read the socket path from the file instead of calculating it
### 2. Backgroundable Daemon Check
- Reapplied #33491 which makes the Nx Console install check run on the
daemon in the background
- This was previously reverted due to the socket race condition (now
fixed by change 1.)
- Running in background also allows pulling the latest check logic from
npm
### 3. Version Mismatch Check
- Added `isNxVersionMismatch()` check in `DaemonClient.enabled()`
- Created shared utility `is-nx-version-mismatch.ts` for version
comparison
- Refactored server.ts to use the shared utility
- Uses `require.resolve('nx/package.json', { paths: [workspaceRoot] })`
to properly resolve the workspace's installed nx version
## Related Issue(s)
Fixes daemon socket path race condition and improves daemon reliability.
## Current Behavior
`copy-workspace-modules` executor only copies workspace dependencies 1
level deep.
If that workspace library depends on another workspace library, it is
not copied correctly.
## Expected Behavior
Copy transitive workspace modules
## Related Issue(s)
Fixes NXC-3466
When adding Cypress to a library, the generated commands.ts causes
TS2669 error because declare global requires the file to be a module.
Changed to use declare namespace Cypress directly.
Fixes#32930
## Current Behavior
PR #33491 introduced a daemon call into every command and caused
unexpected issues...
## Expected Behavior
the change is reverted while we investigate a proper fix
## Changes
This reverts commit 9471207767 from PR
#33491.
## Related Issue(s)
Fixes#33472
## Current Behavior
The manual DTE workflow explicitly sets the `ref` parameter to `${{
github.event.pull_request.head.sha }}` to checkout the actual branch
HEAD instead of the merge commit.
## Expected Behavior
Use GitHub's default ref behavior instead of explicitly overriding it,
as the default behavior now handles this correctly.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When generating a React component with --style=tailwind, the component
template incorrectly includes `className={styles['container']}` and
attempts to import CSS modules.
## Expected Behavior
Components generated with --style=tailwind should not include CSS
modules imports or `styles['container']` references, since Tailwind
doesn't use CSS modules.
## Related Issue(s)
Closes NXC-3511
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Stats don't come along with versions which makes it hard to see if it
was specific changes that make a difference.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stats are tagged with the version so we can compare stats between
versions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR fixes an issue where migrations can hang due to out invocation
of `storybook automigrate`. We are passing both `--config-dir` and
`STORYBOOK_PROJECT_ROOT`, the latter causes hanging with Storybook v9.
https://www.loom.com/share/39bbb350595c4a13aef86ec29f4b748f
## Current Behavior
Hangs
## Expected Behavior
Does not hang
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32492
This PR cleans up the markdown files under `packages/`. We previously
had to support Next.js docs and translate it for astro docs with proper
markdown syntax. This applies to generators, executors, and migrations.
Also removes the function to do the translation in astro app since it's
no longer needed.
## Code block (migrations)
<img width="1086" height="800" alt="Screenshot 2025-11-20 at 1 23 53 PM"
src="https://github.com/user-attachments/assets/bd9acb9b-7960-4e41-9d26-22d29da6658e"
/>
## Aside (generators)
<img width="802" height="443" alt="Screenshot 2025-11-20 at 1 43 17 PM"
src="https://github.com/user-attachments/assets/e2999821-8783-46ed-a984-2193f6f8eafa"
/>
## Current Behavior
During createNodes, if a file is imported and a function in said file
invokes the Nx project graph creation process, there's an infinite loop
that results in all nx commands hanging with little feedback.
Theoretically this loop would terminate at around the 10 minute mark,
but throughout the loop we would be digging deeper and deeper into
recursive territory so its possible that the node process could become
overwhelmed and hang.
## Expected Behavior
If recursive graph creation is detected, Nx terminates and logs the call
stack so it can be investigated properly.
## Related Issue(s)
Fixes#29618
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
This PR adds the ability for users to import ESLint rules from arbitrary
location in the workspace rather than storing them in
`tools/eslint-rules`. This is useful for monorepo not using
npm/yarn/pnpm workspaces and need a mechanism to load from any custom
rules location without them being installed/symlinked.
It also handles TS files automatically.
Demo: https://www.loom.com/share/3c32af4555614eeab4f81fce8db0c955
Example:
```js
import baseConfig from "../../eslint.config.mjs";
import { loadWorkspaceRules } from "@nx/eslint-plugin";
const customRules = await loadWorkspaceRules("foo/bar/eslint-rules");
export default [
...baseConfig,
{
ignores: ["**/out-tsc"],
},
{
files: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"],
plugins: {
custom: { rules: customRules },
},
rules: {
"custom/valid-command-object": "error",
},
},
];
```
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
Daemon command hangs at end instead of exiting
## Expected Behavior
Daemon command exits
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There's some issues with the jest configs in the repo, CJS files having
`import` in them, etc.
## Expected Behavior
CJS files don't have `import`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`cache: true` is overridden if task name is dev
## Expected Behavior
`cache: true` has priority
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32610
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Using .mts extension forces files to always be treated as ESM modules,
ensuring consistent behavior regardless of package.json or tsconfig
settings.
This matters for Node 24 because by default Node will strip types from
`.ts` files and then they are resolved through normal Node resolution.
In the past we can control CJS/ESM through tsconfig options, but now
only extension or `type` in `package.json` matters.
Changes:
- Updated all createOrEditViteConfig calls to pass useEsmExtension: true
- Updated normalizeViteConfigFilePathWithTree to check for .mts files
first
- Updated test files to expect .mts config files
- Updated snapshots to reflect new .mts extension
Closes NXC-3446
Flat config overrides util may fail when it isn't a plain JS object.
This PR makes the `hasOverrides` function more robust against these
cases.
Fixes#31796
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
the JSON parsing is broken because in verbose mode, the gradle plugin
returns more than just JSON.
## Expected Behavior
JSON parsing in the test should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We naively mark WholeFileChange for commits when getting the relevant
commits for projects.
There is already logic to perform better diff checking for lock files,
especially in the case of pnpm catalog usage
## Expected Behavior
Reuse existing logic to determine file changes more accurately
## Related Issue(s)
Fixes#33413
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
If no inputs or named inputs are defined, this area of code was hit:
```
const DEFAULT_INPUTS: ReadonlyArray<InputDefinition> = [
{
fileset: '{projectRoot}/**/*',
},
{
dependencies: true,
input: 'default',
},
];
export function getNamedInputs(
nxJson: NxJsonConfiguration,
project: ProjectGraphProjectNode
) {
return {
default: [{ fileset: '{projectRoot}/**/*' }],
...nxJson.namedInputs,
...project.data.namedInputs,
};
}
```
This resulted in weird behavior when the user would define `default` in
named inputs, but it would seemingly only be applied to the project's
deps and not the project itself
## Expected Behavior
The `default` input is the default for both
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #https://github.com/nrwl/nx/issues/32924
## Current Behavior
Every time a daemon connection is opened, we create a new interval and
unref it. This results in the daemon checking its process termination at
an ever increasing rate, which presents as increased memory usage and
practically means the daemon is just doing a lot more work than it needs
to in this area.
## Expected Behavior
The interval is registered only on initial server startup.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29836
This PR updates the guide here to also include type entries (which we
generate by default):
https://nx.dev/docs/technologies/typescript/guides/compile-multiple-formats
Update the content to account for the new inferred `@nx/rollup/plugin`
setup, but still mentions the executor. And also link to a tool that can
be used to check for types correctness.
Closes#33258
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
if there is an error parsing a schema file for generators/executors then
we should fully error out to prevent caching a "bad" build even if the
site techincally works with missing plugin info.
## Current Behavior
Metrics collection is currently disabled in the CI workflow via the
`NX_CLOUD_ENABLE_METRICS_COLLECTION` environment variable set to
'false'.
## Expected Behavior
Metrics collection should be enabled to gather build and performance
data from CI runs.
## Related Issue(s)
Reverts the change from #33497
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The `@nx/js:typescript-sync` generator never syncs external project
references to `tsconfig.json` files if a runtime tsconfig file exists.
## Expected Behavior
The `@nx/js:typescript-sync` generator should sync external project
references to `tsconfig.json` files if it includes any files or a
runtime tsconfig file doesn't exist.
## Summary
This PR fixes a critical deadlock issue in the metrics collector that
occurred due to inconsistent lock acquisition order between the
collection thread and registration threads. The fix involved
restructuring lock scopes across multiple functions to maintain a
consistent lock hierarchy.
## Changes
- Fixed lock acquisition order in 4 registration functions
(register_main_cli_process, register_main_cli_subprocess,
register_task_process, register_batch)
- Restructured collect_metrics() to minimize system lock scope and
release it before acquiring other locks
- Fixed collection helper methods to read PIDs in scoped blocks without
holding system lock
- Added comprehensive trace logging for debugging lock contentions
- Added concurrent test case to verify no deadlocks occur under stress
## Testing
- All 12 metrics tests pass
- Comprehensive concurrent stress test added:
test_concurrent_group_creation_with_subprocess_updates
- Lock ordering consistency test added:
test_lock_order_consistency_across_registration_threads
## Lock Ordering Rule
Established and enforced this hierarchy across all threads:
1. Acquire system lock first
2. Release system lock
3. Then acquire registration/PID locks
This prevents circular wait conditions (A→B / B→A) that cause deadlocks.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
When Storybook is installed with a version range like `^10.0.0` or
`~8.5.3`, the configuration generator fails with error:
```
NX Invalid Version: ^10.0.0
TypeError: Invalid Version: ^10.0.0
```
This occurs because `gte()` from semver doesn't accept version ranges on
the left-hand side - only valid semver versions are allowed there.
The Storybook configuration generator should work with version ranges by
extracting the actual version number before comparison.
Fixes#33514
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Env variables from the parent target are not propagated to the atomized
target e.g.
`.test-ci.env` will be only applied to **no-op** `test-ci` but not to
`test-ci--path/to/test/file`.
## Expected Behavior
Running an atomized target will load from the parent's env files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Gradle projects in Nx workspaces can only configure metadata through
Gradle's built-in mechanisms. There's no way to specify Nx-specific
project metadata (like tags) or customize task target configurations
other than overriding with `project.json`
## Expected Behavior
Developers can now configure Nx-specific metadata for both projects and
tasks using a type-safe Kotlin/Groovy DSL:
### Project-level metadata (in build.gradle.kts):
```
nx {
set("name", "my-service")
array("tags", "scope:backend", "type:api")
set("description", "Payment processing service")
}
```
### Task-level metadata (in build.gradle.kts):
```
tasks.named("integrationTest") {
nx {
set("cache", false)
array("tags", "integration", "slow")
}
}
```
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
## Current Behavior
In certain scenarios, Nx commands would hang between command completion
and process exit. This was caused by inefficient message end detection
in the
daemon socket communication, where the check for `MESSAGE_END_SEQ` could
fail when TCP packets were fragmented.
## Expected Behavior
With this PR, the message end detection is more robust and handles TCP
packet fragmentation correctly, preventing the hanging issue. The
changes also
add better performance tracking and logging to help diagnose similar
issues in the future.
## Changes Made
- **Improved message end detection**
(`consume-messages-from-socket.ts`): Added a preliminary check of the
last character's code point before checking
the full MESSAGE_END_SEQ, which prevents false negatives when TCP
packets are fragmented
- **Enhanced performance tracking** (`daemon/client/client.ts`,
`daemon-socket-messenger.ts`): Added message-type-specific performance
marks and
measures for better debugging
- **Added server-side logging** (`daemon/server/server.ts`): Added
logging for message receipt, serialization, and response to help
diagnose
communication issues
## Related Issue(s)
This fix addresses hanging issues observed in daemon communication when
commands complete but the process doesn't exit.
Add a skipDefaultTag option to the DockerTargetOptions interface that
allows users to opt out of the automatic default tag that is prepended
to build targets.
This is useful for multi-platform builds that need to push during build
(e.g., using --platform linux/amd64,linux/arm64 --push), where the
default tag causes build failures because it attempts to push a tag that
was not configured.
- Add skipDefaultTag?: boolean to DockerTargetOptions interface
- Modify buildTargetOptions to conditionally skip default tag when
skipDefaultTag is true
- Inherit skipDefaultTag from parent target in configurations
- Add comprehensive unit tests for skipDefaultTag functionality
- Add e2e test to verify skipDefaultTag works end-to-end
- Maintains backward compatibility (default behavior unchanged when
option not specified)
Fixes#33477
## Current Behavior
Loading local plugins that are relative paths from workspace root, that
point to a JS file, still require preliminary data from default plugins
despite being resolvable. This is because we aren't passing `paths` to
`require.resolve`, so it is trying to resolve relative to the nx package
instead of the workspace.
## Expected Behavior
The straight JS path resolves
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The metrics collector has several inefficiencies and architectural
issues:
- Complex hierarchical data structure (`ProcessTreeMetrics`) that
doesn't align with how the data is consumed
- Separate `MetadataStore` struct with unnecessary indirection
- Full metadata resent to all subscribers on every collection cycle
- Mutable parameters passed through collection functions instead of
functional return values
- Repeated allocations and clones across collection cycles
- `CollectionRunner` tightly coupled to NAPI, making it untestable in
pure Rust
## Expected Behavior
This PR restructures the metrics collector for better performance,
testability, and maintainability:
### Architectural Changes
1. **Flat Process Model**: Replaced hierarchical `ProcessTreeMetrics`
with a flat `Vec<ProcessMetrics>`, simplifying data flow
2. **Group-Based Organization**: Introduced `GroupInfo` and `GroupType`
to logically organize processes:
- `MainCLI` - Nx CLI process and its subprocesses
- `Daemon` - Nx daemon and its children
- `Task` - Individual task execution processes
- `Batch` - Batch execution with multiple tasks
3. **Incremental Metadata Updates**:
- Track which groups and processes have been sent using
`Arc<DashMap<String, GroupInfo>>` and `Arc<DashMap<String,
ProcessMetadata>>`
- Only send new metadata to subscribers instead of full state every
cycle
- New subscribers receive full metadata on first update via
`needs_full_metadata` flag
- Automatic cleanup of dead process/group metadata
4. **Shared State with Arc**:
- Metadata maps shared between `ProcessMetricsCollector` and
`CollectionRunner` using `Arc<DashMap>`
- Eliminated duplicate metadata storage
- Single source of truth for all metadata
5. **Functional Programming Pattern**:
- Collection functions now return `Result<MetricsCollectionResult>`
instead of mutating parameters
- Cleaner error handling with `inspect_err` and `map`
- Easier to reason about data flow
- Removed ~100 lines of code by consolidating logic
6. **Channel-Based Communication**:
- Decoupled `CollectionRunner` from NAPI using `crossbeam_channel`
- Collection thread sends metrics via channel to listener thread
- Listener thread receives metrics and notifies NAPI subscribers
- `CollectionRunner` is now NAPI-free and fully testable in pure Rust
- Non-blocking collection (subscriber callbacks don't block metrics
collection)
### Performance Optimizations
- Pre-allocated `Vec` capacity when combining metrics from different
sources
- Eliminated unnecessary `HashMap` clones during metadata updates
- Single-pass insertion into `DashMap` during string key conversion
- Reduced memory allocations in hot paths
- Collection thread never blocks on JavaScript callbacks
### Code Quality Improvements
- **Testability**: Added 7 pure Rust unit tests for `CollectionRunner`:
- Group creation with different registration types
- Incremental metadata updates
- Dead group cleanup
- All tests pass without requiring NAPI/Node.js runtime
- Clearer separation of concerns between collection and notification
- Better comments explaining incremental update strategy
- More idiomatic Rust patterns throughout
- Updated TypeScript type exports to match new structure
### Threading Model
**Before:**
```
CollectionRunner (mixed collection + NAPI notification)
```
**After:**
```
CollectionRunner (pure Rust, testable)
└─> Channel
└─> Listener Thread
└─> NAPI ThreadsafeFunction
└─> Subscribers
```
## Testing
- ✅ 241 Rust tests passing (including 7 new `CollectionRunner` tests)
- ✅ Native module builds successfully
- ✅ TypeScript types updated and exports verified
## Related Issue(s)
Part of ongoing metrics collector optimization work.
## Current Behavior
The Nx Console install check for the prompt happens in the main process,
adding some overhead to each invocation of nx.
## Expected Behavior
We want this check to happen on the daemon so that it's running in the
background. If it's still running when nx is invoked, we can just skip
the prompt since it's non-critical.
Running it in the background also allows us to pull the latest version
of the logic from npm when executing - that way we can keep the logic
older versions up-to-date even when ppl don't migrate to latest.
## Current Behavior
The Maven plugin is currently at version 0.0.9.
## Expected Behavior
This PR bumps the Maven plugin to version 0.0.10 and creates the
necessary migration for users to automatically update their pom.xml
files.
## Related Issue(s)
N/A - Routine version bump
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
https://www.loom.com/share/560ceccdad45462e9fd3e3f185fc9fa5
Node 24 has stricter readline behavior, and enquirer is not checking for
closed state when invoking operations, resulting in an
ERR_USE_AFTER_CLOSE error when users press Ctrl+C during interactive
prompts.
This commit fixes the issue by adding uncaughtException handler to
ignore ERR_USE_AFTER_CLOSE errors.
When users press Ctrl+C, the process now exits cleanly without showing
an ugly error stack trace.
Fixes NXC-3412
Co-authored-by: Claude <noreply@anthropic.com>
Updates the Nx Powerpack docs and marketing page to make it clear that
Powerpack packages are included with Nx Enterprise, and cannot be
purchased separately, and remove references to the Nx Powerpack trial.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
The recipe for switching to TS project references states "If you
reference a local library project with its own `build` task" which
caused confusion. Users thought only buildable libraries should be
included in devDependencies, leading them to create unnecessary path
aliases for non-buildable libraries.
Closes DOC-149
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Currently, telemetry stats are only recorded when `create-nx-workspace`
completes successfully. This doesn't capture how many times the command
is invoked vs completed.
## Expected Behavior
Record a stat when `create-nx-workspace` is first invoked (before any
prompts), enabling analysis of drop-off between initial invocation and
workspace completion.
## Changes Made
### Telemetry
- Added `recordStat()` call in `normalizeArgsMiddleware()` immediately
after welcome message and before any user prompts
- Records with command name `create-nx-workspace` and metadata
`['start']` to distinguish from completion stat
- Allows correlation of invocation and completion events for drop-off
analysis
### AI Agents Prompt
- This is being temporarily disabled because we noticed a dip in
create-nx-workspace completions that lines up when this was released.
Disabling it temporarily to see if the dip is recovered by disabling the
prompt.
### React Framework Selection
- Added early returns in `determineReactFramework()` for cases where
framework is already provided or interactive mode is disabled
- Improves performance by avoiding unnecessary prompt interactions
### Code Quality
- Reorganized imports in alphabetical order for better maintainability
- Removed unused import (`printSocialInformation`)
## Related Issue(s)
WIP - Draft for discussion
## Current Behavior
When `nx add @nx/s3-cache` fails due to incompatible peer dependencies
or other installation errors, users see only a generic error message
without the actual error details from the package manager.
## Expected Behavior
The command should display complete error messages from the package
manager (both stdout and stderr), including peer dependency conflicts
and other important diagnostic information.
## Changes
Fixed the exec callback in the `installPackage` function to:
1. Capture the `stderr` parameter (was previously ignored)
2. Log both stdout and stderr with a newline separator for clarity
3. Ensure users see all error information from package managers
## Why It Matters
Package managers write installation errors and peer dependency warnings
to stderr. By ignoring stderr, users had no visibility into what
actually failed, making it difficult to diagnose and fix issues.
Fixes issue with `nx add` not showing proper error messages.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `remove-redundant-ts-project-references` migration fails with an
error when run on workspaces that don't have a root `tsconfig.json`
file, such as nx-examples.
## Expected Behavior
The migration should skip workspaces that are not using TypeScript
solution setup instead of throwing an error.
## Related Issue(s)
Fixes the issue encountered when running the migration on
nrwl/nx-examples repo.
## Changes
- Added check to skip migration if workspace is not using TS solution
setup
- Updated test setup to properly configure TS solution for existing
tests
- Added new test cases to verify skip behavior
The migration now uses `isUsingTsSolutionSetup()` to detect if:
- `tsconfig.base.json` exists
- `tsconfig.json` exists and extends the base
- Package manager workspaces are configured
- Proper TS solution structure is in place
Workspaces missing any of these requirements will have the migration
skip silently.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The migration for removing redundant TypeScript project references is
set to version `22.1.0-beta.8`.
## Expected Behavior
The migration should be updated to version `22.1.0-rc.1` to align with
the release candidate version.
## Related Issue(s)
N/A - Version update as requested.
## Current Behavior
The `@nx/js:typescript-sync` generator adds project dependencies as
TypeScript project references to each project's `tsconfig.json` and
runtime tsconfig file (e.g., `tsconfig.app.json`, `tsconfig.lib.json`,
etc.). This is redundant since projects' `tsconfig.json` files already
reference the runtime tsconfig file, which would reference the
dependencies.
## Expected Behavior
The `@nx/js:typescript-sync` generator should add project dependencies
as TypeScript project references to each project's runtime tsconfig file
(e.g., `tsconfig.app.json`, `tsconfig.lib.json`, etc.). If the project
only has a `tsconfig.json` file, it should add them to it.
We've observed some performance improvement with this change while
running the `typecheck` tasks.
## Summary
This PR combines two critical performance optimizations for batch task
scheduling and task hashing:
### 1. Batch Scheduling Fix
Fixed a correctness bug in the batch scheduling optimization where the
`visitedInBatch` tracking happened too early. Now tasks are only marked
as visited AFTER all scheduling checks pass, ensuring tasks can be added
to the batch from any valid dependency path.
**Files Modified:**
- `packages/nx/src/tasks-runner/tasks-schedule.ts`
**Impact:**
- Prevents task splitting across unnecessary batch boundaries
- Maintains correctness while optimizing performance
- All batch scheduling tests pass
### 2. Task Output Hashing Optimization
Added a DashMap-based cache to the Rust TaskHasher to prevent redundant
hashing when multiple tasks depend on the same outputs.
**Files Modified:**
- `packages/nx/src/native/tasks/task_hasher.rs` - Added
task_output_cache field
- `packages/nx/src/native/tasks/hashers/hash_task_output.rs` - Implement
cache logic
## Root Cause of Issue #33366
Large project graphs with high dependency fanout exhibit slow
`hashMultipleTasks` because:
- 100+ tasks may depend on the same 10 build tasks' outputs
- This generates 1,000+ separate `TaskOutput` hash instructions
- Each instruction independently:
- Lists output files from disk (filesystem I/O)
- Builds glob patterns
- Hashes the same files
- Result: Same files hashed 100× redundantly
## Solution: Task Output Cache
The cache key combines glob pattern and sorted output paths. When
identical outputs are hashed with the same pattern:
- First task: computes hash (~milliseconds) and stores in cache
- Remaining 99 tasks: cache hits (~nanoseconds each)
### Cache Lifetime
- `TaskHasher` instantiated once per `hashMultipleTasks` call
- Cache persists for entire hashing session
- Discarded when `hashMultipleTasks` completes
- Optimal scope for cache hit maximization
## Performance Impact
**Expected Improvements:**
- Best case (100 tasks, 10 shared deps): 100× speedup
- Typical monorepo: 10-20× speedup
- No shared deps: No regression (cache lookup negligible)
**Issue #33366 Analysis:**
- Current: `Time for 'hashMultipleTasks' 49351.488518` (49 seconds)
- Expected with optimization: ~5-10 seconds (depending on actual
dependency structure)
## Testing
- ✅ All task scheduling tests pass (2262 passed, 0 new failures)
- ✅ Batch mode tests pass (6/6)
- ✅ Native build completed successfully
- ✅ No regressions in existing functionality
## Design Notes
- Task output cache follows same pattern as `workspace_files_cache`,
`external_cache`, `runtime_cache`
- Thread-safe using DashMap with Arc for Rayon parallel processing
- Instrumented with trace-level logging for cache hits/misses
- Cache automatically cleaned up when TaskHasher is dropped
Updates the `ng-packagr` executors to support a breaking change in v21.
This needs to be done in advance because we use the published
`@nx/angular` executors to build the `@nx/angular` source code. To
update to Angular v21, we need this change to be merged, released, and
installed in the Nx repository so that we can build the `@nx/angular`
package containing the support for Angular v21.
Users cannot import TypeScript schema definitions or schema.json files
from Nx packages due to strict package exports introduced in Nx 21.0.0.
Users can now import both TypeScript definitions and JSON schemas from
generator/executor/builder paths using wildcard export patterns. Both
first-level (`*`) and second-level (`*/*`) patterns are supported to
handle different import depths.
Note: For old plugins that had `src/...` deep imports we keep those in
`exports`, but for newer plugins that always used `exports` we skip
`src/` in the export path. So `@nx/nuxt/generators` instead of
`@nx/nuxt/src/generators`.
Fixes#33336
## Current Behavior
nx init is executed with whatever version is installed globally by npm
(might be outdated)
## Expected Behavior
we pull down the latest version from npm (if it has provenance) and run
that when executing.
Also introduced a new `NX_USE_LOCAL` env var that will be respected by
all commands that have this pulling-from-latest behaviour.
Update CI to Node 24. Note that the e2e-release changes are pulled from
the original PR.
Note: There are changes to NPM 11 (Node 24) to make it run slower than
NPM 10 (Node 20/22) for publish. (https://github.com/nrwl/nx/pull/31934)
e.g. https://github.com/npm/cli/releases/tag/v11.0.0-pre.1 (`Upon
publishing, in order to apply a default "latest" dist tag, the command
now retrieves all prior versions of the package.` which incurs more
network cost)
## Current Behavior
The typecheck target in graph/client/project.json only depends on
^typecheck targets from other projects.
## Expected Behavior
The typecheck target now includes nx:build-native as a dependency to
ensure native dependencies are built before type checking.
## Related Issue(s)
This fix resolves typecheck failures caused by missing native
dependencies.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
## Current Behavior
there is no way to generally influence how maven goals/phases are
represented as targets in nx. This could be useful though for organizing
targets in nx, for example through nx.json `targetDefaults`
## Expected Behavior
There's a `targetNamePrefix` plugin option that can be passed.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
After PR #33256 split lockfile parsing into separate node and dependency
caches, a regression occurred where dependencies could be regenerated
without nodes, leaving a shared module-level variable (`keyMap`) empty
and causing incorrect dependency resolution.
Changes:
- Serialize `keyMap` with nodes cache to maintain state between phases
- Remove module-level shared state from pnpm, npm, and yarn parsers
- Move `keyMap` creation inside `getNodes` functions for better
encapsulation
- Update `readCachedExternalNodes` to deserialize `keyMap` internally
Update from the macos-13 is in brownout and will be gone soon.
- macos-15-intel for x86_64-apple-darwin (Intel) builds
- macos-latest for aarch64-apple-darwin (ARM64) builds
Closes NXC-3444
## Current Behavior
We currently only generate vitest projects using Vitest 3
## Expected Behavior
Use Vitest 4 when generating new projects
## Related Issue(s)
Closes NXC-3343
Closes NXC-3379
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Clarifies some details of the Nx Cloud GitHub integration, such as which
features are available when you use the base integration vs a GitHub
powered organization.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
We do not render the commit title in the BC section of generated
changelogs.
## Expected Behavior
We should render the commit title in the BC section of generated
changelogs along with the Remote Release Client reference to the commit.
## Related Issue(s)
Closes NXC-3290
## Current Behavior
There may be a scenario when `cleanedAngularVersion` is of type `object`
rather than `string` which proceeds to error when passed to
`semver.major()`.
## Expected Behavior
If `cleanedAngularVersion` is not `string`, assume the latest version
will be installed. Similar to how no found angular version is handled.
## Related Issue(s)
Fixes#33347
- Fix for a bug with the external project references cache
- Add more caching for repeated operations
- Skip tsconfig files processing based on which targets should be
inferred
Fixes#33076
## Current Behavior
The library generator has an unused import and incorrect import pattern
for the vitest generator.
## Expected Behavior
Clean imports with the correct way to access the configurationGenerator
from @nx/vitest.
## Changes
- Removed unused imports (logger, readJson)
- Updated vitest generator import to use direct require instead of
ensurePackage pattern for accessing the generator
Fixes #
## Current Behavior
The Storybook 10 migration was originally intended to be optional.
## Expected Behavior
Make Storybook 10 migration add the migration generator to
migrations.json always. Users can remove it from here if they do not
want it, or they can use the Migrate UI from Nx Console to choose not to
run it.
Split entry point of `@nx/vitest` into `index.ts` for the Inference
Plugin, `generators.ts` for Generators, `executors.ts` for the
Executors.
Ensure the `README.md` is copied to the correct output directory
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
Split `vitest` out of `@nx/vite` and create a new `@nx/vitest`.
This allows for each plugin to have a single responsibility. One for
bundling, one for testing.
It should allow for lighter setups where Vite for Bundling is not
required, but users still want to use vitest for testing.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Storybook was accidentally downgraded to 9.1.9
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Storybook is upgraded back to 10.0
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cypress v15 is not supported.
## Expected Behavior
Cypress v15 should be supported.
## Related Issue(s)
Fixes#33304
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: leosvelperez <leosvelperez@users.noreply.github.com>
CI and nightlies can flake out during expo test if cypress or playwright
times out waiting for webserver. This makes is to the `export` that
powers `static-serve` is run before running e2e.
This is not usually a problem in new workspaces with inference, but this
legacy test uses executors so continuous task dependency isn't set up.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Nx plugin for Gradle is at version 0.1.8
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx plugin for Gradle is at version 0.1.9
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Track relevant CPU and memory system metrics.
- Link plugins to workers when possible.
- Refactor collector code by splitting it into two separate structs.
## Current Behavior
Maven plugin is currently at version 0.0.8.
## Expected Behavior
Maven plugin should be bumped to version 0.0.9 with a corresponding
migration for users.
## Changes Made
- Updated parent POM version to 0.0.9
- Updated package.json version to 0.0.9
- Updated mavenPluginVersion constant to 0.0.9
- Added new migration (0-0-9) to update user pom.xml files from 0.0.8 to
0.0.9
- Scheduled migration for Nx v22.1.0-beta.6
## Testing
- ✅ Maven package tests pass
- ✅ Build succeeds
- ✅ Linting passes
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Because `./nx` is passing args with `$@`, args are being split by
spaces. Reference for this behaviour:
https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html#Special-Parameters-1
This results in this set of process args when running `./nx start-ci-run
--distribute-on="3 linux-medium-jvm"`
```
[
"<user path>/.nvm/versions/node/v22.19.0/bin/node",
"<user path>/Projects/OTW/mm-test/.nx/nxw.js",
"start-ci-run",
"--distribute-on=3",
"linux-medium-jvm",
]
```
## Expected Behavior
the arg with whitespace should not be split before being passed to nx:
```
[
"<user path>/.nvm/versions/node/v22.19.0/bin/node",
"<user path>/.nx/nxw.js",
"start-ci-run",
"--distribute-on=3 linux-medium-jvm",
]
```
This PR is just for the repo itself to use `.cts` to explicitly use CJS
for jest config. Node 24 strip types so having `.ts` files with ESM
syntax even though we're previously transpiling them to CJS is a
problem.
Make run-one task terminal outputs in the TUI non-interactive by
default. Most tasks don't need interactivity, and it causes TUI to
ignore all its key bindings because it forwards them to the underlying
program. If interactivity is needed, users can press `i` to enable it.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently we detect if inputs are found in the build directory to
determine if they are considered dependent task output files. We can use
a simpler heuristic instead.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If an input is gitignored (and therefore not hashed by Nx), then we
consider it a dependant task output file. This gitignore classifier will
be a mirror of the class used within the Maven plugin. There will be
another PR to move this classifier into a shared kotlin project that can
be used between both projects.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Maven target dependencies are defined as simple strings that reference
other targets. Currently, parameters are not forwarded through these
dependencies when Maven goals are executed.
## Expected Behavior
Target dependencies in Maven should forward parameters (args) to their
dependency targets, enabling better parameter propagation through the
build pipeline.
## Changes Made
Modified `NxTargetFactory.kt` to transform simple string dependency
references into structured dependency objects with explicit parameter
forwarding:
- Install dependencies now forward parameters
- Phase dependencies now forward parameters
- Test dependencies now forward parameters
- CI target dependencies now forward parameters
This ensures that when a Maven goal executes, any parameters passed to
it are properly forwarded to all transitive target dependencies.
## Related Issue(s)
This change enables parameter passing through Maven target dependencies
via the new dependency object format with `"params": "forward"`.
When using Jest 30 with SWC, users are seeing an error where `__dirname`
is not defined for ESM modules. This is because the `.ts` extension is
type-stripped by Node 22.17/24+ via checking for
[`process.features.typescript`](https://github.com/jestjs/jest/blob/fe7f28c9d1941f5c2726831cd9d9e479b401610e/packages/jest-config/src/readConfigFileAndSetRootDir.ts#L46).
This means that instead of using the `commonjs` we set for `ts-node`,
normal Node resolution kicks in, and is now treating `jest.config.ts` as
ESM.
This PR fixes this issue by using an explicit `.cts` extension, which
forces CommonJS that we assume for Jest configs.
Note: For Jest 29 or earlier we need to keep `jest.config.ts` since the
`.cts` extension is not supported prior to Jest 30.
There's also a fix for an existing issue where using `module.exports` of
anything else from `@types/node` will error out if `tsconfig.json` has a
`types` field but does not include `node`. See:
https://www.loom.com/share/7ebe3c90a70e4ec7bfa53cbcccaaea7dFixes#32236
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
`@nx/vite` has a peerDep range of only `1 | 2 | 3` for `vitest`.
This will cause peer dep conflicts for using wishing to use Vitest 4.
## Expected Behavior
Add Vitest 4 to the peerDep range of `@nx/vite` to prevent conflicts.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
when trying to format with prettier while outside of the workspace (for
example in a `tmp` nx installation like is created during
`configure-ai-agents`), resolving prettier could fail even though it's
present in the actual workspace.
## Expected Behavior
resolving prettier works if it's available in either the proper
workspace or the tmp one by specifying `paths` in `require.resolve`
## Current Behavior
We currently support Next 14 and 15.
## Expected Behavior
Add support for Next 16, bringing support to 14, 15, 16.
Existing workspaces will continue to use the version they are on.
New workspaces will use Next 16.
Refer to Next 16 Migration Guide for migrating from Next 15 to 16
## Related Issue(s)
Fixes#33207
---------
Co-authored-by: Eric Büttner <eric.buettner@tuffz.com>
This pull request makes a minor update to the CI workflow configuration.
The change simplifies the `Start CI Run` step by removing the
`--fix-tasks="!*check-commit*"` option from the `npx nx-cloud@next
start-ci-run` command.
Updates @module-federation packages from 0.18.0 to 0.21.2 and
@module-federation/node from 2.7.11 to 2.7.21 to address Koa Open
Redirect vulnerability (CVE: GHSA-g8mr-fgfg-5qpc).
The vulnerability was in transitive dependencies:
@nx/react → @nx/module-federation → @module-federation/enhanced →
@module-federation/dts-plugin → koa@3.0.1-3.0.2
Changes:
- Updated package.json dependencies in @nx/module-federation and
@nx/rspack
- Updated version constants in Angular and React utils/versions.ts
- Added 22.2.0 migrations to all affected packages
Fixes#33285
This PR clarifies that Nx 22 removed SVGR support from Next.js and React
(Webpack/Rspack).
<img width="942" height="1185" alt="image"
src="https://github.com/user-attachments/assets/6ea8393f-b037-489f-804b-eb06d8d07e4c"
/>
Previously we had this option `svgr: true` but was configurable and
didn't align with current best practices like `import Logo from
'./logo.svg?react'`. We removed it from Nx 22, provided a migration, but
users will be confused by the docs.
Fixes DOC-326
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`createVitest` is looking at the full workspace every time. It should
only look at the directory with the config file.
## Expected Behavior
Pass the root as the projectRoot of the config file found.
## Current Behavior
The Nx TUI doesn't provide any visual feedback about task progress
outside of the terminal window itself. Users need to keep the terminal
visible to see task completion status.
## Expected Behavior
With this PR, the TUI now displays real-time task completion progress in
the terminal window chrome (tabs, title bars, dock icons) using the OSC
9;4 escape sequence. This provides at-a-glance progress feedback even
when the terminal is minimized or in the background.
## Related Issue(s)
N/A - This is a new feature enhancement
## Implementation Details
### What is OSC 9;4?
OSC 9;4 is a terminal escape sequence for displaying progress
indicators, originally from ConEmu and now supported by multiple modern
terminals.
### Key Changes
- Added `update_ghostty_progress()` method to calculate and display task
completion percentage
- Added `clear_ghostty_progress()` method to hide progress when done
- Integrated progress updates into task lifecycle (start, status update,
exit)
- Uses ST terminator (`\x1b\\`) for maximum terminal compatibility
- Writes to stderr to avoid conflicts with TUI rendering on stdout
### Supported Terminals
- **Ghostty** - Full support
- **Windows Terminal** (v1.6+) - Full support
- **VTE-based terminals** (GNOME Terminal, Ptyxis) - Full support
- **Other terminals** - Gracefully ignore sequences (no errors)
### Terminal Compatibility Note
The implementation uses the ST (String Terminator) escape sequence
rather than BEL, as this is preferred by Ghostty and required by
VTE-based terminals, while remaining compatible with Windows Terminal.
## Testing
Tested with:
- Building the native module successfully
- Rust formatting and linting passes
- Running nx commands with the TUI active
The progress indicator updates in real-time as tasks complete and clears
automatically when the TUI exits.
## Current Behavior
When processing scheduled batches, tasks are hashed one at a time even
though the hasher has a `hashTasks` method for batch hashing.
Results from a batch with 109 tasks.
```
hash batch: 8.297s
```
## Expected Behavior
Tasks without custom hashers should be batch-hashed using the hasher's
`hashTasks` method for better performance.
Results from a batch with 109 tasks.
```
hash batch: 991.725ms
```
## Related Issue(s)
This is a performance optimization for task hashing.
---
**Changes:**
- Added a new `hashTasks` function that intelligently separates tasks
with custom hashers from those without
- Tasks with custom hashers are hashed individually using `Promise.all`
- Tasks without custom hashers are batch-hashed using the hasher's
`hashTasks` method
- The function automatically filters out tasks that already have a hash
- Updated `processScheduledBatch` in task-orchestrator to use this new
function
## Current Behavior
Vitest's `createVitest` can be over-eager and include other projects in
the workspace when finding relevant test specifications.
This leads atomizer to look at relative paths outside the project root.
## Expected Behavior
Ensure that the plugin does not look at projects outside the project
root.
## Current Behavior
The Maven migration version was incorrectly set to `0.0.8-beta.0` in the
migrations.json file.
## Expected Behavior
The migration version should be set to `22.1.0-beta.4` to align with the
Nx release version.
## Related Issue(s)
Fixes the migration version discrepancy in the Maven plugin.
Embeds videos about self-healing CI into the corresponding feature doc
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
The Maven plugin is at version 0.0.7 with no automated migration path
for users to upgrade their pom.xml files.
## Expected Behavior
Users can upgrade to Maven plugin 0.0.8 and have their pom.xml files
automatically updated via the Nx migration system.
## Changes Made
- Updated Maven plugin version from 0.0.7 to 0.0.8 in:
- `packages/maven/package.json`
- `packages/maven/src/utils/versions.ts`
- `packages/maven/maven-plugin/pom.xml`
- Created `updateNxMavenPluginVersion()` utility function with:
- Proper XML parsing using `@xmldom/xmldom` DOM API
- Targeted updates only for `dev.nx.maven:nx-maven-plugin` elements
- Safe handling of all other version elements (dependencies, parent,
project, etc.)
- Comprehensive error handling
- Added migration `0-0-8/update-pom-xml-version.ts` that:
- Automatically runs when users upgrade to 0.0.8
- Updates root pom.xml files via the utility function
- Logs status of migrations performed
- Registered migration in `migrations.json`
- Added comprehensive unit tests (9 test cases):
- Updates only the nx-maven-plugin version
- Does not update other plugin versions
- Handles missing files gracefully
- Preserves XML formatting and structure
- Handles multiple plugin references
- Handles whitespace correctly
- Only updates plugins, not parent/project versions
- All tests passing (27/27)
## Test Plan
- [x] Unit tests pass (27 passing tests)
- [x] XML parsing correctly identifies and updates only
`dev.nx.maven:nx-maven-plugin`
- [x] Other version elements remain untouched
- [x] Migration registration validated
## Current Behavior:
Tui is working, but only able to be enabled on windows via env vars or
explicit command line config
## Expected Behavior:
Tui is default on
## Current Behavior
Maven and .NET use a bespoke script to handle skipping an optional
native target in case a system is not setup on a dev's machine.
.NET isn't in codeowners
## Expected Behavior
This pull request introduces improvements to the build and formatting
workflows for the `.NET` and Maven plugins, streamlining the execution
of native targets and updating code ownership assignments. The changes
focus on refactoring build scripts to use a unified runner, adding new
formatting capabilities for .NET projects, and updating the CODEOWNERS
file for clearer team responsibilities.
**Build and Format Workflow Improvements**
* Refactored the `.NET` analyzer build command in
`packages/dotnet/project.json` to use the new `run-native-target.js`
script, replacing the previous direct script invocation.
[[1]](diffhunk://#diff-036c1a7f2e7d98f5a3207441f2ff1cb25b5b5a03343672ce473f4ff0189a5946L25-R25)
[[2]](diffhunk://#diff-42d990ddcbf8d3585553503097ee8b8d1fff8cb6e25e0cd545a87e11d64c03a8L1-L7)
* Added new `format-native` and `_format-native` targets to
`packages/dotnet/project.json`, enabling verification and fixing of code
formatting for the .NET analyzer using `dotnet format`.
**Unified Native Target Runner**
* Introduced the `scripts/run-native-target.js` script to standardize
running native build and install targets, controlled by environment
variables for skipping builds.
**Maven Plugin Build Refactor**
* Updated the Maven plugin's install workflow in
`packages/maven/maven-plugin/project.json` to use the new native target
runner, and removed the obsolete `scripts/build-maven-analyzer.js`
script.
[[1]](diffhunk://#diff-2763fe8a7c2989643f53370a14a08c06616e85c29340fd5bcfa1a67d0deaee7aL11-R11)
[[2]](diffhunk://#diff-972edab06956ad35145cbc20b8e250e7067fbb288b1f99c92661c24f64d3e69dL1-L7)
**Ownership Updates**
* Updated the `CODEOWNERS` file to assign `.NET`-related directories to
`@FrozenPandaz` and `@AgentEnder`, clarifying team responsibilities.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We support Storybook 8 and 9
## Expected Behavior
Add support for Storybook 10, bringing Storybook support to 8, 9 and 10
## Related Issue(s)
Fixes#33141
## Current Behavior
Maven dependencies were not being resolved correctly from project roots,
which affected the dependency analysis in monorepos with Maven projects.
## Expected Behavior
Maven dependencies should be properly resolved from each project's root,
allowing Nx to correctly understand the project graph for Maven-based
projects.
## Changes Made
- Updated Maven plugin Kotlin code to properly resolve dependencies from
project roots
- Fixed devkit internal utilities to properly handle Maven dependency
resolution
- Updated TypeScript dependencies plugin to align with the new
resolution logic
## Files Changed
-
`packages/maven/maven-plugin/src/main/kotlin/dev/nx/maven/NxProjectAnalyzer.kt`
-
`packages/maven/maven-plugin/src/main/kotlin/dev/nx/maven/NxProjectAnalyzerMojo.kt`
- `packages/maven/src/plugins/dependencies.ts`
- `packages/dotnet/src/plugins/create-dependencies.ts`
- `packages/devkit/internal.ts`
- `packages/nx/src/devkit-internals.ts`
Fixes #XXXXX
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
CodeQL is not enabled for C#, but C# is in the nx repo
## Expected Behavior
CodeQL is enabled on C#
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR primes the cache for `@vitejs/plugin-vue`, similar to how we
already do for `esbuild`. When `vite.config.ts` is compiled into CJS,
then doing `require('@vitejs/plugin-vue')` may error with a race
condition if an `import` of the same module is in progress.
Fixes #NXC-3289
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
there are recommendations for using the CIPE fixing tools but they are
being removed
## Expected Behavior
removed tools should not be mentioned anymore.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Completed Maven documentation updates:
- [x] Add `nx show projects` command to display Maven projects after
initialization
- [x] Change example from `nx build` to `nx verify`
- [x] Simplify configuration section to use `plugins: ["@nx/maven"]`
with defaults
- [x] Update configuration description to accurately explain how targets
are created
## Summary
Successfully updated the Maven plugin documentation:
1. **Added `nx show projects` command** - Shows users how to list
discovered Maven projects after running `nx init`
2. **Changed example to `nx verify`** - Uses a more appropriate Maven
lifecycle phase that includes tests and verification
3. **Simplified configuration** - Updated the configuration section to
show the simpler string array syntax `plugins: ["@nx/maven"]`
4. **Corrected target creation description** - Updated the text to
accurately explain that `@nx/maven` automatically retrieves information
about projects from Maven and creates targets for each phase, goal, and
some additional targets for CI
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Expand this section
https://nx.dev/docs/technologies/java/maven/introduction#add-nx-to-a-maven-workspace
>
> With instructions to run the following
>
> nx show projects
>
> To see a list of Maven projects
>
> And change nx build Maven project to nx verify Maven project
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: FrozenPandaz <8104246+FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
devcontainer wasn't working reliably
## Expected Behavior
devcontainer should work reliably and reuse the configuration setup we
have for all these different tools that are needed
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
in a `.nx` installation, `require.resolve` won't find the `extends`
preset nx.json file because there are no root `node_modules`
## Expected Behavior
in a `.nx` installation, the nested `.nx/installation/node_modules` are
also used to try and resolve the preset.
This PR builds on the previous fix that ensured `eslint-config-next` was
correctly installed when using Next.js 15. #30258
Now, the logic has been further refined to dynamically determine the
installed Next.js version and install the corresponding
`eslint-config-next` version accordingly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
### Current Behavior
- `next@~15.1.4` is installed
- `eslint-config-next@14.2.16` is installed (incorrect for Next.js 15)
### Expected Behavior
If Next.js 15 is detected -> eslint-config-next@15.1.4 is installed
If Next.js 14 is detected -> eslint-config-next@14.2.16 is installed
### GitHub Repo
https://github.com/tuffz/new-nx-with-preset-nextjs
### Steps to Reproduce
1. Run the following command from the official documentation:
`npx create-nx-workspace@latest --preset=next`
3. Open `package.json` and check the installed dependencies
- `next@~15.1.4` is installed
- `eslint-config-next@14.2.16` is installed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30257 (& #30258)
guides couldn't be merged into one page w/ tabs and keep consistent
headers. so we're back to splitting them out. but all under a
source-control-integration parent route. so we don't need to do any
redirects and such as the index route will contain the links to each one
Removed duplicate information about installing Nx globally.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Duplicate line.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Removed duplicate line.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
the implementation is brittle and will fail if `contextFileName` is not
a string
## Expected Behavior
we should just not handle other things that folks are putting in there.
but not fail
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Dogfoods the Pnpm Catalogs feature in the Nx repo. This is the first
step to move all dependencies to Pnpm Catalogs definitions. More work
will be done incrementally later as we consolidate package versions
across the repository.
The initial list of dependencies moved to Pnpm Catalogs is:
- Angular packages
- React packages
- TypeScript packages
- Jest packages
- Rspack packages
- Some common utilities
## Current Behavior
We have tried to enable v8 serialization again... but it still seems
problematic. We don't want to revert again... so we evaluated some
options:
1. Disable by default
2. Disable for the single client method we think may be problematic
3. Fall back to JSON if v8 fails
4. Disable by default and still fall back if JSON fails
## Expected Behavior
We decided to update Nx such that the default behavior will be a
combination of #4, and #2. So by default we use JSON, if that
serialization fails we'll try v8... but there's an exception so the
method we know to be an issue will never try v8.
If you opt in to v8 by default, the combo changes to #3 + #2. So, by
default we'd use v8... if it fails try json... never try v8 for
processInBackground
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Docker plugin assumed `commitSha` was always non-null; when `null`,
`shortCommitSha.slice` caused a runtime error during target
interpolation.
## Expected Behavior
Plugin should succeed even if latest commit SHA cannot be resolved,
simply omitting shortCommitSha-based substitutions.
## Changes
- Added null guard: `shortCommitSha` now set to `commitSha ?
commitSha.slice(0,7) : null`.
- Added test "should not throw when commitSha is null" verifying node /
target creation succeeds.
- No breaking changes; only broadens safe input surface.
## Additional notes
Logic only executes when `commitSha` was previously null (error case);
normal paths unchanged. If consumers interpolate `{shortCommitSha}`,
they should handle possible null (unchanged if interpolation is already
optional).
This PR removes the need to check links during deploy and instead
enforces it in CI. This removes the need to build astro-docs when
building next.js app.
Reduces Vercel build from 10-11 mins to 6.5 mins.
<img width="1231" height="94" alt="image"
src="https://github.com/user-attachments/assets/ad5d4459-f917-4609-8c00-151f61dc29d6"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Update release notes entry tor 2025.07.3 - short link support for DTE
summary
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
You can see the issue here:
https://staging.nx.app/cipes/68fba96042d3126ee8ec0d19/analysis?runGroup=18785923031-1-linux
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes BAC-1387
This PR wraps one of the exports of `@nx/webpack` within a dynamic
function that ultimately requires `tsquery`. This causes an issue in
yarn v1 where `typescript` cannot be resolved thus causing an error when
`@nx/webpack` is imported.
The errors happens on every new workspace that starts from empty:
```
npx create-nx-workspace --preset=ts --pm=yarn
nx add @nx/web
nx g @nx/web:app apps/demo --bundler=webpack
```
Results in:
```
NX Cannot find module 'typescript'
Require stack:
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@phenomnomnominal/tsquery/dist/src/ast.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@phenomnomnominal/tsquery/dist/src/index.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/src/generators/convert-config-to-webpack-plugin/lib/extract-webpack-options.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/src/generators/convert-config-to-webpack-plugin/convert-config-to-webpack-plugin.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/index.js
- /private/tmp/web4/node_modules/@nx/devkit/src/utils/package-json.js
- /private/tmp/web4/node_modules/@nx/devkit/src/generators/to-js.js
- /private/tmp/web4/node_modules/@nx/devkit/public-api.js
- /private/tmp/web4/node_modules/@nx/devkit/index.js
- /private/tmp/web4/node_modules/@nx/web/src/generators/application/application.js
- /private/tmp/web4/node_modules/nx/src/config/schema-utils.js
- /private/tmp/web4/node_modules/nx/src/command-line/run/executor-utils.js
- /private/tmp/web4/node_modules/nx/src/project-graph/utils/project-configuration-utils.js
- /private/tmp/web4/node_modules/nx/src/utils/package-json.js
- /private/tmp/web4/node_modules/nx/bin/nx.js
Pass --verbose to see the stacktrace.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
Note: Other generators like React/Vue are fine since they have
dependency on tsquery, which installs typescript.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Summary
This PR includes three performance and correctness improvements:
1. **Split lockfile cache into separate node and dependency caches** -
Previously, both createNodes and createDependencies would read/write the
entire cache. Now each manages its own cache independently:
- `parsed-lock-file.nodes.json` for external nodes
- `parsed-lock-file.dependencies.json` for dependencies
2. **Prevent duplicate plugin resolution calls with promise cache** -
Added a promise cache to prevent concurrent duplicate calls to
`retrieveProjectConfigurationsWithoutPluginInference` when multiple
plugins fail to resolve simultaneously
3. **Normalize targets in separate loop after validation** - Moved
target normalization out of the validation loop to ensure proper
sequencing
## Test plan
- [ ] Tests pass (currently failing in CI - needs investigation)
- [ ] Build succeeds
- [ ] Lint passes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
When stringifying a pnpm v9 lockfile with workspace packages, Nx crashes
with: "Cannot destructure property 'specifiers' of 'projectSnapshot' as
it is undefined."
This occurs when:
- The lockfile has a root importer with `link:` references to workspace
packages
- But the lockfile is missing the workspace package importer entries
- The code tries to access `importers[importerPath]` which returns
undefined
- This undefined value gets added to the output lockfile
- During serialization, it crashes when trying to destructure undefined
Workspace packages with missing importers are now silently skipped
during lockfile serialization. This prevents the crash and allows Nx to
continue operating with out-of-sync lockfiles.
The fix adds a null check before adding workspace dependency importers
to the output lockfile.
Closes NXC-3244
This reverts commit 54db861b72.
## Current Behavior
Daemon messaging is all done over JSON messages
## Expected Behavior
Daemon messages use v8 serialization to avoid string length issues
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
With the Accept header in place during the retrieval of cache, the
client always expects an octet-stream from the server.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When the `Accept` header is missing, you might not get the correct data
depending on the underlying implementation of a self hosted cache
solution. We use AWS API Gateway which has a hard requirement for
`Accept` to determine how it should convert the data.
Fixes#33092
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We search for the gradle wrapper of a project by first looking at the
project root, then traversing upwards to the workspace root. If a
workspace has a separate gradle project defined that does not contain a
wrapper, then Nx will error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add a field to the gradle plugin that will allow users to specify a
custom gradle installation within their workspace. Nx will check for a
gradle wrapper that the specified location when executing gradle tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3147
## Current Behavior
When the Nx daemon returns a cached project graph from memory (without
recomputing), it does not write the graph to disk. This creates a
cache/daemon mismatch scenario:
1. Daemon has valid project graph in memory
2. A non-daemon process (fallback when daemon fails) encounters errors
and writes cache to disk with those errors
3. Parent process gets clean graph from daemon
4. Forked executor processes read from disk cache which contains errors
5. The errors cause `readProjectGraphCache()` to return `null` (when no
`minimumComputedAt` is provided)
6. This triggers a misleading "No cached ProjectGraph is available"
error instead of surfacing the actual errors
This issue manifests intermittently in CI environments, especially when:
- Daemon connection timeouts occur
- Multiple concurrent processes are running (DTE scenarios)
- File system latency is high
## Expected Behavior
The daemon should always write its current project graph to disk
whenever it returns it, ensuring the disk cache stays synchronized with
the daemon's in-memory cache. This prevents stale or errored caches from
persisting when the daemon has a valid graph.
## Related Issue(s)
Fixes NXC-3030
## Implementation Details
Modified `getCachedSerializedProjectGraphPromise()` in
`packages/nx/src/daemon/server/project-graph-incremental-recomputation.ts`
to write the project graph cache to disk after retrieving the result,
even when reusing the in-memory cached graph.
The fix ensures that:
- Any errored cache written by a non-daemon process gets overwritten by
the daemon's valid graph
- Forked executor processes always read a consistent cache that matches
what the daemon served to the parent process
- Real errors are properly surfaced instead of being hidden by a generic
"no cache available" message
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Local `tsconfig.app.json` is never picked up due to wrong resolved path.
## Expected Behavior
Local `tsconfig.app.json` is picked up and the path aliases are added to
Vite.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33231
Removed "Explain with AI" feature documentation and redirected all URLs
to Self-Healing CI. Added sunset notice to blog posts, updated
configuration files, and preserved historical content for reference.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When `Dockerfile` is at project root, we attempt to append `--tag .`
which is invalid for docker.
## Expected Behavior
Ensure that if `Dockerfile` is at project root, we use `workspaceRoot`
to determine the `--tag`.
Note, this tag is primarily used as a deterministic method for Nx to
find the correct docker image when calling `docker run` and `nx release`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When using `--output-style=stream-without-prefixes` nx incorrectly shows
the TUI instead of streaming
## Expected Behavior
When using `--output-style=stream-without-prefixes`, nx should stream
with no prefixes just like it does with `--output-style=stream`
## Related Issue(s)
Fixes#32535
Co-authored-by: Hugo Burton <hugo.burton@westpac.com.au>
## Current Behavior
`node_modules` are being copied during copy-local-native
## Expected Behavior
`node_modules` are not being copied during `copy-local-native`
## Current Behavior
Maven is installed as a global dependency for all e2e targets
(`e2e-local`, `e2e-ci--**/**`, and `e2e-macos-ci--**/*`), even when only
the Maven e2e tests need it.
## Expected Behavior
Maven should only be installed as a dependency for the Maven e2e tests
that actually use it, avoiding unnecessary installations for other e2e
test projects.
## Changes Made
- Removed `nx-maven-plugin:install` from the global e2e target defaults
in `nx.json`
- Added `nx-maven-plugin:install` as a specific dependency to the Maven
e2e project targets in `e2e/maven/project.json`
This optimization ensures Maven is only installed when needed, reducing
unnecessary build overhead for other e2e tests.
## Current Behavior
`nx init` does not search for `Dockerfile` patterns to suggest adding
the `@nx/docker` plugin.
## Expected Behavior
`nx init` finds and suggests `@nx/docker` plugin
Fixes NXC-3319
Fixes the order of the arguments in invocations to
`resolveCatalogReference` when resolving catalog references from the
filesystem (not using a `Tree`).
## Current Behavior
In some scenarios, when some processes terminate unexpectedly (e.g.
crashed due to OOM), the task runner will incorrectly determine their
exit code to be 0. This results in Nx storing the task results as a
success, which can cause cache hits with false positive successes.
## Expected Behavior
When processes terminate unexpectedly (e.g. crashed due to OOM), the
task runner should correctly determine their exit code from the signal,
and it should never be 0. The stored task result should not be marked as
successful.
## Related Issue(s)
Fixes#29204
## Current Behavior
When `@nx/docker` is registered via string only (`nxJson.plugins:
["@nx/docker"]`, project graph creation fails because we try to access
`options.buildTarget`.
## Expected Behavior
Handle undefined `options` gracefully, and still create the default
target.
## Related Issue(s)
Fixes NXC-3320
## Current Behavior
Dependencies are outdated and Rust tooling needs to be updated.
## Expected Behavior
Rust dependencies are updated to their latest compatible versions.
## Changes
- Updated Rust dependencies
- Rebased with latest `origin/master`
- Updated pnpm lock file
## Related Issue(s)
None
## Current Behavior
No docs describing migration path
## Expected Behavior
Docs describing migration path
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
.NET sometimes bails on a failed mutex in e2e
## Expected Behavior
it runs only 1 at a time
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
It was removed when the scripts were cleaned up during next.js->astro
migration. Adding this back since blog posts need to be synced first
before serving.
## Current Behavior
When project configuration errors occur due to invalid token usage
(e.g., `{workspaceRoot}` in the middle of a path), error messages don't
provide sufficient context about where the error occurred.
## Expected Behavior
Error messages should include:
- For project-level errors: the project and target context (e.g.,
"libs/my-app:build")
- For nx.json targetDefaults errors: the nx.json context (e.g.,
"nx.json[targetDefaults]:test")
This makes it much easier for users to locate and fix the configuration
issue.
## Changes
This PR adds comprehensive integration tests to verify the improved
error messaging:
- Test for project-level invalid token usage showing project:target
context
- Test for nx.json targetDefaults invalid token usage showing nx.json
context
Tests use mock plugins to simulate realistic scenarios where invalid
`{workspaceRoot}` token usage would occur, ensuring the error messages
contain the expected context information.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
by default code blocks will get text as the lang if not set or the lang
is not supported
but we should be so I don't have to look at the warnings in the terminal
output 😅
also remove the frame=none since the team preferred to have the terminal
frame
Example of invalid codeblock messages

Also added conformance rule for validating image pages for public and
src/assets/ directory
examples of incorrect absolute path ref from "public" folder and
incorrect absolute path:

fixes DOC-242
fixes DOC-259
## Current Behavior
Currently, when configuring the `@nx/docker` plugin, we only set the
target name and a basic command.
The intention was that targetDefaults might be able to be used to
configure additional args, but this falls short in some places.
## Expected Behavior
Allow setting additional args when configuring the `@nx/docker` plugin
that supports interpolated values, similar to `versionSchemes`.
This will allow additional flexibility when setting up the docker build
command such as:
```json
{
"plugin": "@nx/docker",
"options": {
"buildTarget": {
"name": "docker:build",
"args": ["-t {projectName}"]
}
}
}
```
This means that we can use `nx run-many -t docker:build` and it will
successfully add the name of the projects into the tag.
This is one example, other examples include being able to set individual
Docker Layer Caching where each registry needs a unique name.
## Current Behavior
The Maven plugin currently checks if a path is absolute by using
`outputFile.startsWith("/")`. This only works on Unix-like systems and
fails on Windows where absolute paths start with a drive letter (e.g.,
`C:\`).
## Expected Behavior
The Maven plugin should correctly identify absolute paths on all
platforms (Windows, macOS, Linux) using the platform-agnostic
`File.isAbsolute()` method.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A - This is a proactive bug fix for cross-platform compatibility.
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When Nx Cloud is used, but the Nx Cloud client is unavailable, an error
is thrown and commands are not run.
## Expected Behavior
When Nx Cloud is used, but the client is unavailable, continue execution
without Nx Cloud.
## Related Issue(s)
Fixes NXC-3175
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Tests either cause agents to run out of memory:
<img width="956" height="358" alt="image"
src="https://github.com/user-attachments/assets/e55bae05-7757-46e7-88ed-158f72411195"
/>
<img width="1278" height="336" alt="image"
src="https://github.com/user-attachments/assets/40dc8dd6-4409-461e-b75a-5c1c36551da5"
/>
Or setup tasks fail due to network flakiness:
https://staging.nx.app/runs/J1qWVZA7K5
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A fully affected, cache busted task graph should run without any
failures.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request updates the documentation for configuring .NET target
types in the `nx.json` file to provide clearer instructions and
examples. The changes make it easier to understand how to customize
target names and configurations for the `@nx/dotnet` plugin.
Improvements to configuration documentation:
* Added a section describing how each target type can be configured,
including renaming targets, customizing options, disabling targets, and
specifying additional properties.
* Updated the example configuration to show how to rename targets (e.g.,
"build" to "compile"), add configurations (e.g., production
optimization), set dependencies between targets, and disable targets
(e.g., disabling "pack").
* Clarified that targets are created with the configuration specified in
the `nx.json` `plugins` array, rather than just with custom names.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The first-class programmatic API of nx release is only documented within
the manage releases introduction and is incomplete (`ReleaseClient` is
not covered at all).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The programmatic API has its own in depth guide, which is then
cross-referenced from the manage releases guide. `ReleaseClient` is now
documented including its new Nx 22 features.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`run`/`watch` are not mentioned in docs
## Expected Behavior
`run`/`watch` docs are accurate
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Maven plugin targets are only created for goals explicitly bound to
executions in the POM. Goals defined in a plugin but not bound to any
execution are not available as Nx targets.
## Expected Behavior
All available Maven goals should be accessible as Nx targets, including:
- Goals bound to executions (existing behavior)
- Unbound goals defined in the plugin (new behavior)
## Changes Made
1. **Added unbound goal support**: The `NxTargetFactory` now creates
targets for goals defined in a plugin but not bound to any execution.
These targets are created with the format `goalPrefix:goalName` without
an execution ID.
2. **Added continuous build tracking**:
- Added `continuous` property to `NxTarget` data class to track whether
a goal supports continuous builds
- Updated `MojoAnalyzer` to detect continuous goals from the cache
configuration
- All targets now properly propagate continuous mode information
3. **Code improvements**:
- Improved formatting and indentation for consistency
- Made `execution` parameter optional in `createSimpleGoalTarget` to
support both bound and unbound goals
- Updated command generation to work with or without execution IDs
## Related Issue(s)
This change enables better Maven goal discovery and execution in Nx
monorepos.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When an invalid output exists we report:
```
NX The following outputs are invalid:
- foo.txt
Run `nx repair` to fix this.
```
Without specifying the reason, we tell to run `nx repair`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
More feedback provided to the user as to the error with their output:
```
NX The following outputs are invalid:
- foo.txt
** Reason: Outputs must start with either "{workspaceRoot}/" or "{projectRoot}/".
Run `nx repair` to fix this.
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes some pages that don't use the proper markdoc syntax for
line lighting in code blocks. The `{% meta %}` tag is needed and it is
missing in some places.
Closes DOC-2790
## Current Behavior
When the daemon is disabled due to an error, the reason isn't captured,
making it harder to debug why the daemon was disabled.
## Expected Behavior
The error message/reason is now stored when marking the daemon as
disabled, allowing better visibility into what caused the daemon to be
disabled.
## Related Issue(s)
Node tool executions (non-watch) were exiting before completing. This
change ensures they complete before exit.
closes#32385
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Node tool executions are not completing since #32356
## Expected Behavior
Node tool executions complete before exit
## Related Issue(s)
#32385Fixes#32385
## Current Behavior
When errors happen in earlier stages of compilation process, such as
processing global styles, these errors are not printed and the rspack
build process hangs at the Sealing phase.
## Expected Behavior
Ensure that errors that have occurred that would cause the process to
hang are printed and process exits correctly.
Part of this happens because the usual printing of errors happens in the
`afterDone` hook, which is never reached when the above occurs.
## Related Issue(s)
Fixes NXC-3268
## Current Behavior
Readme template files are being published to npm with inconsistent
naming conventions.
## Expected Behavior
Readme template files should be excluded from npm publication and
consistently named as `readme-template.md`.
## Changes
- Renamed all readme template files to `readme-template.md` across
angular-rspack-compiler, angular-rspack, dotnet, and maven packages
- Updated .npmignore files to exclude readme-template.md from npm
publication
- Updated package.json build commands to reference the new
readme-template.md paths
- Removed `!README.md__tpl__` exceptions from package.json files array
entries
add new page for the createNodes api compat
add callouts to extending project graph and tooling plugin page
fixes DOC-255
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Fixes the pnpm caching setup for the `main-macos` job. It can currently
fail when the pnpm cache directory doesn't exist. We need to handle the
pnpm cache conditionally and separately from the node setup.
…as testing projects<!-- Please make sure you have read the submission
guidelines before posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
- Microsoft.Testing.Platform projects are not detected as having a test
target
- `serve` does not have an equivalent
## Expected Behavior
- Test projects are properly detected
- `serve` has been split into 2 targets:
- `watch`
- `run`
The split of `serve` mirrors the`dotnet` cli in the same way that we
mirrored `vite` when adding `preview` and `dev` targets when we moved
with project crystal. `watch` can be used for a variety of cases, but
provides hot reload + run a 'la `dev` / `serve`. `run` is more of a fire
and forget target that starts up the app. Both targets would only really
be used in local dev.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…as testing projects
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
<img width="784" height="196" alt="image"
src="https://github.com/user-attachments/assets/45702b02-a97f-4d75-a67b-76eacdfb56ff"
/>
## Current Behavior
The dependency management documentation does not mention PNPM catalogs
as an option for maintaining single version policy.
## Expected Behavior
Documentation includes information about PNPM catalogs, explaining how
they can be used to maintain a single version policy when using PNPM as
the package manager. This helps if user searches for PNPM catalogs.
## Related Issue(s)
Fixes DOC-302
Co-authored-by: Claude <noreply@anthropic.com>
This PR adds a bit more content to the Java intro page so users can see
how to install Nx, add the plugins, etc. Links to the Gradle and Maven
intro pages, and also the Gradle tutorial.
Fixes DOC-301
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
- add docker to sidebar
- sidebar only shows when there are non-hidden
executor/generator/migration impls to prevent linking to 404 pages
fixes DOC-299
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR fixes a bad redirect where Java intro page went to Angular
Rspack. Also update original Gradle API redirect to go to the Gradle
page rather than the generic Java one.
Closes DOC-298
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
The nxViteTsPaths plugin currently always copys the package.json file at
the end of the build and does not check if the file was generated from
the build process. This adds logic to check if the package.json file
already exists in the dist path before copying to prevent overwriting
generated files.
Closes#30312
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
nxViteTsPaths always copies package.json at end of build.
## Expected Behavior
nxViteTsPaths only copies package.json at end of build if package.json
not generated during build.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30312
This reverts commit d37d8252e4.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Java landing page at nx.dev/java only mentions Gradle support and
indicates that Maven support is coming soon.
## Expected Behavior
The Java landing page should reflect that Maven is now available
alongside Gradle.
https://nx-dev-git-mvn-follow-nrwl.vercel.app/java
## Related Issue(s)
Updates the documentation to reflect the Maven plugin introduced in
#32947
---
**Changes:**
- Updated hero section to state "Nx supports both Gradle and Maven"
- Modified getting started instructions to mention both `@nx/gradle` and
`@nx/maven`
- Updated features description to include Maven builds
- Combined Gradle and Maven documentation links into a single "Learn
More" section with buttons for both
- Updated call-to-action links to point to
`/docs/technologies/java/{gradle,maven}/introduction`
## Summary
Update Maven plugin version from 0.0.6-SNAPSHOT to 0.0.6 for release.
## Changes
- Root pom.xml (nx-parent)
- packages/maven/maven-plugin/pom.xml
- packages/maven/src/utils/versions.ts
## Test plan
- Maven plugin builds correctly with the new version
- No breaking changes to Maven integration
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `main-macos` in the CI verification workflow runs some setup only
needed by the e2e tests unconditionally. This means that even when the
tests are not run, up to ~9 minutes can be spent setting up things that
will not be used.
## Expected Behavior
The `main-macos` in the CI verification workflow should only run the
minimal steps needed to verify whether the tests will be run. If the
tests are to be run, the job should proceed with the remaining required
setup steps; otherwise, it should skip them.
The job will now check whether tests will be run as early as possible
and gate the rest of the steps based on the result.
## Example similar runs
Before: 10m 48s
(https://github.com/nrwl/nx/actions/runs/18625394891/job/53102778452)
After: 1m 3s
(https://github.com/nrwl/nx/actions/runs/18654449747/job/53189013526)
## Current Behavior
When independent versioning with conventional commits, and only one
project in a release group needs bumped, but it depends on another
project via local dependency protocols such as `file://` or `workspace:`
protocol, the local protocol dependency is not replaced.
## Expected Behavior
local protocol is replaced with the current version of the dependency.
## Related Issue(s)
Fixes#30995
## Current Behavior
When there are flaky tasks in a local run for a workspace that has Nx
Cloud enabled, a help message is displayed, advising users to use Nx
Cloud and pointing them to documentation on how to do so. Given that the
workspace is already using Nx Cloud, the message is redundant.
## Expected Behavior
When there are flaky tasks in a local run for a workspace that has Nx
Cloud enabled, no help message should be shown advising users to use Nx
Cloud and pointing them to documentation on how to do so. If the
workspace doesn't have Nx Cloud set up, the message should still be
shown.
- **fix(angular): prevent outputting inline source maps when building an
Angular package**
- **fix(angular): set ng-packagr tsconfig options based on ng-packagr
version**
## Current Behavior
TsConfig options are being set based on older versions of ng-packagr.
These values changed in Angular 20.
## Expected Behavior
Ensure TsConfig options are set based on the version of `ng-packagr`
installed.
## Related Issue(s)
Fixes#33081
Kudos to @daiscog for the initial work on this 🚀
---------
Co-authored-by: David Scourfield <daiscog@users.noreply.github.com>
## Current Behavior
The `@nx/angular` plugin doesn't support generating any project or
artifact when the workspace is using TypeScript project references
because the Angular framework doesn't support it. The message logged to
the users is very generic and slightly misleading. It's not clear enough
and doesn't provide relevant information to allow users to understand
the exact limitation.
## Expected Behavior
The generators from the `@nx/angular` plugin should log a clear error
message with information pointing to the specific issue in the Angular
framework preventing the setup from working for Angular projects.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The AI config is out of date.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The AI config is up to date
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There is no first-party Maven support for Nx
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Maven Support is ready for usage.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When configuring `resolve` config for the `rspack` config with Angular
Rspack, we only consider `node_modules` local to the application.
## Expected Behavior
Ensure workspace root node_modules are also considered and added to the
`resolve` config.
## Related Issue(s)
Closes NXC-3267
Fixes#33026
This PR creates a global spinner handler and adds the runtime
information to the `convert-to-inferred` migration process.
The global spinner ensures a single instance of the `ora` spinner. The
ora cannot run several instances in parallel, so running multiple
instances causes flickering due to message deletion.
The `covert-to-inferred` plugin migration will now show the loading
spinner and progress indicator specifying how many projects have been
converted.
Additional changes:
- DelayedSpinner will not show if there is another (parent) spinner
already running.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Developers may have to install several languages manually to work in the
Nx repo.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Developers can use https://mise.jdx.dev/ to automatically install the
versions of languages necessary to work in the nx repo
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Fix a few failing e2e nightly tests due to npm peer dep conflicts.
Reduced nightly run with the fixed test suites:
https://github.com/nrwl/nx/actions/runs/18651446735. Most of them still
fail, but with existing failures unrelated to npm peer deps issues.
These are not part of the Golden nightly tests yet.
## Current Behavior
Angular Rspack outputs to CJS for Module Federation. It also has
potential issues to cause infinite live reload loops.
## Expected Behavior
Angular Rspack with Module Federation should work as expected
This PR also adds:
- example of Module Federation with Angular Rspack in
`examples/angular-rspack/module-federation`
## Current Behavior
@nx-dotnet/core is recommended plugin for .NET
## Expected Behavior
@nx/dotnet is new .NET plugin
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Vijay Ramakrishnan <vramak@microsoft.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When adding a `project.json` file to configure certain aspects of an
existing Nx project, that project's name will be changed. We had to fix
this for package-json based projects a while back, and as we expand
polyglot its coming up again.
## Expected Behavior
The "default name" behavior stamped into the project.json plugin doesn't
trample existing names. To do this, it had to be moved out of the
project.json plugin and into the validate + normalize flow
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Some migrations used by `nx repair` are missing
## Expected Behavior
Migrations used by `nx repair` are only removed when deemed applicable.
This reverts a portion of commit
a637f9eef9.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes an issue where due to the removal or `--legacy-peer-deps`
for NPM, you can no longer install prerelease versions of Nx. This also
means `npx create-nx-workspace@next` cannot be used with NPM.
For example, if you have this `package.json`:
```json
{
"dependencies": {
"nx": "22.0.0-beta.4",
"@nx/devkit": "22.0.0-beta.4"
},
"license": "MIT"
}
```
And tried `npm install`, it will error out with:
```
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: undefined@undefined
npm error Found: nx@22.0.0-beta.1
npm error node_modules/nx
npm error nx@"22.0.0-beta.1" from the root project
npm error
npm error Could not resolve dependency:
npm error peer nx@">= 21 <= 23" from @nx/devkit@22.0.0-beta.1
npm error node_modules/@nx/devkit
npm error @nx/devkit@"22.0.0-beta.1" from the root project
```
By allowing prereleases via `^22.0.0-0` NPM can work again.
Note: pnpm and yarn are fine.
Formats the `pnpm-workspace.yaml` when catalog definitions are updated
after running `nx migrate`. Like the rest of the Catalog feature, it's
agnostic to the package manager, allowing for an easier addition of
support for future package managers.
The TypeScript packages tutorial shows how to import shared local
libraries but doesn't mention that users need to add dependencies to
package.json and run npm install.
This PR instructs users to link packages properly. Also fixes line
highlighting.
<img width="787" height="718" alt="image"
src="https://github.com/user-attachments/assets/03ec8cca-eab0-4514-8c07-c7d4d316a606"
/>
Installs the correct dependencies after converting to the ESLint Flat
configuration. This was highlighted after removing the npm
`--legacy-peer-deps` flag from default usage in Nx.
Additionally, it fixes nightly e2e failures:
- `e2e-esbuild`
- `e2e-eslint`
- `e2e-gradle`
- `e2e-js`
- `e2e-web`
- `e2e-webpack`
Nightly run where all pass:
https://github.com/nrwl/nx/actions/runs/18592750415
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Terminal output is all logged in one chunk, resulting in a somewhat
jarring experience for lots of output that can cause issues in the
extreme cases.
Task cache status is missing from the run-many outputs
Outputs are sometimes missing
## Expected Behavior
The above are fixed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
- We currently install `@vitejs/plugin-vue` verion `^5` which only
supports `Vite 5 | 6`. This causes peerDep conflicts with `Vite 7`.
- Vue and Nuxt always install v7 version of TypeScript ESLint packages.
This causes peer dep conflicts when ESLint v9 is installed.
## Expected Behavior
- Migrate to `@vitejs/plugin-vue` version `^6` which supports `Vite 5 |
6 | 7`.
- Vue and Nuxt should install a version of the TypeScript ESLint
packages that works for the installed ESLint version.
Nightly run where the previously failing `e2e-vue` tests pass with these
changes:
https://github.com/nrwl/nx/actions/runs/18591984947/job/53009089023
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
This PR removes `nx documentation` and old docs pages from the next.js
app. This improves CI times since we no longer need to check `nx
documentation`, and the next.js app is faster to build.
## Changes
- `.github/workflows/ci.yml` no longer runs `nx documentation`
- Remove `documentation` target from root `project.json` and
corresponding scripts in `scripts/documentation/generators`
- Remove old docs pages from next.js app (e.g.
`nx-dev/nx-dev/pages/[...segments].tsx`)
- Remove manifest JSON files for old docs
- Remove old `og:image` generator for docs (blog, and other pages handle
it differently, this was just for old docs).
- Update bad links in `docs/blog` and `docs/changelog` since we no
longer match them to their manifest JSON files -- the redirects were
already working so just pointed to the new Astro URL
## Notes
- There were some missing dependencies like `ai` for `nx-dev/nx-dev`
that worked previously due to hoisting, but was failing build in this PR
I fixed those.
---------
Co-authored-by: Claude <noreply@anthropic.com>
- **docs(nx-dev): show all blogs in the list below highlighted**
- **docs(nx-dev): adjust ai label on blog posts**
- **docs(nx-dev): adjust how labels are rendered on blog list**
- **docs(nx-dev): swap podcasts tag to ai tag**
Preview:
https://nx-dev-git-nxdev-update-blog-list-page-nrwl.vercel.app/blog
## Current Behavior
When a task is selected and its outputs are displayed in the terminal
pane, the TUI always tracks a task by name regardless of its status.
## Expected Behavior
- When a task is selected, its outputs are displayed in the terminal
pane, and the terminal pane is focused, we track the selected task by
name.
- When a task is in progress, the TUI should track it by name while in
progress.
- When it finishes, it should switch to track another in-progress task
at the same index or in a close index if there is none in progress at
the same index.
- If it's the last task that finished, keep tracking it by name.
- When a task is pending or finished:
- When it's selected and its outputs are displayed in the terminal pane,
the TUI should track it by name.
- When it's selected and its outputs are not displayed in the terminal
pane, the TUI should track the index.
This allows the relevant in-progress section to be visible in more
scenarios than before. The TUI wouldn't blindly follow all tasks by
name.
Additionally, this PR updates the sorting of in-progress tasks to
prioritize start time first, followed by alphabetical order. This
stabilizes the section more (reduces extra movement due to alphabetical
sorting) and aligns with a similar sorting done for finished tasks
(based on the end time).
## Summary
Improved database initialization with better error handling, automatic
recovery from stale files, and cache preservation during error recovery.
## Changes Made
### 1. Iterative Retry Logic with Explicit State
Converted initialization from recursive calls to an iterative loop with
a state flag (`cleaned_up_stale_files`) that limits retries to 2
attempts. This makes retry conditions explicit and self-documenting
while preventing potential stack overflow.
### 2. Complete Auxiliary File Cleanup
Now removes all SQLite database files during cleanup (`.db`, `.db-wal`,
`.db-shm`) instead of just the main `.db` file. This prevents stale
Write-Ahead Logging auxiliary files from causing initialization failures
after version upgrades.
### 3. Smart Compatible Database Handling
Compatible databases (matching version) are now reconfigured based on
their current journal mode:
- **DELETE mode**: Attempts opportunistic upgrade to WAL for better
performance, cleans up any orphaned WAL files from previous runs
- **WAL mode**: Verifies WAL still works; if it fails, removes only
auxiliary files (preserving cache), retries, and falls back to DELETE
mode if still failing
- **Unknown/query failed**: Full reconfiguration with complete cleanup
on failure
This preserves cached build outputs when possible while recovering from
stale file issues automatically.
### 4. WSL1 Proactive Detection
Detects WSL1 environments by reading `/proc/version` and automatically
uses DELETE journal mode instead of attempting WAL (which WSL1 doesn't
support), preventing initialization failures.
### 5. Enhanced Error Messages
Replaced generic error messages with context-specific, platform-agnostic
guidance:
- Permission errors: Explains how to check file/directory permissions
and ownership without platform-specific commands
- Disk full: Suggests freeing space or moving workspace
- Missing directories: Explains unexpected condition with
troubleshooting steps
- All errors: Include debug instructions (`NX_NATIVE_LOGGING=trace`) and
reporting link
Error messages work consistently across Windows, macOS, and Linux
without suggesting commands that may not be available on the user's
platform.
### 6. Code Quality Improvements
Extracted helper functions to reduce duplication:
- `query_journal_mode()` - Query database's current journal mode
- `set_busy_handler()` - Configure connection-level busy handler
- `remove_wal_files()` - Remove only WAL auxiliary files
- `remove_all_database_files()` - Complete database cleanup
- `create_io_error()` / `create_db_error()` - Generate helpful error
messages
## Problems Solved
### Stale WAL Files After Version Upgrades
Leftover `.db-wal` and `.db-shm` files from previous versions no longer
cause initialization to fail. These files are now cleaned up
automatically during initialization.
### Cache Loss on Recoverable Errors
When WAL mode issues occur on otherwise healthy databases, only
auxiliary files are removed, preserving the main database and all cached
build outputs. Full wipes only happen for genuine corruption or version
mismatches.
### WSL1 Compatibility
WSL1 environments now work without initialization failures by
proactively detecting the environment and using DELETE mode instead of
attempting WAL.
### Performance Optimization
Databases in DELETE mode automatically attempt upgrading to WAL when the
environment supports it (e.g., after moving workspace from network drive
to local disk), providing better performance without manual
intervention.
### Poor Debugging Experience
Error messages now provide specific, actionable guidance based on the
error type, helping users resolve issues without needing to ask for
help.
## Impact
- ✅ Users no longer need manual `nx reset` for stale file issues
- ✅ Cache and build outputs preserved during error recovery
- ✅ WSL1 works out of the box
- ✅ Automatic performance improvements when environment changes
- ✅ Better error messages reduce support burden
## Related Issue(s)
Fixes#28640Fixes#30856Fixes#32894
## Current Behavior
`@nx/remix` depends on `@nx/react` which depends on `@nx/vite`.
`@nx/vite` has a `peerDependency` on `vite: 5 || 6 || 7`
This direct dependency chain causes an issue wherein vite 7 is installed
and causes a conflicting peer dependency between `@remix-run: 2`
## Expected Behavior
Remix should use `Vite 5 | 6`. Break the chain between `@nx/react` and
`@nx/vite` causing `Vite 7` to be installed.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Replaced legacy custom `PlayButton` with the `VideoPlayer` component for
a consistent video playback experience. Applied changes across multiple
components and integrations.
This PR adds 404 and header custom events back for docs. These were
previously in the Next.js docs pages, but were missing when we migrated
to Astro.
The `sendCustomEvent` and `sendPageEvent` functions did not account for
the way that Astro is configured via `window.__CONFIG` object, so this
PR fixes those too.
## Screenshots
I ran these in preview mode with the site built with
`COOKIEBOT_DISABlED=true`.
Custom page view on 404:
<img width="2672" height="1527" alt="Screenshot 2025-10-15 at 3 10
05 PM"
src="https://github.com/user-attachments/assets/5bbe30fc-56cb-4427-b138-56edcf3bbc71"
/>
Header docs CTA event:
<img width="2672" height="1527" alt="Screenshot 2025-10-15 at 3 13
02 PM"
src="https://github.com/user-attachments/assets/246cb99d-0a30-4d94-a4a3-8f8659062f23"
/>
Header `Try Cloud` CTA event:
<img width="2672" height="1527" alt="Screenshot 2025-10-15 at 3 10
10 PM"
src="https://github.com/user-attachments/assets/addd2645-cf3e-4c83-ae39-9f00a434a21d"
/>
## Current Behavior
Using TS Soln Workspaces and/or Packaage Manager Workspaces, handling of
certain workflows and scenarios is not correct.
Detecting and Sharing Workspace Libraries relies entirely on TS Path
Aliases existing in the base TSConfig file.
All guidance also points towards adding Workspace Libraries as
dependencies or devDependencies within the consuming application's
package.json file.
This also does not allow correct configuration of sharing.
Meanwhile, TS Path Aliases are added for remote applications such that
TS can find them in consuming applications, while also being able to
provide Typing Support.
However, this has an increased build-time cost for TS compilation as it
will follow the path in source.
## Expected Behavior
Allow attaching Workspace Libraries as deps in the package.json of host
and remote applications.
Configure packages added in such a manner correctly for share scope in
Module Federation.
Attach Remote applications to Host applications via devDependencies in
package.json.
Configure the `exports` and `main, types` properties in the remote
application's package.json to point to the `src/remote-entry.ts` file
such that node resolution can correctly follow the paths.
Bundler will continue to strip this out of compilation and replace with
Module Federation Module Loading code.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When rendering changelogs for releases, breaking changes with multi-line
explanations
are not formatted correctly:
1. Only the first line of a breaking change explanation is captured and
rendered
2. PR references (like `#33014`) are missing from breaking change
entries, making it
difficult to trace back to the original PR
3. Multi-paragraph breaking changes lose their formatting and structure
For example, a breaking change with this format:
BREAKING CHANGE: The --legacy-peer-deps behavior is no longer forced.
If you need it, configure your package manager to enforce it.
Would only render the first line, and without the PR reference.
## Expected Behavior
The changelog renderer should:
1. Capture and render all lines of a breaking change explanation, not
just the first
line
2. Include PR/commit references in the breaking change section (e.g.,
`([#33014](url))`)
3. Properly indent multi-line and multi-paragraph breaking changes for
better
readability
4. Maintain consistent formatting between the feature/fix entry and its
corresponding
breaking change entry
Example of correct output:
```markdown
### ⚠️ Breaking Changes
- **misc:** The `--legacy-peer-deps` behavior is no longer forced.
([#33014](url))
If you need it, configure your package manager to enforce it.
```
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`NX_VERBOSE_LOGGING` turns on/off the debug logs for the gradle plugin
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`NX_GRADLE_VERBOSE_LOGGING` turns on/off the debug logs for the gradle
plugin
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Running `nx run nx:test --help` and `nx test nx --help` behave
differently
## Expected Behavior
They are equivalent
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The tui is enabled even for a single task, and it currently doesn't
bring a lot of value for those single-task use cases
## Expected Behavior
The tui is disabled for single task runs.
## Current Behavior
The bottom corner indicator of the in-progress section in the TUI is not
displayed when there are more tasks in progress than the maximum
parallel capacity (this can occur when there are continuous tasks).
## Expected Behavior
The bottom corner indicator of the in-progress section in the TUI should
always be displayed at the end of the running tasks.
## Current Behavior
The `--legacy-peer-deps` behavior is forced by Nx to try to account for
potential incompatible peer deps users might have.
## Expected Behavior
Nx shouldn't force the `--legacy-peer-deps` behavior. Users can easily
set this up by configuring the package manager they use.
## Related Issue(s)
Fixes#22066Fixes#29537
BREAKING CHANGE: The `--legacy-peer-deps` behavior is no longer forced.
If you need it, configure your package manager to enforce it.
technically the fix to plugin stats now showing up was expired GH token.
But refactored the plugin stats fetching to skip locally unless
NX_DOCS_PLUGIN_STATS env var is set to help speed up local serves/builds
since 99% of the time we're not concerned with the plugin-registry page.
along with trying to centralized the logic between 1st/3rd party plugins
since it was a little confusing from my initial impl.
## Current Behavior
The `remoteUrlDefinitions` variable in
`packages/react/mf/dynamic-federation.ts` is
initialized as an empty object (`{}`), which causes:
1. The `resolveRemoteUrl` callback is never called because
`remoteUrlDefinitions` is
always truthy
2. When `loadRemoteModule` is called before `setRemoteDefinitions`,
users get a cryptic
error "Cannot read properties of undefined (reading 'endsWith')" instead
of the
helpful error message
## Expected Behavior
- `resolveRemoteUrl` should be called when provided and
`remoteUrlDefinitions` hasn't
been set
- The helpful error message should be shown when `loadRemoteModule` is
called before
setup
## Changes Made
Applied the same fix from PR #27927 (for Angular) to the React
implementation:
- Changed `remoteUrlDefinitions` initialization to be `undefined` by
default
- Added nullish coalescing operator (`??=`) in `setRemoteDefinition` to
initialize only
when needed
## Related Issue(s)
Fixes#33055
This follows the same pattern as PR #27927 which fixed#27793 and #27842
for Angular.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
blog and marketing pages will still link to astro docs, so depend on the
astro sitemap to check all links available to be used.
NOTE: the specific header links (url fragments) are skipped for pages
that come from astro docs (prefixed with /docs) due to not having a
simple way to create these lists without parsing all the build html
files out and that's not the part we really care about
confirmed working https://github.com/nrwl/nx/pull/33042 and
https://github.com/nrwl/nx/pull/33036 which are blocked until this
change merges
Fixes DOC-264
## Current Behavior
The Nx release configuration currently uses 5 separate flat properties
for release tag
configuration:
- `releaseTagPattern`
- `releaseTagPatternCheckAllBranchesWhen`
- `releaseTagPatternRequireSemver`
- `releaseTagPatternPreferDockerVersion`
- `releaseTagPatternStrictPreid`
This flat structure makes the configuration verbose and harder to
organize, especially
as more release tag options are added.
Example of current configuration:
```json
{
"release": {
"releaseTagPattern": "{projectName}@{version}",
"releaseTagPatternRequireSemver": true,
"releaseTagPatternStrictPreid": false
}
}
```
## Expected Behavior
After this PR, all release tag-related configuration is consolidated into a single
nested releaseTag object with the following structure:
- releaseTag.pattern (was releaseTagPattern)
- releaseTag.checkAllBranchesWhen (was releaseTagPatternCheckAllBranchesWhen)
- releaseTag.requireSemver (was releaseTagPatternRequireSemver)
- releaseTag.preferDockerVersion (was releaseTagPatternPreferDockerVersion)
- releaseTag.strictPreid (was releaseTagPatternStrictPreid)
Example of new configuration:
```
{
"release": {
"releaseTag": {
"pattern": "{projectName}@{version}",
"requireSemver": true,
"strictPreid": false
}
}
}
```
Migration & Backward Compatibility:
- An automatic migration transforms old configurations to the new structure
- Old flat properties are deprecated but still supported during the migration period
- The deprecated properties will be removed in Nx 23
- All internal code has been updated to use the new nested structure
BREAKING CHANGE: This is a breaking change in the preferred configuration structure. Existing configurations will continue to work through the migration period, but users should update to the new nested format.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When versioning independent projects in Nx release, the updateDependents
configuration
defaults to 'auto'. This means that dependents are updated (with a patch
version bump)
when a dependency is versioned, as long as a group or projects filter is
not applied
that does not include them.
With 'auto', if you apply a filter that excludes dependents, they won't
be updated even
though their dependencies have been versioned.
## Expected Behavior
The updateDependents configuration now defaults to 'always'. This means
that dependents
will always be updated (with a patch version bump) when a dependency is
versioned,
even if they are not included in the group or projects filter.
This provides more predictable behavior and ensures that versioned
dependencies don't
cause version mismatches with their dependents, which could lead to
broken builds or
runtime issues.
BREAKING CHANGE: Users who relied on the previous 'auto' behavior can
explicitly set `updateDependents: 'auto'` in their nx.json:
```json
{
"release": {
"version": {
"updateDependents": "auto"
}
}
}
```
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The current `stop-agents-on-failure` description is confusing customers
as they are expecting agents to be shut down after the first failure
## Expected Behavior
The `stop-agents-on-failure` description clearly distincts between task
and command failure.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Show the same options for flat config as we do for legacy config.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR adds support for generating embeddings using docs in the
`astro-docs` folder. The embeddings are used for `docs_search` MCP tool,
and we currently do not populate new content into it.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
This PR skips check for the required env var during graph creation.
Although it only happens when `NODE_ENV === 'production'` it is possible
that this is set as such, which would cause an error.
The blob outputs could be missing because CI or user ran `affected -t
e2e-ci` and the changeset did not affect e2e tests, thus no reports
generated. In this case, intead of erroring we should just log out a
warning so users know what happened.
<img width="1252" height="212" alt="image"
src="https://github.com/user-attachments/assets/a90f1f93-0d49-4976-8fa6-a40d2a46161a"
/>
The generator `setup-tailwind` is outdated and not necessary. You can
easily set up Tailwind yourself in 1 minute. Keep the pages around
because people do search for tailwind in our docs.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The PR to add the .NET plugin is failing because it uses the scope
`dotnet`, and that has to be present in master since the pr-title-checks
workflow validates against scopes in master.
## Expected Behavior
The scope is in master
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
In the vite nxTsConfigPaths plugin, when using `buildLibsFromSource:
false`, it has no effect when running vitest.
This is an issue especially in large nx projects when running vitest
browser mode because it has a potential to load all the files from the
entire project using the vite dev server (if no modules mocking is being
used).
This increases the amount of time vitest runs substantially.
Plus, there is no way for vite plugin authors to reuse the same
generated tsconfig file (the one generated by nx that points to the
`dist/` folder path) and reuse this information to configure TypeScript
for example.
One example that comes to mind is analog's angular-vite-plugin, meaning
even if nx supported it, that plugin wouldn't be able to know where is
the generated tsconfig is.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
I expect to be able to use `buildLibsFromSource: false` in my vitest
browser mode tests and reduce the amount of time it takes to run those
tests in large scale projects.
In one of my benchmarks I managed to reduce tests from over 1 minute to
9 seconds (!) with this option enabled.
In order to share the generated tsconfig path I've added another
environment variable called `process.env.NX_GENERATED_TSCONFIG_PATH`
Please let me know if this should be added to the documentation
somewhere and if so where, and I'll add it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
When release groups changed to become more flexible and powerful, with
`updateDependents` tracing across any number of transitive release
groups, the logic for filtering (e.g. `--projects` and `--groups` on the
CLI) was never updated to reflect this new dynamism and complexity.
Now in this PR, release graph construction has been fully separated out
from the release-group-processor. It now lives in the new
`ReleaseGraph`. This is also now where filtering takes place so that the
filters can be fully graph aware.
There is additionally a new `always` option available for
`updateDependents` in addition to `auto` and `never` which are
unchanged. `always` means that a project's dependents will be updated
wherever they may live in the graph, regardless of whether or not they
were directly included within a project or graph filter. We feel that
this is what people want most of the time so this is also going to
become the default in a follow up breaking change PR. In order to be
easier to review, and to increase confidence in this refactor, this PR
does not yet make that change to leave as many tests as possible
untouched (other than utilities changing).
BREAKING CHANGE: The signature of `init()` on `VersionActions` has
changed, it no longer accepts a second argument. Validation of the
manifest files, if any, now takes place via a separate method
(`validate()`) call after construction of the new `ReleaseGraph`. For
the most part, users do not need custom `VersionActions` so only a small
percentage of consumers should be impacted.
Fixes https://github.com/nrwl/nx/issues/31273
## Current Behavior
Currently the `nx-schema.json` is enforcing a `groups: properites` type
when it should be `groups: Record<string, properties>`
## Expected Behavior
Update `nx-schema.json` to have `release.groups: Record<string,
propeties>`
## Current Behavior
NestJS dependencies are not added to the project's package.json leading
to issues when pruning lockfile for dockerfiles.
## Expected Behavior
Ensure NestJS dependencies are added to the project's package.json.
## Related Issue(s)
Fixes#32548
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`nx preview <app>` does not enable watch mode on the build.
This used to be the case until (I think)
https://github.com/nrwl/nx/pull/20367
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx preview <app>` should also enable watch mode and rebuild on files
change.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
FYI: I also had to apply [this config
change](https://github.com/vitejs/vite/issues/19410#issuecomment-2655507784)
for Vite 6 to unstuck from "Rebuilding project...". Maybe it's just my
project, not sure but in any case those are 2 separate issues.
Fixes#31604
The codebase contains conditional logic based on `NEXT_PUBLIC_ASTRO_URL`
environment variable to support both old Next.js docs and new Astro docs
paths.
Since the migration to Astro is complete, the checks aren't needed.
Also add support for different `NX_DEV_URL` avalues for the Astro docs
so canary docs don't point to prod website, for example. (`footer.tsx`
and `Header.astro`).
Note: The changes are largely just removing the var check. Some files of
interest are:
- astro-docs/src/components/layout/Header.astro
- nx-dev/ui-common/src/lib/footer.tsx
- nx-dev/nx-dev/next.config.js
- nx-dev/nx-dev/redirect-rules.js
Also note that plugin registry and doc viewer should no longer be used.
Once we don't need the Next.js app anymore, we can just delete the
project rather than removing it right now. For now, just set `noindex`.
Closes DOC-161, DOC-230
---------
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Fixed the description of the commands to not have raw markdown when
running `npx nx login help`. Also updated the description such that we
don't specifically mention `cloud.nx.app` as not all users will be using
this environment by default.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The TUI title displays `Running Running ...` in its title.
## Expected Behavior
The TUI title should not display `Running` duplicated in its title.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
PR releases are being released with a range of `-1 - 1` which is
incorrect
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
PR releases have a peer dependency on just that PR release.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Remove the old CreateNodes v1 signature and related types from the
public API.
This standardizes on CreateNodesV2 as the primary interface.
Related to Nx 22 createNodes v2 compatibility work.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com><!-- Please make sure you
have read the submission guidelines before posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
<!-- This is the behavior we have today -->
Workspaces that did not use package manager workspaces lost some
dependencies with the other fix.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Workspaces that do not use package manager workspaces will still get the
correct dependencies.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When resolving the tsconfig file, project root is always used,
regardless of cwd.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Prepend workspaceRoot to force absolute path resolution
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31987
- **chore(repo): split remaining long e2e tests (#32948)**
- **chore(repo): run hanging tests serially**
- **chore(repo): bust cache to test changes**
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
https://linear.app/nxdev/issue/CLOUD-3753/hanging-tests
Fixes CLOUD-3753
Clarify which name should be used when calling a local plugin
Fixes DOC-232
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR adds an option to allow users to include certain third-party
deps in the bundle by specifying the `excludeFromExternal` option. There
is an existing `thirdParty: true` option that Nx Console uses to bundle
_all_ third-party deps in the bundle, but the new option is more
granular.
## Current Behavior
Nx automatically detects certain dependencies (like optional peer
dependencies) and marks them as external. Users have no way to override
this behavior when they want to bundle these packages instead.
## Expected Behavior
Users can specify an `excludeFromExternal` option to exclude specific
packages from the external list, allowing them to be bundled even if Nx
automatically detected them as external.
## Related Issue(s)
Closes #NXC-2532
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When creating a buildable library for Next w/ Vite, we do not configure
an additional entry point for server components.
## Expected Behavior
Ensure additional server entry point is configured.
## Related Issue(s)
Fixes#31457
Behaviour changes introduced:
- `preserveMatchingDependencyRanges` set to `true` by default
- `releaseTagPatternStrictPreid` set to `true` by default
- `releaseTagPattern` for fixed release groups set to
`{releaseGroupName}-v{version}`
BREAKING CHANGE
## Current Behavior
JSON files are not being filtered from transform with the
JavascriptTransformer.
## Expected Behavior
Only handle JS/TS files with the JavascriptTransformer.
## Related Issue(s)
Fixes#32690
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Nx is currently using a vulnerable version of axios (<1.12.0) which has
a reported high-level vulnerability
[CVE-2025-58754](https://www.cve.org/CVERecord?id=CVE-2025-58754). This
is being flagged by GitHub Advanced Security on a Nx-powered monorepo:
<img width="1260" height="712" alt="Screenshot 2025-09-12 at 09 42 56"
src="https://github.com/user-attachments/assets/251b47c7-07d1-4c21-aafb-0811554d8861"
/>
## Expected Behavior
Nx should be using a patched version of axios (≥1.12.0) that addresses
said vulnerability.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
Error on install in node_modules folder.
[ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in
/Volumes/ssd/user/Dev/project/node_modules/@nx/remix/package.json
at exportsNotFound (node:internal/modules/esm/resolve:313:10)
## Expected Behavior
Can install without error.
## Related Issue(s)
* [@nx/remix package.json is broken due to export
misspelling](https://github.com/nrwl/nx/issues/32810)
Fixes#32810
We show legacy eslintrc format that's been deprecated and shouldn't be
used anymore. We still want to document the legacy format in case users
haven't switched yet.
---------
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
This PR removes redundant `typecheck` targets from projects already
building with `tsc`.
- Add `addTypecheckTarget: false` to projects using `tsc` as
`build-base`.
- Exclude `e2e` and `nx-dev` projects from having `tsc` build inferred
but leave the `typecheck` target
Note: angular-rspack and angular-rspack-compiler has an issue where
`@nx/vite/plugin` is inferring the typecheck target. We may want to
check `addTypecheckTarget` for that plugin as well.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
Closes NXC-3208
## Current Behavior
Nx Release currently only checks for commits with affected files changed
under the root of projects configured for release.
However, changes to other files may affect and invalidate these projects
also.
## Expected Behavior
Reuse Nx's affected logic to determine when commits contain changes that
affect the projects configured for release.
BREAKING CHANGE: More files are now being used to determine relevant
commits, meaning there is higher chance for projects to receive version
bumps
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Fix docs so it aligns with remote cache implementation.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32870
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The inputs for nx:build did not have transitive true for it's node
inputs
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The inputs for nx:build did not have transitive true for it's node
inputs
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
The install command will fail on Linux machines due to `apt` command
only allowing one invocation at a time. This PR solves this by writing
lock and status files to coordinate between potentially many tests on
the same machine.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Set up search analytics for docs.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes DOC-220
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Relative deploy URL is not being handled correctly in the
postcss-cli-resources Plugins for Webpack and Rspack after switching to
use WHATWG URL in favour of the url.resolve() method.
## Expected Behavior
Ensure the relative deploy URL is properly resolved when using relative
paths
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32714
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `nx` package is being published with the native package dependencies
using an invalid version range `"*"`.
## Expected Behavior
The `nx` package should be published with the native package
dependencies pointing to the same version as the `nx` package.
A recent change to `nx release` requires workspace packages to be
identified as such when deciding to replace the version.
## Related Issue(s)
Fixes#32898
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
These fields were not being used and it takes time to calculate.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The fields are removed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates our module boundary feature/rule pages such that:
- It is clear that the feature is for both JS/TS projects (ESLint) and
any language (conformance)
- Update links to the ESLint rule from feature page to the actual ESLint
rule page (since feature covers both ESLint and Conformance now)
- Add a "Why" section to the conformance overview page
The conformance page (`docs/enterprise/powerpack/conformance`) is meant
to be the main landing page that we send to users. Also updates the
Enterprise page so link to the overview page.
<img width="1024" height="459" alt="image"
src="https://github.com/user-attachments/assets/c24f110d-cc44-41c8-b448-56d4a246a7b6"
/>
## Updated Pages
- /docs/features/enforce-module-boundaries
- /docs/enterprise/powerpack/conformance
-
/docs/technologies/eslint/eslint-plugin/guides/enforce-module-boundaries
- /docs/reference/powerpack/conformance/overview
- /docs/enterprise/polygraph#conformance
- /enterprise
## Notes
The `/docs/enterprise/powerpack/conformance` and
`/docs/reference/powerpack/conformance/overview` have some overlaps,
where the latter documents all the API options. We should look at
cleaning both the conformance and owners reference pages such that they
are just API docs.
## Related Issue(s)
Closes DOC-206
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Devkit creates the ignore object using the `ignore` package. Nx also
creates the ignore object.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Only `nx` creates the ignore object using the `ignore` package. Devkit
utilizes a util from nx.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
Optimizes `get_dep_output` by replacing recursive traversal with BFS +
parallel processing.
**Key optimization**: The old recursive implementation processed the
same task multiple times when it appeared in multiple dependency paths
(diamond dependencies). The new implementation:
- Uses BFS with a visited HashSet to process each task exactly once
- Collects all tasks first, then processes them in parallel with Rayon
- Returns task references directly, eliminating redundant HashMap
lookups
This deduplicates work and leverages parallelism, significantly
improving performance on large task graphs.
**Note**: Only processes regular dependencies, not
continuous_dependencies, since continuous tasks (like watch/serve) don't
produce outputs that need to be hashed.
The same test on my machine without these changes takes many minutes
before crashing my editor. Now it takes <3ms.
## Test plan
- ✅ All Rust tests passing
- ✅ Native module builds successfully
- ✅ Added 4 unit tests covering direct dependencies, transitive
dependencies, diamond deduplication, and task output filtering
- ✅ Added performance test verifying large graphs (depth 30 = 90 tasks)
complete in <10ms
## Current Behavior
TypeScript build info files (*.tsbuildinfo) are currently committed to
git in several e2e test directories:
- e2e/release/tsconfig.tsbuildinfo
- e2e/remix/tsconfig.tsbuildinfo
- e2e/rollup/tsconfig.tsbuildinfo
- e2e/storybook/tsconfig.tsbuildinfo
These are generated build artifacts that should not be tracked in
version control.
## Expected Behavior
Build info files should be ignored by git and not committed to the
repository.
## Related Issue(s)
N/A - General housekeeping to clean up committed build artifacts
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The provenance error pops up frequently for custom registries and it can
be confusing.
## Expected Behavior
With an updated error message, it's clearer what's going on and how to
fix it. This is what it looks like for a custom registry:
```
NX The migrate command failed.
NX An error occurred while checking the provenance of nx@21.10.5-provenance.
This might be due to a custom registry configuration (http://localhost:4874/). Please check whether provenance is correctly configured for your registry.
To disable this check at your own risk, you can set the NX_SKIP_PROVENANCE_CHECK environment variable to true.
```
## Current Behavior
Tasks inferred by the `@nx/js/typescript` plugin can result in a cache
hit when the public API (`.d.ts` files) of external deps changes. This
is incorrect.
Those tasks correctly have an input `dependentTasksOutputFiles:
'**/*.d.ts'`, but that only covers local workspace dependencies, not
external dependencies.
## Expected Behavior
Tasks inferred by the `@nx/js/typescript` plugin should result in a
cache miss when the public API (`.d.ts` files) of external deps changes.
The `tsc -b` command would invalidate its own cache when any dependency
(local or external) `.d.ts` files change, and the Nx cache should do the
same.
This is a temporary workaround that will more aggressively invalidate
the cache, but it's safer than having false positives. We'll work on a
proper solution that will only hash `.d.ts` files from external
dependencies. Once we have it, we'll revert this change so that the
inputs are as surgical as possible while still being safe.
markdoc graph components were not updating the theme if the user changed
their theme preference causing contrast issues with graph content.
now the graph components will update the selected them when the system
theme or pages theme changes
also do not render title bar if no title is provided
fixes: DOC-237
Since Nx only keeps the last 2 majors listed in a plugins
migration.json, it's possible migrations can be defined and a valid
link, but a new nx version will removed those migrations now causing the
page to 404 a link that previously worked.
instead of 404-ing when plugin migrations delete old versions of
migrations we provide a message stating that there are no migrations,
but you can check the previous versions of the docs to check if the
migration you need is listed here.
We still will not include the migrations link in the sidebar when the
migration.json does not contain any migrations.
Example:
<img width="780" height="425" alt="image"
src="https://github.com/user-attachments/assets/de27c4f7-1442-44e6-9005-970450cabe1e"
/>
Fixes DOC-251
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
- remove side_by_side and the usage of cards grid for graph views
- re-center project/task graphs on render to better fit into view
- also updating the height of a few usages of the graph for when there
was a tall stack of nodes to better fit
- NOTE: we can still apply custom node styles if we want, but since the
complaint was just the default render size bc zoom level, I decided to
just resize the view for the elements.
before:

after:

fixes: DOC-248
This reverts commit 5f4a0fe852.
The previous PR was erroneously merged into `master` for 21.6.x, so we
had to revert it. This PR brings it back for 22.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There are migrations for v19.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Migrations prior to v20 (v19 and below) are cleaned up. Users migrating
from Nx 19 will have to do it piece meal by going to Nx 20 first, then
they will be able to go straight to Nx 22.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Remove the deprecated `decorate-cli` script.
- Stop sorting TypeScript path mappings by default in `nx format` and
generators.
BREAKING CHANGE: The long-deprecated `decorate-cli` script has been
removed.
BREAKING CHANGE: The `nx format` command and generators no longer
default to sorting TypeScript path mappings. To keep the previous
behavior, pass the `--sort-root-tsconfig-paths` flag to the command or
set `NX_FORMAT_SORT_TSCONFIG_PATHS=true`.
## Current Behavior
The experimental inlining feature in the `@nx/js:tsc` and `@nx/js:swc`
executors is deprecated.
## Expected Behavior
The experimental inlining feature in the `@nx/js:tsc` and `@nx/js:swc`
executors should be removed.
BREAKING CHANGE: The experimental inlining feature in the `@nx/js:tsc`
and `@nx/js:swc` executors was removed. A migration will remove the
related options (`external` and `externalBuildTargets`). Still, if you
use or rely on the feature, you need to make your dependencies buildable
or use a different build tool with bundling capabilities.
## Current Behavior
The configuration of the `@rollup/typescript-plugin` is incorrect and
overrides options provided by tsconfig.
It also doesn't respect options from the tsconfig file.
## Expected Behavior
Ensure tsconfig options are respected and not implicitly overriden.
The webpack package contains deprecated options that were marked with
TODO(v22) comments for removal:
- deleteOutputPath option
- sassImplementation option
These deprecated options were still being referenced in the codebase and
schema files, potentially causing confusion for users.
Remove the deprecated options from the webpack package to clean up the
API for v22:
- Remove deleteOutputPath option from the webpack executor and related
configurations (use Webpack's output.clean option instead)
- Remove sassImplementation option from the webpack executor and related
configurations (sass-embedded is now the default)
- Add a migration to automatically update existing workspaces that use
these deprecated options
Closes NXC-3108
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The rspack package contains deprecated options that were marked with
TODO(v22) comments for
removal:
- deleteOutputPath option in the rspack executor schema (Line 79 in
models.ts)
- sassImplementation option in the rspack executor schema (Line 164 in
models.ts)
These deprecated options were still being referenced in the codebase and
schema files,
potentially causing confusion for users.
## Expected Behavior
Remove the deprecated options from the rspack package to clean up the
API for v22:
- Remove deleteOutputPath option from the rspack executor and related
configurations
- Remove sassImplementation option from the rspack executor and related
configurations
- Add a migration to automatically update existing workspaces that use
these deprecated options
## Related Issue(s)
Resolves NXC-3112
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
There isn't a replacement for `bundle-rollup` since the rollup executor
does not support isolated configs. This module ensures that existing
projects will continue to work.
This PR removes an unnecessary logic for React component testing via
Cypress. We've made it not possible to have optional webpack configs a
while back (i.e. non-isolated config support). This means that even
legacy users _must_ have a webpack config using `composePlugin(...)`.
Thus, pass the options to that plugin function and things will continue
to work as usual for those users.
Remove the Rspack Application Generator in favour of generators from
`@nx/react`, `@nx/angular` and other plugins with app generators.
Resolves NXC-3109
The default TypeScript plugin for Rollup has changed from
rollup-plugin-typescript2 to @rollup/plugin-typescript. To continue
using the legacy plugin, explicitly set useLegacyTypescriptPlugin: true
in your configuration.
Resolves NXC-3094
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
The deprecated simpleName option has been removed from the library
generators for Angular, React, Nest, and JS packages. Use the --name
option to provide the exact name for the library.
BREAKING CHANGE: simpleName option is no longer supported in library
generators
Closes NXC-3107, NXC-3098, NXC-3093, NXC-3111
This PR fixes an issue with new docs where graph or PDV tag with inner
JSON content will cause formatting issues with other code blocks on the
page.
Rather than using `<slot/>` to render the inner code fence, which seems
to not play well with the rest of the page, we instead skip rendering
the inner content altogether, and pass the data as `astroRawData` to the
underlying React component. This removes the need to handle
HTML/attribute parsing, so it is much cleaner in addition to resolving
conflicts.
Note: Also fixed some of the previous JSON content as they were invalid.
BREAKING CHANGE: The svgr option has been removed from withReact,
NxReactWebpackPlugin, and withNx (for Next.js). Projects that need SVGR
support should now use the new withSvgr composable function from
@nx/react.
For React webpack projects:
- Import withSvgr from '@nx/react'
- Add withSvgr() to your composePlugins chain after withReact()
For Next.js projects:
- Add SVGR webpack configuration directly to your next.config.js
Migrations have been provided to automatically update existing
configurations.
Closes NXC-3106
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The spinners shown during project graph creation display incorrect
plugin counts. They show the total number of registered plugins instead
of the actual number of plugins being processed for each specific phase.
For example, if there are 10 total plugins but only 3 have
`createDependencies`, the spinner would incorrectly show "Creating
project graph dependencies with 10 plugins" instead of "Creating project
graph dependencies with 3 plugins".
## Expected Behavior
Spinners should show accurate counts reflecting the actual number of
plugins being executed for each phase of project graph creation.
## Related Issue(s)
This fixes a misleading user experience where users see progress
indicators that don't match the actual work being performed.
## Changes Made
### 1. Dependencies Phase
- Use `createDependencyPlugins.length` instead of `plugins.length` for
spinner count
### 2. Metadata Phase
- Filter plugins once for `createMetadata` capability
- Use filtered count for spinner
- Eliminate double filtering by using filtered array directly in
processing
### 3. Create Nodes Phase
- Filter plugins once for `createNodes[0]` pattern existence
- Use filtered count for spinner
- Eliminate redundant pattern check in loop
## Benefits
- **Accurate Progress**: Users see correct plugin counts during each
phase
- **Better Performance**: Eliminated redundant filtering operations
- **Consistent Code**: All three phases now follow the same pattern of
filter-once-use-everywhere
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The messaging can be confusing if vscode/cursor are installed but not
added to PATH.
## Expected Behavior
The messaging is clearer.
## Current Behavior
`svgr` support has been deprecated in `webpack` for some time, but it
was never marked as deprecated for `rspack`.
## Expected Behavior
Mark `svgr` support as deprecated with aim for removal in v23
## Current Behavior
The publish workflow has a duplicate `permissions` block incorrectly
nested under a GitHub script action step, which causes a syntax error in
the GitHub Actions workflow.
## Expected Behavior
The workflow should run without syntax errors. The `permissions` block
should only be defined at the job level, not within individual steps.
## Related Issue(s)
This fixes a GitHub Actions workflow syntax issue where permissions were
incorrectly nested under a step action.
The `pull-requests: write` permission is already correctly defined at
the job level (lines 510-513), so the duplicated permissions block under
the step was unnecessary and causing errors.
🤖 Generated with [Claude Code](https://claude.ai/code)
## Current Behavior
The project graph build process incorrectly handles dependencies when
workspace projects have
different versions or are referenced via specific version ranges. This
causes several issues:
1. NPM lockfile parser crashes when encountering symlinked nested
dependencies in workspaces
(which don't have versions)
2. Package.json dependencies that reference workspace projects with
specific versions (e.g.,
"proj4": "1.0.0" when workspace has "version": "2.0.0") incorrectly
resolve to the workspace
project instead of the installed npm package
3. Version ranges and file references to workspace projects are not
properly validated
## Expected Behavior
The dependency resolution should:
- Handle symlinked workspace packages in npm lockfiles without crashing
- Correctly differentiate between workspace projects and npm packages
when specific versions are
referenced
- Properly validate version ranges against workspace package versions
using semver
- Support file references (e.g., "file:../proj6") for workspace
dependencies
- Only resolve to workspace projects when the version constraint is
satisfied or when using
wildcards
## Notes
This has inadvertently caused issues when calculating which manifest
files need to be updated in the JSVersionActions / Nx Release for Npm
Packages
## Related Issues
Fixes#31454
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
## Current Behavior
NestJS libraries using decorators in constructor, or otherwise, are
causing TS errors due to missing configuration for decorators.
## Expected Behavior
Ensure decorator config settings are set in `tsconfig.lib.json`.
## Related Issue(s)
Fixes#30749
This PR brings back PR releases.
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
This pull request introduces support for configuring specific AI agents
in Nx workspaces, allowing users to select which agents to set up and
generating only the relevant configuration files for those agents. It
also updates documentation, schemas, and tests to reflect this new, more
flexible approach.
The most important changes are:
**Agent Selection and Configuration:**
* Added the ability to specify which AI agents to configure via an
`agents` array, both in the setup schema (`schema.json`) and the
`CreateWorkspaceOptions` type. The supported agents are: `claude`,
`gemini`, `codex`, `cursor`, and `copilot`. The generator only creates
configuration files for the selected agents, rather than all by default.
[[1]](diffhunk://#diff-f4d0a6778d70986b54028fb1a5a9338ad4db252edd6db4066e7ee87e8d7f28a5R22-R30)
[[2]](diffhunk://#diff-8141dbb37440f99a460b1e23d0c7229cd16338984832faf528d0ff23de179766R40-R50)
[[3]](diffhunk://#diff-ed4e3e85dbc5d3358491bcef52a8f403a9607df8c874ec9dadef7cd2a1eba6c7R89-R121)
* Implemented prompt logic for selecting AI agents interactively during
workspace creation, and exposed available agent types for use in prompts
and configuration.
[[1]](diffhunk://#diff-672af9097acda13d133130b660df34e6ddf6a61a74f9a6d66832255123e8f9b9R16)
[[2]](diffhunk://#diff-672af9097acda13d133130b660df34e6ddf6a61a74f9a6d66832255123e8f9b9R75-R119)
**File Generation Logic:**
* Refactored the `setupAiAgentsGenerator` implementation to generate
only the files relevant to the specified agents (e.g., `CLAUDE.md`,
`.mcp.json` for Claude; `.gemini/settings.json` for Gemini; `AGENTS.md`
for others), and to append to existing files rather than overwrite them.
[[1]](diffhunk://#diff-ed4e3e85dbc5d3358491bcef52a8f403a9607df8c874ec9dadef7cd2a1eba6c7R1-R45)
[[2]](diffhunk://#diff-ed4e3e85dbc5d3358491bcef52a8f403a9607df8c874ec9dadef7cd2a1eba6c7R89-R121)
* Added new utility functions for determining config file paths and
reading agent-specific configuration, improving maintainability and
clarity of file handling logic.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Pre and post hooks lack corellation Id which might make it difficult to
culculate stats for task using pre and post hooks.
Additionally, post hook does not expose the duration or time span for
the task. Using pre/post hook might not be precise enough.
## Expected Behavior
Hooks expose the unique taskId so we can corellate pre hook of a task to
the post hook of the same task. Post hook should expose start and end
time of the task run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Resolves discussion
[31076](https://github.com/nrwl/nx/discussions/31076)
Refactored multiple components to integrate `motion` animations for a
smoother UI experience. Implemented `AnimateValue` for animated
statistic values across various sections and improved readability by
replacing `JSX.Element` with `ReactElement` where applicable.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `README.md` file for `@nx/web` is currently not copied into the
publish directory for release.
## Expected Behavior
Ensure the `README.md` file is copied into the publish directory.
## Related Issue(s)
Fixes NXC-3055
Add a new `NX_MIGRATE_SKIP_REGISTRY_FETCH` environment variable to opt
out of fetching package versions and migrations metadata from the
registry and instead, use package installation to get the information.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running `nx format:check`, if there is an error, it is considered
as files not formatted correctly
But if Prettier is throwing a real error, it is not diplayed. We just
see an empty result without information
For example:
Format check failing with empty result
```
nx format:check
```
But when running the command, we can see the error:
```
node "/node_modules/prettier/bin/prettier.cjs" --list-different "packages/lib/.spec.swcrc"
packages/lib/.spec.swcrc
[error] No parser could be inferred for file "/packages/lib/.spec.swcrc".
```
## Expected Behavior
I should see the prettier error to understand why it is failing
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Building on Netlify fails.
```
3:03:48 PM: FAILURE: Build failed with an exception.
3:03:48 PM: * What went wrong:
3:03:48 PM: A problem occurred configuring root project 'nx'.
3:03:48 PM: > Could not resolve all artifacts for configuration 'classpath'.
3:03:48 PM: > Could not resolve dev.nx.gradle:project-graph:0.1.7.
3:03:48 PM: Required by:
3:03:48 PM: root project : > dev.nx.gradle.project-graph:dev.nx.gradle.project-graph.gradle.plugin:0.1.7
3:03:48 PM: > Dependency requires at least JVM runtime version 17. This build uses a Java 8 JVM.
3:03:48 PM: > Could not resolve com.ncorti.ktfmt.gradle:plugin:0.24.0.
3:03:48 PM: Required by:
3:03:48 PM: root project : > com.ncorti.ktfmt.gradle:com.ncorti.ktfmt.gradle.gradle.plugin:0.24.0
3:03:48 PM: > Dependency requires at least JVM runtime version 17. This build uses a Java 8 JVM.
3:03:48 PM: * Try:
3:03:48 PM: > Run this build using a Java 17 or newer JVM.
3:03:48 PM: > Run with --stacktrace option to get the stack trace.
3:03:48 PM: > Run with --debug option to get more log output.
3:03:48 PM: > Run with --scan to get full insights.
3:03:48 PM: > Get more help at https://help.gradle.org.
3:03:48 PM: BUILD FAILED in 30s
```
## Current Behavior
Gradle plugin needs Java 17, but Netlify uses 8.
## Expected Behavior
Skip targets on Netlify just like on Vercel.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-3175
- add prettier overrides for mdoc files to be treaded as markdown (along
with running format)
- update links to nx-commands refs to use correct header links
- fix link on quickstart page to point to CI feature overview
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- Bump version of gradle plugin to V2
- Add java to publish pipelines so that we can build the gradle plugin.
- Removed files from freeBSD VM to prevent disk storage limit issues
- Bumped up the kotlin version of gradle projects such that kotlin can
build on freeBSD
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The TUI had two distinct scrolling issues:
1. **Tasks List Events Scrolling**: Any tasks list event (scrolling,
arrow keys, task status changes) would cause the terminal pane to scroll
down exactly 8 lines in two batches of 4 - one immediately and another
after ~200ms delay.
2. **New Task Initial Positioning**: When navigating to a task for the
first time, the task output would render 4 lines above the bottom
position, then automatically scroll to the correct bottom position after
a short delay.
## Expected Behavior
1. Tasks list navigation and events should not cause any scrolling in
the terminal pane
2. Task output should appear correctly positioned at the bottom from the
first render without any delayed scroll adjustments
---
## Technical Details
### Root Cause
**Issue 1 - Tasks List Events Scrolling (8 lines)**
- Task list events triggered `debounce_pty_resize()` calls
- This caused immediate resize + 200ms delayed resize
- Each resize applied 4-line scroll adjustments due to dimension
recalculations
- Result: 8 lines total scroll (4 immediate + 4 delayed)
**Issue 2 - New Task Initial Positioning (4 lines)**
- New PTY instances created with default dimensions (24×80)
- Terminal panes had different calculated dimensions (e.g., 22×137)
- Viewport height mismatch caused content to appear 4 lines up from
bottom
- Delayed resize would correct positioning, causing visible
scroll-to-bottom
### Solution
**Architectural Improvement**: Migrated from individual dimension fields
to shared dimensions using `Arc<RwLock<(u16, u16)>>` to ensure
consistency across all PTY references.
**Issue 1 Fix**: Removed redundant `debounce_pty_resize()` calls during
task navigation events, eliminating the double-resize pattern.
**Issue 2 Fix**: Added immediate dimension correction in
`render_terminal_pane_internal()` to ensure correct positioning from
first render.
### Changes Made
- **pty.rs**: Replaced individual `rows`/`cols` fields with shared
`dimensions: Arc<RwLock<(u16, u16)>>`
- **app.rs**: Added immediate resize in
`render_terminal_pane_internal()` for correct initial positioning
- **app.rs**: Removed redundant `debounce_pty_resize()` calls during
task navigation events
- Improved error handling and eliminated potential deadlock risks in
resize operations
### Performance Impact
- Eliminated double-resize pattern during navigation (~67% reduction in
resize operations)
- No more visible scrolling delays or positioning issues
- Maintained all layout change functionality while removing unnecessary
operations
## Current Behavior
The `cache_outputs` table is always created with a foreign key to the
`task_details` table. When `NX_DISABLE_DB=true` is set, the
`task_details` table is not created, and this results in an error when
trying to insert any records in the `cache_outputs` table.
## Expected Behavior
When `NX_DISABLE_DB=true` is set, the `cache_outputs` table should not
have a foreign key to the non-existent `task_details` table.
## Related Issue(s)
Fixes#32208
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
provenance checks fail on latest on windows because `npm.cmd` is only
executable with a shell. That removes the entire security aspect of
using `execFile` so we just go back to `exec`.
## Expected Behavior
provenance checks shouldn't fail on windows.
## Related Issue(s)
Fixes#32713
Increased the maximum number of active contributors mentioned in the
pricing description from 30 to 50 in the `Pricing` component
(`nx-dev/ui-cloud/src/lib/pricing.tsx`).
## Current Behavior
The React init generator unconditionally adds the
@nx/react/router-plugin to the nx.json plugins
array whenever addPlugin is true. This causes the React Router plugin to
be added even for
React applications that don't use React Router, which is unnecessary and
can lead to unwanted
behavior.
## Expected Behavior
The React Router plugin should only be added to nx.json when:
1. The React application is actually using React Router (specifically
for SSR/RSC scenarios)
2. The addPlugin option is true
This ensures that:
- Applications without React Router don't get the plugin unnecessarily
- Applications with React Router for SSR/RSC get the plugin
automatically when created with the
--useReactRouter flag
- Libraries never get the React Router plugin as they don't need it
## Related Issue(s)
Fixes#32525
update pagefind config to improve search hits
add weight and filter properties for docs to control individual pages
filter` allows selecting "type" of docs being searched

where weight can set the given pages search weight
unfortunately this will set the weight of the whole page content instead
which can make performance worse so important to use it sparingly.
current set values are trial and error based. and subject to change over
time really just depends on feedback over time of the search
performance.
fixes DOC-159
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
only claude has dedicated setup in the nx repo.
## Expected Behavior
Claude, Gemini and things that use AGENTS.md have dedicated setup in the
nx repo.
## Current Behavior
The `tsx` package is missing causing TUI to hang in interactive mode.
## Expected Behavior
The `tsx` package is installed so commands running `npx tsx` don't need
to ask for a permission to install it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Reverting gradle v2 plugin from Nx due to issues with publish pipelines
not being able to handle the new changes. Will re-apply once the kinks
in publish are ironed out.
The AI chat on nx.dev shows an error 'Failed to parse stream string. No
separator found.' after successfully receiving a response from the API.
The AI chat should work without showing streaming parse errors after
successful responses.
Also fixed tailwind pruning by including `feature-ai` in the globs to
check.
https://github.com/user-attachments/assets/2517d856-7a45-48f4-b71b-885f3714fb44
Fixes DOC-216
When NEXT_PUBLIC_ASTRO_URL is set, the blog index now includes a
dedicated search box that filters results to only blog posts. This
ensures blog search functionality is maintained when the main docs
search is moved to the Astro site.
Blog index page has no search functionality when Astro docs are enabled,
making it difficult to find specific blog posts.
Blog index page displays a search box that searches only within blog
posts (using Algolia facet filter for 'Nx | Blog') when Astro docs are
enabled, preserving the ability to search blog content.
Without astro docs:
<img width="1162" height="733" alt="Screenshot 2025-09-19 at 2 26 34 PM"
src="https://github.com/user-attachments/assets/a499fb03-ecc6-4a4f-9303-2198e32f9a77"
/>
With astro docs:
<img width="1143" height="784" alt="Screenshot 2025-09-19 at 2 27 42 PM"
src="https://github.com/user-attachments/assets/4d0bfa7e-0ca6-4694-bba0-fc5e63d1b140"
/>
https://github.com/user-attachments/assets/fe96bc49-dafe-4bc6-9b89-578f29f93cf7
Fixes DOC-221
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We were managing disparate versions across all gradle projects.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Centralize all plugins and dependencies into one location for easier
maintenance.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Algolia search appears on all nx-dev pages, including non-documentation
pages like AI chat and changelog, even when the new Astro documentation
site is enabled. This creates confusion as search should only be
available on documentation pages.
- When NEXT_PUBLIC_ASTRO_URL is set (indicating new docs are enabled),
Algolia search is disabled on all nx-dev pages
- Non-documentation pages (AI chat, changelog) use the non-documentation
header without search
- Documentation header only shows search when Astro docs are not enabled
- Clean up existing styling issues and ensure consistent header usage
across the site
- Updated documentation-header.tsx to conditionally hide search when
NEXT_PUBLIC_ASTRO_URL is set
- Updated header.tsx to pass showSearch prop based on
NEXT_PUBLIC_ASTRO_URL
- Modified AI chat page to use non-documentation header and fixed
styling issues
- Modified changelog page to use non-documentation header-
- Fixed astro header such that `Office Hours` and `Live Streams` are
replaced with `Nx Live` (already done on Next.js side)
- Fixed astro sidebar reference updater middleware formatting
## Examples
Non-docs headers (for homepage, blog, cloud, enterprise, etc.):
<img width="1349" height="103" alt="Screenshot 2025-09-19 at 11 49
06 AM"
src="https://github.com/user-attachments/assets/5a9e6355-43b9-4142-9c76-b30ccc4982b1"
/>
Changelog (with astro docs):
<img width="1467" height="1401" alt="Screenshot 2025-09-19 at 11 48
36 AM"
src="https://github.com/user-attachments/assets/8e135ca7-fe36-4b44-b181-633d3dc5890d"
/>
AI Chat (with astro docs):
<img width="1246" height="952" alt="Screenshot 2025-09-19 at 11 48
24 AM"
src="https://github.com/user-attachments/assets/866c7e4d-8eac-40ab-9c77-5d125135d4e9"
/>
Changelog (without astro docs);
<img width="1180" height="1132" alt="image"
src="https://github.com/user-attachments/assets/eccdeb17-08fc-4f90-949d-5c7879abe3d3"
/>
AI Chat (without astro docs):
<img width="1172" height="1407" alt="image"
src="https://github.com/user-attachments/assets/2ad6b797-32bc-498b-93cb-29cc368030f1"
/>
Astro docs header with updated `Nx Live` link:
<img width="685" height="434" alt="Screenshot 2025-09-19 at 11 48 51 AM"
src="https://github.com/user-attachments/assets/48facc87-2c90-4195-97c7-024b11112001"
/>
Fixes DOC-219
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Fixed the `parseAstroHtmlWrappedJson` function used by PDV and graph tag
components to render code fence properly.
The problem was that inner HTML with code fence caused escaped
double-quotes (`\"`) to be improperly handled. By the time we read the
HTML via React props, the escape character is already done (`\`). Thus,
use code fence to let Starlight render the full block, and then parse
out the JSON object from the `[data-code]` attribute on the div.
For example, previously this would fail:
```
{% project_details %}
{ "foo": "\"bar\"" }
{% /project_details %}
```
That doesn't work because the HTML is just ""bar"", which is invalid.
But changing the above to this works:
````
{% project_details %}
```json
{ "foo": "\"bar\"" }
```
{% /project_details %}
````
This works because you get something like `data-code=""foo":
"\"bar\"""` set on the `div`. So we can use regexp
to match everything within that attribute and parse it out as JSON once
we convert some entities.
Check the
[`nx-dev/ui-markdoc/src/lib/utils/parse-astro-html-wrapped-json.ts`](https://github.com/nrwl/nx/pull/32778/files#diff-c3d8e90b624e30217beaa44c46a16b9053533cf9a8542a4f7301ccaf3dbdab58)
file for the full logic.
Also added JSON code fences to all graph tags in mdoc files to ensure
proper parsing.
<img width="709" height="866" alt="Screenshot 2025-09-18 at 3 41 26 PM"
src="https://github.com/user-attachments/assets/fdae86a6-929a-4a1f-82fe-7d4052de5db5"
/>
Closes #DOC-217
This PR migrates to the unified `@nx/graph` with UI and persisted url
graph state.
- new UI components
- remove obsolete state machines code
- remove obsolete URL query parameters handling
## Current Behavior
When generating workspaces or projects with ESLint and using the TS
solution setup, the generated `out-tsc` directory for TS output is not
ignored in the ESLint configuration. This results in the lint task
processing and potentially reporting errors from that directory.
## Expected Behavior
When generating workspaces or projects with ESLint and using the TS
solution setup, the generated `out-tsc` directory for TS output should
be ignored in the ESLint configuration.
## Current Behavior
Options configured in the `e2e-ci` tasks are not forwarded to their
atomized tasks.
## Expected Behavior
Options configured in the `e2e-ci` tasks can be forwarded to their
atomized tasks.
The `@nx/cypress/plugin` and `@nx/playwright/plugin` plugins will infer
their `e2e-ci` dependencies to atomized tasks with `"options":
"forward"`.
This resolves multiple database-related race conditions that cause
"database is locked" errors and `BorrowMutError` panics during task
cleanup and service initialization.
## Issues Fixed
1. **Task cleanup race condition**: Exit handlers and cleanup methods in
the task orchestrator simultaneously attempted to remove the same task
record, causing SQLite lock contention
2. **Missing database retry logic**: Native operations bypassed the
existing retry mechanism, making them vulnerable to concurrent access
failures
3. **SQLite connection borrowing conflicts**: Direct connection access
in `NxTaskHistory::setup()` violated Rust's borrowing rules when other
services held concurrent borrows
## Solution
### Application-level coordination
- Added atomic check-and-remove pattern using `Map.delete()` return
value
- Only the process that successfully removes from the task map performs
the database operation
- Eliminates duplicate database calls entirely
### Database-level robustness
- Fixed `RunningTasksService` methods to use retry-enabled database
operations
- Replaced `prepare() + stmt.execute()` pattern with direct
`db.execute()` calls
- Ensures all operations benefit from exponential backoff retry logic
(up to 20 attempts)
### Connection access safety
- Moved `array::load_module` from service setup to centralized database
connection opening
- Removed direct `.conn` access that bypassed safe wrapper patterns
- Load array module once per connection instead of per service
instantiation
## Files Changed
- `packages/nx/src/tasks-runner/task-orchestrator.ts` - Race condition
prevention
- `packages/nx/src/native/tasks/running_tasks_service.rs` - Retry logic
fixes
- `packages/nx/src/native/db/initialize.rs` - Centralized array module
loading
- `packages/nx/src/native/tasks/task_history.rs` - Removed unsafe
connection access
Provides comprehensive concurrency safety through defense-in-depth:
prevents race conditions at the application level while ensuring
database operations are resilient to concurrent access.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently we do not support overwriting the default test target since
with custom tests from Gradle. This means you cannot use a test suite
other than the default `test`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- We can now detect custom test suites via the Gradle API, which
receives the test tasks via the task type rather than the test name.
- We can atomize against test targets without having to set these
targets in the gradle plugin configuration
- Setting a custom test target that conflicts with a defined test suite
in Gradle now throws an error
- Check-ci correctly depends on all atomized targets of test targets
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-2962
## Current Behavior
When Angular components reference assets in their stylesheets using
`url()` (e.g., `background-image: url('../assets/test-pattern.svg')`),
the Nx Angular Rspack plugin processes the CSS but fails to extract and
copy the referenced asset files to the output directory. This results
in:
- CSS is processed and URLs may be rewritten to reference output paths
(e.g., `url('./media/test-pattern.svg')`)
- The actual asset files are never copied to the output directory
- Browser shows 404 errors for missing asset files when the application
runs
- No `media` directory is created in the build output
## Expected Behavior
With this fix, assets referenced in component stylesheets are now
properly extracted and emitted to the output directory:
- Asset files referenced in component stylesheets are extracted and
copied to the output directory
- CSS URLs are correctly rewritten to point to the copied assets
- No 404 errors occur for asset files
- A `media` directory is created in the output with the extracted assets
- Both inline and external component styles properly handle asset
extraction
## Related Issue(s)
Fixes#32487
## Changes Made
### Core Fix
- Modified the Angular Rspack plugin to properly collect and emit
stylesheet assets during the compilation process
- Added asset collection during both bundle file and inline style
processing in `setup-compilation.ts` and
`setup-with-angular-compilation.ts`
- Implemented asset emission in the `processAssets` hook of the Angular
Rspack plugin
### Test Coverage
- Added comprehensive example application
(`examples/angular-rspack/csr-css-assets`) that demonstrates:
- External component stylesheets with asset references
- Inline component styles with asset references
- Various asset types (SVG, images)
- Proper asset extraction and URL rewriting
### Technical Details
The fix addresses the gap between Angular's `ComponentStylesheetBundler`
which correctly processes assets and generates `outputFiles`, and the Nx
Angular Rspack plugin which now properly emits these files using
`compilation.emitAsset()` during the build process.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
All errors.. even Project Graph errors cause the daemon to shutdown.
This meant that showing partial graphs in the graph application no
longer worked.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Shutting down the daemon won't help for project graph errors. In this
case, we should not shutdown the daemon. And showing partial project
graphs will work again.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When running `pnpm nx test-native nx`, OSC (Operating System Command)
escape sequences appear after the test completes, displaying as random
characters like `10;rgb:f8f8/f8f8/f2f2` and `11;rgb:0000/2b2b/3636`.
## Expected Behavior
Test execution should complete cleanly without any escape sequences
appearing in the terminal.
## Root Cause
The issue occurs because:
1. Tests in `tasks_list.rs` create `TasksList` components for testing UI
functionality
2. `TasksList` accesses the `THEME` static for styling (e.g.,
`THEME.secondary_fg`)
3. `THEME` is a `LazyLock` that initializes by calling `is_dark_mode()`
4. `is_dark_mode()` uses `terminal_colorsaurus::color_scheme()` which
sends OSC queries to detect terminal colors
5. The test process often exits before the terminal responds, leaving
orphaned responses that appear as escape sequences
## Solution
Added compile-time conditional compilation to skip terminal color
detection during tests:
- `#[cfg(test)]`: Returns `true` (dark mode) without sending OSC
queries. Tests run in virtual buffers and don't need the terminal theme.
It's also less deterministic to have tests relying on the terminal
theme.
- `#[cfg(not(test))]`: Performs normal terminal detection for production
use
This approach:
- ✅ Eliminates OSC sequences during test execution
- ✅ Preserves normal color detection in production
- ✅ Provides deterministic test behavior regardless of terminal theme
- ✅ Improves test performance by avoiding I/O operations
When i18n localization is enabled, rspack generates assets with locale
prefixes
(e.g., 'fr/main.abc123.js'), but chunk.files array is empty. This caused
the
stats reporting to show 0 bytes for all files.
Updated the asset filtering logic in stats.ts to:
- Try exact match first (preserves existing behavior for non-i18n
builds)
- Match assets by chunk names when chunk.files is empty (i18n builds)
- Handle assets with locale prefixes and hash values in filenames
Fixes#32277
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump version of gradle plugin to 0.1.8
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…me cache inputs (#31428)"
This reverts commit 5679b3ea
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This commit caused a major perf regression.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This commit is reverted for now.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Gradle plugin is at version 0.1.7
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump version to 0.1.8
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
We already have `NEXT_PUBLIC_NO_INDEX` supported in pages router, so
canary.nx.dev does not get indexed. However, we missed this in the app
router, so `/blog` is not setting `noindex` in preview environments.
## Current Behavior
When running an npm script through nx and not using the PseudoTerminal,
child processes might not be killed when the `nx:run-script` executor is
killed.
## Expected Behavior
When running an npm script through nx and not using the PseudoTerminal,
child processes should be killed when the `nx:run-script` executor is
killed.
## Current Behavior
Generating Angular projects with Jest results in Jest v30 being used,
which is not supported by Angular and causes peer dependency errors.
## Expected Behavior
Generating Angular projects with Jest should install a compatible
version of Jest (Angular currently supports `^29.5.0`).
Add missing Nx Cloud documentation pages.
Files added:
- astro-docs/src/content/docs/reference/Nx Cloud/config.mdoc
- astro-docs/src/content/docs/reference/Nx Cloud/release-notes.mdoc
- astro-docs/src/content/docs/guides/Nx Cloud/optimize-your-ttg.mdoc
Redirects fixed:
- 8 CI/concepts pages now point to correct locations
Closes DOC-204
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There's no way to distribute Cypress Component Tests.
## Expected Behavior
Cypress Component Tests can be distributed.
Users can choose to infer individual tasks per Cypress Component Test
files that can be distributed across Nx Agents using DTE, by setting the
`ciComponentTestingTargetName` option for the `@nx/cypress/plugin`:
```json
// nx.json
{
...
"plugins": [
{
"plugin": "@nx/cypress/plugin",
"options": {
...
"componentTestingTargetName": "component-test",
"ciComponentTestingTargetName": "component-test-ci"
}
},
...
]
}
```
## Current Behavior
gradle dependencies are hardcoded to included builds & subprojects
## Expected Behavior
we use project configurations to determine dependencies like the tooling
api does
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: lourw <56288712+lourw@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
remove remix and react-native guides and redirect to their intro pages
since they functionally covered the same content already
remove the Module federation concepts since those were already
removed/redirected in the main nx.dev and didn't need to be copied over
to astro site.
fixes: DOC-183
Tabs were not aligning properly on mobile, causing visual
inconsistencies. Added align-items: end to tablist elements to ensure
proper vertical alignment.
<img width="528" height="614" alt="image"
src="https://github.com/user-attachments/assets/b9a1d9b3-c051-43ac-9454-21b16c7f21b5"
/>
Fixes DOC-168
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When updating manifests, Nx Release will replace explicit peerDependency
ranges with the new version that is being created.
i.e.
```json
"peerDependencies": {
"nx": ">= 20 <= 22"
}
```
`nx release version 21.6.0`
```json
"peerDependencies": {
"nx": "21.6.0"
}
```
## Expected Behavior
When processing dependency updates, check for
`preserveMatchingDependencyRanges`.
If this is set to `true` or an array with explicit `dependencyTypes`
check if a valid range is set.
If so, do not update the range.
i.e.
`preserveMatchingDependencyRanges: true`
```json
"peerDependencies": {
"nx": ">= 20 <= 22"
}
```
`nx release version 21.6.0`
```json
"peerDependencies": {
"nx": ">= 20 <= 22"
}
```
If the new version breaks the range, throw an error asking user to
update the range.
i.e.
```json
"optionalDependencies": {
"nx": ">= 20 <= 22"
}
```
`nx release version 23.2.0`
```
The version "23.2.0" is not a valid range for optionalDependencies "nx" in manifest "dist/packages/devkit/package.json". Please update to a valid range.
```
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Update all documentation links in nx-dev UI components to conditionally
use the new /docs
structure when NEXT_PUBLIC_ASTRO_URL is set. This prevents landing on
the old docs page due to the lack of redirect support in Next.js'
`<Link>` when used with pages router.
Note: Blog pages are not updated in `docs/blog` because blog is using
app router which supports redirects. For example, on
https://canary.nx.dev/blog/nx-self-healing-ci the link at the end for
`Nx AI Docs` point to https://canary.nx.dev/features/enhance-AI and is
correctly redirected to https://canary.nx.dev/docs/features/enhance-ai.
## Logic
- When NEXT_PUBLIC_ASTRO_URL is set: links point to /docs/* URLs
- When NEXT_PUBLIC_ASTRO_URL is not set: links use legacy URLs (current
production behavior)
## Pages and components updated
### Pages router pages and components
These are critical since pages router does not support redirects in next
config.
- Homepage (/) components
- AI Page (/ai) components
- Enterprise Page (/enterprise) components
- NX Cloud (/nx-cloud) components
- Pricing (/pricing) components
- Community (/community) components
- Contact (/contact) components
- Powerpack (/powerpack) components
- Gradle pages components
- Common UI components (footer, headers, sidebar)
- Solution pages (engineering, leadership, management)
- Changelog (/changelog)
### App router pages
These pages would have worked regardless since app router supports
redirects in next config.
- React Page (/react):
- ui-react/src/lib/hero.tsx - 1 link
- ui-react/src/lib/features.tsx - 4 links
- ui-react/src/lib/feature-sections.tsx - 3 links
- Powerpack Page (/powerpack):
- ui-powerpack/src/lib/powerpack-features.tsx - 2 links
- Remote Cache Page (/remote-cache):
- ui-remote-cache/src/lib/remote-cache-solutions.tsx - 2 links
- ui-remote-cache/src/lib/faq.tsx - 1 link
---
Verified with NEXT_PUBLIC_ASTRO_URL=https://canary.nx.dev:
- All links now point to /docs URLs (no 308 redirects)
- Old URLs still redirect for backward compatibility
- Pages load successfully with updated links
Fixes DOC-184
## Current Behavior
The Module Federation docs had out of date code snippets
## Expected Behavior
Bring the Module Federation docs in line with recent developments
## Current Behavior
The inferred `docker:build` target does not depend on the build target.
Given that most `docker build` commands rely on the initial application
itself to be built first, it makes sense to depend on the build target.
## Expected Behavior
`docker:build` dependsOn `build`
switch to making typedoc to the rendering and then pull in the generated
file contents instead of manually parsing the reflection metadata.
Fixes: DOC-63
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Add SVG icons to the Technologies section sidebar items to improve
visual hierarchy and navigation. Icons are displayed next to technology
labels like TypeScript, Angular, React, Vue, Node.js, Java, etc.
`Sidebar` is now using a custom `SidebarSublist` that uses `data-icon`
(if it exists) to render the SVG images. A middleware is used since
`attrs` cannot be set on sidebar items with children. Alternatively, we
could cast the sidebar config to avoid type errors.
<img width="746" height="410" alt="image"
src="https://github.com/user-attachments/assets/4da0385b-e38b-4a58-b83f-19c517c79bac"
/>
<img width="529" height="509" alt="image"
src="https://github.com/user-attachments/assets/f9c00af7-5ed6-40dc-b99c-6ef78ebdd5ba"
/>
Closes #DOC-197
The astro-docs header lacks the CTA buttons (Contact and Login) that are
present in the Next.js version, missing important navigation elements
for user engagement.
Added Contact and Login buttons to the astro-docs header with responsive
design:
- Desktop (≥1280px): CTA buttons visible in header
- Mobile (<1280px): CTA buttons appear in mobile menu at bottom
- Proper element priority to prevent overflow: Theme switcher (always
visible) > CTAs > Social icons
- Visual ordering: CTA buttons, social icons, divider, theme switcher
https://www.loom.com/share/34feb737d11342b19f3ef2df0174a5dc?fromJoinRequest=true
Closes DOC-142
## Current Behavior
We are using the default codeql setup, which refuses to run on PRs from
forks
## Expected Behavior
We use the yml based codeql setup, which should run correctly
> [!IMPORTANT]
> This is only the first half of this effort. After this is merged, PRs
will need to be rebased and the repo will need a settings update from
@FrozenPandaz
Fixes orphaned `fork.js` processes that occur when the parent Rust
PseudoTerminal process terminates faster than the fork process can
complete its cleanup, causing the fork to hang during Node.js socket
cleanup.
- Add deleteOutputPath option to rspack executor schema
- Modify rspack executor to only clean output directory when
deleteOutputPath is not explicitly set to false
- This aligns rspack executor behavior with webpack executor and allows
users to control output cleaning
- Fixes issue where rspack.output.clean configuration was being bypassed
Fixes#32015
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
There is no method for overriding the repo config for Container Registry
and Repository Name per environment.
## Expected Behavior
Allow an environment variable `NX_DOCKER_IMAGE_REF` to be set to modify
the full image reference
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Summary
- Moved git utilities that depend on `ignore-files` crate from
`utils/git.rs` to `watch/git_utils.rs`
- Made `find_git_root` and `collect_workspace_gitignores` functions
private since they're only used internally
- Fixed WASM build failure caused by `ignore-files` dependency not being
available for WASM targets
## Test plan
- [x] Verified `pnpm build:wasm` now succeeds
- [x] Verified regular `nx build nx` still works
- [x] Confirmed watch functionality remains intact
The `ignore-files` crate is conditionally excluded from WASM builds in
Cargo.toml, but the git utilities were trying to import it
unconditionally. Moving these utilities to the watch module (which is
already excluded from WASM) provides a cleaner solution than conditional
compilation.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Import is unused
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Import is removed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request makes minor updates to the GitHub Actions workflow
configuration for Rust toolchain installation. The main change is the
addition of an explicit (empty) `rustflags` parameter to the
`actions-rust-lang/setup-rust-toolchain` steps in both the CI and
publish workflows, and a correction of the `targets` parameter to
`target` in the publish workflow.
* CI workflow updates:
* Added `rustflags: ''` to the Rust toolchain setup steps in
`.github/workflows/ci.yml` to ensure no custom Rust flags are set during
installation.
[[1]](diffhunk://#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR72-R73)
[[2]](diffhunk://#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR277-R278)
* Publish workflow updates:
* Changed `targets` to `target` and added `rustflags: ''` for the Rust
toolchain setup in `.github/workflows/publish.yml` to fix parameter
usage and clarify Rust flags.
## Current Behavior
Task duration estimation includes all task runs regardless of their
status (success, failure, cancelled), which can lead to inaccurate
timing predictions.
## Expected Behavior
Task duration estimation should only consider successful task runs to
provide more accurate timing estimates for future task execution
planning.
## Related Issue(s)
Fixes inaccurate task duration estimation by filtering out
failed/cancelled tasks from the calculation.
## Changes Made
- Modified SQL query in `get_estimated_task_timings` to filter by
`status = 'success'`
- Added database index on `status` column to improve query performance
- Updated both the WHERE clause condition and table schema
initialization
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The import is unused
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The import is removed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request updates the workflow configuration for PR title
validation to simplify the setup and improve caching behavior.
Workflow configuration updates:
* Removed the explicit installation step for `pnpm` using
`pnpm/action-setup`, as this workflow doesn't install packages
* Updated the Node.js setup step to disable package manager caching by
setting `package-manager-cache: false`, which replaces the previous
`cache: 'pnpm'` option.…. as this workflow doesn't install packages
## Current Behavior
When using Atomizer with Playwright, test reports are generated per
atomized tasks, and Nx doesn't offer a way to merge them into a single
report. This requires the user to handle multiple reports for a single
test file or run a manual/custom aggregation.
## Expected Behavior
When using Atomizer with Playwright, Nx offers an extra target that can
be run separately to merge/aggregate the Atomized task reports.
The "blob" reporter must be configured in the Playwright configuration
so that it can be generated and used to merge and generate a unified
report. For that purpose, the Nx Playwright preset includes the blob
reporter by default when in CI. An option called `generateBlobReports`
can be used to opt out.
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvelperez@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The TUI tasks list uses pagination when it has many tasks that don't fit
in the viewport.
## Expected Behavior
The TUI tasks list should be scrollable and not use pagination.
Additionally, this PR includes a fix so that when a task is selected in
the task list, it's always ensured that the task is visible if resizing
the terminal or when the task is moved due to a different status.
> [!NOTE]
> CI is failing on this PR right now, its expected. We don't currently
adhere to this advice, and its causing issues. This PR should represent
a sync of this, and future protection
## Current Behavior
Previously, we had no automated check to detect when files tracked by
Git were inadvertently listed in `.gitignore`. This could lead to
inconsistent behavior in Nx's caching system.
## Expected Behavior
With this PR, the CI pipeline now includes a check
(`check-git-ignored-tracked-files`) that identifies tracked files that
would be ignored by Git if they weren't already being tracked. This
ensures consistency in Nx's cache hash calculation.
## Why This Matters for Nx
This check is critical for Nx's caching system because:
**Hash Calculation Consistency**: Nx calculates cache hashes based on
the files that Git tracks. When a file is both tracked by Git and listed
in `.gitignore`, it creates an inconsistency where:
- Git includes the file in operations (and Nx hash calculations)
- `.gitignore` indicates the file should be ignored
- This can lead to different hash calculations depending on timing and
environment
**Impact on Cache Performance**:
- **Cache Misses**: Valid cache entries may be missed due to hash
discrepancies
- **Unreliable Builds**: Tasks may not re-run when they should, or may
re-run unnecessarily
- **Cross-Environment Issues**: Different developers or CI environments
may calculate different hashes for identical code
**The Solution**: The new script identifies these problematic files and
provides clear remediation steps:
- For files that shouldn't be tracked: `git rm --cached <file>`
- For files that should be tracked: Update `.gitignore` to be more
specific
This ensures that Nx's intelligent caching system works as designed,
providing fast, reliable builds across the entire development workflow.
## Related Issue(s)
Fixes the inconsistency between Git tracking and ignore patterns that
can affect Nx cache hash calculations.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
Terminal panes in the TUI show focus state through color changes only -
focused panes display the task name in primary foreground color while
unfocused panes use secondary foreground color.
## Expected Behavior
Terminal panes should provide stronger visual feedback when focused by
making the title bold in addition to the existing color change,
consistent with other TUI components like the dependency view.
## Related Issue(s)
This enhancement improves the visual hierarchy and makes it easier for
users to identify which terminal pane currently has focus, especially in
multi-pane layouts.
## Changes Made
- Modified the title styling logic in `TerminalPane::render()` to
conditionally apply `Modifier::BOLD` when the pane is focused
- Added a test to verify the focus state behavior is correctly
implemented
- The change follows the existing pattern used in other components and
maintains backward compatibility
The implementation uses a conditional modifier that applies bold styling
only when `state.is_focused` is true, leaving unfocused panes unchanged.
This provides consistent visual feedback across the TUI while preserving
existing functionality.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
This PR updates the the plugin registry links to point to intro since
the API docs aren't useful as a discovery page.
Since we use the API path to build generator, executor, etc. links I
added a new `introPath` property instead.
This PR pins our publish actions to specific SHAs, and removes unused
logic tied to the previous PR release support.
Note: `dtolnay/rust-toolchain` cannot be pinned since will treat the SHA
as the Rust version. e.g. `@abc` will try to install Rust version `abc`,
which is invalid.
ReleaseGroupProcessor already iterates through all release groups, and
sometimes change is anyways not propagated.
## Current Behavior
All release groups are iterated in a way that, if group A depends on
group B:
- A will
[propagate](https://github.com/nrwl/nx/blob/53bb276a39a2de09938ed1161fadbbe92a96e596/packages/nx/src/command-line/release/version/release-group-processor.ts#L832)
changes to B
- B will
[check](https://github.com/nrwl/nx/blob/53bb276a39a2de09938ed1161fadbbe92a96e596/packages/nx/src/command-line/release/version/release-group-processor.ts#L894)
if it should be bumped by its dependencies
This means there is redundant double-checking in the code.
However, propagation doesn't always work. The linked
[snippet](https://github.com/nrwl/nx/blob/53bb276a39a2de09938ed1161fadbbe92a96e596/packages/nx/src/command-line/release/version/release-group-processor.ts#L1626-L1661)
selects a random project of group *A*, and if that project doesn't have
dependencies to projects in group *B*, it doesn't consider *B* as
bumped.
## Expected Behavior
### Ideally
There would be no double loops.
### Otherwise
If there are, they should consider all projects when deciding what to
bump. For instance, with something like:
```typescript
const hasDependencyInChangedGroupV2 = Array.from(releaseGroupFilteredProjects).some(
(project) => {
const dependencies = this.projectGraph.dependencies[project] || [];
return dependencies.some(
(dep) =>
this.getReleaseGroupNameForProject(dep.target) ===
changedDependencyGroup
)
})
```
## Notes
- I know it's a bold move to simply delete code. I wanted to highlight
that, if tests pass, we are either missing tests or we are doing
unnecessary work. I would like to replicate locally with a bit more
confidence, but `jest` tests seem to be flaky
- I would need to pick @JamesHenry 's brain about what's the intention
with this "double" propagation in order to have the full context here
## Current Behavior
If the daemon shuts down, and the user tries to run `nx reset`, an ESRCH
error is thrown since the pid in server-process.json doesn't match up to
a process
## Expected Behavior
We check if the process is alive before terminating it
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Relative urls are not being handled correctly in the
`postcss-cli-resources` Plugins for Webpack and Rspack after switching
to use WHATWG URL in favour of the deprecated `url.parse()` method.
## Expected Behavior
Ensure relatives are handled appropriately by resolving them based on
the context of the current resource being loaded.
## Related Issue(s)
Fixes#32582
## Current Behavior
When external nodes change, the project graph cache is not invalidated.
This can sometimes lead to missing dependencies due to reusing cached
dependencies for nodes that no longer exist.
## Expected Behavior
When external nodes change, the project graph cache should be
invalidated.
## Current Behavior
The README.md file contains a broken link to the CI documentation that
points to `/ci/intro`, which no longer exists.
## Expected Behavior
The README.md file should contain the correct link to the CI
documentation pointing to `/ci/getting-started/intro`.
## Related Issue(s)
Fixes#32549
Credits to @MeAkib for originally identifying and addressing this issue.
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 Share your feedback on Copilot coding agent for the chance to win a
$200 gift card! Click
[here](https://survey3.medallia.com/?EAHeSx-AP01bZqG0Ld9QLQ) to start
the survey.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: FrozenPandaz <8104246+FrozenPandaz@users.noreply.github.com>
## Current Behavior
If an invalid bundler is provided to `create-nx-workspace` for the
`angular-monorepo` preset, it defaults to `webpack`.
## Expected Behavior
Invalid bundler option should default to the default provided within in
the angular app generator
## Current Behavior
The `Vite`'s `resolveConfig` always adds default server settings to the
config:
```
server: {
preTransformRequests: true,
sourcemapIgnoreList: [Function: isInNodeModules$1],
middlewareMode: false,
fs: {
strict: true,
allow: [Array],
deny: [Array],
cachedChecks: undefined
}
},
```
This leads to `libs` always ending up with serve targets even if we
don't define `serve` configuration
## Expected Behavior
The serve targets should only exist if we explicitly set port or host.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Migrate gradle project graph plugin to 0.1.7
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Reverts nrwl/nx#32416
Picking up tests via test name is fragile and breaks workspaces where
nx-expected task names do not have exact named counterparts.
…#32435)"
This reverts commit 2c678a1d51.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This causes a regression in Nx Cloud
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is no regression in Nx Cloud.. gotta find a different way.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes#32526
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`--help` behaviour is defined in the Nx alias entrypoints, and doesn't
show the correct output:
```
npx nx start-ci-run --help
nx start-ci-run [options]
Starts a new CI run for distributed task execution. This command is an alias for [`nx-cloud start-ci-run`](/ci/reference/nx-cloud-cli#npx-nxcloud-start-ci-run).
Options:
--help Show help [boolean]
--version Show version number [boolean]
--verbose Prints additional information about the commands (e.g., stack traces).
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When running `npx nx start-ci-run --help` the help from the file in the
NxCloud repo should be displayed:
```
npx nx start-ci-run --help
Usage: npx nx-cloud start-ci-run [options]
Starts an Nx Cloud CI Pipeline Execution and configures distribution.
Options:
--distribute-on <config> Configure how to distribute with Nx Agents. Accepts:
- "<count> <launchTemplate>" (e.g., "8 linux-medium-js")
- path to a .yaml/.yml file for dynamic changesets
- "manual" to disable the warning for legacy DTE setups
--stop-agents-after <targets> Comma-separated targets that signal agents can stop.
Include configuration when needed, e.g., "build:locale-en".
--require-explicit-completion Require explicitly completing the CI run with
"npx nx-cloud complete-ci-run".
--stop-agents-on-failure Stop all agents when a command fails (default: true).
--with-env-vars <CSV> Extra env vars to forward to agents in addition to NX_* (e.g., "VAR1,VAR2").
--use-dte-by-default Use this to disable auto-distribution of Nx tasks (default: true)
--no-distribution Disable distribution for this run
--assignment-rules <file> YAML file with assignment rules (for manual DTE only, see docs)
--fix-tasks <csv> Task names to auto fix
--force Force start a CIPE even when a CI environment is not detected.
--help, -h Show this help and exit.
Notes:
- Do not run this command locally. If run accidentally, clean up with "npx nx-cloud cleanup".
- For legacy manual DTE setups, you can pass "--distribute-on=manual".
Examples:
npx nx-cloud start-ci-run --distribute-on="8 linux-medium-js" --stop-agents-after=lint,test,build
npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yaml" --stop-agents-after=e2e
npx nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after=e2e
npx nx affected -t lint,test,build
Docs:
https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirunhttps://nx.dev/ci/reference/assignment-rules
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #CLOUD-3580
## Current Behavior
The daemon process check in `startServer()` was running continuously
without any interval, causing excessive CPU usage. The `setInterval()`
call was missing the timing parameter, making it run as fast as
possible.
## Expected Behavior
With this change, the daemon process check runs every 20ms,
significantly reducing CPU overhead while maintaining responsive daemon
process monitoring.
## Related Issue(s)
This change optimizes CPU usage in the Nx daemon server by preventing a
continuous polling loop.
## Changes Made
- Added `20` as the interval parameter to the `setInterval()` call in
`packages/nx/src/daemon/server/server.ts:572`
- The daemon process ID check now runs every 20ms instead of
continuously
- Maintains the same functionality while dramatically reducing CPU
consumption
## Current Behavior
The `@nx/devkit` package has `nx` as a direct dependency.
## Expected Behavior
The `@nx/devkit` package should not have `nx` as a direct dependency.
Update `postinstall` script to only be needed for Angular versions lower
than v20.2.0, for which the relevant entry points are patched to expose
needed functionality.
This reverts commit f3bc2b207a.
# Testing
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Many CI runs are running out of memory causing Agents to get OOM killed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This change is reverted and CI runs.. only sometimes run out memory
😅
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cargo deps get fetched on first usage, which is when graph computes +
cargo metadata runs under @monodon/rust
## Expected Behavior
Cargo deps are fetched separately.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, the flaky task detection considers ALL tasks that have mixed
success/failure results as "flaky", including non-cacheable tasks like
development servers (`nx serve`) which are expected to have inconsistent
behavior.
## Expected Behavior
With this PR, only explicitly cacheable tasks (`cache: true`) are
considered for flaky detection. Non-cacheable tasks with mixed results
will no longer trigger flaky warnings.
## Related Issue(s)
This addresses the issue where non-cacheable tasks like development
servers were incorrectly being flagged as flaky, creating noise in the
flaky task detection system.
## Implementation Details
### Changes Made
1. **Database Schema Updates**
- Added `cache` column to `task_details` table
- Updated `HashedTask` struct to include `cache: Option<bool>` field
2. **Query Logic Enhancement**
- Modified flaky task detection query to JOIN with `task_details` table
- Added filter condition `AND task_details.cache = 1` to exclude
non-cacheable tasks
- Added clear comments explaining the query logic
3. **Data Flow Updates**
- Updated TypeScript code in `hash-task.ts` to pass `cache` information
from Task objects to native layer
- Both batch and individual task detail recording now include cache
property
4. **Comprehensive Testing**
- Updated existing tests to include cache information
- Added new test "should not consider non-cacheable tasks as flaky" that
verifies:
- Tasks with `cache: false` are NOT marked as flaky
- Tasks with `cache: undefined` are NOT marked as flaky
- Only explicitly cacheable tasks with mixed results are marked as flaky
### Test Results
- **Rust tests**: 202 passed ✅
- **TypeScript tests**: 4 passed ✅ (all NxTaskHistory tests)
## Benefits
- **Improved Accuracy**: Flaky detection now focuses only on tasks where
consistency is expected
- **Reduced Noise**: Development servers and other non-cacheable tasks
no longer create false positives
- **Better Developer Experience**: More relevant and actionable flaky
task warnings
---------
Co-authored-by: Claude <noreply@anthropic.com>
When NEXT_PUBLIC_ASTRO_URL is set and nx-dev serves docs through Astro,
certain URLs cause infinite redirect loops due to self-referencing
redirect rules. Specifically:
- /docs/guides/nx-cloud/setup-ci redirected to itself
- /docs/reference/devkit redirected to itself
There is also a missing redirect from `/docs` to
`/docs/getting-started/intro` in the Next.js app, leading to a
client-side redirect from Astro website. Plus, `/getting-started/:path*`
was being redirected to the intro page instead of the the more specific
pages.
URLs should either redirect to their proper destinations or serve
content without infinite loops. Removed the two self-referencing
redirect rules that were causing the problem.
`/docs` redirects on server-side not client-side, and `/getting-started`
URLs are redirected to specific pages e.g.
/getting-started/start-new-project ->
/docs/getting-started/start-new-project
Fixes DOC-196
## Current Behavior
CodeQL analysis fails for Java projects in Gradle workspaces because the
required build tasks (clean and testClasses) are not available for
included builds.
## Expected Behavior
CodeQL can successfully analyze Java code by having access to the
necessary Gradle build tasks for all included builds in the workspace.
## Related Issue(s)
This change ensures CodeQL compatibility for Java projects by
dynamically adding clean and testClasses tasks to all included builds.
Fixes #
## Current Behavior
Scrolling via trackpad is way too fast in comparison with scrolling via
arrow keys / mouse wheel
## Expected Behavior
Scrolling via trackpad is analogous to mouse / arrow keys. Additionally,
home + end can jump to the beginning / end of terminal outputs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Themes are not picked up correctly from Nx Console
<img width="1128" height="637" alt="image"
src="https://github.com/user-attachments/assets/8dad4935-6d98-49f3-95a9-34f4880e2551"
/>
## Expected Behavior
Theme is applied
<img width="856" height="543" alt="image"
src="https://github.com/user-attachments/assets/aa7e21ae-a243-4399-b351-a85be339fd4b"
/>
### Changes
- Fix builtin module test to avoid duplicate `node:` prefixes
### Testing
- Update ci pipeline to use node v24
- Update agents to use node v24
### MISC
Requires: https://github.com/nrwl/nx/pull/32223
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
`neverConnectToCloud` can be confusing due to 2 aspects
1. the setup of nx cloud is named via the command `nx connect`
2. network connectsion to external services i.e. nx cloud
`neverConnectToCloud` is meant to control 1 and not 2
this means if you have previously connected to nx cloud and have an
access token configures. nx cloud will still be used since you're not
trying to "setup up nx cloud" aka `nx connect` but are instead using nx
cloud (i.e. making network requests to nx cloud)
Instead using `--no-cloud` or `NX_NO_CLOUD=true` would be how you
prevent network access to nx cloud
Fixes: DOC-194
## Current Behavior
The `@nx/js:typescript-sync` wrongly identifies stale project
references.
## Expected Behavior
The `@nx/js:typescript-sync` should correctly identify stale project
references.
## Current Behavior
The Claude Code workflow is currently enabled and responds to @claude
mentions in issues and PRs.
## Expected Behavior
The Claude Code workflow should be disabled by removing the workflow
file.
## Related Issue(s)
This change disables the automated Claude responses on the repository.
## Current Behavior
If another plugin, or project/package.json exists in the repo that has a
`serve-static` target, running `nx add @nx/rpsack` will fail.
The `@nx/rspack:init` generator does not have any alternative names for
`serve-static` causing conflicts.
## Expected Behavior
The `init` generator should provide more options for the `serve-static`
target such that the plugin can be added without error.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- fix some remnants on old navigation pattern for task graph in PDV
- fix an issue where UI only has `target` and `project` but backend
returns TaskGraph with default configuration
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
In a devcontainer environment, the tmp file we write to when the user
doesn't want to install nx console isn't saved. This means that every
time they start
## Expected Behavior
Devcontainers are a special case, we can skip asking the user if we
detect we are in one.
## Description
With `@module-federation/enhanced@0.18`, dynamic federation changed. The
`init` method is now deprecated and setup is different dependent on
whether the MFP Build Plugin is used. For us, it is, requiring a change
to how we initialise MF.
This also requires an update to Rspack also to `1.5.0`.
`NxModuleFederationDevServerPlugin` currently ignores static dynamic
remotes and does not start them automatically locally.
## Changes
- Replace usage of `init` with `registerRemotes`
- Support Rspack 1.5
- Fix issue with `NxModuleFederationDevServerPlugin` ignoring static
dynamic remotes during dev locally
- Remove restriction on shape of the `module-federation.manifest.json`
## Related Issues
Fixes#32542
## Current Behavior
- Sidebar active link uses default text color instead of accent color
(DOC-143)
- Breadcrumb current page text is barely visible with opacity 0.2
(DOC-141)
- TOC lacks proper spacing between items and has no background styling
(DOC-174)
- TOC hard to parse (DOC-138)
## Expected Behavior
- Sidebar active link uses accent color for better visibility
- Breadcrumb current page has proper text color and visibility
- Deepdive callout paragraphs have compact 12px spacing
- TOC has proper spacing and background styling with dark mode support
<img width="1450" height="1357" alt="Screenshot 2025-08-28 at 1 58
10 PM"
src="https://github.com/user-attachments/assets/b0414e22-ed6c-46ac-b66f-79e80fb868a5"
/>
<img width="1331" height="1030" alt="image"
src="https://github.com/user-attachments/assets/d0a7341e-f389-4357-9028-9def94a23b4f"
/>
<img width="716" height="1187" alt="image"
src="https://github.com/user-attachments/assets/fe4617fa-4c45-4748-aced-a0e513f50965"
/>
## Related Issue(s)
Fixes DOC-143
Fixes DOC-141
Fixes DOC-138
Fixes DOC-174
also fixed issue where links contained 'CI Features' instead of
'ci-features' in URL breaking the markdown to html link rendering
Fixes: DOC-181
Fixes: DOC-186
## Current Behavior
Nx for Gradle plugin is at version 0.1.6
## Expected Behavior
Bumped up the version for the Nx for Gradle plugin, and added necessary
migrations to `nx migrate` the plugin to the newest version.
The Next.js documentation site has no redirect rules to guide users to
the new Astro documentation structure, resulting in broken links and 404
errors when users try to access the old URLs.
All legacy documentation URLs from the Next.js site should redirect to
their appropriate locations in the new Astro documentation site,
following a consistent mapping strategy.
This commit implements the following redirect mapping strategy:
1. **API References Consolidation**: Individual generator and executor
pages are redirected to their parent listing pages since the new docs
don't have individual pages:
- `/api/generators/<specific>` → `/generators`
- `/api/executors/<specific>` → `/executors`
- `/api/migrations` → `/migrations`
2. **CI Content Reorganization**: CI-related content has been
restructured into three main areas:
- Platform-specific CI setup guides consolidated into
`/docs/guides/nx-cloud/setup-ci`
- DTE setup for all platforms consolidated into
`/docs/guides/nx-cloud/manual-dte`
- Security topics moved to `/docs/concepts/ci-concepts/cache-security`
3. **URL Convention Normalization**:
- All redirect targets are prefixed with `/docs`
- Spaces in paths converted to hyphens (e.g., "Nx Cloud" → "nx-cloud")
- Special cases like `convert-to-inferred` redirect to
`/docs/guides/tasks-caching/convert-to-inferred`
4. **Content Consolidation**:
- Technologies without dedicated executor/generator pages (Java, Vue,
Node) redirect to their main/intro technology page
- Deprecated content marked with TODO comments for future migration
decisions
All redirect targets have been verified to exist on canary.nx.dev.
There are some TODOs for missing content that we need to follow-up on,
or check if they are addressed in other PRs.
Fixes DOC-154
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
There is currently no way to pass `templateParameters` to the
`HtmlRspackPlugin`.
## Expected Behavior
Add `templateParameters` to the NxAppRspackPluginOptions and pass
through to `HtmlRspackPlugin`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
We use a regular npm publish flow using access tokens and provenance.
## Expected Behavior
We use https://docs.npmjs.com/trusted-publishers which is more secure
and has provenance configured automatically.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
add link verification script that
- gets all links in the build html files
- compares all links to sitemap links
- fails if there is a link not in the sitemap to prevent creating broken
links
NOTE:
some generated api docs still ref the old URLS (i.e. non /docs prefixed)
which we'll need to change either in this PR or in a quick follow up PR
before releasing as to not break any doc changes that have to be shipped
before full astro port
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
The logo in the documentation header links to the docs intro page
(/docs/getting-started/intro) instead of the main Nx homepage.
The logo should link to https://nx.dev to allow users to easily navigate
back to the main Nx homepage from the documentation.
Fixes DOC-167
Demo: https://www.loom.com/share/71fb2b78d40b4730a073fdfe4a3b66c2
The breadcrumbs component was showing 'Docs' as a clickable segment
which led to a 404 since there's no page at /docs. This filters out the
'docs' segment from the UI while keeping all href links with the /docs/
prefix.
Fixes DOC-165
Demo: https://www.loom.com/share/33aa13e515cf4213a64ecbf29200f3e1
## Current Behavior
When merging project config its easy to return `''` for the root
project's root, but we expect `'.'`.
## Expected Behavior
We normalize this to prevent plugin author's from making an easy mistake
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The React Native e2e tests contain variable naming conflicts and
inconsistent error handling in the process cleanup sections:
- Variables named `process` shadow the global Node.js `process` object
- Inconsistent error handling patterns in process cleanup logic
- Some cleanup operations attempt to kill processes that may not exist
## Expected Behavior
The React Native e2e tests should have:
- Clear variable names that don't shadow global objects
- Consistent error handling patterns throughout all test cleanup
sections
- Robust process cleanup that handles cases where processes may not be
running
### Changes Made
1. **Variable Naming**: Renamed `process` variables to `childProcess` to
avoid shadowing the global Node.js `process` object
2. **Error Handling**: Added consistent try-catch blocks around all
process cleanup operations
3. **Process Cleanup**: Simplified cleanup logic by passing `undefined`
for process ID when the process reference is not available, allowing
`killProcessAndPorts` to handle port cleanup appropriately
This fixes issues that could occur in nightly builds where process
cleanup wasn't being handled consistently, potentially leading to
hanging processes or ports.
Add docs explaining docker version schemes and the default option
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we attempt to create a new cloud-connected workspace with
`create-nx-workspace`, we read `package.json` from the incorrect
location. This means we are not able to retrieve the workspace name
correctly and results in the newly created cloud workspace having the
fallback name `my-workspace`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When we try to read `package.json` we pass in in the correct directory
in which we expect to find the file. This allows us to correctly parse
the json file and retrieve the correct workspace name.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
There was a recent change to `TaskGraphClientResponse` where we drop the
multiple `taskGraphs` and replace with single `taskGraph`. Goal was to
improve the performance for `nx graph` task graph in general and support
multiple targets. Docs pages that render task graph were not updated to
adhere to the new single task graph model. This PR fixes it.
This PR also adjusts the project graph to handle missing props more
gracefully.
## Current Behavior
We retry NX_VERSION_CHANGED errors
## Expected Behavior
We retry NX_VERSION_CHANGED and LOCK_FILES_CHANGED errors
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
- Adds support for `incompatibleWith` field in `packageJsonUpdates` to
prevent updates from running when specified packages are present
- Provides the opposite functionality of the existing `requires` field
- Implements logic to skip packageJsonUpdates when any incompatible
packages are found
## Changes Made
### Core Implementation
- Added `incompatibleWith?: Record<string, string>` to
`PackageJsonUpdates` type
- Implemented `areIncompatiblePackagesPresent()` method with semver
checking
- Updated migration logic to check for both requirements and
incompatibilities
- Added comprehensive tests for both positive and negative scenarios
### Vite 7 Compatibility Fix
- Added `incompatibleWith: { "@remix-run/dev": "*" }` to vite 7
packageJsonUpdate
- Prevents vite 7 update from running when @remix-run/dev is present
## Usage Example
```json
{
"packageJsonUpdates": {
"17.0.0": {
"version": "17.0.0",
"packages": {
"new-package": { "version": "^17.0.0" }
},
"incompatibleWith": {
"old-package": "*",
"conflicting-package": "<2.0.0"
}
}
}
}
```
The update will be skipped if either `old-package` (any version) or
`conflicting-package` (version < 2.0.0) is present in the workspace.
## Test Plan
- [x] Added unit tests covering both positive and negative scenarios
- [x] Verified existing tests still pass
- [x] Applied to real-world case (vite 7 + Remix incompatibility)
- [ ] Test on workspace with @remix-run/dev to verify vite 7 is skipped
- [ ] Test on workspace without @remix-run/dev to verify vite 7 is
applied
## Type of Change
- [x] New feature (non-breaking change which adds functionality)
- [x] Bug fix (non-breaking change which fixes an issue)
## Notes
This feature enables better control over migration paths and prevents
package conflicts during nx migrate operations. The vite 7 + Remix case
is a concrete example where this prevents incompatible package
combinations.
## Current Behavior
Angular v20.2 is not supported.
## Expected Behavior
Angular v20.2 is supported.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
… (#32458)"
This reverts commit c916349179.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This workflow may have a vulnerability.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We'll investigate it before re-introducing it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The `ProjectMetadata` type does not allow for additional properties,
despite the schema having `"additionalProperties": true`. This prevents
folks who are extending Nx and adding details there from doing so in a
way that does not result it type errors.
## Expected Behavior
Userland code extending Nx should be able to add to ProjectMetadata
without running into type errors.
This PR fixes issues with connecting new Astro docs with the `/docs`
rewrite rule on Next.js side.
https://www.loom.com/share/150deedd25a24259b0aa8cb141cec1d3
The redirects now go through Netlify since it's a lot more flexible, and
we need to do that later when porting Next.js to Netlify, etc.
## Not done / follow-up:
Other pages and UI components that use `<Link>` to a doc page need to
check against `NEXT_PUBLIC_ASTRO_URL` and make sure to use the updated
`/docs` path for that. I only handled the homepage for now just to show
it working.
update robots.txt to point to the sitemap-index.xml so crawlers
shouldn't actually look at sitemap.xml directly anyway
but also included sitemap.xml to match that of the sitemap-index.xml
content for historical reasons in case anything still references that
older sitemap
## Current Behavior
There is currently no overview page for the Docker plugin, just
documentation on the using it with Nx Release.
## Expected Behavior
Add an overview page for the Docker plugin
## Current Behavior
The `@nx/js:typescript-sync` generator does not detect duplicate project
references.
## Expected Behavior
The `@nx/js:typescript-sync` generator should detect duplicate project
references.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We had hardcoded test target names which meant that users who specify
custom test suites would not get their atomized tests correctly picked
up.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Allow users to configure the `testTargetName` field in their `nx.json`
and correctly identify which tasks to atomize.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`expo export` expects the `--output-dir` to be within the project
directory.
When using Nx w/o Inference Plugins, we generate an export target that
attempts to place the output directory outside the project directory.
## Expected Behavior
Ensure that the output directory is within the project directory.
- **docs(nx-dev): rename directory to match existing routes**
- **docs(nx-dev): use route middleware to populate sidebar w/ auto
generate command docs**
Unlike the technology section w/convention based file structure driving
the content that is auto generated. the devkit/nx-cli/cnw pages do not
have a reference file structure to generate from. so we leverage the
astro content collections to pull the desired pages. only issues is this
has to be at "run time" and not at setup time. which means we have to
inject these routes via the route middleware.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we migrate version catalogs to use new versions of the gradle
project graph plugin, we lose the original formatting of the version
catalogue file.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We use AST parsing on the version catalogue so that we can make version
edits on the specific portion of the file.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When detecting whether a workspace is set up with pnpm workspaces, we
only check for the existence of the `pnpm-workspace.yaml` file. While
most of the time that's enough, it's not entirely correct because that
file can exist without a `packages` entry and solely contain other
settings.
## Expected Behavior
When detecting whether a workspace is set up with pnpm workspaces, we
should check for the existence of the `pnpm-workspace.yaml` file and the
`packages` entry.
This pull request updates the `mcp.ts` command handler to improve
compatibility with multiple package managers and enhance argument
handling for command execution. The changes ensure that the correct
flags are used for each package manager and that commands with spaces
are executed properly.
* Adjusted arguments passed to the `dlx` command for `npm`, `yarn`, and
`bun` to use their respective flags (`-y`, `--quiet`, `--silent`),
ensuring consistent behavior across different package managers.
* Improved handling of `dlx` commands that may contain spaces (e.g.,
`pnpm dlx`) by splitting the command and passing arguments appropriately
to `spawnSync`.
* Updated both `mcpHandler` and `showHelp` functions to use the new
argument handling logic for executing commands and displaying help
output.
Remove unnecessary file.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #DOC-157
## Current Behavior
When creating a workspace, some pnpm-specific settings are written to an
`.npmrc` file in the workspace root. Npm warns about those unknown
config properties.
## Expected Behavior
The pnpm-specific settings should be written to the
`pnpm-worskpace.yaml` file for pnpm versions that support it (10.6.0+).
## Current Behavior
The e2e tests in the repo can sometimes fail due to Cypress and/or
Playwright version mismatches between the version in the repo lockfile
and the version that gets installed in workspaces generated when running
the e2e tests.
The e2e tests rely on the browsers installed by the agent, but the agent
installs the browser for the version the repo lockfile has, while the
e2e tests need the version that gets generated in the workspaces.
## Expected Behavior
The e2e tests in the repo should not fail due to Cypress and/or
Playwright version mismatches. It's unreliable to rely on the browsers
installed by the agent due to potential version mismatches.
## Current Behavior
When daemon is not running, its pid is null... We don't handle this in
`stop`
## Expected Behavior
We handle this in stop.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, there is no automated check to ensure that PR titles follow
our conventional commit format. This can lead to inconsistent PR titles
that don't match our commit conventions.
## Expected Behavior
With this change, all PR titles will be automatically validated against
our git commit rules when a PR is:
- Opened
- Edited
- Synchronized
- Reopened
The check uses the existing `scripts/commit-lint.js` script to validate
PR titles, ensuring they follow the same format as our commit messages
(e.g., `feat(scope): description`, `fix(scope): description`, etc.).
## Related Issue(s)
This was requested to improve PR quality and consistency across the
repository.
## Implementation Details
- Added a new GitHub Actions workflow:
`.github/workflows/pr-title-validation.yml`
- The workflow writes the PR title and body to a temporary file in the
format specified
- Runs `node ./scripts/commit-lint.js` on the file to validate the PR
title
- The check will fail if the PR title doesn't match our conventional
commit format
- The workflow only runs for the `nrwl` repository owner (consistent
with other workflows)
## Test Plan
- [x] Tested locally with valid PR titles (e.g., `feat(core): add new
feature`)
- [x] Tested locally with invalid PR titles (confirmed validation
failure)
- [x] Tested with breaking change notation (`fix(core)!: breaking
change`)
- [ ] Test on actual PR once merged
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
This PR updates the base href for the new astro docs to match how we
plan to launch it.
The assets including `_astro/` and `.netlify/` are rewritten correctly
now, as well as stripping trailing slash to match what we have in
Next.js.
## Current Behavior
getProjects(Tree) from project-configuration.ts does not return projects
created in generators when called from generator callbacks. This happens
because findCreatedProjectFiles only looks for changes with type ===
'CREATE', but during callbacks, the tree has already been flushed to
disk, so newly created project files are marked as 'UPDATE' instead of
'CREATE'.
## Expected Behavior
getProjects(Tree) should return all projects, including those created
during the current generator run, even when called from generator
callbacks.
## Changes Made
- Modified findCreatedProjectFiles() to include both CREATE and UPDATE
changes
- Added deduplication using Set to prevent duplicate project files
- Added comprehensive test coverage for the callback scenario
## Related Issue(s)
Fixes#29852🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
## Current Behavior
Angular with Esbuild does not error when server bundles violate the
budgets.
Currently, Angular Rspack will error when server bundles violate the
budgets.
## Expected Behavior
Match the behaviour with Angular with Esbuild in Angular Rspack.
Do not error when server bundles violate the budgets.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Summary
Fixed bug where `alwaysAddToPackageJson: "devDependencies"` was ignored
and always defaulted to "dependencies".
- Updated ternary logic in migrate.ts to properly handle string values
- Added comprehensive test case for string values
- Maintains backward compatibility with boolean values
## Test Plan
- [x] Added test case covering both "dependencies" and "devDependencies"
string values
- [x] Verified existing tests still pass
- [x] Confirmed backward compatibility with boolean values
Fixes#30586
Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Craigory Coppola <AgentEnder@users.noreply.github.com>
Fixes path handling issue in @nx/plugin generators where the last folder
name in the path was being ignored.
The executor and generator generators were not creating subdirectories
as expected when provided with directory paths. This fix detects when
the path looks like a directory path and adjusts the directory to
include the artifact name as a subdirectory.
**Changes:**
- Modified normalizeOptions in both executor and generator generators to
detect directory paths
- Added logic to create subdirectories when the path segment matches the
artifact name
- Added comprehensive tests to verify the fix works correctly
- Ensures backward compatibility with existing file path usage
Fixes#31803Fixes#31776
Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Craigory Coppola <AgentEnder@users.noreply.github.com>
## Current Behavior
When running commands in parallel with `nx:run-commands`, if a command
fails, others are not stopped, and the task continues until all commands
finish. This means that if a long-running command is running, it won't
be stopped when other commands have already failed.
## Expected Behavior
`nx:run-commands` should fail fast. In a parallel execution, the rest of
the running commands should be terminated if a command fails.
## Related Issue(s)
Fixes#28477
## Current Behavior
Previously, we needed to rely on `virtualRuntimeEntry` to allow builds
between caching to operate successfully.
## Expected Behavior
In more recent version of `@module-federation/enhanced` this is no
longer the case.
By setting this option, it is now inflating the size of the bundles
produced by Webpack and Rspack
As it is no longer a strict requirement, remove it.
Users can still set it manually if they run into issues
## Related Issue(s)
Fixes#31831Fixes#32404
## Current Behavior
We use dark gray for a secondary fg color, but when dimmed and in
certain terminals its not easy to read for light mode
## Expected Behavior
We've struggled with getting this pallet right for a while, while we
continue working on it we'll just set it to all black
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When the Nx daemon detects a version mismatch and returns
`NX_VERSION_CHANGED`, the client shuts down the connection but doesn't
retry the current message that triggered the error. This causes the
current operation to fail silently.
## Expected Behavior
When `NX_VERSION_CHANGED` is received, the client should:
1. Shut down the current connection
2. Automatically retry the message that triggered the version change
error
3. Continue with the operation transparently
## Related Issue(s)
This improves daemon resilience when Nx versions change during
development.
Fixes#29446
## Changes Made
- Modified `packages/nx/src/daemon/client/client.ts` to track the last
sent message and retry it when `NX_VERSION_CHANGED` is received
- Added `retryLastMessage()` method to `PromisedBasedQueue` to support
message retry
- Added proper logging for version change detection in
`shutdown-utils.ts`
The fix ensures that operations don't fail when the daemon detects a
version change, improving the developer experience.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
The Claude GitHub Actions workflow includes xiongemi, ndcunningham,
isaacplmann, and mandarini in the allowed users list.
## Expected Behavior
These users should be removed from the allowed users list for Claude
GitHub Actions workflow permissions.
## Related Issue(s)
<!-- No specific issue number -->
Fixes configuration by removing users from allowed list.
## Current Behavior
We error if a non-parallel task has a continuous dependency, but when
running a command that contains a task that depends on a continuous task
which itself is marked as non-parallel we do not error. This results in
the command hanging on the continuous non-parallel task, instead of
running the parent task as well.
## Expected Behavior
We error in both situations.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Signed-off-by: AgentEnder <craigorycoppola@gmail.com>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Currently, the NX Console installation prompt can appear in
non-interactive environments like CI/CD pipelines, causing processes to
hang indefinitely waiting for user input.
## Expected Behavior
The NX Console installation prompt should only appear in TTY
(interactive terminal) environments where users can actually respond to
the prompt.
## Related Issue(s)
This change adds a TTY check (`process.stdout.isTTY`) before showing the
NX Console installation prompt, preventing hanging in automated
environments while preserving the interactive experience for developers
working in terminals.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Certificates in the local trust store are ignored, because reqwest
(rustls) is using webpki-roots.
## Expected Behavior
Certificates from the local trust store are trusted.
This PR solves this the same way as turborepo - by turning on the
`rustls-tls-native-roots` feature in reqwest.
This PR re-enables the escaped markdoc tags. Note that graph and PDV
tags that pointed to an external JSON file is changed to inline the JSON
instead so we don't need that extra file loading logic.
## Current Behavior
Multiple pages in the Astro documentation site display broken components
due to:
- Escaped template blocks (\{% ... %\}) that prevent proper rendering
- Component name mismatches using hyphens instead of underscores
- Missing side-by-side component causing "Undefined tag" errors
- Graph components showing "Could not parse JSON" due to markdown code
blocks
- External JSON file references not being inlined properly
## Expected Behavior
All documentation pages render correctly with:
- Proper template block syntax without backslash escaping
- Component names matching markdoc.config.mjs registrations
- All required components available and properly configured
- Graph and project_details components displaying JSON data inline
- All Markdoc components functioning as intended
<img width="824" height="849" alt="Screenshot 2025-08-20 at 10 55 53 AM"
src="https://github.com/user-attachments/assets/3d94e2a8-c971-49a6-a7aa-95ac40a8c86b"
/>
<img width="797" height="627" alt="Screenshot 2025-08-20 at 12 33 19 PM"
src="https://github.com/user-attachments/assets/1352e8bd-f5df-4db0-8679-a1627b2b6911"
/>
Also add back the `side_by_side` tag for now since it's used in a couple
of places:
<img width="797" height="627" alt="Screenshot 2025-08-20 at 12 33 19 PM"
src="https://github.com/user-attachments/assets/4ecaf12b-592f-4885-88d8-bc25e4c7d087"
/>
<img width="775" height="1059" alt="Screenshot 2025-08-20 at 12 55
23 PM"
src="https://github.com/user-attachments/assets/0cc32bd4-e2f0-41b9-b2a6-29edabccae0e"
/>
## Related Issue(s)
Fixes DOC-148
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Code snippets use custom Nx attributes (fileName and highlightLines)
that don't display properly in Astro Starlight
## Expected Behavior
Code snippets use Starlight's native format with filenames shown as
comments and highlights using curly brace syntax
<img width="980" height="710" alt="Screenshot 2025-08-20 at 10 58 07 AM"
src="https://github.com/user-attachments/assets/38c6629f-8be3-4934-b839-ae5ece980f36"
/>
## Related Issue(s)
Fixes DOC-137
This PR prepares for the canary environment where we can use `/docs/*`
for the new astro docs while keeping the same domain.
## Current Behavior
The nx-dev Next.js app doesn't have any rewrite rules for the `/docs`
path, making it unable to proxy requests to the Astro documentation
site.
## Expected Behavior
When the `NEXT_PUBLIC_ASTRO_URL` environment variable is set, the
Next.js app configures rewrites for `/docs` and `/docs/*` paths to proxy
to the Astro documentation site. If the environment variable is not set,
no rewrites are configured, maintaining backward compatibility.
## Related Issue(s)
Fixes DOC-134
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The Astro/Starlight documentation pages display duplicate titles because
both the frontmatter title and an h1 heading in the content are being
rendered. This creates a poor user experience with the same title
appearing twice at the top of each page.
## Expected Behavior
Each documentation page should display its title only once. Starlight
automatically renders the frontmatter title as the page's h1, so there
should be no h1 headings in the content body. The frontmatter title
should be the single source of truth for the page title, with optional
sidebar labels for customization.
## Related Issue(s)
Fixes DOC-125
## Current Behavior
Some test expectations fail in macOS due to some paths not being
normalized in the assertions.
## Expected Behavior
Tests should pass.
## Current Behavior
The `@nx/js/typescript` plugin incorrectly infers that all projects are
libraries. This is not correct, because apps also have tsconfig files
which would be processed and targets will be inferred for them (e.g.
`typecheck`). Depending on the order of the plugin execution, it can
result in projects having the wrong type.
## Expected Behavior
The `@nx/js/typescript` plugin should not infer the project type. The
project type will be correctly derived later, when the project graph
nodes are normalized.
## Current Behavior
Nx release now updates peer dependency versions, which is great... but
it broke the peer dep range in the published version of @nx/devkit.
## Expected Behavior
@nx/devkit maintains a version range of +/- 1 major version of nx. We
will fix release soon.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31801 (already fixed, but comments on this highlighted the
problem)
## Summary
Fixes an issue where dummy tasks (created when dependency projects don't
have required targets) would generate non-deterministic dependency
structures based on target processing order.
## Current Behavior
When creating task graphs with targets in different orders, dummy tasks
would inherit different configurations from different source tasks,
leading to inconsistent task graphs.
For example:
- Processing `[test, lint]` vs `[lint, test]` would create the same
dummy task IDs
- But the dummy tasks would have different dependency structures
depending on which task created them first
## Expected Behavior
Task graphs should be deterministic regardless of target processing
order. The same dummy task should always have the same dependencies.
## Related Issue(s)
This addresses the issue described where task graph generation was
non-deterministic due to dummy task dependency variations.
## Test Plan
- [x] Added unit test: "should create deterministic task graphs
regardless of target order"
- [x] Verified existing tests continue to pass
- [x] Test validates task graphs are identical when targets are
processed in different orders
🤖 Generated with [Claude Code](https://claude.ai/code)
## Current Behavior
The sidebar in the Astro docs has two issues:
1. Introduction pages are not appearing first in technology sections -
they appear after Generators, Executors, and Migrations
2. Nested groups (like Guides folders and sub-technology sections) are
expanded by default, making the sidebar difficult to navigate
## Expected Behavior
With this PR:
1. Technology sections now display items in the correct order:
- Introduction (if exists)
- Guides (if exists)
- Generators (if exists)
- Executors (if exists)
- Migrations (if exists)
- Everything else (other static files and nested sections)
2. All nested groups are collapsed by default for better navigation:
- Guides folders are collapsed
- Sub-technology sections (Next, Remix, Express, Nest, etc.) are
collapsed
- Any auto-generated folder groups are collapsed
<img width="789" height="484" alt="Screenshot 2025-08-19 at 2 30 36 PM"
src="https://github.com/user-attachments/assets/0562693c-b17a-4562-8f58-a0fba50fc6fe"
/>
## Related Issue(s)
DOC-122 (Linear)
- Expanded inputs with placeholder to prevent content shifting
- Bump `@nx/graph` to fix task graph missing transitive deps issue
- Disabling cache will throw runtime errors for expanded inputs
operation so putting in a couple of safe fallbacks when things are
undefined
## Current Behavior
The PostCSS CLI resources plugins in webpack, rspack, and angular-rspack
packages currently use the deprecated `url.parse()` and `url.format()`
methods, which generate security warnings:
```
(node:xxx) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead.
```
## Expected Behavior
The code should use the modern WHATWG URL API to eliminate deprecation
warnings and improve security.
## Related Issue(s)
This change addresses the Node.js deprecation of `url.parse()` due to
security implications and lack of standardization.
## Changes Made
- **URL Parsing**: Replace `url.parse(inputUrl)` with `new
URL(normalizedUrl, 'file:///')`
- **URL Reconstruction**: Replace `url.format({ pathname, hash, search
})` with simple string concatenation
- **URL Resolution**: Replace `url.resolve(deployUrl, outputUrl)` with
`new URL(outputUrl, deployUrl).href`
## Files Modified
- `packages/webpack/src/utils/webpack/plugins/postcss-cli-resources.ts`
- `packages/rspack/src/plugins/utils/plugins/postcss-cli-resources.ts`
- `packages/angular-rspack/src/lib/utils/postcss-cli-resources.ts`
## Implementation Details
- Uses WHATWG URL API with a `file:///` base for parsing relative URLs
consistently
- Maintains backward compatibility - all existing functionality works
the same
- Simple string concatenation for URL reconstruction is cleaner and more
readable
- Clear variable names (`normalizedUrl`, `parsedUrl`) improve code
maintainability
## Testing
- All existing tests pass
- Build and lint validation successful
- No functional changes to URL handling behavior
This migration eliminates security warnings while modernizing the
codebase to use standardized URL APIs.
## Summary
- Add CURSOR_TRACE_ID environment variable detection for Cursor
- Simplify get_env_var to be purely map-based for better testability
- Add Cursor support to extension installation logic
- Add test case for CURSOR_TRACE_ID detection
## Test plan
- [x] All existing tests pass
- [x] New test case for CURSOR_TRACE_ID detection passes
- [x] Rust code compiles and passes clippy checks
- [x] Prepush validation passes
This ensures Nx Console extension can be properly installed in Cursor
when the CURSOR_TRACE_ID environment variable is present, providing
better support for Cursor users.
Fixes #[ISSUE_NUMBER]
## Current Behavior
Running Angular migrations (particularly Angular Material migrations)
normally results in many warnings stating that projects were skipped.
This happens because Angular migrations make some assumptions that are
not guaranteed in Nx monorepos:
- build and test tasks are literally called `build` and `test` (it they
have a different name, the Angular migrations don't handle them)
- those tasks must have a `tsConfig` option set in the task `options`
object
While Nx can't change the first assumption, it can ensure that
`tsConfig` is set in some tasks that allow it.
## Expected Behavior
Tasks using the `@nx/angular:package`, `@nx/angular:ng-packagr-lite`,
and `@nx/jest:jest` executors should have the `tsConfig` option set to
aid the Angular migrations to run.
Note: This PR restores the `tsConfig` option for the `@nx/jest:jest`
executor that was recently removed. The option description states that
it is only metadata for Angular migrations and is not used by the
executor. The option will only be set by Nx generators for Angular
projects.
## Related Issue(s)
Fixes#32138
## Current Behavior
The `@nx/js/typescript` plugin exhibits the following wrong behaviors
when it comes to determining whether a project is buildable:
- Having a custom conditional export other than `development` pointing
to a source file means the project is not buildable
- Having any conditional export pointing to source files means the
project is not buildable
- It falls back to check against included files when `outDir` is defined
The above creates issues where some buildable libraries are not
identified.
## Expected Behavior
The `@nx/js/typescript` plugin should behave as follows (simplified)
when it comes to determining whether a project is buildable:
- If `outFile` is defined:
- If the `.` entry point is defined and it's pointing to the `outFile`
or any of its conditional exports are pointing to the `outFile`, it's
buildable
- If `exports` is not defined and `main` or `module` are defined and
pointing to the `outFile`, it's buildable
- Otherwise, it's not buildable
- Otherwise, if `outDir` is defined:
- If the `.` entry point is defined and it's pointing to a path
contained in the `outDir` or any of its conditional exports are pointing
to a path contained in the `outDir`, it's buildable
- If `exports` is not defined and `main` or `module` are defined and
pointing to a path contained in the `outDir`, it's buildable
- Otherwise, it's not buildable
- Otherwise (no `outFile` and no `outDir`):
- If the `.` entry point is defined and it's pointing to a path not
matched by the `files` or `include` patterns or any of its conditional
exports are pointing to a path not matched by the `files` or `include`
patterns, it's buildable
- If `exports` is not defined and `main` or `module` are defined and
pointing to a path not matched by the `files` or `include` patterns,
it's buildable
- Otherwise, it's not buildable
The above also ensures that custom conditional exports are not a factor,
given that all that is needed is that at least one conditional export is
deemed non-buildable.
## Related Issue(s)
Fixes#32116Fixes#32290
…URL API"
This reverts commit f768886ae7.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Accidentally pushed this without review
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Reverting it so it can be reviewed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Replace the deprecated url.parse() and url.format() methods with the modern WHATWG URL API in PostCSS CLI resources plugins to resolve security and maintainability concerns.
- Replace url.parse(inputUrl) with new URL(normalizedUrl, 'file:///')
- Replace url.format({ pathname, hash, search }) with simple string concatenation
- Replace url.resolve(deployUrl, outputUrl) with new URL(outputUrl, deployUrl).href
- Apply changes consistently across webpack, rspack, and angular-rspack packages
The deprecated url.parse() method is prone to security vulnerabilities and is not standardized. WHATWG URL API provides a modern, secure, and standardized way to parse URLs while maintaining all existing functionality.
Resolves deprecation warnings about url.parse() security implications.
This PR improves our error message whenever our GitHub API token expires
so we're not confused about what's broken. It expires each year as
required by Octokit.
Current error:
```
Error occurred prerendering page "/changelog". Read more: https://nextjs.org/docs/messages/prerender-error
HttpError: Bad credentials
```
New error:
```
Error occurred prerendering page "/changelog". Read more: https://nextjs.org/docs/messages/prerender-error
Error: The GitHub token is invalid or has expired. Please provide a new Personal Access Token (PAT) via the GITHUB_TOKEN environment variable.
```
## Current Behavior
Nx currently installs an outdated `@types/node` version (18.16.9) which
lacks TypeScript definitions for the native `fetch` API introduced in
Node.js 18. This causes "fetch is undefined" TypeScript errors in NestJS
projects and other Node.js applications when using webpack transformers
or other build tools.
## Expected Behavior
The `fetch` API should be properly typed in TypeScript without requiring
additional type packages or workarounds. Users should be able to use the
native fetch API in Node.js applications without TypeScript compilation
errors.
## Related Issue(s)
Fixes#31637
Fixes https://github.com/nrwl/nx/issues/29714
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <cferry09@gmail.com>
add new redirects file
redirect root to the intro page
redirect legacy showcase projects to quickstart until those projects get
updated
closes: DOC-94
closes: DOC-114
## Current Behavior
ESM Loader for Windows is not working because it is encountering an
absolute path that is not using the `file://` protocol.
## Expected Behavior
Ensure that when loading the `esm-loader`, it uses the file protocol
## Related Issue(s)
Fixes#32376
## Current Behavior
We currently do not support converting webpack configs using
`NxAppWebpackPlugin` to `NxAppRspackPlugin`.
## Expected Behavior
Add support for converting webpack configs using the
`NxAppWebpackPlugin`.
## Related Issue(s)
Fixes#30292
## Current Behavior
The Jest plugin does not use `NX_CACHE_PROJECT_GRAPH` in its
implementation. Unlike other plugins (e.g., ESLint, TypeScript), it does
not provide a way to control or disable its internal caching behavior.
## Expected Behavior
The Jest plugin should leverage `NX_CACHE_PROJECT_GRAPH`, ensuring
consistent caching behavior across Nx plugins. This would make it easier
to manage or override caching strategies when building higher-order
plugins that extend Nx core functionality.
## Related Issue(s)
Fixes #
---
### Additional Context
* When creating higher-order plugins that extend Nx core plugins, it’s
often useful to manage cache differently. Without this, concurrency
issues can occur if `createNodesV2` is invoked multiple times in
parallel.
* This highlights a broader need for improved plugin extensibility:
* Instead of re-invoking `createNodesV2` (which handles multiple files,
cache, etc.), it would be helpful to expose lower-level functions
responsible only for generating configuration.
* This would give plugin authors more granular control while reducing
unintended side effects.
## Current Behavior
The Astro docs site doesn't display breadcrumbs at the top of the page
content, making navigation context unclear.
## Expected Behavior
Breadcrumbs should appear at the top of each page content (after the
page title) showing the navigation hierarchy, matching the behavior from
the original Next.js app.
<img width="1343" height="361" alt="Screenshot 2025-08-15 at 2 47 19 PM"
src="https://github.com/user-attachments/assets/8f2c983a-710f-4d0b-aa6e-b2303884596a"
/>
## Current Behavior
The @nx/js:node executor had several process management issues:
- Multiple concurrent builds could cause overlapping/corrupted console
output,
especially in NestJS projects
- Process stdout streams weren't properly coordinated between different
tasks
- Rapid file changes could trigger multiple simultaneous rebuilds
without
proper debouncing
- Console output formatting could break with mixed output from
overlapping
processes
## Expected Behavior
The node executor should:
- Handle process output streams cleanly with no overlapping/corrupted
output
- Properly debounce rebuild triggers to prevent resource conflicts
- Maintain clean console formatting even with rapid file changes
- Coordinate output between concurrent processes using a global stream
manager
## Related Issue(s)
Fixes#30247Fixes#22999Fixes#22945
## Current Behavior
When using version plans, after running the release command, version
plans were deleted.
This happened even if a `project` or `group` filter was supplied and not
all version plans were used.
## Expected Behavior
Ensure that:
- Only Version Plans for projects in filter are deleted
- If filtered projects exist in version plans that contain unfiltered
projects, hard error
## Related Issue(s)
Fixes#31327
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
If a host does not have any remotes, it fails to serve as the
`staticRemotesPort` returns as `-Infinity`.
## Expected Behavior
When a host has no remotes, set `staticRemotesPort` to `undefined` and
use this to determine whether we should wait for it.
Add a new option `skipBuildCheck` to the `@nx/js/typescript` plugin
build options to allow skipping the check for a buildable setup and
always infer a build task.
## Current Behavior
Running `nx migrate` in a non-js repo (no `package.json` in the
workspace root) hangs.
## Expected Behavior
Running `nx migrate` in a non-js repo should work correctly.
Open Graph images on nx.dev are returning 404 errors for several pages:
- `/ai-chat` and `/changelog` reference non-existent
`/images/nx-media.jpg`
- `/extending-nx` references non-existent
`/images/open-graph/extending-nx.jpg`
- Pages with anchors have broken og:image URLs
All pages should have working Open Graph images for proper social media
sharing.
Fixes DOC-98
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When resolving token data for creating the GitHubReleaseClient, The GH
CLI supports `https` option for `git_protocol` and it is not being
handled.
This results in no token data being resolved.
Further API requests that require a `Bearer` token in the headers fail.
## Expected Behavior
Ensure `https` protocol is also handled.
`gh auth token` still operates and produces a token that can be used.
## Related Issue(s)
Fixes#31828
## Current Behavior
When `nx g @nx/react:host` is used and 0 `--remotes` are passed, we
still add the `loadRemote` helper from
`@module-federation/enhanced/runtime`.
This causes a typecheck error as it is unused.
## Expected Behavior
Only add the helper when it is needed (i.e. >0 remotes).
## Current Behavior
The astro-docs structure lacks index pages for directory navigation,
making it difficult for users to discover and navigate between related
content sections. Additionally, some index pages were missing the proper
sidebar configuration to hide them from the navigation.
## Expected Behavior
With these changes, all directories in astro-docs now have proper
index.mdoc files that:
- Display auto-generated cards for subdirectory navigation using the `{%
indexpagecards %}` component
- Are hidden from the sidebar navigation with `sidebar: hidden: true`
- Provide clear entry points for discovering related content
The changes include:
- Added index.mdoc files for all technology, concept, guide, and
reference directories
- Implemented proper case handling for directory names (e.g., "Guides" →
"guides")
- Enhanced the IndexPageCards component to work with .mdoc files
- Ensured consistent sidebar configuration across all index pages
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
The Astro docs site header had a different structure and styling
compared to the production nx.dev header. It was missing key navigation
elements like the version switcher, Resources dropdown with icons, and
proper navigation ordering.
The Astro docs header now matches the production nx.dev header structure
with:
- Version switcher (v21, v20, v19) positioned correctly
- Resources dropdown with organized sections (Learn, Events, Company)
and icons
- Proper navigation order: Blog, Resources, | AI, Nx Cloud | Enterprise
- Consistent styling using Tailwind CSS classes
- Maintained social icons and theme switcher functionality
- All links without underlines and proper hover states
Fixes DOC-111
This removes the need to ignore `@nx/cypress` in
`packages/cypress/.eslintrc.json`. This was never really a ciruclar dep,
as
`packages/cypress/src/generators/configuration/files/v9/__directory__/plugins/index.js`
is a template for `generateFiles`, thus appending `__tmpl__` fixes it.
Other packages have valid reasons so a comment is added to clarify for
the future.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Our project graph gradle migrations currently only bump up the gradle
plugin if its versions are set in `build.gradle.kts` files. This means
that migrations will not work with workspaces that use version catalogs
and aliases.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Given a workspace using the project graph gradle plugin on a legacy
version, migrations should bump up the version of the Nx gradle plugin
if its specified in `libs.versions.toml` instead of `build.gradle.kts`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-2952
- Added "worker" to exclusion pattern in add-snippet.ts to prevent
worker creation code from being added to the generated worker file
itself
- Fixed double slash in tsconfig.worker.json template by removing extra
"/" since offsetFromRoot() already returns paths ending with "/"
- Added comprehensive tests to prevent regression including edge cases
with complex worker names
Fixes#31977
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The Nest.js webpack build target configuration was generating
webpack-cli arguments without the required cwd in build.options.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Nest.js webpack build target should generate proper webpack-cli
arguments with the cwd as part of the build.options
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31863
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
When we switched to the TS solution setup with inferred `tsc` builds, we
didn't update the dependencies for `@nx/vite` to use `tslib` instead of
`@swc/helpers`. It was previously using `@nx/js:swc` executor, but now
`build-base` target is inferred as `tsc -b`.
It did not cause issues since other packages including `nx` always
install tslib, but technically it is incorrect, and we were ignoring the
errors by adding `tslib` and `@swc/helpers` to be ignored in
`.eslintrc.json`.
This PR also cleans up the eslint config for all other packages since we
do not need to ignore `tslib` for `@nx/dependency-checks` to pass.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`@nx/vite` is missing `tslib` dependency even though the built JS file
uses it.
## Expected Behavior
Should have `tslib` as a dependency and not `@swc/helpers`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When using TypeScript solution setup with rspack, conditionally enable
build mode for TsCheckerRspackPlugin to generate declaration files.
This prevents TS6305 errors in module federation scenarios where
declaration files are expected but missing.
Fixes#31929
The additionalEntryPoints option was failing on Windows because
tinyglobby
expects POSIX-style paths but was receiving Windows-style paths with
backslashes.
This fix applies normalizePath to ensure cross-platform compatibility.
Fixes#29690
## Current Behavior
Rspack + React + Module Federation applications are not able to work
properly due to the presence of splitChunks optimization on default web
configs.
## Expected Behavior
Optimizations like this should be overridden by the Module Federation
plugin in order for them to work.
## Related Issue(s)
https://github.com/nrwl/nx/issues/32329
Fixes #
Added override of splitChunks configs for Nx's Module Federation
plugins.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Upgrades both `@nx/expo` and `@nx/react-native` to use the latest
versions of Expo and React Native. Expo iOS and Android builds work
perfectly.
> [!WARNING]
> This PR explicitly does not modify `@nx/detox`; see comment
[here](https://github.com/nrwl/nx/discussions/19473#discussioncomment-13414668)
on a discussion about why Nx should consider using Maestro instead.
## Tasks
- [x] Fix `@nx/expo` E2E tests
- [x] Verify Android and iOS builds
- [x] Fix `@nx/expo` legacy tests (see comment
[here](https://github.com/nrwl/nx/pull/31497#issuecomment-2961048831))
- [x] Fix Android builds with `@nx/expo`
- [x] Remove `react-test-renderer` from `@nx/expo`
- [x] Add migration to remove dependencies from `@nx/expo`
- [x] `@testing-library/jest-native`
- [x] `react-test-renderer`
- [x] Fix `@nx/react-native` E2E tests (see comment
[here](https://github.com/nrwl/nx/pull/31497#issuecomment-2964720118))
- [x] Verify Android and iOS builds (see comment
[here](https://github.com/nrwl/nx/pull/31497#issuecomment-2960921558))
- [x] Add migrations to update deps for `@nx/react-native`
- [x] Add migration to remove dependencies from `@nx/react-native`
- [x] `@testing-library/jest-native`
- [x] `jest-react-native`
- [x] `react-test-renderer`
- [x] Remove `react-test-renderer` from `@nx/react-native`
## Changes
- Upgrade Expo to v53 and update project templates
- Upgrade React Native to v0.79 and update project templates
- Upgrade React to v19.0
- Upgrade `metro-config` and `metro-resolver` to v0.82.4 (fixes#30557)
- Remove `react-test-renderer`
- Remove `jest-react-native`
- Remove `@testing-library/jest-native`
- Fix bug in `@nx/expo` and `@nx/react-native` application generators
where the generated `package.json` was being overwritten (fixes#31416)
## Links
-
https://github.com/facebook/react/tree/main/packages/react-test-renderer#react-native-testing
-
https://callstack.github.io/react-native-testing-library/docs/migration/jest-matchers
-
https://react.dev/blog/2024/04/25/react-19-upgrade-guide#deprecated-react-test-renderer
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Nx generates an Expo project using SDK v52, and React Native projects
using RN 0.76
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx should generate an Expo project using SDK v53, and React Native
projects using RN 0.79
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31498, #30557, #31416
---------
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- use regex to get test class name
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- remove the filter on the test file name
- use junit first to get test class name
- then if junit does not work, use regex as fallback
- fix warnings of unit tests
- upgrade dev.nx.gradle.project-graph to 0.1.3
in ci, in order to testClassDirs to exist, might need to run
compileTestKotilin or compileTestJava first.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes https://github.com/nrwl/nx/pull/31693
---------
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Running `npx create-nx-workspace` always results in `error.log` in the
new workspace.
## Expected Behavior
No `error.log`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When using build targets with nested library dependencies (App -> lib1
-> lib2),
dependencies from the deepest libraries were not being included in the
generated
package.json due to restrictive target input patterns.
This fix adds an isTransitiveDependency parameter to findAllNpmDeps
function that
uses broader file patterns ({projectRoot}/**/*) when processing
transitive
project dependencies instead of the restrictive build target patterns.
Fixes#30895
## Current Behavior
`joinPathFragments` in nest app generator for the target dir of the
template files is incorrect because it makes the path unix-style which
does not work for Windows.
## Expected Behavior
Use `path.join`
## Related Issue(s)
Fixes#31992
## Current Behavior
Using `joinPathFragments` with `generateFiles` is incorrect as we do not
take into OS-specific paths with `joinPathFragments`.
This is problematic when trying to read files on the system for Windows
users for example.
## Expected Behavior
Use `path.join` to ensure the correct file path is used and passed to
`readdirSync`
## Current Behavior
The `name` property is not set for vitest configs. Vitest will therefore
infer the name for the test suite based off the directory name.
In a monorepo this can cause issues as the directory name may be
repeated but for different contexts.
## Expected Behavior
Set the project name as the name in the test config
## Related Issue(s)
Fixes#32163
# Description
Move Angular Rspack into the Nx repo.
The relevant packages are:
- angular-rspack
- angular-rspack-compiler
## Examples
Adds `Angular Rspack` examples to `examples/angular-rspack` which allow
for demonstration of various configs to use various features within
angular, such as:
- proxy
- ssr
- ssg
- i18n
These examples use `@nx/angular-rspack` with `workspace:*` protocol
allowing for immediate feedback on changes to `angular-rspack` and
`angular-rspack-compiler` to be reflected in these examples.
* fix: errors from ComponentStylesheetResult are hidden
if componentStylesheetBundler.bundleFile/bundleInline doesn't throw an error
but the results still contain errors, the errors will not be reported and
the resulting style sheet will be empty.
* fix: sass/includePaths are not passed to setup function
* feat(angular-rspack,angular-rspack-compiler): reuse existing compilation if exists
* feat(angular-rspack,angular-rspack-compiler): ensure only affected file is rebuilt
* test(angular-rspack): add unit tests for angular-transform-loader
* test(angular-rspack): add unit tests for angular-transform-loader
* fix: format
* fix: wip
* fix: test change
* fix: test change 2
* feat(angular-rspack): add withConfigurations
* test(angular-rspack): add unit tests for withConfigurations
---------
Co-authored-by: Michael <michael.hladky@push-based.io>
* fix: errors from ComponentStylesheetResult are hidden
if componentStylesheetBundler.bundleFile/bundleInline doesn't throw an error
but the results still contain errors, the errors will not be reported and
the resulting style sheet will be empty.
* fix: sass/includePaths are not passed to setup function
* feat(angular-rspack,angular-rspack-compiler): reuse existing compilation if exists
* feat(angular-rspack,angular-rspack-compiler): ensure only affected file is rebuilt
- Added serveStaticTargetName options array with 5 alternative names
- Fixes conflicts when Angular module federation projects create
serve-static targets
- Allows webpack plugin to work with existing Angular setups without
manual nx.json editing
Fixes#32267Fixes#31384
### Summary
Fixes a TypeError in the Nx release-publish executor that occurs when
`npm dist-tag add` fails, preventing users from seeing the actual npm
error message.
### Problem
When `npm dist-tag add` fails during `nx release publish`, users see a
JavaScript TypeError instead of the actual npm error:
```
npm dist-tag add error:
Something unexpected went wrong when processing the npm dist-tag add output
TypeError: Cannot read properties of undefined (reading 'summary')
at runExecutor (/node_modules/@nx/js/src/executors/release-publish/release-publish.impl.js:207:50)
```
### Root Cause
The error handler attempts to access `stdoutData.error.summary` without
checking if `error` exists. Since npm dist-tag outputs errors to stderr
(not stdout), the parsed stdout is typically an empty object `{}`,
causing `stdoutData.error` to be `undefined`. Accessing `.summary` on
`undefined` throws a TypeError.
### Solution
Added optional chaining (`?.`) when accessing error properties to
prevent TypeErrors:
```javascript
// Before (throws TypeError):
if (stdoutData.error.summary) { ... }
// After (safe):
if (stdoutData.error?.summary) { ... }
```
### Example
**Before this fix:**
```bash
$ nx release publish
npm dist-tag add error:
Something unexpected went wrong when processing the npm dist-tag add output
TypeError: Cannot read properties of undefined (reading 'summary')
```
**After this fix:**
```bash
$ nx release publish
npm dist-tag add error:
# (The actual npm error from stderr is shown, or if no JSON error, the code continues gracefully)
```
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
Jest module resolution requires manual maintenance of workspace package
mappings in moduleNameMapper with brittle relative paths that break
across different directory structures.
## Expected Behavior
Dynamic workspace package resolution without manual maintenance, using
absolute paths that work from any test directory.
## Changes
- Remove all workspace package mappings from `jest.preset.js`
`moduleNameMapper`
- Add `@nx/*` and `nx/src/*` resolution to `patched-jest-resolver.js`
- Use absolute paths and efficient workspace root detection for PNPM
- Add file vs directory checks to prevent `EISDIR` errors
### References:
`ts-jest` project references issue:
https://github.com/kulshekhar/ts-jest/issues/1648
## Current Behavior
The TUI dependency view experiences buffer overflow panics when
rendering scrollbars on small or constrained terminal sizes. Users
encounter crashes with messages like "index outside of buffer" at
various coordinates such as (134, 37), (86, 0), (107, 0), etc.
## Expected Behavior
The TUI should handle all terminal sizes gracefully without crashing,
maintaining proper visual rendering of scrollbars and padding elements
while staying within buffer boundaries.
## Key Code Changes
The fix adds **clean, reusable helper functions** for bounds checking to
prevent buffer overflows:
### 1. **New Helper Functions** (lines 216-239):
```rust
/// Check if a rectangle fits within buffer boundaries
fn fits_in_buffer(area: &Rect, buf: &Buffer) -> bool {
area.x + area.width <= buf.area().width && area.y < buf.area().height
}
/// Create a safe rectangle clamped to buffer boundaries
fn clamp_to_buffer(area: Rect, buf: &Buffer) -> Option<Rect> {
if area.width == 0 || area.height == 0 {
return None;
}
let safe_area = Rect {
x: area.x,
y: area.y,
width: area.width.min(buf.area().width.saturating_sub(area.x)),
height: area.height.min(buf.area().height.saturating_sub(area.y)),
};
if safe_area.width > 0 && safe_area.height > 0 { Some(safe_area) } else { None }
}
```
### 2. **Simplified Scrollbar Bounds Check** (lines 478-481):
```rust
// Render scrollbar with bounds checking
if let Some(safe_scrollbar_area) = Self::clamp_to_buffer(outer_area, buf) {
scrollbar.render(safe_scrollbar_area, buf, &mut state.scrollbar_state);
}
```
### 3. **Cleaner Padding Validation** (lines 241-286):
```rust
fn render_scrollbar_padding(outer_area: Rect, buf: &mut Buffer, style: Style) {
const PADDING_WIDTH: u16 = 2;
const RIGHT_MARGIN: u16 = 3;
const WIDTH_PADDING: u16 = 2;
const TOTAL_WIDTH: u16 = PADDING_WIDTH + RIGHT_MARGIN + WIDTH_PADDING;
// Early exit if area is too small or has no height
if outer_area.width < TOTAL_WIDTH || outer_area.height == 0 {
return;
}
// Use helper function for bounds checking
if Self::fits_in_buffer(&top_area, buf) {
// render top padding
}
if Self::fits_in_buffer(&bottom_area, buf) {
// render bottom padding
}
}
```
**Key improvements:**
- **Reduced complexity**: Scrollbar bounds checking went from 11 lines
to 3 lines
- **Reusable helpers**: `fits_in_buffer()` and `clamp_to_buffer()` can
be used throughout the codebase
- **Named constants**: Replaced magic numbers with descriptive constants
- **Clear intent**: Function names clearly express what the code does
## Related Issue(s)
This fixes buffer overflow panics that occur when the terminal user
interface attempts to render scrollbar widgets and padding outside the
available buffer boundaries, particularly on smaller terminal sizes or
when the terminal is resized.
The fix adds minimal bounds checking to:
1. **Scrollbar rendering**: Validates the scrollbar area fits within
buffer boundaries before rendering
2. **Padding rendering**: Ensures top/bottom padding areas don't extend
beyond buffer limits
**Comprehensive test coverage added**: 10 unit tests covering all edge
cases including the specific problematic buffer dimensions that
previously caused panics (45×30, 76×30, 104×30, 135×37, etc.).
Tested across multiple terminal buffer sizes and confirmed no more
buffer overflow panics while maintaining correct scrollbar
functionality.
Previously, the documentation indicated that the nx-cloud fix-ci command was only needed when not using Nx Agents. This has been updated to clarify that the fix-ci command is always required for self-healing CI functionality, regardless of whether Nx Agents are being used or not.
- Updated docs/shared/features/self-healing-ci.md to remove Nx Agents distinction
- Updated blog post to show fix-ci is always required
- Simplified CI configuration examples to show proper placement after nx commands
use resolved module as base path for the file replacement, making sure
the path will be absolute
## Current Behavior
file are replaced using the relative path written on the "with" key.
Using AnalogJs I have problems on using the fileReplacement feature
using vite dev server.
```ts
mode === 'development' &&
replaceFiles([
{
replace: './src/environments/environment.ts',
with: './src/environments/environment.development.ts',
},
]),
```
this is not working because modules are resolved with their absolute
path, so this piece of code:
```ts
const foundReplace = replacements.find((replacement) =>
resolved?.id?.endsWith(replacement.replace)
);
```
is not finding anything with the leading './' (no log on console for
replacement).
Changing to this:
```ts
mode === 'development' &&
replaceFiles([
{
replace: 'src/environments/environment.ts',
with: 'src/environments/environment.development.ts',
},
]),
```
logs `replace "src/environments/environment.ts" with
"src/environments/environment.development.ts"` but vite throws an error
cause it doesn't find the module.
My solution ensures that files are replaced using the base path from the
existing module, replacing only the involved substring.
## Expected Behavior
correct file replacement
## Current Behavior
The heading unit test for the @nx/expo:application generator uses
toHaveTextContent with a strict string comparison. This causes the test
to fail when the heading output includes minor formatting differences or
additional content.

## Expected Behavior
The test should use a regular expression with toHaveTextContent to allow
partial matches.
### Summary
- Enhanced VS Code debugging: All Node applications now automatically
get VS Code
debugging configuration
- Improved webpack source maps: Added `devtoolModuleFilenameTemplate`
for better
debugging experience
- Smart port allocation: Automatically assigns unique debug ports to
prevent conflicts
- Comprehensive file support: Debug configuration supports `.js`,
`.mjs`, and `.cjs` output files
This improvement makes debugging Node applications in Nx workspaces
seamless and consistent across all frameworks and bundlers.
closes: https://github.com/nrwl/nx/issues/14708
This PR enables the Node.js executor to run ESM-only packages (like
`node-fetch`@3) alongside CommonJS modules.
### Changes:
- ESM loader: Implemented custom ESM resolver to handle Nx workspace
library mappings in ESM contexts
- Dynamic execution: Node executor now switches between CommonJS and ESM
loaders based on the detected module format
- esbuild updates: Enhanced esbuild executor to properly handle ESM
output formats and creating a proper `package.json`
closes: #10296
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Enhanced TUI Experience: Intelligent Pane Management and Dependency
Analysis
This PR significantly improves the TUI experience by implementing smart
pane switching and enhanced dependency visualization when tasks fail.
### 🚀 Key Features
#### Automatic Pane Switching for Failed Dependencies
- **Smart Detection**: When a task becomes skipped due to dependency
failures, the TUI automatically identifies the root cause
- **Intelligent Switching**: Panes showing skipped tasks automatically
switch to display the failed dependency's terminal output
- **Duplicate Prevention**: If both panes would show the same failed
task, the layout automatically consolidates to a single pane to avoid
redundancy
#### Enhanced Dependency View for Skipped Tasks
- **Root Cause Analysis**: Skipped tasks now show clear messaging about
which dependency caused the failure
- **Visual Indicators**: Skipped tasks use warning colors (orange
borders, scrollbars) to distinguish them from pending tasks
- **Interactive Navigation**: Users can scroll through dependencies of
skipped tasks to understand the failure chain
#### Centralized Status Icon System
- **Consistent Styling**: Created a centralized `status_icons` module
for consistent task status representation across all components
- **Unified Theming**: All status indicators (checkmarks, spinners,
warning symbols) now use consistent colors and styling
### 🔧 Technical Improvements
#### Code Optimization
- **Simplified Logic**: Replaced complex `matches\!` patterns with
direct equality checks where appropriate (e.g., `status_map.get(dep) ==
Some(&TaskStatus::Failure)`)
- **Cleaner Conditionals**: Converted nested match statements to more
readable if-else patterns using `matches\!` macro
- **Functional Programming**: Used iterator chains with `filter` and
`map` for cleaner collection processing
#### Enhanced State Management
- **Layout Consolidation**: When duplicate panes are detected, the
system automatically switches from double to single pane layout
- **State Consistency**: Proper cleanup of terminal pane data,
dependency view states, and layout areas when consolidating panes
- **Key Event Handling**: Extended keyboard navigation to work with both
pending and skipped tasks in dependency view
### 🎯 User Experience Improvements
#### Better Failure Visibility
- **Immediate Focus**: Failed dependencies are immediately brought to
the user's attention without manual navigation
- **Context Preservation**: When switching panes, the system maintains
proper focus and scroll states
- **Clear Messaging**: Skipped tasks display specific information about
which dependency failed rather than generic messages
#### Responsive Layout
- **Dynamic Adaptation**: Layout automatically adjusts from double to
single pane when appropriate
- **Consistent Theming**: Skipped tasks use warning colors throughout
the interface for immediate recognition
- **Improved Scrolling**: Enhanced scrollbar styling that adapts to task
status (warning colors for skipped tasks)
### 🛠 Files Changed
- **`app.rs`**: Core pane switching logic, layout management, and
automatic failure detection
- **`dependency_view.rs`**: Enhanced skipped task support, root cause
analysis, and improved styling
- **`tasks_list.rs`**: Integration with centralized status icon system
- **`graph_utils.rs`**: New dependency analysis functions for failure
chain detection
This enhancement transforms the TUI from a passive monitoring tool into
an intelligent assistant that proactively helps users understand and
navigate build failures.
## Current Behavior
When generating a new Angular component it imports `CommonModule` by
default.
## Expected Behavior
The `CommonModule` is not needed as often in modern angular because of
the new control flow syntax and the move away from `[ngClass]` and
`[ngStyle]` in favour of `[class]` and `[style]`. It is also not
included by the official angular component generator.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
This PR upgrades both `@module-federation/enhanced` and
`@module-federation/sdk` to
[0.18.0](https://github.com/module-federation/core/releases/tag/v0.18.0),
which uses the transitive dependency koa@3 that contains a patch for the
reported vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2025-8129
## Current Behavior
The `@module-federation/enhanced` and `@module-federation/sdk`
dependencies are on version 0.17.0, which contains a reported
vulnerability related to the use of koa@2.
This causes any consumers of the latest nx version to receive a security
vulnerability warning due to the transitive dependency koa@2 being
installed, e.g. via GitHub security overview:
<img width="938" height="375" alt="Screenshot 2025-08-07 at 23 26 26"
src="https://github.com/user-attachments/assets/d4653940-3a23-45c6-881f-639e4732fdce"
/>
## Expected Behavior
Having nx installed should not raise a security vulnerability warning.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
_n.a._
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Bump `@nx/graph` version with the fix for `nx-dev`. This only happens
for pages with multiple project graphs because the internal
`ProjectGraphClient` assumes a singleton.
## Summary
Implements lazy loading for task graphs to significantly improve initial
load times in the graph visualization UI. Instead of loading all task
graphs upfront, graphs are now fetched on-demand based on user
interaction.
### Key Changes
- On-demand loading: Task graphs are loaded only when needed (when
selecting a target or specific projects)
- Server-side optimization: Efficient task graph generation for specific
targets and projects
- Client-side caching: Intelligent cache management to avoid refetching
already loaded graphs
- Multiple query patterns support:
- `/tasks/:selectedTarget` - Load all projects with that target
- `/tasks/:selectedTarget?projects=app1 app2` - Load specific projects
only
- `CLI: nx <target> <project> --graph`
### Server-side
`packages/nx/src/command-line/graph/graph.ts`
- Added `createTaskGraphsForTargetAndProjects` function for flexible
task graph generation
- Modified `/task-graph.json` endpoint to support query parameters
(projects, target)
- Implemented proper handling for both UI (projects param) and CLI
requests
- Added server-side caching for task graphs (Map-based cache)
### Client-Side
Routes and Loaders (graph/client/src/app/routes.tsx)
- Added selectedTargetLoader with cache-aware fetching
- Integrated task graph cache for optimal data fetching
- Simplified route structure by removing unnecessary metadata loader
Cache Management (graph/client/src/app/task-graph-cache.ts)
- Created sophisticated TaskGraphCache class
- Tracks individual project graphs and fetch status
- Supports partial fetching (only missing projects)
- Handles different query patterns intelligently
Components (graph/client/src/app/feature-tasks/tasks-sidebar.tsx)
- Updated to use selectedTarget loader data
- Graceful handling when no data is available
Service Layer (graph/shared/src/lib/project-graph-data-service/)
- Updated all service implementations to support getSpecificTaskGraph()
- Modified method signature to accept projects: string | string[] | null
- Services updated: Fetch, Local, Mock, NxConsole
Type Definitions (graph/shared/src/lib/)
- Updated ProjectGraphService interface
- Cleaned up type imports and definitions
Build Configuration
- scripts/generate-graph.ts - Simplified generation logic
- scripts/generate-graph-environment.ts - Updated workspace
configuration
- graph/client/webpack.config.js - Updated asset paths
- .gitignore - Updated ignored directories
### Bug Fixes (Latest Update)
### Performance Impact
**Before:**
- Generates ALL task graphs upfront (hundreds/thousands in large repos)
- Blocks main thread during generation
- Large network payloads regardless of usage
- No caching, regenerates on every request
**After:**
- Only generates task graphs when actually needed
- Lightweight metadata response for fast initial load
- Progressive loading as users explore
- Intelligent caching with cache invalidation
- **Stable and error-free**: No console crashes or race conditions
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Chau <25516557+nartc@users.noreply.github.com>
## Current Behavior
There is no method for specifying an exact version for docker version
during `nx release`
## Expected Behavior
Add `--dockerVersion` to provide the user with a manner of providing an
exact docker version
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <Coly010@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The new Pre/Post Tasks Execution API was missing command information
that was available in the old `StoreRunInformationLifeCycle` system.
This made it impossible to track the original command that initiated
task execution, particularly problematic for complex commands like `nx
affected` and `nx run-many`.
## Expected Behavior
With this change, both `PreTasksExecutionContext` and
`PostTasksExecutionContext` now include an `argv: string[]` field
containing the complete raw command line arguments from `process.argv`.
## Related Issue(s)
Addresses the missing command information discussed in
https://github.com/nrwl/nx/discussions/29637
## Changes Made
- **Add `argv: string[]` field** to `PreTasksExecutionContext` interface
- **Add `argv: string[]` field** to `PostTasksExecutionContext`
interface
- **Pass `process.argv` directly** to both execution contexts
- **Remove command parsing functions** (no longer needed)
## Benefits
- **Complete Raw Data**: Provides full `process.argv` including node
executable path, script path, and all arguments
- **No Information Loss**: Every argument preserved exactly as passed to
the process
- **Better Analysis**: Consumers can parse/analyze arguments however
needed
- **Simpler Implementation**: No parsing required - just pass
`process.argv` directly
## Example
Instead of missing command information, plugins now receive:
```typescript
{
workspaceRoot: '/path/to/workspace',
nxJsonConfiguration: { ... },
argv: [
"/usr/bin/node",
"/usr/local/bin/nx",
"affected",
"--target=build",
"--head=HEAD~1"
]
// ... other fields
}
```
This is especially valuable for tracking complex commands like `nx
affected` and `nx run-many` where the original command context was
previously lost.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Commit message validation only happens during the pre-push hook, which
means developers don't get feedback about incorrect commit message
format until they try to push their changes to the remote repository.
## Expected Behavior
Commit messages should be validated immediately when creating a commit,
providing instant feedback and preventing incorrectly formatted commits
from being created in the first place.
## Changes Made
- **Add `.husky/commit-msg` hook** - Validates commit messages before
commit creation
- **Enhance `scripts/commit-lint.js`** - Support both commit-msg hook
and existing pre-push validation
- **Add WIP support** - Allow "wip" messages to bypass format validation
for work-in-progress commits
- **Maintain backward compatibility** - Existing pre-push validation
continues to work
## Benefits
- Immediate feedback on commit message format
- Prevents bad commits from being created
- Supports WIP commits for development workflow
- No disruption to existing validation process
## Related Issue(s)
This improves the developer experience by catching commit message format
issues earlier in the workflow.
## Current Behavior
We currently do not have a method for interpolating Environment
Variables into the `versionSchemes` for Docker Release.
## Expected Behavior
We allow the usage of `{env.VAR_NAME}` to interpolate Environment
Variables
## Current Behavior
The esbuild e2e test `it should generate an app that cosumes a
non-buildable ts library` is failing and causing CI issues.
## Expected Behavior
The test should be temporarily disabled until the underlying issue is
resolved.
## Related Issue(s)
The test failure is due to https://github.com/pinojs/pino/issues/2253.
This test should be re-enabled once that pino issue is resolved.
## Changes
- Added `.skip` to the failing test
- Added a TODO comment referencing the pino issue for when to re-enable
the test
## Current Behavior
- Some resizing (e.g., splitting the terminal) when the TUI shows the
Dependency View causes the TUI to crash with an out-of-bounds issue
while rendering.
- The Dependency View shows the scrollbar as an inner scrollbar instead
of being located in place of the right border (like the Terminal Pane
does).
<img width="828" height="361" alt="image"
src="https://github.com/user-attachments/assets/b9f8de5f-6fb3-401c-9da3-4867cd71ca73"
/>
## Expected Behavior
- The TUI shouldn't crash when showing the Dependency View and a big
resize occurs.
- The Dependency View should show the scrollbar in place of the right
border (like the Terminal Pane does).
<img width="827" height="362" alt="image"
src="https://github.com/user-attachments/assets/a04bf7c0-00ca-485c-9f5f-5a316557bd3b"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When generating a Next.js application with Jest as the unit test runner,
Jest configuration fails because it defaults to looking for
`tsconfig.app.json` which doesn't exist in Next.js projects. Next.js
apps use `tsconfig.json` as their main TypeScript configuration file.
## Expected Behavior
Jest should be configured to use `tsconfig.json` as the runtime
TypeScript configuration for Next.js applications, allowing Jest to
properly resolve TypeScript configurations.
## Related Issue(s)
Fixes#31555
## Summary
Fixes#31602 by adding validation to `create-nx-workspace` to reject
workspace names that start with numbers, preventing confusing errors
later in the workspace generation process.
## Changes Made
- **Added `validateWorkspaceName()` function** - Validates that
workspace names start with letters
- **Integrated validation into workspace creation flow** - Validates
both command-line arguments and interactive input
- **Clear error messaging** - Provides helpful error message with
examples of valid names
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
The repository currently uses outdated versions of the `tmp` and
`@types/tmp` dependencies:
- `tmp` version ~0.2.1
- `@types/tmp` version ^0.2.0
## Expected Behavior
Update to the latest compatible versions of these dependencies:
- `tmp` version ~0.2.4
- `@types/tmp` version ^0.2.6
This will ensure we have the latest bug fixes and improvements from
these packages.
## Related Issue(s)
This is a general dependency update to keep the project up to date.
## Related Issue(s)
[tmp allows arbitrary temporary file / directory write via symbolic link
`dir` parameter](https://github.com/advisories/GHSA-52f5-9888-hmc6)
Fixes Github advisory https://github.com/advisories/GHSA-52f5-9888-hmc6
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when running gradle command with args, it requires to use
--args="--continutous"
for bootRun, which is continuous, i got an error
```
Execution failed for task ':bootRun'.
> Failed to query the value of task ':bootRun' property 'mainClass'.
> Querying the mapped value of task ':resolveMainClassName' property 'outputFile' before task ':resolveMainClassName' has completed is not supported
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
change it when just running `nx run demo:bootRun --continuous`, it will pass --continuous directly to ./gradlew.
any args not in the list
```
new Set([
'taskName',
'testClassName',
'args',
'excludeDependsOn',
'__unparsed__',
]);
```
will passed as arga to the ./gradlew
i try to add `__unparsed__`, but it is always empty.
for bootRun, i add excludeDependsOn as false in nx.json and that error
goes away.
```
"bootRun": {
"options": {
"excludeDependsOn": false
}
}
```
so for all continuous task, i changed excludeDependsOn as false in the
option
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When Nx Cloud is enabled, task details are not stored in the task
history. This results in features like local flaky task detection or
displaying estimated task durations in the TUI not working.
## Expected Behavior
Task details should always be stored in the task history regardless of
Nx Cloud being enabled.
## Current Behavior
The Gradle plugin does not normalize project root paths when creating
project nodes, which can lead to inconsistent path handling across
different operating systems and file systems.
## Expected Behavior
Project root paths should be normalized using `normalizePath` from
`@nx/devkit` to ensure consistent path handling regardless of the
operating system or file system.
## Related Issue(s)
This is a general improvement to prevent potential path-related issues
in Gradle project detection and configuration.
add basic registry page at /plugin-registry
Note: most of this work was aimed at getting the content to the page, we
can come back to making the plugin registry page prettier and have more
functionality in future PRs

resolves: DOC-71
This is to ensure that the NX_CLOUD_AUTH_TOKEN is treated the same as
ACCESS_TOKEN.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
If there isn't any Nx Cloud properties in the `nx.json`, the CLI doesn't
recognize `NX_CLOUD_AUTH_TOKEN` as a environment variable to communicate
with Nx Cloud. If I provide just `NX_CLOUD_ACCESS_TOKEN`, the CLI does.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Since `AUTH_TOKEN` is suppose to be an alias for `ACCESS_TOKEN`, the
behavior should be the same.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
This plugin is listed first, despite being last maintained 3 years ago.
## Expected Behavior
We should not show unmaintained projects when there are others covering
the same technology that are maintained
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
E2E tests are distributed to agents but run sequentially (1 per agent),
underutilizing agent capacity.
## Expected Behavior
E2E tests run in parallel (2-3 per agent) with proper port allocation to
prevent conflicts.
## Changes Made
- Add port allocation utilities to prevent port conflicts in parallel
tests
- Configure CI agents to run 2-3 e2e tests in parallel per agent
- Keep `e2e-release` sequential due to shared git state requirements
### MISC
- On CI browsers (cypress/playwright) are already pre-installed, we
improve this by short-circuiting the installation.
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
The website should still function when Brave shield is up.
`window.Cookiebot` defaults to `<script id="Cookiebot">` when the script
is blocked... so the original check is not fully correct.
## Current Behavior
React Router requires using a Vite plugin. This means that during the
CNW flow, if a user selects `Yes` to the prompt for `React Router for
SSR`, we do not prompt them for `bundler`.
This can be confusing for users that expect to be able to select
bundler.
## Expected Behavior
Clarify during the prompt for React Router for SSR that Vite will be
selected as the bundler.
intro docs for nx-cloud aren't needed as it's duplicate information and
should instead be covered by the regular intro flows, which now mention
nx cloud.
Moved over some content into applicable pages, such as `nx g
ci-workflow` command and calling out `nx connect` command in places.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
- The logic to detect whether the workspace uses the TS solution setup
restricts the top-level properties in the `tsconfig.base.json` file and
only allows `compilerOptions`. This prevents extending from other
tsconfig files in the `tsconfig.base.json` file.
- Generating projects in a workspace without any known root tsconfig
files (`tsconfig.json`, `tsconfig.base.json`) results in the old setup
being generated. Workspaces without root TS configuration should be able
to use the TS solution setup.
## Expected Behavior
- The logic to detect whether the workspace uses the TS solution should
not restrict the top-level properties in the `tsconfig.base.json` file.
The only things required for the TS solution setup are to have
`composite: true` and `declarations` enabled.
- The TS solution setup should be used when generating projects in a
workspace without any known root tsconfig files (`tsconfig.json`,
`tsconfig.base.json`).
## Related Issue(s)
Fixes#32134
Add cookie consent for website using
[Cookiebot](https://www.cookiebot.com).
Moves all tracking logic into
`window.addEventListener('CookiebotOnAccept', ...)` callback.
when using worktrees I'm getting an error like
```
❯ git worktree add ../test-feat-a feat-a
Preparing worktree (checking out 'feat-a')
Updating files: 100% (9887/9887), done.
HEAD is now at c14325d3d3 feat(nx-dev): update nx.dev homepage (#32132)
fatal: bad object 0000000000000000000000000000000000000000
husky - post-checkout script failed (code 128)
```
this is due to our post-checkout husky hook. This PR fixes it
## Current Behavior
Running the `@nx/react:remote` generator as a standalone generator in a
TS Proj Workspace will result in the generator throwing an error that
`@org/remoteName` is invalid.
## Expected Behavior
Ensure we normalize the project name early to disregard the scope that
is added.
This matches the behaviour of the host generator.
## Related Issue(s)
Fixes#30807
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, the project name is just last part to full gradle path, for
example:
- gradle path for :parent-path:project-name, it currently takes only
project-name
this might create duplicates in a large project
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- change the name to match gradle path exactly, then the project name
would just be the gradle path
- for example, the gradle command would be `./gradlew
:parent-path:project-name:build`, nx command would be `nx run
:parent-path:project-name:build`
https://linear.app/nxdev/issue/NXC-2917/fix-terminal-ui-compatibility-with-gradle-naming
need to be fixed before this pr
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behaviour
E2e tests fail with Node 24 because npm 11 writes deprecation warnings
to stderr even on successful commands, causing registry version
resolution to fail.
## Expected Behaviour
Registry version resolution should work with npm 11 warnings in stderr.
## References
```
NX Unable to resolve the current version from the registry: "registry=http://localhost:4873" tag=latest. Please ensure that the package exists in the registry in order to use the "registry" currentVersionResolver. Alternatively, you can use the --first-release option or set "release.version.fallbackCurrentVersionResolver" to "disk" in order to fallback to the version on disk when the registry lookup fails.
```
https://staging.nx.app/runs/l9kRV3E6ST
- use lfs for imgs
- copy over concepts to astro site.
- note: some of the markdoc impl hasn't been done yet, so those are left
as plain text. things like the project view, graph, side-by-side still
need to be moved.
closed: DOC-67
The federationRuntime option not longer exists in experiments, use
asyncStartup to enable asynchronous container startup.
## Current Behavior
When creating a new project with module federation (`nx g
@nx/angular:host host --remotes=remote1,remote2 --ssr`) and then try to
to run the `serve-ssr` target (`nx serve-ssr host`) you get this error:
<img width="1615" height="511" alt="image"
src="https://github.com/user-attachments/assets/19819020-821b-4422-83ae-88203018b981"
/>
## Expected Behavior
It should serve the application using SSR.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
As it currently stands, there is no (easy) way to get HMR support
working with Rspack + Nest by using the `@nx/rspack:rspack` build
executor and `@nx/js:node` serve executor because we need to turn
`watch: false` in the serve executor (as we don't want it to watch and
call the build again) but that in turn makes the rspack build executor
not use `compiler.watch` this only building once.
Due to the way options are passed through to the executor (via
`runExecutor`) even if we do:
```
"options": {
"buildTarget": "myapp:build",
"buildTargetOptions": {
"watch": true
},
"watch": false
}
```
The `watch: false` overwrites it.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We should be able to have the Rspack executor abide by whatever the
`watch` configuration is that is returned from our `rspack.config.ts`
file for the application.
There is precedent for abiding by the tools configuration file vs the
executor option, the Webpack executor already does it.
The Webpack compiler is started in watch mode if the `watch` flag is
true in the webpack config itself vs. strictly abiding by the executors
options. Based on
https://github.com/nrwl/nx/issues/1992#issuecomment-2826664777 I could
do what I want, but I am using Rspack not Webpack.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/issues/1992
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
At some point in time, we had support for Module Federation aliases, and
I noticed some of our examples broke in the latest versions of Nx.

This is an attempt to regain that support with some normalization of
Module Federation project names.
## Expected Behavior
We need to have the mapping back of aliases in the format:
```typescript
const mfConfig = {
// ...
"@nx-mf/remote": "_nx_mf_remote@http://localhost:3001",
// ...
}
```
## Related Issue(s)
https://github.com/nrwl/nx/issues/31346
Fixes #
Add a function specific to parse Federated names into resolvable
JavaScript vars.
Use this function in every place a `str.replace(/-/, '_')` is being
used.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
We currently generate a Dockerfile for node applications that only takes
into account npm.
This means that if the workspace is using yarn or pnpm then when we
prune the lockfile, we have an incorrect lockfile in the output folder
for the docker build.
## Expected Behavior
Ensure the generated Dockerfile is compliant for the package manager
used in the workspace
## Current Behavior
Framework deps such as `express` are not added to the app's package.json
## Expected Behavior
Ensure framework deps are added to app's package.json
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`graph-client` application uses `@nx/graph/legacy`
## Expected Behavior
The entire repo should be free of `@nx/graph/legacy` imports. Existing
behaviors of the graph should be maintained.
## Current Behavior
When multiple commands use the same option, we follow a pattern of using
`withX` helpers.
The `dockerVersionScheme` option does not follow this pattern.
## Expected Behavior
Create `withDockerVersionSchemeOptions` to follow the pattern
## Current Behavior
Running tasks for Angular projects that use Angular CLI builders can
result in validation errors when the project or workspace configurations
contain Nx-specific properties.
## Expected Behavior
Running tasks for Angular projects that use Angular CLI builders
shouldn't result in validation errors when the project or workspace
configurations contain Nx-specific properties.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running `nx prune api` it fails with:
```
NX The following outputs are invalid:
- apps/api/dist/package.json
- apps/api/dist/package-lock.json
```
## Expected Behavior
Prune should work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Jest fails to parse TypeScript config files with ES module syntax on
Node.js 24 with error:
```
Error: Jest: Failed to parse the TypeScript config file
SyntaxError: Unexpected token 'export'
```
## Expected Behavior
Jest should successfully parse TypeScript config files on Node.js 24.
## Related Issue(s)
This occurs because Jest 30 + Node.js 24 can't parse TS configs with
imports without the `--no-experimental-strip-types` flag.
Related to: https://github.com/jestjs/jest/issues/15682
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Running `nx release changelog [version]` fails for docker images
## Expected Behavior
it should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
If user sets `registryUrl` to `docker.io` then release fails.
## Expected Behavior
We should support setting it to `docker.io` even though it's not
necessary.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`nx release` supports `--dockerVersionScheme`
`nx release version` does not.
## Expected Behavior
`nx release version --dockerVersionScheme` should work
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, in the repo, the version is 0.1.0
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
since i modify the new code, i need to publish a version of
https://plugins.gradle.org/plugin/dev.nx.gradle.project-graph
change the version to 0.1.4
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
See:
https://nx-dev-git-docs-node-docker-nrwl.vercel.app/features/manage-releases
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
Generating a node application does not set the outputs for the prune and
copy workspace modules tasks.
## Expected Behavior
Ensure the outputs are set so that cache can be restored correctly
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Storybook docgen assume `flow` types when encountering `import type`
syntax.
## Expected Behavior
Ensure `reactDocgen` is set to typescript
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when run bootJar and bootRun, i got this error:
```
> Querying the mapped value of task ':application:resolveMainClassName' property 'outputFile' before task ':application:resolveMainClassName' has completed is not supported
```
both bootJar and bootRun dependsOn resolveMainClassName. however, when
it runs with excludeDependsOn, the gradlew command will be `./gradlew
:app:bootRun --exclude-task :app:resolveMainClassName`. when running the
command like that, it will cause an issue
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
for bootJar and bootRun, hardcode excludeDependsOn to false
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There is a runtime issue in project graph pruning where we attempt to
eagerly traverse workspace nodes when they may not exist.
## Expected Behavior
Ensure the workspace node exists before traversing it.
## Current Behavior
The `@nx/node:setup-docker` generator does not initialize the docker
plugin.
## Expected Behavior
The `@nx/node:setup-docker` generator sets up the docker plugin
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When using `nx release` with Docker projects, the
`release.releaseTagPattern` defined at the root level is not inherited
by release groups. Users must explicitly specify the `releaseTagPattern`
at both the root level AND within
`release.groups.<group>.releaseTagPattern` for it to work correctly when
using 'independent' releases.
Example configuration that doesn't work as expected:
```json
{
"release": {
"releaseTagPattern": "release/{projectName}/{version}",
"groups": {
"apps": {
"projectsRelationship": "independent",
// releaseTagPattern is not inherited here
}
}
}
}
```
## Expected Behavior
The `release.releaseTagPattern` should be automatically inherited by
group configurations, following the same inheritance pattern as other
release configuration properties. Users should only need to specify the
pattern once at the root level unless they want to override it for
specific groups.
With this fix, the above configuration will work correctly, and the
docker releases will use the `release/{projectName}/{version}` pattern
for git tags.
## Related Issue(s)
Fixes #
We should match the version which we install of `@rspack/core` to be the
same as `@nx/rspack` as the mismatch can cause errors:
https://staging.nx.app/runs/McxmSeecWa/task/e2e-rspack%3Ae2e-local
```
> rspack build --node-env=production
● ━━━━━━━━━━━━━━━━━━━━━━━━━ (10%) building builtin:swc-loader??ruleSet[1].rules[2].use[0]!/../my-rspack-react/apps/my-rspack-react/src/../repos/my-rspack-react/node_modules/@nx/rspack/node_modules/@rspack/core/dist/cssExtractLoader.js:141
}) : result, dependencies.length > 0 && this.__internal__setParseMeta(PLUGIN_NAME, JSON.stringify(dependencies)), callback(null, resultSource, void 0, data);
^
TypeError: this.__internal__setParseMeta is not a function
at /../my-rspack-react/node_modules/@nx/rspack/node_modules/@rspack/core/dist/cssExtractLoader.js:141:58
at ../my-rspack-react/node_modules/@nx/rspack/node_modules/@rspack/core/dist/cssExtractLoader.js:142:11
at /../my-rspack-react/node_modules/@rspack/core/dist/index.js:3435:255
at /../my-rspack-react/node_modules/@rspack/core/dist/index.js:3431:120
Node.js v22.16.0
```
This version is also the same as in our migrations for `@nx/rspack`.
References:
https://github.com/nrwl/nx/blob/master/packages/rspack/package.json#L32https://github.com/nrwl/nx/blob/master/packages/rspack/migrations.json#L81
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
before:
gradle tutorial didn't match with other tutorials format
after:
gradle tutorial fits format of other tutorials
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Currently users running `nx release` without a correct setup will see an
unhelpful message:
```
NX Release group "__default__" matches no projects. Please ensure all release groups match at least one project:
The relevant config is defined here: nx.json
```
This change provides a link to https://nx.dev/features/manage-releases
so users can find the correct information to fix their setup.
This is particular useful when users are curious or checking out `nx
release` for the first time, and may not realize that there are set up
steps.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Error message is not helpful
## Expected Behavior
Provide a link for users to find the info they need
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
In certain cases, `execSync` was not returning data correctly based on
`stdio` settings.
## Expected Behavior
Use `exec` and handle stdout manually to ensure information is retrieved
and processed correctly
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Task ordering for running `prune` was not correct as the
`prune-lockfile` and `copy-workspace-modules` targets need the build to
have succeeded first.
## Expected Behavior
Ensure `prune-lockfile` and `copy-workspace-modules` depends on `build`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/node:app` generator does not set up `prune` as a target to
prune the lockfile for TS Solution based repos. Nor does it handle
workspace modules that may be used by the application.
## Expected Behavior
Create the following targets when generating a node application
- `copy-workspace-modules`
- `prune-lockfile`
- `prune`
The latter should act as a noop, depending on the other two targets to
ensure a fully pruned output
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Docker Version Utils will interpolate `{currentDate|YY.MM.DD}` with the
local timezone.
## Expected Behavior
Force the formatting to be UTC
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Bun's text-based lockfile is not parsed correctly when collecting nodes
and dependencies for the project graph.
## Expected Behavior
Bun's text-based lockfile should be parsed correctly when collecting
nodes and dependencies for the project graph.
## Related Issue(s)
Fixes#31862Fixes#31433Fixes#31338Fixes#30607Fixes#30603Fixes#30466Fixes#30460Fixes#30362Fixes#30302
## Current Behavior
The post install hook creates the project graph... which contains quite
a bit of work and appears to be hanging at times.
## Expected Behavior
The post install hook is slimmer, and has a hard timeout of 30s to avoid
hanging.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31694
## Current Behavior
We do not currently have a plugin for docker to infer targets such as
- build
- run
## Expected Behavior
The Docker Plugin should remain agnostic between tech stacks, but should
allow for the containerization of projects.
It should support initially the ability to build and run images by
inferring targets on projects that contain a Dockerfile.
`nx release` should be expanded to support releasing Docker images to
registries
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When you run `npx -y create-nx-workspace@latest nameofmyrepo-monorepo
--preset=apps --nxCloud=skip --skip-install --skip-prettier --verbose`
it fails because `--skip-install` is passed to the `new` generator (even
though it's not an CNW option), which means no `node_modules` to resolve
`nx/bin/nx`.
## Expected Behavior
Running CNW should not skip install ever.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31834
- Add a label to the TUI terminal pane with the live/actual task
execution duration and estimated duration based on available task
history
- Consolidate the `INTERACTIVE`/`NON-INTERACTIVE` information at the
bottom alongside the instructions to toggle
- Handle smaller available width and hide labels accordingly, with a
priority of Task Name, Duration, Tab to Focus help label when deciding
what to show
- Increase the tick rate to calculate live times every 100ms
## Current Behavior
The ESLint flat config generator crashes with "Debug Failure. False
expression: Negative numbers should be created in combination with
createPrefixUnaryExpression" when running `nx g
@nx/eslint:convert-to-flat-config`.
## Expected Behavior
The generator should handle negative numbers properly and complete
without errors.
## Related Issue(s)
Fixes#31955
Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvelperez@users.noreply.github.com>
## Current Behavior
The `pnpm-parser` does not handle when `importerSnapshot.dependencies`
is undefined and is trying to access indexes of the object.
## Expected Behavior
Add a check to make usre `importerSnapshot.dependencies` exists before
accessing values within it
Allow application names starting with @ symbol to support scoped
packages like @myorg/myapp.
Updated the validation pattern to match the library generator pattern
that already supports this.
Fixes#31229
Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvelperez@users.noreply.github.com>
## Current Behavior
The `@nx/js:typescript-sync` generator does not provide details about
the out-of-sync files. It only returns a generic message.
<img width="1155" height="107" alt="image"
src="https://github.com/user-attachments/assets/6fc170cc-6aab-49cd-b17d-764da57b840a"
/>
## Expected Behavior
The `nx sync:check` command should display additional details about the
out-of-sync files if provided by the sync generators. The
`@nx/js:typescript-sync` generator should provide details about the
out-of-sync files.
<img width="1140" height="214" alt="image"
src="https://github.com/user-attachments/assets/3c74df6c-7dc3-4462-b0c9-75bce5bf81b4"
/>
Note: the `nx sync` command will still only display the generic message
to avoid cluttering the logs and the details can be seen in the changes
made to files.
## Current Behavior
When building the project graph nodes, the node `type` is always
inferred as `lib` when `projectType` is not set.
## Expected Behavior
When building the project graph nodes, the node `type` should be derived
correctly using the same logic used by generators when `projectType` is
not set.
## Related Issue(s)
Fixes#31983
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Caleb Ukle <caleb.ukle+github@pm.me>
## Current Behavior
The TUI (Terminal User Interface) is enabled for all environments,
including AI agents like Claude Code, which can cause issues with
AI-driven development workflows.
## Expected Behavior
When an AI agent is detected through environment variables, the TUI
should be automatically disabled to prevent interference with AI-driven
interactions.
## Related Issue(s)
This change improves the developer experience when using AI agents by
automatically detecting their presence and adjusting the interface
accordingly.
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The native Rust code in nx_walker and logger components was creating
threads that weren't being properly cleaned up, leading to resource
leaks over time.
## Expected Behavior
With these changes, threads are properly managed and cleaned up to
prevent resource leaks, improving the overall stability and performance
of Nx operations.
## Related Issue(s)
This addresses native thread leak issues discovered during development.
Fixes thread leaks in native components
## Current Behavior
The TUI's arrow key handling uses only alternate screen mode detection
to determine whether to send arrow key sequences to programs or handle
scrolling locally. This works for programs like vim, less, and git log,
but fails for enquirer-style prompts that use cursor positioning without
alternate screen mode.
## Expected Behavior
Arrow key handling should properly detect when interactive programs like
enquirer are running and send arrow key sequences to them for
navigation, while maintaining TUI scrolling for regular command output.
## Related Issue(s)
This improves the TUI's interaction with enquirer prompts and similar
interactive programs that don't use alternate screen mode but still need
to receive arrow key input.
## Changes Made
- **Enhanced Detection Logic**: Added `handles_arrow_keys()` method that
detects interactive programs using:
- Alternate screen mode detection (vim, less, git log, htop)
- Cursor movement sequence detection (enquirer-style programs)
- **Refactored Arrow Key Handling**: Updated `handle_arrow_keys()` to
use improved detection
- **Consistent Mouse Event Handling**: Updated `send_mouse_event()` to
use same detection logic
- **Comprehensive Tests**: Added tests for interactive program detection
patterns
## Technical Details
The new `handles_arrow_keys()` method checks for:
1. **Alternate screen mode** - Strong indicator for programs like vim,
less
2. **Cursor control sequences** - Detects enquirer-style programs that
use:
- `\x1b[?25l` / `\x1b[?25h` (hide/show cursor)
- `\x1b[H` (cursor positioning)
- `\x1b[A/B/C/D` (cursor movement)
This ensures enquirer prompts receive proper arrow key navigation while
maintaining backward compatibility with existing TUI scrolling behavior.
Fixes arrow key navigation in enquirer prompts and similar interactive
programs.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When resolving "./" imports from a nested project, the target project
locator incorrectly resolves to the parent project instead of the
current project.
For example, given:
- `parent-project` at `libs/parent-path`
- `child-project` at `libs/parent-path/child-path` (nested 1 level under
parent)
When importing "./" from `libs/parent-path/child-path/module.ts`, it
incorrectly resolves to `parent-project` instead of `child-project`.
## Expected Behavior
"./" imports from within a nested project should resolve to that
project, not its parent.
## Related Issue(s)
Fixes#31980
### Changes
- add `tsBuildInfoFile` option all packages `tsconfig.lib.json`
- fix `legacy-post-build` executor via `copy-asset-handler` to ignore
dirs that we won't be copying from to improve glob search efficiency.
## Current Behavior
- When the minimal view in the TUI is shown, some borders are initially
shown for a fraction of a second.
- When rendering terminal panes, the scrollbar can be wrongly shown for
a fraction of a second when the PTY dimensions are stale. This looks
like the scrollbar flashes.
## Expected Behavior
- When the minimal view in the TUI is shown, no borders should ever be
shown.
- The scrollbar should only be shown when rendering terminal panes when
needed.
## Current Behavior
Angular tests run with other tests in parallel causing memory issues.
## Expected Behavior
Angular tests are isolated to run on their own agent to prevent memory
issues.
## Related Issue(s)
This is a maintenance improvement to prevent CI memory issues.
Fixes nrwl/nx internal issue
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Security package is removed. This resolution fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remove the resolution.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Angular projects use `jest-preset-angular` v14, which doesn't support
Jest v30.
Note: When support for Jest v30 was added, `jest-preset-angular` didn't
have a version explicitly supporting it.
## Expected Behavior
Angular projects should use `jest-preset-angular` v15, which supports
Jest v30.
## Related Issue(s)
Fixes#32024
BREAKING CHANGE: Stylus (.styl) files are no longer supported.
Stylus has been deprecated and was slated to be removed in Nx 20.
Now we are removing it.
- Remove `stylus` and `stylus-loader` dependencies
- Remove `deprecated-stylus-loader` file
- Remove `stylus` configuration from `webpack` and `rspack` plugins
- Remove `'styl'` option from `rspack` generator schemas and TypeScript
definitions
- Remove `.styl`/`.stylus` extensions from executor schema file
completion globs
MISC
Even though we removed stylus from our repo as a dependency other
projects in the workspace still have stylus as an optional dependency:
- Vite
- Astro
So we add a placeholder for it since on npm registry there is a
_security_ placeholder.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
`npm-parser` for lockfile pruning is trying to run `Object.entries` on a
potentially null or undefined object (packageJson.dependencies).
## Expected Behavior
Ensure `?? {}` is used when evaluating `Object.entries`
### Changes
The stylus npm registry has been compromised.
So can resolve `stylus` with `npm:ignore@*` it tells the package manager
to replace the dependency with the ignore package from npm registry.
Until we can merge: https://github.com/nrwl/nx/pull/32035
## Current Behavior
In the TUI, opening the Terminal Pane for a task with the space bar,
navigating to another task, and pressing "1" to pin it, results in the
terminal pane displaying the output of the task for which the space bar
was pressed initially instead of the pinned task.
## Expected Behavior
Pinning tasks in the TUI should work correctly and always display the
output of the pinned task.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
improve doc page where people land after running `nx init`
- clarify how to use nx after setup
- make sure to update CI configs
- how to finish nx cloud setup if opted-in for cloud
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
add documentation for build-ci target for gradle
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
currently there is no build-ci target documented
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
tutorial intro language is subpar
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
improve tutorial intro language
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The migration for Jest v30 is missing package updates for `ts-jest` and
`jest-util`.
## Expected Behavior
The migration for Jest v30 should have package updates for `ts-jest` and
`jest-util`.
## Current Behavior
When running the Jest `replace-removed-matcher-aliases` migration on
Windows, it resolves the spec files incorrectly and fails.
## Expected Behavior
Running the Jest `replace-removed-matcher-aliases` migration should work
correctly regardless the OS.
## Related Issue(s)
Fixes#31991
## Current Behavior
When using the TS solution setup, tasks inferred by the
`@nx/next/plugin` do not have the `@nx/js:typescript-sync` generator
set.
## Expected Behavior
When using the TS solution setup, tasks inferred by the
`@nx/next/plugin` should have the `@nx/js:typescript-sync` generator
set.
## Related Issue(s)
Fixes#31983
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When running ESLint using the `@nx/eslint:lint` executor with `--quiet`
and `--fix`, and there are errors, no fix is made, and the task
incorrectly succeeds.
This is a regression introduced by
https://github.com/nrwl/nx/commit/9406d2bfdb15e33ad85345533f96f6136130e817,
which updated the executor to not fix warnings when `--quiet` is used,
but the solution was incorrect.
## Expected Behavior
When running ESLint using the `@nx/eslint:lint` executor with `--quiet`
and `--fix`, and there are errors, fixes should be applied, and the task
should succeed if there are no remaining errors. It should not fix
warnings.
## Related Issue(s)
Fixes#31868
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Jest is currently pinned to version 29 due to compatibility issues with
synckit@0.11.10 that caused TypeErrors in Jest tests.
## Expected Behavior
With the synckit compatibility issue resolved in v0.11.11, Jest can be
safely upgraded back to version 30, providing users with the latest Jest
features and improvements.
## Related Issue(s)
The underlying synckit compatibility issue has been fixed:
https://github.com/un-ts/synckit/issues/252
This reverts the temporary downgrade that was applied in #31981.
Fixes the Jest version regression by restoring Jest 30 support.
Updating Nx from 21.3.0-beta.7 to 21.3.0-rc.0
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
## Current Behavior
When running nx-cloud commands like `nx start-ci-run` in environments
without local Nx installation, users get this error:
```
NX Could not find Nx modules at "/path/to/workspace".
Have you run npm/yarn install?
```
This prevents legitimate use of nx-cloud commands in CI environments
that don't have local Nx modules installed.
## Expected Behavior
nx-cloud commands should be able to run using the global Nx installation
without requiring local Nx modules, since they're designed to work
independently of the local workspace setup.
## Related Issue(s)
This fixes scenarios where users run `nx start-ci-run` in CI
environments without local Nx installation.
## Changes Made
- Added `isNxCloudCommand()` function to identify nx-cloud commands:
`start-ci-run`, `login`, `logout`, `connect`, `view-logs`, `fix-ci`,
`record`
- Modified the missing local installation check to exclude nx-cloud
commands
- Added execution path for nx-cloud commands when no local Nx is
available - they now run via the global nx-commands module
- Preserves the error check for regular Nx commands that require local
installation
## Testing
- Verified that nx-cloud commands are properly identified
- Confirmed that regular Nx commands still show the error when local Nx
is missing
- Ensured nx-cloud commands can run without local Nx installation
## Current Behavior
The `create-nx-workspace` command only creates local git repositories
and does not provide any integration with GitHub for pushing the newly
created workspace to a remote repository.
## Expected Behavior
The `create-nx-workspace` command should offer users the option to
automatically create a GitHub repository and push their new workspace to
it using the GitHub CLI (`gh`), streamlining the workflow from workspace
creation to remote repository setup.
## Changes Made
- **New Options**: Added `skipGitHubPush` and `verbose` command-line
options
- **GitHub Integration**: Integrated GitHub repository creation and push
workflow into the main create-workspace process
- **Interactive Prompts**: Added user-friendly prompts for GitHub
repository creation with validation
- **Async Refactor**: Converted git utilities from sync to async/await
pattern for better error handling
- **Bug Fix**: Fixed `gh repo create` command to include `--source` flag
for proper directory specification
- **Error Handling**: Added comprehensive error handling with optional
verbose logging
## Implementation Details
### New CLI Options
- `--skipGitHubPush`: Skip pushing to GitHub via gh CLI (default: false)
- `--verbose` (`-v`): Enable verbose logging for detailed error messages
### Workflow Integration
- After successful git initialization and commit, prompts user if they
want to push to GitHub
- Uses `gh` CLI to authenticate and create repository
- Provides default repository name format (`username/workspace-name`)
- Validates repository name format
- Handles errors gracefully with helpful fallback instructions
### Technical Changes
- Refactored `git.ts` utilities to use `execAndWait` and `spawnAndWait`
for better async handling
- Added `pushToGitHub` function with comprehensive error handling
- Updated `CreateWorkspaceOptions` interface with new optional
properties
- Enhanced command-line argument parsing in `yargs-options.ts`
## Testing
The changes maintain backward compatibility - existing workflows
continue to work unchanged. The new GitHub integration is opt-in and
gracefully handles cases where:
- GitHub CLI is not installed
- User is not authenticated with GitHub
- Network issues prevent repository creation
- User chooses not to push to GitHub
## Related Issue(s)
This PR enhances the user experience by providing seamless integration
between workspace creation and GitHub repository setup.
## Current Behavior
The static build for a React Module Federation application can suffer
from issues where react is not initialised on load.
This is caused by Module Federation trying to lazily instantiate the
library.
## Expected Behavior
Ensure that React deps are marked as eager in the module federation
config to allow them to be instantiated on load
## Related Issue(s)
Fixes#31612
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <Coly010@users.noreply.github.com>
## Current Behavior
The workspace packages logic for pruning lockfile assumes the
jsPackageName is the same as the node name.
This is not always the case.
## Expected Behavior
Ensure the actual node name is used to reference the node in the project
graph
## Summary
- support configuring max cache size via NX_MAX_CACHE_SIZE env var
- show max cache size from env var in `nx report`
- document the new `NX_MAX_CACHE_SIZE` option
- test NX_MAX_CACHE_SIZE in e2e cache tests
## Testing
- `pnpm nx run-many -t lint,test,build` *(failed: NX Lexer error)*
- `pnpm test:e2e` *(failed: Command "test:e2e" not found)*
- `pnpm e2e` *(failed: Failed to process project graph)*
------
https://chatgpt.com/codex/tasks/task_e_68503bff022c832c8c014c61432aa2ed
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running Nx tasks without the daemon, tui, and using run-commands w/
serially running tasks, its possible that Nx will not properly terminate
on receiving SIGTERM.
## Expected Behavior
Nx properly shuts down child tasks on receiving SIGTERM
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When an Nx workspace exists inside a subdirectory of another git
repository or when parent directories contain `.gitignore` files, those
ignore patterns can affect file traversal within the Nx workspace,
making project resolution non-deterministic.
For example, if a workspace is inside a directory with `*` in its
`.gitignore`, Nx fails to properly traverse workspace files.
## Expected Behavior
Nx should respect `.gitignore` files in a smart way:
- **Workspace is git root**: Ignores all parent gitignore files
- **Workspace nested in git repo**: Respects gitignore files within the
git repository but ignores any gitignore files above the git root
- **No git repo found**: Respects all parent gitignore files (backwards
compatibility)
This ensures deterministic project resolution regardless of where the
workspace is located.
## Related Issue(s)
Fixes#27368, #28000, #27295, #28123, #29413
Supersedes #29245 (incorporates feedback from @Cammisuli and @adamalton)
## Implementation Details
The fix implements smart gitignore boundary detection that:
1. **Finds the nearest git repository root** by walking up the directory
tree
2. **Uses built-in git ignore handling** for maximum compatibility
3. **Disables automatic parent discovery** and manually adds only
relevant `.gitignore` files
4. **Stops at git repository boundaries** to prevent external gitignore
files from affecting the workspace
This approach addresses the feedback from the original PR #29245 to
handle both:
- Standalone workspaces (where workspace root = git root)
- Workspaces nested within larger git repositories
The solution leverages the `ignore` crate's existing functionality while
providing precise control over which ignore files are considered.
## Test Plan
- [x] Unit tests covering all three scenarios
- [x] Workspace is git root: ignores parent gitignores
- [x] Workspace nested in git repo: respects repo gitignores, ignores
external ones
- [x] No git repo: uses all parent gitignores (backwards compatibility)
- [x] All existing walker tests continue to pass
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Adam Biggs <adam.biggs@lmpm.com>
## Current Behavior
The `nx watch` command currently requires a file change before executing
the specified command for the first time.
## Expected Behavior
Add support for running the watch command once before watching for
changes. This is useful when you want to see results immediately without
having to make a file change first.
## Related Issue(s)
N/A - Feature addition
## Implementation Details
- Added a new `--initialRun` flag (alias `-i`) to the `nx watch` command
- When the flag is set to `true`, the command executes once before
setting up the file watcher
- Works with both `--all` mode and specific project selections
- Default value is `false` to maintain backward compatibility
- Documentation has been updated to reflect this new option
## Usage Examples
```bash
# Run the command initially, then watch for changes
nx watch --all --initialRun -- echo "Running command"
# Or with the alias
nx watch --projects=myapp -i -- npm run test
```
## Test Plan
- [ ] Manual testing with `--all` flag
- [ ] Manual testing with specific projects
- [ ] Verify command runs initially when flag is set
- [ ] Verify command does not run initially when flag is not set
(default behavior)
- [ ] Documentation generated correctly
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The daemon doesn't log several things which would be helpful when
troubleshooting issues
## Expected Behavior
There are several more logs
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/webpack` and `@nx/rspack` packages depend on a pinned version
of `less` and `less-loader`.
This causes an issue with dependency resolution for packages that
require a different version of these packages.
## Expected Behavior
Use a range for `less` and `less-loader` to aid package managers in
resolution and hoisting.
## Related Issue(s)
Fixes#31953
## Current Behavior
Nx switched to use sass-loader with `modern-compiler` api. However, it
did not update to use `loadPaths` instead of `includePaths`.
## Expected Behavior
Use `loadPaths`.
## Related Issue(s)
Fixes#30340
## Current Behavior
<!-- This is the behavior we have today -->
Scroll position gets reset when unrelated tasks finish. Additionally,
scrolling is just really slow.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This pull request introduces momentum-based scrolling and improves
scroll position preservation across terminal panes and pseudo-terminal
instances (`PtyInstance`). It also adds a new `ScrollMomentum` module to
manage scrolling behavior dynamically based on user input patterns. The
changes enhance user experience by making scrolling smoother and more
intuitive, especially during rapid or sustained scrolling.
### Scroll Momentum Enhancements:
* Added the `ScrollMomentum` module to calculate dynamic scrolling
behavior based on time intervals and direction changes, allowing for
accelerated scrolling during sustained input.
(`packages/nx/src/native/tui/scroll_momentum.rs`,
[packages/nx/src/native/tui/scroll_momentum.rsR1-R101](diffhunk://#diff-60e4cfcd0a48b7d32e565a9254f89f142587e07a37536ca103b1ae76a760135eR1-R101))
* Integrated momentum-based scrolling into `TerminalPaneData` and
`PtyInstance`, replacing static scroll methods with dynamic ones
(`scroll_up` and `scroll_down`) that use calculated momentum values.
(`packages/nx/src/native/tui/components/terminal_pane.rs`,
[[1]](diffhunk://#diff-494d587e52e864f34496326a7453461a9a15e5c136d504a54db36a59cae7c446L45-R66);
`packages/nx/src/native/tui/pty.rs`,
[[2]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L122-R158)
[[3]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L148-R192)
[[4]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L175-R231)
### Scroll Position Preservation:
* Enhanced `PtyInstance` to preserve scroll position during terminal
resize operations, ensuring better continuity when dimensions change.
(`packages/nx/src/native/tui/pty.rs`,
[[1]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L76-R91)
[[2]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L91-R120)
### Code Improvements:
* Added momentum reset logic when switching interactive modes or
changing scroll direction to avoid abrupt changes in scrolling behavior.
(`packages/nx/src/native/tui/components/terminal_pane.rs`,
[[1]](diffhunk://#diff-494d587e52e864f34496326a7453461a9a15e5c136d504a54db36a59cae7c446R150-R169);
`packages/nx/src/native/tui/scroll_momentum.rs`,
[[2]](diffhunk://#diff-60e4cfcd0a48b7d32e565a9254f89f142587e07a37536ca103b1ae76a760135eR1-R101)
* Updated `TerminalPaneData` and `PtyInstance` constructors to
initialize `ScrollMomentum` instances for consistent scrolling state
management. (`packages/nx/src/native/tui/components/terminal_pane.rs`,
[[1]](diffhunk://#diff-494d587e52e864f34496326a7453461a9a15e5c136d504a54db36a59cae7c446R38);
`packages/nx/src/native/tui/pty.rs`,
[[2]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14R53)
[[3]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14R67)
These changes collectively improve the usability of terminal panes and
pseudo-terminal instances by making scrolling more responsive and
preserving user context during resize events.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we generate a router-router app the e2e test generated expects the
server to be ran on port `4300`.
Which fails because react-router serves from only one port and it's the
dev port which is defaults to `4200`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This should work out of the box
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When generating stories, the generation can fail due to a bad path
normalization with:
```bash
NX Failed to read src/src/app/app.tsx
Pass --verbose to see the stacktrace.
```
## Expected Behavior
Generating stories should work correctly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This line was added by accident.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This line is removed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, the CI workflow templates and setup messages contain
potentially confusing or outdated information:
1. CI workflow templates include a comment about "Nx Affected runs only
tasks affected by the changes in this PR/commit. Learn more:
https://nx.dev/ci/features/affected." which may be redundant or
confusing
2. The setup messages for CI and remote cache simply say "Finish it by
visiting: {url}" which doesn't provide clear next steps
## Expected Behavior
With these changes:
1. The redundant affected comment is removed from CI workflow templates
to reduce noise
2. The setup messages are improved to say "Push your repository and
finish the setup: {url}" which provides clearer guidance on what the
user needs to do next
3. Jest snapshot test references are updated to use the current Jest
documentation URL
## Related Issue(s)
This is a minor cleanup improvement to reduce confusion and provide
better user guidance in the CI setup flow.
Improve the generation of Storybook stories:
- Import relevant types from the appropriate packages
- Use TypeScript `satisfies` operator
- Simplify the selector in the generated interaction test example
- Fix an issue when source root is not set in the project configuration
When we generate a random port in our node e2e tests we should ensure
that the random generation port generation range starts from 1024.
Also, move the `getRandomPort` function to `e2e-utils` so that other
tests benefit from this change.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
In some rare occurences we've observed our atomization plugins returning
an invalid list of test files. We've only seen this in the jest plugin
in our internal monorepo under a very specific yet hard to repro area.
## Expected Behavior
If this occurs, the plugin errors.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Currently, there is no way for a target using `run-commands` to define
where in the command args are attached.
This is problematic in some tooling cases where args positional location
matters
## Expected Behavior
Placing `{args}` into the command should allow for interpolation of any
and all args provided.
Therefore commands can be written such as `docker run {args} imageRef`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, when options.install=true (need to do pod install), it only
syncs deps.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
make it sync deps regardless of options.install, so when developers
choose to run `pod-install` after, it will work right away.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when serve up the react-native app using web configuration, it defaults
tsconfig to
```
tsConfig: joinPathFragments(options.projectRoot, 'tsconfig.app.json'),
```
which is not right
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
not hard code ts config path, add a function determineTsConfig for that
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
NX has a dependency to a [vulnerable version of
esbuild](https://github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99)
## Expected Behavior
Updating several `@module-federation` dependencies to update esbuild to
v0.25.5 and fix the vulnerability
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31923
## Current Behavior
When a task with no PTY (e.g. a task using the `nx:noop` executor) has
its output pane open and it finishes successfully, no output is shown,
and there's a blank space to the right of the task list where the output
pane is meant to be.
<img width="1366" height="413" alt="image"
src="https://github.com/user-attachments/assets/fc34cc18-1bed-4d73-9b94-5a25069e8a3d"
/>
## Expected Behavior
When a task with no PTY (e.g. a task using the `nx:noop` executor) has
its output pane open and it finishes successfully, the output pane
should be correctly rendered in a successful status.
<img width="1365" height="411" alt="image"
src="https://github.com/user-attachments/assets/cb8862d5-f1c2-4aa6-a098-f710020e64f4"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
This PR adds support for the `proxyConfig` option in the
@rspack/dev-server executor, similarly to the existing option in the
matching Webpack executor. This new options is another step for allowing
simpler migration to Rspack when coming from Webpack, adding to the
feature parity of the Rspack executor.
## Current Behavior
The `@nx/rspack:dev-server` executor does not allow for passing a
`proxyConfig` as an option, opposed to the matching Webpack executor,
that does.
## Expected Behavior
The `@nx/rspack:dev-server` executor allows for passing a `proxyConfig`
option, same as the `@nx/webpack:dev-server` executor.
## Related Issue(s)
None.
## Current Behaviour
We are having a lot of cache misses due to using `compilerOptions` the
key for registering the `ts-node` service.
This can cause out-of-memory errors due to several registrations of the
`ts-node` service consecutively.
https://github.com/nrwl/nx/actions/runs/16233768215/job/45840886378
## Expected Behaviour
The `ts-node` service _should_ have cache hits so that the knock-on
effect of multiple registration (out-of-memory) does not happen via
plugins.
## MISC
If we set `NX_PREFER_TS_NODE` env variable we should not show the
warning fallback message.
## Current Behavior
Gray for secondary light foreground has low contrast in light themes
## Expected Behavior
This pull request includes a small change to the `Theme` implementation
in the `packages/nx/src/native/tui/theme.rs` file. The change updates
the `secondary_fg` color from `Color::Gray` to `Color::DarkGray` to
improve visual contrast.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo is using Nx `21.3.0-beta.5`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo is using Nx `21.3.0-beta.6`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When the available space in the TUI task list is small, task names can
be cropped while still displaying the Duration column.
## Expected Behavior
When the available space is insufficient, task names should be
prioritized over duration. Additionally, update the overall column
display decision logic to better use the available space.
### Before
<img width="622" height="368" alt="image"
src="https://github.com/user-attachments/assets/bd486408-abef-4601-9339-b2bf3c589287"
/>
### After
<img width="618" height="369" alt="image"
src="https://github.com/user-attachments/assets/5331172a-23b8-4924-8f3f-b2b107d011d8"
/>
## Current Behavior
Jest v30 is not supported.
**Note**: this is currently awaiting for `jest-preset-angular` to
support Jest v30:
https://github.com/thymikee/jest-preset-angular/pull/3175.
## Expected Behavior
Jest v30 should be supported.
## Related Issue(s)
Fixes#31778
## Current Behavior
When tasks are pending (not started yet), the TUI shows an empty
terminal pane with no information about why the task is waiting. Users
have no visibility into task dependencies or their status.
## Expected Behavior
When a task is pending, the TUI now displays a comprehensive dependency
view showing:
- Progress header indicating how many dependencies are complete vs total
- Scrollable list of all dependencies (direct and transitive) with
real-time status updates
- Support for continuous tasks where InProgress/Stopped are considered
complete
- Keyboard navigation (arrow keys, j/k vim keys, page up/down)
- Dependencies sorted by complexity (most dependencies first), then
alphabetically
### Dependencies Pending

### Dependencies Ready but waiting for thread

### Scrollable

## Related Issue(s)
This enhancement improves the TUI experience by providing clear
visibility into task dependencies, making it easier to understand build
pipelines and debug issues.
---------
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
excludeDependsOn is true by default, but got this error when running `nx
run nx-api:compileTestKotlin`:
```
* What went wrong:
Execution failed for task ':nx-api:compileTestKotlin'.
> Error while evaluating property 'friendPathsSet$kotlin_gradle_plugin_common' of task ':nx-api:compileTestKotlin'.
> Querying the mapped value of provider(java.util.Set) before task ':nx-api:compileJava' has completed is not supported
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
have a way to turn off excludeDependsOn
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
Fixes #
## Summary
- support `--tui` flag alongside `--output-style`
- expose tui option in NxArgs
- respect `tui` CLI option in TUI detection
- warn when environment can't display TUI even if flag is set
- test tui CLI flag parsing
## Testing
- `pnpm nx run-many -t lint,test,build` *(fails: Failed to process
project graph)*
- `pnpm test:e2e` *(fails: Command "test:e2e" not found)*
------
https://chatgpt.com/codex/tasks/task_e_68517adad738832c81ecdfba7f4a1feb
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Craigory Coppola <AgentEnder@users.noreply.github.com>
Introduced a new "Credit Pricing" reference page for Nx Cloud, detailing credit consumption and pricing metrics. Updated documentation structure, menus, sitemap, and headers to integrate the new page. Removed outdated FAQ entries and replaced the "Pricing" reference with the new "Credits Pricing" link in navigation. Adjusted related redirects and UI components for consistency.
## Current Behavior
The CI workflow generators for both @nx/workspace and @nx/gradle
currently reference the old documentation URL `https://nx.dev/ai` when
explaining the `nx fix-ci` command.
## Expected Behavior
The CI workflow generators should reference the correct self-healing CI
documentation URL `https://nx.dev/ci/features/self-healing-ci`.
## Related Issue(s)
<\!-- Please link the issue being fixed so it gets closed when this is
merged. -->
This is a follow-up to update the documentation links to point to the
correct self-healing CI feature page.
## Changes Made
- Updated @nx/workspace CI workflow generator to use the correct
documentation URL
- Updated @nx/gradle CI workflow generator to use the correct
documentation URL
- Updated all snapshot tests to reflect the new URLs
- Updated tutorial documentation that shows the CI workflow examples
**Files Updated:**
- `packages/workspace/src/generators/ci-workflow/ci-workflow.ts`
- `packages/gradle/src/generators/ci-workflow/generator.ts`
-
`packages/workspace/src/generators/ci-workflow/__snapshots__/ci-workflow.spec.ts.snap`
-
`packages/gradle/src/generators/ci-workflow/__snapshots__/generator.spec.ts.snap`
- `packages/workspace/src/generators/ci-workflow/ci-workflow.spec.ts`
- `docs/shared/tutorials/react-monorepo.md`
- `docs/shared/tutorials/typescript-packages.md`
- `docs/shared/tutorials/angular-monorepo.md`
- `docs/shared/tutorials/gradle.md`
All changes ensure users are directed to the correct self-healing CI
documentation when using the `nx fix-ci` command in their CI workflows.
## Current Behavior
Angular v20.1 is not supported.
## Expected Behavior
Angular v20.1 should be supported.
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
## Current Behavior
The `sourceRoot` project configuration property is optional. Several
places in the codebase do not properly handle this, which can result in
issues.
## Expected Behavior
A missing `sourceRoot` project configuration property should be handled
correctly throughout the codebase.
## Related Issue(s)
Fixes#30638
## Current Behavior
When generating a facade with the NgRx generators, the spec file imports
a non-existent `readFirst` from `@nx/angular/testing`. That helper was
deprecated for a long time and removed in Nx v21, but this usage was
missed, causing those tests to fail.
The e2e tests that cover this were disabled for the pnpm package
manager, so it was not caught in the PR/main CI pipeline. It was
correctly failing in the Nightly CI pipeline. The tests are now enabled
for all package managers.
Nightly failure:
https://staging.nx.app/runs/uRlR20Fzt9/task/e2e-angular%3Ae2e-local
## Expected Behavior
When generating a facade with the NgRx generators, the spec file for the
facade should be correct.
## Related Issue(s)
Fixes #
## Current Behavior
Currently, users can opt out of sorting the root tsconfig file path
mappings by providing `--sort-root-tsconfig-paths=false` to the `nx
format` commands, or by providing `{ sortRootTsconfigPaths: false }` to
the `formatFiles` function when invoked programmatically. Still, Nx
generators sort the root tsconfig file path mappings by default, and the
only way to bypass that is to run two different commands:
```bash
nx g component path/to/component --skip-format
nx format:write --sort-root-tsconfig-paths=false
```
## Expected Behavior
Users should be able to easily opt out of sorting the root tsconfig file
path mappings by setting the `NX_FORMAT_SORT_TSCONFIG_PATHS` environment
variable to `false`. With that set, all the relevant commands, including
`nx generate` will respect it.
## Related Issue(s)
Fixes#29043
## Current Behavior
Nx-cloud commands are scattered across different directories in the
command-line structure, making them harder to find and maintain.
Commands like `record`, `start-ci-run`, and `fix-ci` don't exist as
direct nx commands. The fix-ci command in CI workflows doesn't run when
previous steps fail.
## Expected Behavior
All nx-cloud related commands are organized in a dedicated directory
with consistent patterns and shared utilities. New commands provide
better CI/CD integration. The fix-ci command always runs to provide
AI-powered recommendations even when builds fail.
## Related Issue(s)
Improves code organization and adds missing CI workflow commands for
better developer experience.
## Changes Made
### 🏗️ **Reorganized nx-cloud commands**
- Created `/packages/nx/src/command-line/nx-cloud/` directory structure
- Moved existing commands (`login`, `logout`, `connect`) to new location
- Extracted shared utility function to eliminate code duplication
### 🆕 **Added new nx-cloud commands**
- `nx record` - Records command execution for distributed task execution
- `nx start-ci-run` - Starts new CI run for distributed execution
- `nx fix-ci` - Fixes CI configuration issues with AI-powered
suggestions
### 🔧 **Code quality improvements**
- Reduced code duplication by 80+ lines across command implementations
- All commands now follow consistent patterns using shared utilities
- Fixed import paths throughout codebase after reorganization
### 🚀 **Enhanced CI workflow support**
- **Gradle Generator**: Added `alwaysRun` property to Command type for
conditional execution
- **Template Updates**: GitHub Actions and CircleCI templates now handle
`alwaysRun` property
- **Fix-CI Integration**: The `fix-ci` command now always runs
regardless of previous step failures
### 📚 **Comprehensive documentation updates**
- Updated all CI provider documentation (GitHub Actions, Azure DevOps,
GitLab, Bitbucket, CircleCI, Jenkins)
- Updated Nx Cloud tutorial documentation (GitHub Actions, CircleCI)
- **Framework Tutorials**: Added `if: always()` condition to fix-ci
commands in:
- Gradle tutorial (`/docs/shared/tutorials/gradle.md`)
- Angular monorepo tutorial
(`/docs/shared/tutorials/angular-monorepo.md`)
- React monorepo tutorial (`/docs/shared/tutorials/react-monorepo.md`)
- TypeScript packages tutorial
(`/docs/shared/tutorials/typescript-packages.md`)
- Added proper documentation linking for all new commands
- All validation passes (TypeScript, formatting, documentation)
### 🎯 **Key Technical Improvements**
- **Always-Run Logic**: Fix-ci command uses platform-specific
conditional execution:
- GitHub Actions: `if: always()`
- CircleCI: `when: always`
- Azure DevOps: `condition: always()`
- **Consistent Patterns**: All nx-cloud commands follow unified
implementation approach
- **Backward Compatibility**: All existing functionality preserved
during reorganization
All nx-cloud commands now provide a more cohesive experience with better
CI integration, ensuring users get AI-powered recommendations even when
builds fail.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
For really large objects (particularly those containing large strings)
JSON.stringify can fail
## Expected Behavior
Daemon serialization doesn't fail for the same strings when setting
`NX_USE_V8_SERIALIZER=true`. This should become the default behavior.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
The existing parallelization example does not work correctly due to the
encapsulated run_command swallowing the status codes and passing the
runs with a failed command.
If users are interested in how to parallelize the tasks they can easily
find it today. We should provide minimal example like we do for other CI
providers.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This reverts commit
[a745ca5dd6fac1c91233976b9fe3713a7018cfe3](https://github.com/nrwl/nx/pull/31860/commits/a745ca5dd6fac1c91233976b9fe3713a7018cfe3).
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/31837
The main Nx Cloud page was completely rebuilt with a new component structure, replacing the old sections (`Hero`, `TrustedBy`, `FasterAndCheaper`, etc.) with new ones like `NxCloudHero`, `CiBottleneck`, `TimeToGreen`, `Features`, and others.
## Summary
This PR refactors the @nx/workspace CI workflow generator to adopt the
same centralized command generation pattern used by the Gradle
generator, making it more maintainable and consistent.
## Key Changes
### 1. Centralized Command Generation
- Added `getCiCommands()` function that generates command arrays for all
CI providers
- Replaced hardcoded commands in templates with dynamic command
substitution
- All CI providers now use identical commands with provider-specific
formatting
### 2. Performance Improvement
- Replaced `nx affected` with `nx run-many` for better performance
- Updated all CI workflow templates and snapshots accordingly
### 3. Better Code Organization
- Separated nx-cloud record comments from nx-affected comments
- Added helper functions `getCiPrefix()` and `getCiArgs()` for cleaner
code
- Improved comment clarity to guide users on when to switch to nx
affected
### 4. Bitbucket Prefix Fix
- Fixed inconsistent YAML formatting in Bitbucket pipelines
- Pull requests section: no prefix for comments
- Branches section: proper "- " prefix for comments
### 5. Template Consistency
- All CI providers (GitHub, Azure, GitLab, CircleCI, Bitbucket) now
generate identical commands
- Consistent comment structure across all templates
- Updated tutorial template to match new format
## Test Results
- ✅ All 114 tests passing
- ✅ All 95 snapshots updated and verified
- ✅ 100% backward compatibility maintained
## Benefits
1. **Maintainability**: Changes to commands only need to be made in one
place
2. **Consistency**: All CI providers use identical commands and comments
3. **Performance**: nx run-many provides better performance than nx
affected
4. **Extensibility**: Easy to add new CI providers or modify existing
ones
5. **Clean Architecture**: Follows the same pattern as other generators
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
for spring-framework
```
rootProject.children.each {project ->
project.buildFileName = "${project.name}.gradle"
}
```
it got custom build file name
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- change nxProjectGraph plugin, add buildFiles in the output json like:
```
{
"nodes": {},
...
"buildFiles": ["build.gradle"]
}
```
then, it get the build files from reports, combine build files from
build.gradle and custom build files from reports.
```
const allBuildFiles = Array.from(
new Set([...buildFilesFromSplitConfigFiles, ...buildFiles])
);
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Inserted an announcement callout highlighting the upcoming Nx Essentials Online Workshop (July 29-30) in the Getting Started and Quick Start documentation pages. Includes a link for registration and early bird details.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
for gradle, its inputs depends on outputs of its dependsOn task. (e.g.
jar task)
however, if the output file does not exist, (for example, running for
1st time in ci), it will not add to inputs.
when getting inputs, it would give a warning like
```
file or directory '/Users/emily/code/ocean/dist/libs/shared/db-schema-kotlin/classes/java/main', not found
file or directory '/Users/emily/code/ocean/dist/libs/shared/db-schema-kotlin/classes/kotlin/main', not found
file or directory '/Users/emily/code/ocean/dist/libs/shared/db-schema-kotlin/resources/main', not found
```
it is a warning, not an error, so can't be caught.
```
In Gradle's file resolution internals:
When you call task.inputs.files → Gradle resolves each file/directory.
If a declared file or dir does not exist AND it's allowed to be missing, Gradle does not throw an error — instead it logs:
file or directory '...' not found
This log is just an INFO or DEBUG message.
Gradle's normal file resolution is designed to be tolerant —
so missing files do NOT stop the build by default
```
## Expected Behavior
this solution basically take AL
<img width="1106" alt="Screenshot 2025-06-22 at 1 02 33 PM"
src="https://github.com/user-attachments/assets/7a6e8a50-44ec-4c83-bf3d-dc52346b331d"
/>
L of outputs of dependsOn tasks and add to inputs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The getPackageManagerCommand call in the new generator has a long line
that doesn't follow the codebase's formatting standards.
## Expected Behavior
The code should be properly formatted with line breaks for better
readability.
## Related Issue(s)
Code formatting improvement - no related issue.
This PR addresses the issue where the `eslint-plugin` rules fail to
`require()` modules during development when working with ts source
files. The problem occurs because `require.resolve()` finds .js paths in
package.json exports, but the actual .js files don't exist in
development mode - only .ts files are present.
So when you `require()` and the file is loaded NodeJS throws an error
because the `.js` imports cannot be resolved.
This can occur in a ts solution workspace environment where the failure
is not accommodating.
Instead, we can use `tsquery` to check if the file has a valid named
function export.
## Current Behavior
The native cache system has minimal logging, making it difficult to
debug issues or understand what's happening during cache operations.
When problems occur, there's insufficient visibility into:
- File copying operations and their progress
- Output expansion and glob pattern matching
- Cache PUT operation timing and success/failure details
- Directory creation and cleanup processes
## Expected Behavior
With these changes, the native cache system provides comprehensive
logging that:
- Tracks all file operations with sizes and timing
- Provides detailed visibility into glob pattern expansion
- Logs cache PUT operations with performance metrics
- Includes trace-level debugging for troubleshooting
- Makes it easier to diagnose cache-related issues
## Related Issue(s)
This enhancement improves the observability and debugging capabilities
of the native cache system without changing its core functionality.
## Changes Made
- **Enhanced cache PUT operations**: Added timing metrics and detailed
logging for each step
- **Improved file copying**: Added progress tracking, size reporting,
and detailed trace logs
- **Better output expansion**: Added comprehensive logging for glob
pattern analysis and path validation
- **Fixed borrow checker error**: Resolved compilation issue in file_ops
copy function
- **Comprehensive tracing**: Added trace and debug logging throughout
the cache operations
The logging follows a structured approach:
- `trace\!()` for detailed step-by-step operations
- `debug\!()` for summary information and timing metrics
- Proper error context for debugging issues
This makes the native cache system much more observable and easier to
debug when issues arise.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Updated tests to utilize the `customRegistryUrl` variable instead of hardcoded `http://localhost:7190` URLs, improving maintainability and flexibility.
## Current Behavior
When using third-party presets with `npx create-nx-workspace`, passing
framework values other than the predefined backend frameworks fails with
a schema validation error:
```
Error: Property 'framework' does not match the schema. 'angular' should be one of express,koa,fastify,nest,none.
```
For example:
```bash
npx create-nx-workspace --preset=@rig/cli@alpha --framework=angular --theme=pcb --name=hello-world
```
## Expected Behavior
Third-party presets should be able to pass any framework value without
schema validation errors, allowing for greater flexibility in the Nx
ecosystem.
## Related Issue(s)
This fixes the issue where third-party presets cannot pass framework
values like 'angular', 'react', 'vue', etc., due to overly restrictive
schema validation.
## Changes
- Removed the `enum` constraint from the `framework` property in the
workspace preset generator schema
- The property remains a string type but now accepts any value
- Maintains backward compatibility with existing functionality
The built-in Nx preset generators still only handle frameworks they know
about, but the schema validation no longer blocks third-party presets
from passing other framework values.
## Test plan
- [x] Workspace package builds successfully
- [x] Schema validation allows any string value for framework property
- [x] Backward compatibility maintained for existing presets
- [ ] Manual test: `npx create-nx-workspace --preset=@rig/cli@alpha
--framework=angular` should work without schema validation errors
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
Co-authored-by: Claude <claude@anthropic.com>
Running Nx in CI without a remote cache is a common misconfiguration that leads to slow, inefficient builds. This change introduces a proactive warning to prevent this "silent failure" and guide users toward a performant setup.
A new `NxCloudCIMessageLifeCycle` hook now checks for a remote cache configuration at the start of any command run within a CI environment.
The warning is only displayed if no remote caching is detected. It is intelligently suppressed if the workspace has:
* An Nx Cloud access token configured.
* A dependency on nx-cloud or @nrwl/nx-cloud.
* An on-premise cache provider (s3, gcs, azure, sharedFs) configured in nx.json.
* The NX_SELF_HOSTED_REMOTE_CACHE_SERVER environment variable set.
* `tasksRunnerOptions` is configured
This ensures we only notify users who are genuinely missing out on caching, improving the out-of-the-box developer experience.
When creating a node app If you want plugins to be added and
`applicationGeneratorInternal` is called instead of
`applicationGenerator` the option will be overwritten by the default
`false`.
This PR changes our Nightly GHA status reporting from a
per-project-per-environment basis to a per-project basis.
This consolidation will make the status reports easier to understand by
reducing the granularity of reporting.
Additionally, we now capture timed-out jobs as a failure instead of
being overlooked.
Sample:
```
Golden Test Failure
⭐ : Golden Projects
✅ : Passing: 15
❌ : Failing: 1
🚨 : Failed Golden Projects
| Failed project |
|--------------------------------|
| e2e-node |
```
This PR enhances the typescript plugin build detection. Notably the
changes include:
- Add absolute path handling for package.json entry points.
- Simplify the buildable verification
- Add glob pattern matching for `include` patterns.
MISC:
- Also fixes `e2e-rollup` test failing due to the typescript plugin
having the same build target as rollup so it created an unexpected
output.
closes: #29670
## Current Behavior
When installing Storybook dependencies with pnpm, the regex for
extracting base framework names from compound framework packages (e.g.,
@storybook/web-components-vite) was not properly handling hyphens in
framework names. This
caused it to extract incorrect base framework names like @storybook/web
instead of @storybook/web-components, leading to attempts to install
non-existent packages.
## Expected Behavior
The regex should properly extract base framework names that include
hyphens, correctly identifying @storybook/web-components as the base
framework for packages like @storybook/web-components-vite. This ensures
that only valid
Storybook packages are installed during dependency resolution.
## Related Issue(s)
Fixes#31292
This PR Improves the test cleanup logging for `killPorts`.
Instead of asserting that no error is thrown during cleanup, we now log
the error message when one occurs. This helps surface common but
non-critical errors (like `ECONNRESET`) without failing the test
unnecessarily.
So a test like this:
https://github.com/nrwl/nx/actions/runs/15918605455/job/44900857152
won't fail although the primary body of the test has passed
successfully.
The documentation for migrating to TypeScript project references only
shows examples for library projects, making it unclear whether the same
configuration requirements apply to application projects.
This PR clarifies that the steps apply to both libs and apps, with the
latter typically using `tsconfig.app.json` instead of
`tsconfig.lib.json`.
Fixes#31715🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When using bun as a package manager with Nx bundling operations
(webpack, vite,
etc.), lockfile creation was failing with various errors:
- "Unable to create bun lock files" warnings
- "argument 'value' must be either string or Buffer" errors
- External dependencies not being found (next, webpack-cli, etc.)
- Build failures when using generatePackageJson option
- Project graph issues with bun text-based lockfiles
This affected multiple bundlers and scenarios across the Nx ecosystem.
## Expected Behavior
Bun lockfile creation should work seamlessly across all Nx bundling
operations
without errors. Users should be able to use bun with any Nx bundler
(webpack,
vite, esbuild) and the generatePackageJson option without encountering
lockfile-related build failures.
## Related Issues
Fixes#30568Fixes#26640
## Current Behavior
When Vite projects use Vue, the typecheck target still uses the standard
TypeScript compiler (tsc) instead of vue-tsc, which is the recommended
TypeScript compiler for Vue projects. This can lead to incomplete type
checking as
tsc doesn't understand Vue's single-file components (.vue files) and
their specific syntax.
## Expected Behavior
When a Vite project uses the Vue plugin (vite:vue), the typecheck target
should automatically use vue-tsc instead of tsc for type checking. This
ensures proper type checking of Vue components and maintains
compatibility with
Vue's TypeScript integration. The external dependencies and help
metadata are also updated to reflect the use of vue-tsc when
appropriate.
## Related Issue(s)
Fixes#31647
## Current Behavior
When generating a JS library with the rollup bundler, the generator
would always create a .swcrc file regardless of the includeBabelRc flag
setting. This meant that even when users explicitly requested a Babel
configuration by
setting includeBabelRc: true, the generator would ignore this preference
and still use SWC configuration.
## Expected Behavior
When generating a JS library with any bundler (including rollup), the
generator should respect the includeBabelRc flag. If includeBabelRc is
set to true, it should create a .babelrc file and skip creating a .swcrc
file. Only
when includeBabelRc is false or not set should it fall back to creating
the appropriate transformer configuration file (.swcrc for swc/rollup
bundlers).
## Related Issue(s)
Fixes#31582
## Current Behavior
The Nest.js webpack build target configuration was generating
webpack-cli arguments without the required -- prefix, resulting in
node-env=production and node-env=development instead of proper CLI
arguments.
## Expected Behavior
The Nest.js webpack build target should generate proper webpack-cli
arguments with the -- prefix: --node-env=production and
--node-env=development for correct command line execution.
## Related Issue(s)
Fixes#31578
## Current Behavior
When the `@nx/eslint:lint` executor runs and an unexpected error occurs,
only the error message is displayed and not the stack trace. This
requires users to re-run with `--verbose` to see the stack trace.
## Expected Behavior
When the `@nx/eslint:lint` executor runs and an unexpected error occurs,
the error message and the stack trace should be logged.
## Related Issue(s)
Fixes#21630
## Current Behavior
Running Angular CLI schematic migrations that update project
configurations that contain Nx tokens (e.g. `{workspaceRoot}`,
`{projectRoot}`, `{projectName}`) does not work correctly. The schematic
migrations receive the project configuration option values with the
non-expanded tokens, which is not something handled.
## Expected Behavior
The Nx adapter for Angular should expand Nx tokens in project
configurations so schematic migrations can correctly process them. When
writing the project configuration back, the tokens should be restored on
a best-effort basis.
## Related Issue(s)
Fixes#29052
## Current Behavior
When generating Expo apps and libs with `--unit-test-runner=none` some
test-specific files and dependencies are generated.
## Expected Behavior
When generating Expo apps and libs with `--unit-test-runner=none` no
test-specific files and dependencies should be generated.
## Related Issue(s)
Fixes#30366
## Current Behavior
Projects generated with Vite that import from another project will
produce incorrect declaration files when built in an integrated
workspace (using TS path mappings).
## Expected Behavior
Projects generated with Vite that import from another project should
produce the correct declaration files when built in an integrated
workspace (using TS path mappings).
## Related Issue(s)
Fixes#30814
template examples use nx-cloud record feature which will fail if cloud
isn't enable making for bad user experience. We instead commend out the
usage and call attention to how to connect to cloud so the template will
work OOTB
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Currently the TUI is disabled on windows due to poor support for the
pseudoterminal and some lingering issues.
## Expected Behavior
This PR starts tackling this by making the TUI more usable without the
pty. The first step here is enabling processes created without the pty
to display live outputs in the TUI, which was currently not possible.
## Copilot Summary
This pull request introduces enhancements to task execution and output
handling in the Nx task runner. The changes focus on improving the
handling of progressive output for the TUI (Text User Interface), adding
support for pseudo-terminal processes, and refining the orchestration of
tasks. Below are the most important changes grouped by theme:
### Enhancements to Task Execution and Output Handling:
*
[`packages/nx/src/tasks-runner/running-tasks/node-child-process.ts`](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cR12):
Added a new `onOutput` method to allow streaming output to the TUI via
callbacks. Updated `stdout` and `stderr` handlers to invoke these
callbacks for progressive output. Introduced a
`canProvideProgressiveOutput` method to indicate whether a task can
stream output.
[[1]](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cR12)
[[2]](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cL55-R80)
[[3]](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cL88-R112)
### Support for Pseudo-Terminal Processes:
*
[`packages/nx/src/tasks-runner/forked-process-task-runner.ts`](diffhunk://#diff-9e7468f39e004b5e6087ab9a309150efa755b4f9f8047514b63fc71f8034c930L143-R143):
Added comments to clarify when pseudo-terminal processes are used for
interactive tasks and when non-interactive processes with piped output
are used. These changes improve readability and understanding of the
trade-offs involved.
[[1]](diffhunk://#diff-9e7468f39e004b5e6087ab9a309150efa755b4f9f8047514b63fc71f8034c930L143-R143)
[[2]](diffhunk://#diff-9e7468f39e004b5e6087ab9a309150efa755b4f9f8047514b63fc71f8034c930R155-R165)
### Improvements to Task Orchestration:
*
[`packages/nx/src/tasks-runner/task-orchestrator.ts`](diffhunk://#diff-e9bae83332b3d6e57c023959ab2e5f191c97e0a154a8c1d36dd81f8f869e1bdfL637-R637):
Enhanced the registration of tasks in the TUI lifecycle. Added checks to
ensure tasks that support progressive output but are not interactive
(e.g., `NodeChildProcessWithNonDirectOutput`) are registered correctly.
Introduced a fallback for tasks that don't support progressive output.
[[1]](diffhunk://#diff-e9bae83332b3d6e57c023959ab2e5f191c97e0a154a8c1d36dd81f8f869e1bdfL637-R637)
[[2]](diffhunk://#diff-e9bae83332b3d6e57c023959ab2e5f191c97e0a154a8c1d36dd81f8f869e1bdfL649-R655)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cypress `open-cypress` inferred task in a workspace with the
`customConditions` TypeScript compiler option set, fail with the error:
```bash
TSError: ⨯ Unable to compile TypeScript:
error TS5098: Option 'customConditions' can only be used when 'moduleResolution' is set to 'node16', 'nodenext', or 'bundler'.
```
This happens because Cypress forces `ts-node` to use `module: commonjs`
and `moduleResolution: node10`, which is incompatible with the
`customConditions` TypeScript compiler option.
## Expected Behavior
Cypress `open-cypress` inferred task in a workspace with the
`customConditions` TypeScript compiler option set should work as
expected.
## Related Issue(s)
Fixes#31616
## Current Behavior
The `@nx/jest/plugin` loads the Jest config file using the project's
`tsconfig.json` file.
## Expected Behavior
The `@nx/jest/plugin` should try to load the Jest config file using the
`tsconfig.spec.json` file (or other common filenames also handled by the
nx jest resolver). If those files don't exist, it should fall back to
the project's `tsconfig.json` file.
## Related Issue(s)
Fixes#31351
## Current Behavior
The `@nx/jest:configuration` generator always adds the
`firsttris.vscode-jest-runner` to the VSCode recommended extensions if
it's missing.
## Expected Behavior
The `@nx/jest:configuration` generator should only add the
`firsttris.vscode-jest-runner` to the VSCode recommended extensions when
configuring `@nx/jest` for the first time.
## Related Issue(s)
Fixes#29345
## Current Behavior
When a message handler in the Daemon server throws an error, the process
exits, and nothing is printed to the terminal.
## Expected Behavior
Errors thrown by message handlers in the Daemon server should be handled
appropriately and printed to the output.
## Related Issue(s)
Fixes#31407Fixes#31567
## Current Behavior
When using the Rollup executor with TypeScript, the build process uses
`rollup-plugin-typescript2` which can fail when importing types from
external dependencies.
This results in errors like "Invalid value for option 'files' - entry
does not exist" when
the TypeScript plugin tries to resolve type imports from node_modules.
## Expected Behavior
Users should be able to build TypeScript projects with Rollup without
encountering errors
when importing types from external packages. Additionally, users should
have the option to
migrate to the newer `@rollup/plugin-typescript` which handles external
dependencies more
gracefully.
## Related Issue(s)
Fixes#30488
This PR updates the description for `indexHtmlTransformer` for Angular
webpack browser executor to clarify what it accepts. Also adds an
example
<img width="1192" alt="Screenshot 2025-06-26 at 8 22 23 AM"
src="https://github.com/user-attachments/assets/883d9d91-21a9-4806-ae1d-336779b09061"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30831
- Fixed documentation to clarify grep uses regex not glob patterns
- Updated examples to show proper regex usage
- Corrected both --grep and --grepInvert documentation
Fixes#30181
## Current Behavior
The Vite build executor uses naive string manipulation to calculate the
output directory path, which fails in nested monorepo structures where
the workspace root and project root have different relative paths.
## Expected Behavior
The Vite build executor properly resolves the output directory path
using Node.js path utilities, ensuring correct path calculation
regardless of monorepo nesting structure.
## Related Issue(s)
Fixes#31234
## Current Behavior
Module federation templates in React generators use subpath imports
without explicit file extensions (e.g., @nx/rspack/app-plugin,
@nx/module-federation/webpack). This causes compatibility issues with
Node.js 24's native TypeScript support, which requires explicit file
extensions for ESM package subpath imports.
## Expected Behavior
Module federation templates should include .js extensions on all subpath
imports to ensure compatibility with Node.js 24 while maintaining
backwards compatibility with earlier Node.js versions. The imports
should be in the format @nx/rspack/app-plugin.js,
@nx/module-federation/webpack.js, etc.
## Related Issue(s)
Fixes#31448
## Current Behavior
The Angular library generator ignores the `skipTsConfig` option and
always modifies the `tsconfig.base.json` file, even when users
explicitly set `skipTsConfig=true` to avoid TypeScript configuration
changes.
## Expected Behavior
When `skipTsConfig=true` is passed to the Angular library generator, the
`tsconfig.base.json` file should not be modified. Project-specific
tsconfig files should still be created as expected, but the
workspace-level TypeScript
configuration should remain untouched.
## Related Issue(s)
Fixes#31185
The command `nx g @nx/angular:service
libs/shared/data-access-user/src/lib/user` was missing the required
`--project` parameter. Added `--project=data-access-user` to fix the
error "Required property 'project' is missing".
Fixes#31410
Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
## Current Behavior
Module federation configurations with relative URLs are broken due to PR
#30615, which forced all remote URLs to be parsed as absolute URLs
using `new URL()`. This breaking change prevents developers from using
relative URLs in their module federation setups, causing runtime errors
when the application tries to load remote modules.
## Expected Behavior
Module federation should support both relative and absolute URLs
seamlessly:
- Relative URLs should work as they did before, maintaining backward
compatibility
- Absolute URLs should continue to work with enhanced query parameter
support
- The URL processing should be consistent across all module federation
helpers (Angular and React)
## Related Issue(s)
Fixes#31538
## Overview
This PR enhances the Migrate UI by adding a "Stop" button that allows
users to halt in-progress migrations at any point during execution.
It works in tandem with https://github.com/nrwl/nx-console/pull/2567
### Currently
When a migration is running and needs to be stopped for any reason:
- User accidentally triggered the migration
- Migration is taking longer than expected
- Changes are needed before completion
Users must wait for the migration to complete before using the available
"Undo" or "Skip" options.
### Expected
Users should be able to stop a currently running migration at any time
before it completes, providing immediate control over the migration
process.
### Key Features:
- Refactor guards to improve migration state checks and add conditions
for running and completing migrations.
- Update the state machine to handle new states for running, stopped,
and evaluating migrations.
- Implement logic to track running migrations and allow for stopping
them gracefully.
- Introduce a new process for running migrations in a separate child
process to support cancellation.
- Enhance metadata management to include stopped migrations and update
UI accordingly. (The UI is completely driven by the backend now aka Nx
Console)
- Add tests to cover new migration states and behaviours.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
This adds new partners `Angular Architects` and `This Dot Labs`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `nxViteTsPaths` plugin determines the buildable libraries by
checking the existence of the following target:
```ts
process.env.NX_TASK_TARGET_TARGET === 'serve'
? 'build'
: process.env.NX_TASK_TARGET_TARGET
```
But it later creates the command to build the dependencies to always run
the `process.env.NX_TASK_TARGET_TARGET` target. This is wrong and
results in trying to run the `serve` task for the dependencies when the
root task is `serve`.
## Expected Behavior
The `nxViteTsPaths` plugin should use the same task name to determine
the buildable libraries and run the command to build the dependencies.
## Related Issue(s)
Fixes#31333
## Current Behavior
When a user sets `target: node` in their Webpack or Rspack config,
`NxAppRspackPlugin` and `NxAppWebpackPlugin` do not respect additional
user config for `library.target`.
## Expected Behavior
The user config should be respected.
## Related Issue(s)
Fixes#30937
This PR fixes and issue with Next.js + Jest to remove warnings about
outdated transforms.
## Changes Made
- Updated Next.js application generator to use next/jest.js instead of
manual babel-jest configuration
- Updated Next.js library generator to use the same modern configuration
approach
- Added e2e tests to verify the new Jest configuration works correctly
- Kept same CJS vs ESM logic for JS vs TS config (existing behavior)
## Current Behavior
When using React 19 with Next.js applications in Nx, developers receive
a warning about outdated JSX transform because the Jest configuration
uses
manual babel-jest setup instead of Next.js's recommended approach.
## Expected Behavior
Next.js applications and libraries generated by Nx should use
next/jest.js configuration which automatically handles the modern JSX
transform
(runtime: 'automatic') and provides proper Jest setup for Next.js
projects without warnings.
## Related Issue(s)
Fixes#27900
## Current Behavior
Documentation examples show `tsconfig.lib.json` and
`tsconfig.spec.json` extending from `./tsconfig.json`.
## Expected Behavior
Examples should extend directly from `../../tsconfig.base.json` to
match Nx's recommended TypeScript configuration structure.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31704
- Modified create-ts-config.ts to make tsconfig.json extend
./.nuxt/tsconfig.json instead of root tsconfig
- Updated nuxt.config.ts template to make .nuxt/tsconfig.json extend the
root tsconfig with correct relative path
- Added relativePathToRootTsConfig parameter to template generation
- Updated test snapshots to reflect the new configuration chain
This ensures IDEs can properly recognize Nuxt components, composables,
and auto-imports by establishing the correct TypeScript configuration
inheritance chain: tsconfig.app.json → tsconfig.json →
.nuxt/tsconfig.json → tsconfig.base.json
## Related Issues
#30742
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When users provide an absolute path for the Module Federation manifest
file
that already includes the workspace root, the plugin incorrectly
prepends the
workspace root again, resulting in an invalid path like
`/workspace/root/workspace/root/path/to/manifest.json`.
## Expected Behavior
The plugin should detect if the provided manifest file path already
starts with
the workspace root and avoid prepending it again. This allows users to
provide
either relative or absolute paths for the manifest file, and both will
work
correctly.
## Related Issue(s)
Fixes#31524
## Current Behavior
`@module-federation/enhanced` v0.9.0 has a dependency to
`@module-federation/dts-plugin` v0.9.0, which has a dependency to `koa`
v2.15.4, which has a [security vulnerability
](https://github.com/koajs/koa/security/advisories/GHSA-x2rg-q646-7m2v)
And because `@module-federation/enhanced` is pinned with `^0.9.0` it
won't automatically update it to a version greater than `0.9.x`
## Expected Behavior
Until `@module-federation/enhanced` releases a v1, it needs to be
manually updated when we want to benefit from a newer "minor" version.
Pinning `@module-federation/enhanced` to `^0.15.0` allows to benefit
from the latest release and security fix.
## Related Issue(s)
Fixes#30502Fixes#30748
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
In the new TS Soln Setup with Package Manager Workspaces, there is
currently no builtin method for creating a pruned lockfile that is
agnostic across bundlers and compilers.
This is problematic for apps that must be containerized.
## Expected Behavior
Add a new `@nx/js:prune-lockfile` executor that can be used to produce a
pruned lockfile in the build artifact output directory, ready for
containerization.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <Coly010@users.noreply.github.com>
Created a new contact page for Nx Labs to highlight services and provide a form for inquiries. Updated the professional services section in the header menu to include a link to this page.
## Description
This PR fixes an issue where asset files copied during a build using the
`@nx/js:tsc` executor are placed in the wrong directory depending on the
current working directory from which the `nx` command is executed.
This behavior becomes particularly problematic in scenarios like release
workflows that rely on `preVersionCommand` to run E2E tests. For
instance, when using tools like Jest from the root of an E2E project,
scripts like `start-local-registry` may trigger a build and run the
`preVersionCommand`. However, instead of placing assets in the expected
`dist` folder of the project, they are incorrectly copied relative to
the E2E folder’s location.
## Reproduction Steps
1. Create a new Nx workspace:
```bash
npx --yes create-nx-workspace assets-issue --preset=ts --no-interactive
cd assets-issue
```
2. Add the Nx Plugin package:
```bash
nx add @nx/plugin
```
3. Generate a new plugin:
```bash
nx g @nx/plugin:plugin packages/my-plugin --linter eslint
--unitTestRunner jest
```
4. Add a generator to the plugin:
```bash
nx g @nx/plugin:generator packages/my-plugin/src/generators/my-generator
```
5. Build the plugin from the workspace root:
```bash
nx build my-plugin
```
✅ Assets are copied correctly:
```
dist/packages/my-plugin/generators/files/src/index.ts.template
dist/packages/my-plugin/generators/schema.json
dist/packages/my-plugin/generators/schema.d.ts
```
6. Now build the same project from a nested folder:
```bash
mkdir e2e && cd e2e
nx build my-plugin --skip-nx-cache
```
❌ Assets are copied relative to the current folder:
```
e2e/packages/my-plugin/dist/generators/files/src/index.ts.template
e2e/packages/my-plugin/dist/generators/schema.json
e2e/packages/my-plugin/dist/generators/schema.d.ts
```
## Expected Behavior
The build output—especially copied assets—should always respect the
project’s `outputPath` configuration regardless of where the `nx`
command is invoked from. The behavior should be consistent and **not
influenced by `process.cwd()`**.
The simpleName option is no longer useful as we've moved to using
options "as provided" without transformation. Users should provide the
exact name, directory, and import path they want to use.
## Changes
- Add x-deprecated to schema.json marking for removal in Nx 22
- Add runtime warning when simpleName is used
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Users are confused with `--simpleName` with using `--name` AND
`--directory`
## Expected Behavior
We should tell users that only `--name` should be used.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29508
---------
Co-authored-by: Claude <noreply@anthropic.com>
Update React monorepo tutorial:
- Fix reference to .eslintrc.base.json (now eslint.config.mjs)
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30199
Co-authored-by: Claude <noreply@anthropic.com>
## Changes
- Update build output path from {workspaceRoot}/dist/{projectRoot} to
.next folder
- Replace vite.config.ts example with next.config.js distDir
configuration
- Add note about legacy executor configuration vs inferred tasks
- Clarify that sourceRoot may not exist in all Next.js projects
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The docs for Next.js says output can be configured in `vite.config.ts`,
which is nonsense. It also mentions the output directory that is only
applicable in the legacy setup.
## Expected Behavior
Fix configuration example, and show different ways to configure output
(both new crystal setup, and legacy executor-based setup).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31037
Co-authored-by: Claude <noreply@anthropic.com>
Refined AI features including new capabilities (self-healing CI, AI data analysis), updated descriptions, and rearranged feature order. Adjusted section ID for CI security and added links to highlight AI integrations in pricing plans.
This PR fixes an issue when you use React with Webpack/Rspack, and
aren't using `@nx/webpack/plugin` or `@nx/rspack/plugin`.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Project configuration contains this for build options:
```
"styles": ["src/myapp/styles.tailwind"]
```
## Expected Behavior
It shoud be :
```
"styles": ["src/myapp/styles.css"]
```
Which is what we actually generate.
## Current Behavior
The deprecation warning for the old script to decorate the Angular CLI
doesn't state the version in which it will be removed. This was
intentional to allow sufficient time for users to migrate away from it.
## Expected Behavior
The deprecation warning for the old script to decorate the Angular CLI
should state that it will be removed in Nx v22. It has been a long time
since it was deprecated, and it should have provided more than enough
time for users to move away from it.
## Related Issue(s)
Fixes #
## Current Behavior
The `set-inject-document-domain` migration updates the component
configuration. This is incorrect since the `inject-document-domain` is
not a property supported by the component configuration.
## Expected Behavior
The `set-inject-document-domain` migration should not update the
component configuration.
## Related Issue(s)
Fixes#31610
## Current Behavior
When the user hasn't interacted with the TUI and has not disabled the
auto-exit functionality, it will always auto-exit regardless of the
number of failed tasks.
## Expected Behavior
When the user hasn't interacted with the TUI and has not disabled the
auto-exit functionality, it should not auto-exit if there are multiple
failed tasks. Additionally, as long as no terminal output panes are open
(e.g., the run one command will always display the initiating task
terminal pane), it should focus and open the first failed task.
If all tasks succeed or there's only one failure, it should continue to
auto-exit.
Adds comprehensive explanation that both files support executors and all
Nx features through the 'nx' property in package.json. Clarifies that
project.json is optional.
Preview:
https://nx-dev-git-issues-28715-nrwl.vercel.app/reference/project-configuration#project-level-configuration-files
## Current Behavior
The documentation for project configuration does not clearly explain
that both package.json and project.json support the same Nx features,
including executors.
## Expected Behavior
The documentation now clearly states that:
- Both package.json and project.json support targets through the "nx"
property in package.json
- The choice between the two is primarily a matter of preference
- Includes an updated example showing how to use `nx.targets` in
package.json
## Related Issue(s)
Fixes#28715
## Current Behavior
When Nx is invoked from a global install, both the global and local
versions register process exit handlers that flush captured logs. This
causes Nx Cloud logs to be displayed twice - once from the global
installation and once from the local installation.
## Expected Behavior
Only the local Nx installation should handle log flushing, preventing
duplicate log output. The process exit handler is moved from the global
entry point (nx.ts) to the local entry point (init-local.ts) so that log
flushing only occurs once.
## Related Issue(s)
This change requires users to update their globally installed Nx to
fully resolve the duplicate logging issue, as the fix is now in the
local version that gets invoked.
## Current Behavior
The string regex the script uses to validate commits is not correctly
escaped.
## Expected Behavior
The string regex the script uses to validate commits should be correctly
escaped.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Adds the path to the terminal output s.t. you can at least debug what's
going on

## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When building applications that depend on workspace libraries for
deployment (particularly in containerized environments like Docker),
developers must manually handle copying workspace dependencies and
updating package.json references.
This creates friction when trying to deploy applications that consume
workspace libraries, as the build output doesn't contain the necessary
workspace dependencies and the package.json still references them with
`workspace:` protocol which doesn't work outside the workspace context.
## Expected Behavior
With the new `@nx/js:copy-workspace-modules` executor, developers can
automatically prepare their built applications for deployment by:
1. **Automatically copying workspace dependencies**: The executor scans
the application's package.json for workspace dependencies (those with
`workspace:` or `file:` version specifiers) and copies the source code
of these dependencies into a `workspace_modules` directory within the
build output
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Some Angular migrations collect the Angular projects from the project
graph using the dependencies information. When reading the project
configuration for those projects, it can throw an error if trying to do
it for a completely inferred project (it doesn't have a project
configuration file).
## Expected Behavior
The Angular migrations collecting Angular projects from the project
graph using the dependencies information should gracefully handle
projects that were completely inferred when trying to read the project
configuration.
In fact, the current migrations didn't need to read the project
configuration and could use the project graph information directly, so
the call to read the project configuration was removed.
## Related Issue(s)
Fixes#31607
## Current Behavior
`nx run lint --quiet --fix` doesn't respect `--quiet` and fixes all
issues, even silenced ones. This is different from how `eslint --quiet
--fix` behaves.
## Expected Behavior
`nx run lint --quiet --fix` should only fix issues that aren't silenced
by `--quiet`, like `eslint` does
## Related Issue(s)
Fixes#31401
This PR added two TUI environment variables to the reference page:
- NX_TUI to enabled/disable
- NX_TUI_AUTO_EXIT to control auto-exit behavior
## Current Behavior
The environment variables documentation does not include the new
Terminal UI (TUI) environment variables `NX_TUI` and `NX_TUI_AUTO_EXIT`
that were recently added to control the interactive terminal interface
for task
execution.
## Expected Behavior
The documentation now includes comprehensive information about the TUI
environment variables:
- `NX_TUI`: Controls whether the Terminal UI is enabled or disabled for
running tasks
- `NX_TUI_AUTO_EXIT`: Controls the auto-exit behavior of the TUI after
tasks complete, supporting boolean values or a number for countdown
seconds
## Related Issue(s)
Fixes#31111
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when atomized=false, it does not generate build-ci and check-ci targets
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- when atomized=false, it should still generate build-ci and check-ci
targets
- upgrade dev.nx.gradle.project-graph version to 0.1.2
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR adds bun to list of package managers that can be used on the CI
deployment page.
Fixes#31431
## Current Behavior
The CI deployment documentation at
https://nx.dev/ci/recipes/other/ci-deployment only mentions npm, yarn,
and pnpm as supported package managers. However, Bun is actually
supported by Nx as shown in the PackageManager type
definition which includes 'bun' as a valid option.
## Expected Behavior
The documentation should accurately reflect all supported package
managers, including Bun. Users should be aware that they can use Bun as
their package manager when following the CI deployment recipes.
## Related Issue(s)
Fixes#31431
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
fix to run gradle on windows
./gradlew command is only macos
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
use @nx/gradle:gradle executor instead of command ./gradlew
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
This pull request updates the documentation to reflect changes in
project names for task dependencies. The documentation was referring to
the `modules-shared-ui` and `modules-products` packages on the chart,
but these packages are called differently.

## Current Behavior
Some links in the Angular and React tutorials are broken.
## Expected Behavior
The links in the Angular and React tutorials work correctly.
## Related Issue(s)
Fixes#31601
## Current Behavior
Using the `ng-packagr` executors in an Angular version lower than v20
results in an error due to a bad import.
## Expected Behavior
The `ng-packagr` executors should work correctly regardless of the
Angular version used.
## Related Issue(s)
Fixes#31597
Extended the `Callout` component and schema to support a new 'announcement' type with corresponding styles and icon. Updated documentation example for the new type.
2025-06-13 11:55:49 -04:00
7714 changed files with 426354 additions and 426071 deletions
description: Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
@@ -28,12 +28,12 @@ Note: We reserve the right to remove unmaintained plugins from the registry. If
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
- Update the `astro-docs/src/content/approved-community-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/plugin-registry)
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/docs/plugin-registry)
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
strategy:
fail-fast:false
matrix:
include:
- language:actions
build-mode:none
# We would like to test our Java / Kotlin... but its currently failing. We can follow up.
# - language: java-kotlin
# build-mode: autobuild
- language:javascript-typescript
build-mode:none
- language:rust
build-mode:none
- language:csharp
build-mode:autobuild
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
shell:bash
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
strategy:
fail-fast:false
matrix:
include:
- language:actions
build-mode:none
# See comment in @./codeql-master.yml about Java / Kotlin
# - language: java-kotlin
# build-mode: autobuild
- language:javascript-typescript
build-mode:none
- language:rust
build-mode:none
- language:csharp
build-mode:autobuild
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
shell:bash
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
uses:dawidd6/action-download-artifact@v2# Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
uses:dawidd6/action-download-artifact@268677152d06ba59fcec7a7f0b5d961b6ccd7e1e # v2# Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
// TODO (emily): Fix Windows support as gradle fails when running nx build https://staging.nx.app/runs/LgD4vxGn8w?utm_source=pull-request&utm_medium=comment
// TODO (Jack): Fix Windows support as gradle fails when running nx build https://staging.nx.app/runs/LgD4vxGn8w?utm_source=pull-request&utm_medium=comment
# Check out the PR branch to get its copy of nx-release.ts
repository:${{ steps.script.outputs.repo }}
ref:${{ steps.script.outputs.ref }}
path:pr-branch-checkout
- name:(PR Release Only) Ensure that nx-release.ts has not changed in the PR being released
- name:(PR Release Only) Ensure that release scripts have not changed in the PR being released
if:${{ steps.script.outputs.ref != '' }}
env:
FILE_TO_COMPARE:"scripts/nx-release.ts"
run:|
if ! cmp -s "latest-master-checkout/${{ env.FILE_TO_COMPARE }}" "pr-branch-checkout/${{ env.FILE_TO_COMPARE }}"; then
echo "🛑 Error: The file ${{ env.FILE_TO_COMPARE }} is different on the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} vs latest master on nrwl/nx, cancelling workflow. If you did not modify the file, then you likely just need to rebase/merge latest master."
exit 1
else
echo "✅ The file ${{ env.FILE_TO_COMPARE }} is identical between the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} and latest master on nrwl/nx."
fi
# List of files that must not change in PR releases
FILES_TO_CHECK=(
"scripts/nx-release.ts"
"scripts/publish-resolve-data.js"
)
for FILE in "${FILES_TO_CHECK[@]}"; do
if ! cmp -s "latest-master-checkout/$FILE" "pr-branch-checkout/$FILE"; then
echo "🛑 Error: The file $FILE is different on the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} vs latest master on nrwl/nx, cancelling workflow."
echo "If you did not modify the file, then you likely just need to rebase/merge latest master."
exit 1
else
echo "✅ The file $FILE is identical between the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} and latest master on nrwl/nx."
1. Suggest relevant commands from the "Essential Commands" section when applicable
2. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
analysis
3. Mention the plugin ecosystem and support for various frameworks when relevant
4. Emphasize the importance of running the full validation suite before committing changes
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this
file.
## Documentation Contributions
When working on Nx documentation, all documentation content lives in the `astro-docs/` folder. This is the new Astro-based documentation site built with Starlight.
**Important**: Before making any documentation changes, read the `astro-docs/README.md` file for detailed guidance on:
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
### 2. Analyze the Plan
- Look for a plan or implementation details in the issue description
- Check comments for additional context or clarification
- Identify affected projects and components
### 3. Implement the Solution
- Follow the plan outlined in the issue
- Make focused changes that address the specific problem
- Ensure code follows existing patterns and conventions
### 4. Run Full Validation
Use the testing workflow from the "Essential Commands" section.
### 5. Submit Pull Request
- Create a descriptive PR title that references the issue
- **Always fill in the PR template** - don't leave it empty
- Include "Fixes #ISSUE_NUMBER" in the PR description
- Provide a clear summary of changes made
- Request appropriate reviewers
## Pull Request Template
**IMPORTANT**: When creating a pull request, you MUST fill in the template found in `.github/PULL_REQUEST_TEMPLATE.md`.
Do not leave the template sections empty. The template includes:
### Required Sections
1.**Current Behavior**: Describe the behavior we have today
2.**Expected Behavior**: Describe the behavior we should expect with the changes in this PR
3.**Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
### Template Format
```markdown
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
Fixes #ISSUE_NUMBER
```
### Guidelines
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
- Use `fix:`, `feat:`, `chore:`, etc. as appropriate types.
- Scope is **required** for all commits. Possible scopes are listed in `scripts/commitizen.js`.
- Read the submission guidelines in CONTRIBUTING.md before posting
- For complex changes, you can request a dedicated Nx release by mentioning the Nx team
- Always link the related issue using "Fixes #ISSUE_NUMBER" to automatically close it when merged
<!-- nx configuration start-->
<!-- Leave the start & end comments to automatically receive updates. -->
# General Guidelines for working with Nx
- When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly
- You have access to the Nx MCP server and its tools, use them to help the user
- When answering questions about the repository, use the `nx_workspace` tool first to gain an understanding of the workspace architecture where applicable.
- When working in individual projects, use the `nx_project_details` mcp tool to analyze and understand the specific project structure and dependencies
- For questions around nx configuration, best practices or if you're unsure, use the `nx_docs` tool to get relevant, up-to-date docs. Always use this instead of assuming things about nx configuration
- If the user needs help with an Nx configuration or project graph error, use the `nx_workspace` tool to get any errors
# CI Error Guidelines
If the user wants help with fixing an error in their CI pipeline, use the following flow:
- Retrieve the list of current CI Pipeline Executions (CIPEs) using the `nx_cloud_cipe_details` tool
- If there are any errors, use the `nx_cloud_fix_cipe_failure` tool to retrieve the logs for a specific task
- Use the task logs to see what's wrong and help the user fix their problem. Use the appropriate tools if necessary
- Make sure that the problem is fixed by running the task that you passed into the `nx_cloud_fix_cipe_failure` tool
1.Use the `nx_workspace` mcp tool for understanding the workspace architecture when appropriate
2.When working in projects, use the `nx_project` mcp tool to analyze and understand the specific project structure and
dependencies
3. Suggest relevant commands from the "Essential Commands" section when applicable
4. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
1.Suggest relevant commands from the "Essential Commands" section when applicable
2.Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
analysis
5. Mention the plugin ecosystem and support for various frameworks when relevant
6. Emphasize the importance of running the full validation suite before committing changes
3. Mention the plugin ecosystem and support for various frameworks when relevant
4. Emphasize the importance of running the full validation suite before committing changes
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this
file.
## Documentation Contributions
When working on Nx documentation, all documentation content lives in the `astro-docs/` folder. This is the new Astro-based documentation site built with Starlight.
**Important**: Before making any documentation changes, read the `astro-docs/README.md` file for detailed guidance on:
- Use `.mdoc` (Markdoc) or `.mdx` format for documentation files
- Run `nx serve astro-docs` to start the local dev server
- Sidebar structure is defined in `astro-docs/sidebar.mts`
## GitHub Issue Response Mode
When responding to GitHub issues, determine your approach based on how the request is phrased:
@@ -177,6 +193,31 @@ Fixes #ISSUE_NUMBER
### Guidelines
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
- Use `fix:`, `feat:`, `chore:`, etc. as appropriate types.
- Scope is **required** for all commits. Possible scopes are listed in `scripts/commitizen.js`.
- Read the submission guidelines in CONTRIBUTING.md before posting
- For complex changes, you can request a dedicated Nx release by mentioning the Nx team
- Always link the related issue using "Fixes #ISSUE_NUMBER" to automatically close it when merged
<!-- nx configuration start-->
<!-- Leave the start & end comments to automatically receive updates. -->
# General Guidelines for working with Nx
- When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly
- You have access to the Nx MCP server and its tools, use them to help the user
- When answering questions about the repository, use the `nx_workspace` tool first to gain an understanding of the workspace architecture where applicable.
- When working in individual projects, use the `nx_project_details` mcp tool to analyze and understand the specific project structure and dependencies
- For questions around nx configuration, best practices or if you're unsure, use the `nx_docs` tool to get relevant, up-to-date docs. Always use this instead of assuming things about nx configuration
- If the user needs help with an Nx configuration or project graph error, use the `nx_workspace` tool to get any errors
# CI Error Guidelines
If the user wants help with fixing an error in their CI pipeline, use the following flow:
- Retrieve the list of current CI Pipeline Executions (CIPEs) using the `nx_cloud_cipe_details` tool
- If there are any errors, use the `nx_cloud_fix_cipe_failure` tool to retrieve the logs for a specific task
- Use the task logs to see what's wrong and help the user fix their problem. Use the appropriate tools if necessary
- Make sure that the problem is fixed by running the task that you passed into the `nx_cloud_fix_cipe_failure` tool
<p style="text-align: center;"><img src="https://raw.githubusercontent.com/nrwl/nx/master/images/how-to-contribute.png" width="600" alt="Nx - How to contribute"></p>
<p style="text-align: center;"><img src="./images/how-to-contribute.png" width="600" alt="Nx - How to contribute"></p>
</a>
## Got a Question?
@@ -194,76 +194,73 @@ To build Nx on Windows, you need to use WSL.
## Documentation Contributions
We would love for you to contribute to our documentation as well! Please feel welcome to submit fixes or enhancements to
our existing documentation pages and the `nx-dev` application in this repo.
our existing documentation pages, `astro-docs` and the `nx-dev` application in this repo.
### Documentation Structure
#### Documentation Pages
Our documentation pages can be found within this repo under the `docs` directory.
Our documentation pages can be found within this repo under the `astro-docs/src/content/docs` directory.
The `docs/map.json` file is considered our source of truth for our site's structure, and should be updated when adding a
new page to our documentation to ensure that it is included in the documentation site. We also run automated scripts
based on this `map.json` data to safeguard against common human errors that could break our site.
Documentation is written in `.mdoc` (Markdoc) or `.mdx` (MDX) format and supports custom Markdoc tags for rich content
such as videos, graphs, interactive components, and more. See the `astro-docs/README.md` for a full list of available
custom tags and their usage.
When you make a change to the `map.json` file, make sure to run `pnpm documentation` to propagate your changes to the `nx-dev` application.
The sidebar structure is defined in `astro-docs/sidebar.mts` and should be updated when adding new sections or pages
to ensure proper navigation.
#### Astro-Docs Application
Our public `nx.dev/docs` documentation site is built with [Astro](https://astro.build) and [Starlight](https://starlight.astro.build),
and can be found in the `astro-docs` directory of this repo. See [docs README for more details](./astro-docs/README.md)
#### Nx-Dev Application
Our public `nx.dev` documentation site is a [Next.js](https://nextjs.org/) application, that can be found in
the `nx-dev` directory of this repo.
The documentation site is consuming the `docs/` directly by copy-ing its content while deploying, so the website is
always in sync and reflects the latest version of `docs/`.
The `nx-dev` directory contains a [Next.js](https://nextjs.org/) application used for blog posts and landing pages.
Jump to [Running the Documentation Site Locally](#running-the-documentation-site-locally) to see how to preview your
changes while serving.
### Changing Generated API documentation
`.md` files documenting the API for our CLI (including executor and generator API docs) are generated via the
corresponding `schema.json` file for the given command.
API documentation for CLI commands, executors, and generators is automatically generated during the build process from
the corresponding `schema.json` files in each package.
After adjusting the `schema.json` file, `.md` files for these commands can be generated by running:
The documentation is generated using content loaders in the `astro-docs` application and requires a rebuild to reflect
changes. After adjusting a `schema.json` file:
```bash
pnpm documentation
```
This will update the corresponding contents of the `docs` directory. These are generated automatically on push (via
husky) as well.
1. Restart the development server with `nx serve astro-docs` to see the changes
2. Or run `nx preview astro-docs` to view the built site locally
Note that adjusting the `schema.json` files will also affect the CLI manuals and Nx Console behavior, in addition to
adjusting the docs.
the generated documentation.
### Running the Documentation Site Locally
To run `nx-dev` locally, run the command:
To run the documentation site locally, run the command:
```bash
npx nx serve-docs nx-dev
```shell
nx serve astro-docs
```
You can then access the application locally at `localhost:4200`. Changes to markdown documentation files will be automatically applied to the site when you refresh the browser.
You can then access the application locally at `localhost:4321`. Changes to markdoc files should reflect automatically in the browser on save.
#### Troubleshooting: `JavaScript heap out of memory`
#### Working with Plugin Registry
If you see an error that states: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`,
you need
to [increase the max memory size of V8's old memory section](https://nodejs.org/api/cli.html#--max-old-space-sizesize-in-megabytes):
To view plugin registry statistics (GitHub stars, npm downloads, etc.) during local development:
```bash
export NODE_OPTIONS="--max-old-space-size=4096"
NX_DOCS_PLUGIN_STATS=true nx serve astro-docs
```
After configuring this, try to run `npx nx serve nx-dev` again.
Note: Plugin stats are disabled by default in development to improve performance.
### PR Preview
When submitting a PR, this repo will automatically generate a preview of the `nx-dev` application based on the contents
When submitting a PR, this repo will automatically generate a preview of the documentation site based on the contents
of your pull request.
Once the preview site is launched, a comment will automatically be added to your PR with the link your PR's preview. To
check your docs changes, make sure to select `Preview` from the version selection box of the site.
Once the preview site is launched, a comment will automatically be added to your PR with the link to your PR's preview.
## Submission Guidelines
@@ -344,6 +341,7 @@ The scope must be one of the following:
- express - anything Express specific
- js - anything related to @nx/js package or general js/ts support
- linter - anything Linter specific
- module-federation - anything Nx Module Federation specific
[](https://gitter.im/nrwl-nx/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
[](https://go.nx.dev/community)
@@ -21,7 +21,7 @@
# Smart Repos · Fast Builds
An AI-first build platform that connects everything from your editor to CI. Helping you deliver fast, without breaking things.
Get to green PRs in half the time. Nx optimizes your builds, scales your CI, and fixes failed PRs. Built for developers and AI agents.
Create a new Nx workspace with
@@ -47,7 +47,7 @@ Connect your existing Nx workspace with
npx nx connect
```
Learn more in the [Nx CI docs »](https://nx.dev/ci/intro?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo)
Learn more in the [Nx CI docs »](https://nx.dev/ci/getting-started/intro?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo)
## Useful links
@@ -67,7 +67,7 @@ our [guidelines for contributing](https://github.com/nrwl/nx/blob/master/CONTRIB
Nx/Nrwl takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations.
If you believe you have found a security vulnerability in any Nx-owned repository that meets Nx's definition of a security vulnerability, please report it to us as described below.
## Reporting Security Issues
**Please do not report security vulnerabilities through public GitHub issues.**
Instead, please report them to the Security Team at security@nrwl.io.
You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
Nx follows the principle of Coordinated Vulnerability Disclosure.
[](https://starlight.astro.build)
The Nx documentation site built with Astro and Starlight, featuring advanced content management through Markdoc and dynamic plugin documentation generation.
## Architecture Overview
This documentation site leverages Astro's static site generation capabilities with Starlight for documentation-specific features. The architecture consists of:
### Core Technologies
- [**Astro**](https://docs.astro.build) - Static site generator with island architecture
- [**Starlight**](https://starlight.astro.build) - Documentation theme with built-in navigation, search, and i18n
- **React** - For implementing UI components
- **Netlify** - Deployment and hosting
### Key Features
- [Markdoc](https://markdoc.dev) with custom tags for rich content such as videos, graphs, etc.
- TailwindCSS for styling in Astro and React components
- Dynamic API documentation generation from Nx packages and CLI commands
- Community plugin registry
## Project Structure
```
astro-docs/
├── src/
│ ├── assets/ # Images and static assets to be optimized by Astro
-`{% install_nx_console %}` - IDE extension installer
#### Content Enhancement
-`{% badge %}` - Status/label pills
-`{% metrics %}` - Metrics display
-`{% testimonial %}` - Customer testimonials
## Development Workflow
### Getting Started
```bash
# Install dependencies and link workspace packages
# This will build Nx packages as well for API docs
nx serve astro-docs
# Or run astro dev directly
# This will not build Nx packages
cd astro-docs
npx astro dev
# Custom ports (useful for AI agents with git worktrees)
npx astro dev --port 3000
```
### Adding New Content
#### Regular Documentation
1. Create `.mdoc` file in `src/content/docs/`
2. Add frontmatter with title and description
3. Use Markdoc tags for rich content
4. File location determines URL structure
Example:
```markdown
---
title: 'My New Guide'
description: 'Learn how to use this feature'
---
# Introduction
{% aside type="note" title="Important" %}
This is a note about the feature.
{% /aside %}
```
#### Adding Custom Markdoc Tags
1. Create Astro component in `src/components/markdoc/`
2. (Optional) Create React component for more complex components, or ones that need to be shared with blog or non-docs pages
3. Register in `markdoc.config.mjs`
4. Define attributes and validation
### Updating Plugin Documentation
Plugin documentation is auto-generated during build. To update:
1. Make changes to the plugin's schema/implementation
2. Run the build process
3. The loader will automatically fetch and generate updated docs
### Sidebar Management
The sidebar structure is defined in `sidebar.mts`. To add new sections:
```javascript
exportconstsidebar=[
{
label:'Section Name',
items:[
{
label:'Page Title',
link:'path/to/page',
},
// Nested sections
{
label:'Subsection',
collapsed:true,
items:[...]
}
]
}
];
```
> Note there is a special case for sidebar items appearing in the sidebar. Such as the `Reference` section which is handled via the `[sidebar-reference-updater](./src/plugins/sidebar-reference-updater.middleware.ts)` middleware.
## Styling and Theming
- Uses Tailwind CSS v4 with Vite plugin
- Global styles in `src/styles/global.css`
- Component-specific styles use Tailwind utilities
- Dark/light mode support built into Starlight and customized in `global.css`
## Configuration Files
### `astro.config.mjs`
- Site configuration
- Integration setup (React, Markdoc, Starlight)
- Vite plugins
- Build options
### `markdoc.config.mjs`
- Custom tag definitions
- Attribute validation
- Component mappings
### `sidebar.mts`
- Navigation structure
- Section organization
- Dynamic content injection points
## Banner Configuration
The floating banner promotes events/webinars. It's fetched at **build time** from a Framer CMS page and stored as an Astro content collection.
### Setup
Set `BANNER_URL` to point to a Framer page that renders banner JSON:
"comment":"package.json#scripts runs in the project root directory with astro assumes is where the node_modules is. which fails. so run the scripts in project.json#targets with --root command instead",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.