## 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
(cherry picked from commit 21783402b7)
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>
(cherry picked from commit c08e83c73d)
## 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>
(cherry picked from commit f87e20fe75)
- 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
(cherry picked from commit e3a4233cfe)
## 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>
(cherry picked from commit 1ecbd8082c)
## 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>
(cherry picked from commit 1eea5edb50)
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>
(cherry picked from commit b6958b3e88)
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>
(cherry picked from commit 017ad93d35)
## 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
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`
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)
// 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
# Automated schedule - canary releases from master
schedule:
- cron:"0 20 * * 1-5"# Monday - Friday, at 20:00 UTC (8pm UTC)
- cron:"0 19 * * 1-5"# Monday - Friday, at 19:00 UTC (7pm UTC)
# Manual trigger - PR releases or dry-runs (based on workflow inputs)
workflow_dispatch:
inputs:
pr:
description:"PR Number - If set, a real release will be created for the branch associated with the given PR number. If blank, a dry-run of the currently selected branch will be performed."
required:false
type:number
release:
types:[published ]
@@ -28,6 +35,11 @@ jobs:
# - release:
# - We are running a full release which is based on the tag that triggered the release event, we can use default
# ref resolution in actions/checkout. The exact version will be generated within scripts/nx-release.ts.
#
# - workflow_dispatch:
# - We are either running a dry-run on the current branch, in which case the version will be static and we can use
# default ref resolution in actions/checkout, or we are creating a PR release for the given PR number, in which case
# we should generate an applicable version number within publish-resolve-data.js and use a custom ref of the PR branch name.
# 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 release scripts have not changed in the PR being released
if:${{ steps.script.outputs.ref != '' }}
run:|
# 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."
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.
@@ -182,3 +179,26 @@ Fixes #ISSUE_NUMBER
- 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.
Nx Cloud AI offers a suite of features designed to **enhance your development workflow with AI-driven capabilities**. These tools assist in troubleshooting, optimizing resource allocation, and improving your overall development process.
- **[Explain with AI](/docs/features/ci-features/explain-with-ai)** - This feature uses AI to provide detailed explanations about failed tasks.
## Enable Nx Cloud AI Features
To enable AI features for your organization, go to your organization's settings on [Nx Cloud](https://cloud.nx.app/orgs?utm_source=nx.dev&utm_campaign=ai) and select the organization where you want to enable AI.
In the **settings** menu, find the "AI Features" section and toggle it to "On".

Ensure that you **accept the AI terms** to start using the AI features.
{% aside type="note" title="AI Features Availability" %}
AI features are available only for the [Nx Cloud Team plan](https://nx.dev/pricing).
{% /aside %}
### Enable AI Features for Enterprise On-Prem Installations
To enable AI features for enterprise on-prem installations, add the following configuration to your `helm-values.yaml` file:
```yaml
nxApi
deployment:
env:
- name: NX_CLOUD_AI_ENABLED
value: 'true'
frontend
deployment:
env:
- name: OPENAI_SECRET_KEY
valueFrom:
secretKeyRef:
name: open-ai-secrets
key: OPENAI_SECRET_KEY
- name: NX_CLOUD_AI_ENABLED
value: 'true'
```
Ensure your OpenAI secret key is correctly configured to provide the necessary credits for `gpt-3.5-turbo` and `gpt-4`.
### Regional Availability
This feature is not available for the EU cluster in public cloud installations due to regional restrictions. However, on-prem customers in the EU can still use this feature by providing their own OpenAI secret key and enabling the required environment variables.
description: Learn how Nx features combine to create optimized CI pipelines through fast tools, reduced waste, and efficient task distribution
filter: 'type:Concepts'
---
Nx has many features that make your CI faster. Each of these features speeds up your CI in a different way, so that enabling an individual feature will have an immediate impact. These features are also designed to complement each other so that you can use them together to create a fully optimized CI pipeline.
description: Best practices for securing your remote cache and preventing cache poisoning in Nx Cloud
filter: 'type:Concepts'
---
{% aside type="caution" title="Use Caution With Read-Write Tokens" %}
@@ -53,7 +55,7 @@ In order to guarantee that cache poisoning will never affect your end users, [sk
### Do Not Manually Share Your Local Cache
Nx implicitly trusts the local cache which is stored by default in the `.nx/cache` folder. You can change the location of that folder in the `nx.json` file, so it could be tempting to place it on a network drive and easily share your cache with everyone on the company network. However, by doing this you've voided the guarantee of immutability from your cache. If someone has direct access to the cached files, they could directly poison the cache. Nx will automatically detect if a cache entry has been created in your local cache using a different machine and warn you with an [Unknown Local Cache Error](/docs/troubleshooting/unknown-local-cache). Instead, use Nx Cloud [remote caching](/docs/features/ci-features/remote-cache). If you want share your local cache anyway, you can [activate Nx Powerpack](/docs/enterprise/activate-powerpack) and use the [`@nx/shared-fs-cache`](/docs/reference/remote-cache-plugins/shared-fs-cache) plugin.
Nx implicitly trusts the local cache which is stored by default in the `.nx/cache` folder. You can change the location of that folder in the `nx.json` file, so it could be tempting to place it on a network drive and easily share your cache with everyone on the company network. However, by doing this you've voided the guarantee of immutability from your cache. If someone has direct access to the cached files, they could directly poison the cache. Nx will automatically detect if a cache entry has been created in your local cache using a different machine and warn you with an [Unknown Local Cache Error](/docs/troubleshooting/unknown-local-cache). Instead, use Nx Cloud [remote caching](/docs/features/ci-features/remote-cache). If you want share your local cache anyway, you can use the [`@nx/shared-fs-cache`](/docs/reference/remote-cache-plugins/shared-fs-cache) plugin.
description: Understanding task parallelization strategies and distributed task execution with Nx Agents
filter: 'type:Concepts'
---
Nx speeds up your CI in several ways. One method is to reduce wasted calculations with the [affected command](/docs/features/ci-features/affected) and [remote caching](/docs/features/ci-features/remote-cache). No matter how effective you are at eliminating wasted calculations in CI, there will always be some tasks that really do need to be executed and sometimes that list of tasks will be everything in the repository.
@@ -32,7 +34,7 @@ You can either distribute tasks across machines manually, or use Nx Cloud distri
One way to manually distribute tasks is to use binning. Binning is a distribution strategy where there is a main job that divides the work into bins, one for each agent machine. Then every agent executes the work prepared for it. Here is a simplified version of the binning strategy.
```yaml
```yaml
// main-job.yml
# Get the list of affected projects
- nx show projects --affected --json > affected-projects.json
@@ -41,13 +43,13 @@ One way to manually distribute tasks is to use binning. Binning is a distributio
- node storeAffectedProjects.js
```
```yaml
```yaml
// lint-agent.yml
# Run lint for all projects defined in PROJECTS
- nx run-many --projects=$PROJECTS -t lint
```
```yaml
```yaml
// test-agent.yml
# Run test for all projects defined in PROJECTS
- nx run-many --projects=$PROJECTS -t test
@@ -105,6 +107,6 @@ In the same way that Nx efficiently assigns tasks to parallel processes on a sin
## Conclusion
If your repo is starting to grow large enough that CI times are suffering, or if your parallelization strategy is growing too complex to manage effectively, try [setting up Nx Agents](/docs/features/ci-features/distribute-task-execution). You can [generate a simple workflow](/docs/reference/core-api/workspace/generators/ci-workflow) for common CI providers with a `nx g ci-workflow` or follow one of the [CI setup recipes](/docs/guides/nx-cloud/setup-ci).
If your repo is starting to grow large enough that CI times are suffering, or if your parallelization strategy is growing too complex to manage effectively, try [setting up Nx Agents](/docs/features/ci-features/distribute-task-execution). You can [generate a simple workflow](/docs/reference/workspace/generators#ci-workflow) for common CI providers with a `nx g ci-workflow` or follow one of the [CI setup recipes](/docs/guides/nx-cloud/setup-ci).
Organizations that want extra help setting up Nx Cloud or getting the most out of Nx can [sign up for Nx Enterprise](https://nx.dev/enterprise). This package comes with extra support from the Nx team and the option to host Nx Cloud on your own servers.
description: How the affected command and remote caching eliminate wasted time in CI pipelines
filter: 'type:Concepts'
---
This article explores two ways that Nx improves the average speed of your CI pipeline - `nx affected` and remote caching. Using the `nx affected` command speeds up the first CI run for a PR and remote caching speeds up every CI run after that. Both `nx affected` and remote caching provide more benefits to repositories with more projects and a flatter project structure.
@@ -16,9 +18,9 @@ How much benefit you gain from this is different for each repository, but there
If we look at these two trivial examples, you can see that the repository with more projects gains more value from the affected command.
@@ -89,9 +94,9 @@ If we look at these two trivial examples, you can see that the repository with m
"groupByFolder": false,
"exclude": []
}
{% /graph %}
```
{% /cards %}
{% /graph %}
In the one project example, every PR will affect the entire repository. In the four project example, modifying one project only affects 25% of the repository. For the one project repository `nx affected -t build` is identical to `nx run-many -t build`, whereas for the four project repository, `nx affected -t build` cuts out the 75% of wasted work.
@@ -101,9 +106,9 @@ With this principle in mind, you can add more applications to the repository to
@@ -219,9 +231,9 @@ Consider the following example repo structures.
"groupByFolder": false,
"exclude": []
}
{% /graph %}
```
{% /cards %}
{% /graph %}
If we assume that each project has an independent 50% chance of being modified on a given PR, we can calculate the expected average number of affected projects. Intuitively, the flat structure should have less affected projects than the stacked structure and the grouped structure should fall somewhere in between. That is, in fact, the case.
@@ -288,8 +300,9 @@ The first time CI runs for a particular PR, affected is doing most of the work t
Take a look at the example below. The projects are setup in the suboptimal stacked arrangement from before. On the first CI run, `project3` was modified, so every project is affected. Then the developer realizes that `project2` should be changed as well and pushes a new commit. For the second CI run, every project is still affected when compared against the `main` branch, but `project3` hasn't changed between the first CI run and the second, so the cache from the first CI run can be used instead of re-running that task. `project2` tasks need to be re-run since it was modified and `project1` tasks need to be re-run since it depends on a project that was modified.
description: Learn about code ownership challenges in monorepos and how Nx helps manage shared code with tools like CODEOWNERS and module boundary rules.
sidebar:
order: 100
filter: 'type:Concepts'
---
One of the most obvious benefits of having a monorepo is that you can easily share code across projects. This enables you to apply the Don't Repeat Yourself principle across the whole codebase. Code sharing could mean using a function or a component in multiple projects. Or code sharing could mean using a typescript interface to define the network API interface for both the front end and back end applications.
description: Compare independently maintained dependencies versus single version policy approaches for monorepos, with guidance on choosing the right strategy for your team.
filter: 'type:Concepts'
---
When working with a monorepo, one of the key architectural decisions is how to manage dependencies across your projects. This document outlines two main strategies and helps you choose the right approach for your team.
@@ -44,6 +45,10 @@ For building and deployment, you'll need to ensure each project only includes it
The main challenge with this approach is coordinating dependency updates across independent teams. When multiple teams work on different, or even the same, applications within the same repo, they need to align on dependency upgrades. While this requires more coordination, it often results in less total work - upgrading a dependency once across all projects is typically more efficient than managing multiple separate upgrades over time.
When using PNPM, use [PNPM catalogs](https://pnpm.io/catalogs) to maintain single version policy. Define versions in `pnpm-workspace.yaml` and reference them as `"<package>": "catalog:"` in project `package.json` files (Nx 22+).
description: Learn about organizing your Nx monorepo with effective folder structures, and how to easily move or remove projects as your organization evolves.
filter: 'type:Concepts'
---
Nx can work with any folder structure you choose, but it is good to have a plan in place for the folder structure of your monorepo.
@@ -9,19 +10,19 @@ Projects are often grouped by _scope_. A project's scope is either the applicati
## Move Generator
Don't be too anxious about choosing the exact right folder structure from the beginning. Projects can be moved or renamed using the [`@nx/workspace:move` generator](/docs/reference/core-api/workspace/generators/move).
Don't be too anxious about choosing the exact right folder structure from the beginning. Projects can be moved or renamed using the [`@nx/workspace:move` generator](/docs/reference/workspace/generators#move).
For instance, if a project under the `booking` folder is now being shared by multiple apps, you can move it to the shared folder like this:
```shell {% frame="none" %}
```shell
nx g move --project booking-some-project shared/some-project
```
## Remove Generator
Similarly, if you no longer need a project, you can remove it with the [`@nx/workspace:remove` generator](/docs/reference/core-api/workspace/generators/remove).
Similarly, if you no longer need a project, you can remove it with the [`@nx/workspace:remove` generator](/docs/reference/workspace/generators#remove).
```shell {% frame="none" %}
```shell
nx g remove booking-some-project
```
@@ -32,6 +33,7 @@ Let's use Nrwl Airlines as an example organization. This organization has two ap
The purpose of these folders is to help with organizing by scope. We recommend grouping projects together which are (usually) updated together. It helps minimize the amount of time a developer spends navigating the folder tree to find the right file.
{% filetree %}
- apps/
- booking/
- check-in/
@@ -45,6 +47,7 @@ The purpose of these folders is to help with organizing by scope. We recommend g
- seatmap/ <---- grouping folder
- data-access/ <---- project
- feature-seatmap/ <---- project
{% /filetree %}
## Sharing Projects
@@ -54,6 +57,7 @@ One of the main advantages of using a monorepo is that there is more visibility
Let's consider our reference monorepo. The `shared-data-access` project contains the code needed to communicate with the back-end (for example, the URL prefix). We know that this would be the same for all libs; therefore, we should place this in the shared lib and properly document it so that all projects can use it instead of writing their own versions.
description: Evaluate the organizational considerations for choosing between monorepo and polyrepo approaches, including team agreements on code management and workflows.
filter: 'type:Concepts'
---
Monorepos have a lot of benefits, but there are also some costs involved. We feel strongly that the [technical challenges](/docs/concepts/decisions/why-monorepos) involved in maintaining large monorepos are fully addressed through the efficient use of Nx and Nx Cloud. Rather, the limiting factors in how large your monorepo grows are interpersonal.
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.