## Current Behavior
On Node.js v24+, the `@nx/jest/plugin` sets
`--no-experimental-strip-types` in NODE_OPTIONS which causes an error:
"node: --no-experimental-strip-types is not allowed in NODE_OPTIONS".
Additionally, `jest.config.ts` files using ESM syntax (`export default`,
`import`) fail to load correctly under Node.js type-stripping when the
project is configured for CommonJS.
## Expected Behavior
- Remove the NODE_OPTIONS manipulation that adds
`--no-experimental-strip-types`
- Add a migration (22.2.0-beta.2) that converts `jest.config.ts` files
from ESM to CJS syntax for projects using `@nx/jest/plugin`
- The migration only runs when `@nx/jest/plugin` is registered in
`nx.json`
- Projects with `type: module` are warned as they're incompatible with
the plugin
- Files using ESM-only features (import.meta, top-level await) are
skipped with a warning for manual conversion
## Demo
https://www.loom.com/share/8a157a0b01d144ae8d6ae48b9b0cd0e4
## Related Issue(s)
Closes NXC-3541
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
We don't have a migration to migrate users to use the new @nx/vitest
package if they're currently using @nx/vite
Given that we have Vitest-related operations marked as deprecated when
used via @nx/vite, we should have a migration.
## Expected Behavior
Add a migration that:
1. Installs @nx/vitest
2. Switches @nx/vite:test executor usage to use @nx/vitest:test executor
usage
3. Splits `@nx/vite/plugin` in nx.json that sets up vitest test targets
to use `@nx/vitest` instead
## Current Behavior
The `@nx/vite:test` executor is not returning the async iterable. This
causes a destructuring issue.
## Expected Behavior
Ensure the `@nx/vite:test` executor returns the async iterable.
## Related Issue(s)
Fixes#33588
This PR updates the `workspace-rule` generator so use ESLint v9 by
default. It currently forces the unsupported ESLint v8.
In theory this is only useful if not using workspaces and you need
tsconfig paths to be mapped and resolved correctly. For workspaces, you
can easily just generate any library to be used to contain custom rules.
Closes NXC-3500
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Blog posts contain broken links pointing to old `/powerpack` and
`/docs/enterprise/powerpack/*` paths that no longer exist.
## Expected Behavior
Links should point to the new enterprise documentation paths:
- `/powerpack` → `/enterprise`
- `/docs/enterprise/powerpack/*` → `/docs/enterprise/*`
- `/docs/reference/powerpack/*` → `/docs/reference/*`
## Related Issue(s)
Closes DOC-354
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When running `NX_PERF_LOGGING=true nx graph --file graph.json`, many
performance logs are missing (e.g., `create-project-graph-async`,
`retrieve-project-configurations`).
Only plugin-specific logs like `createDependencies` appear.
## Expected Behavior
All performance timing logs should appear, matching the output of
`NX_PERF_LOGGING=true nx show projects`.
## Related Issue(s)
N/A - Internal improvement for debugging/profiling.
## Solution
The `graph.ts` file had `process.exit(0)` calls that terminated the
process immediately, not giving the async `PerformanceObserver` callback
time to fire.
Added `await new Promise((res) => setImmediate(res))` before
`process.exit(0)` to give the event loop one tick to process pending
callbacks. This follows the existing
pattern in `show/projects.ts` and `show/project.ts`.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The Nx Console installation prompt blocks commands when run in
non-interactive contexts such as:
- CI environments
- AI agents
- Piped commands
The prompt only checked `process.stdout.isTTY` but not
`process.stdin.isTTY`, causing it to wait indefinitely for input that
would never arrive.
## Expected Behavior
Commands should complete without prompting when run in non-interactive
environments.
## Related Issue(s)
Fixes#33552
## Solution
Updated the check to verify:
1. Both `stdin` and `stdout` are TTY (truly interactive terminal)
2. Not running in a CI environment (using existing `isCI()` utility)
This ensures the prompt only appears when the user can actually provide
input.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Since Nx 21.6.1, running `nx graph` or other commands that calculate
affected projects prints git errors to stderr when the default branch is
not fetched:
```
fatal: ambiguous argument 'main': unknown revision or path not in the working tree.
```
This causes CI pipelines with strict stderr checking to fail, even
though the nx commands succeed.
## Expected Behavior
Git error messages should not be printed to stderr. The errors are
already caught and handled gracefully - they just shouldn't be visible
to the user.
## Related Issue(s)
Fixes#33330
## Solution
Added `stdio: 'pipe'` to the `execSync` call in `parseGitOutput()`. This
suppresses stderr output while still allowing the command to throw on
failure (which is already caught by the try-catch in `graph.ts`).
This matches the pattern used in `getMergeBase()` which already uses
`stdio: 'pipe'`.
## Current Behavior
When running `nx migrate latest`, the `create-nx-workspace` package is
not updated along with other Nx packages, even though it's a core part
of the Nx ecosystem that users may have as a dependency (especially when
extending the install package pattern).
## Expected Behavior
The `create-nx-workspace` package should be updated to the same version
as `nx` and other `@nx/*` packages when running migrations.
## Related Issue(s)
Fixes#33585
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The nuxt preset test was checking for `apps/${name}/src/app.vue`, but
since the generator now defaults to Nuxt v4 which uses the app directory
structure, this file is no longer created at that path.
## Expected Behavior
Tests should pass on master.
## Solution
Updated the test to check for `apps/${name}/app/app.vue` which is the
correct path for Nuxt v4's app directory structure.
## Current Behavior
When Nx commands finish or receive termination signals (SIGINT, SIGTERM,
SIGHUP), child processes spawned by continuous tasks (such as `nx
serve`) can remain orphaned in certain scenarios. This happens because
only the direct child process is killed using `childProcess.kill()`,
leaving grandchild processes running.
## Expected Behavior
When Nx terminates, all processes in the spawned process tree should be
properly terminated and no orphaned processes should remain.
## Related Issue(s)
Fixes#32438Fixes#33460
## Changes
- Updated signal handlers in `RunningNodeProcess` to use `this.kill()`
instead of `this.childProcess.kill()`, leveraging the existing
`tree-kill` implementation
- Added `tree-kill` to `NodeChildProcessWithNonDirectOutput` and
`NodeChildProcessWithDirectOutput` kill methods to ensure entire process
trees are terminated
We missed a peer dep error in the Nuxt 4 PR since CI allowed install to
go through, but in a real repo it would have failed.
We _may_ need to still have the `prefer-frozen-lockfile=false` option,
but let's let CI run with this first.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
We currently do not support Nuxt 4. We still generate Nuxt 3.
## Expected Behavior
Support Nuxt 4.
New workspaces will get Nuxt 4.
Existing Workspaces that use Nuxt 3 intentionally will continue to use
Nuxt 3.
Add a migration to update users to Nuxt 4
Handle ESLint flat config
## Related Issue(s)
Closes NXC-3525
Closes NXC-3497
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
The base `eslint` config will ignore `**/dist` but not `**/out-tsc`.
This can cause issues if lint is run after a `typecheck` which has
placed `.d.ts` files into an `out-tsc` directory.
## Expected Behavior
Base eslint config should ignore `**/out-tsc`
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Storybook support is not explicitly set to 10.1 which has just been
released.
## Expected Behavior
Explicitly set storybook version to 10.1 to ensure support for Angular
21
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
- E2E nightly tests only run on Node 20 and 22.
- E2E nightly tests now also run on Node 24, 22, and 20 for linux. For
Windows and Mac run only 24.
Did a test run from this branch, and Node 24 passes where other versions
pass, and fails where other versions fail. It shouldn't make any golden
tests fail just due to Node 24, but it's possible that things will flake
more since the matrix has expanded. We just have to make them more
robust.
<img width="920" height="1089" alt="image"
src="https://github.com/user-attachments/assets/90ee4d04-68d5-4d0d-9729-60cacfbc99db"
/>
Close NXC-3491
## Current Behavior
The Next 16 AI Migration Instructions are always created, regardless of
existing Next version
## Expected Behavior
Make the Next 16 Migration optional
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
There is no documentation on how to create and use custom ESLint rules
in Nx workspaces.
Users can follow a guide to create custom ESLint rules using either:
1. Package Manager Workspaces (npm/yarn/pnpm/bun) - create a dedicated
ESLint plugin package that's symlinked via the package manager
2. `loadWorkspaceRules` utility from `@nx/eslint-plugin` - load rules
from any directory with automatic TypeScript transpilation
The guide includes:
- Comparison table for choosing the right approach
- Step-by-step instructions for both approaches
- TypeScript execution options (build first, Node.js native support,
tsx)
- Rule testing with `@typescript-eslint/rule-tester`
- Best practices and troubleshooting tips
Page:
https://deploy-preview-33618--nx-docs.netlify.app/docs/technologies/eslint/guides/custom-workspace-rules
Closes DOC-339
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Despite @nx/vite depending on @nx/vitest it only does so in the same
version that introduces the migration for Vitest 4.
This means the user does not get any migrations for Vitest 4
## Expected Behavior
Add the Vitest 4 migrations to the @nx/vite package to allow users to
migrate.
There's a problem when `@nx/rollup` is installed with yarn@1.22, and
typechecks.
This is caused by the transitive dependency chain:
```
rollup-plugin-copy@3.5.0 -> globby@10.0.1 -> @types/glob@7.2.0 -> @types/minimatch
```
When users run tsc without explicit `types` configuration, TypeScript
auto-discovers `@types/minimatch` from `node_modules` but can't properly
resolve it.
Note: This doesn't happen with NPM and PNPM, nor newer yarn versions.
Verified fix with this repro: https://github.com/jaysoo/rollup-251124Fixes#32398
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
- Storybook generator docs banner says "Nx uses Storybook 7"
- Separate storybook-9-setup.mdoc page exists
- No documentation for migrate-10 generator
## Expected Behavior
- Update banner to "Nx uses Storybook 10"
- Consolidate storybook-9-setup into upgrading-storybook guide
- Add migrate-10-generator-examples.md with AI-assisted migration docs
- Update all references to point to new consolidated guide
---
Main content is here:
https://deploy-preview-33619--nx-docs.netlify.app/docs/technologies/test-tools/storybook/guides/upgrading-storybook
Need to follow-up on the sidebar ordering as it doesn't seem to take it
into account for technologies section.
Fixes DOC-347
## Current Behavior
When a continuous task depends on another continuous task and the
dependent task exits with an error, the parent task continues running
indefinitely. The task execution never terminates, leaving processes
running in the background.
For example, if task `a` (continuous) depends on task `b` (continuous),
and task `b` exits with error code 1, task `a` will continue running
even though its dependency failed.
## Expected Behavior
When a continuous task exits (with any exit code), the failure should be
propagated to dependent tasks:
1. The failed continuous task should be marked as failed
2. Dependent continuous tasks should be marked as skipped
3. All affected continuous tasks should be killed
4. Task execution should terminate with an error
---
## Changes Made
### 1. Restore Error Handling in Continuous Task Exit Handlers
- Re-added the `cleaningUp` flag that was removed in a previous
TUI-related commit
- Modified `onExit` handlers for both regular and shared continuous
tasks to:
- Check if the task exited during normal cleanup vs. unexpectedly
- Call `complete()` with 'failure' status for unexpected exits
- Log error messages for debugging
### 2. Fix `cleanUpUnneededContinuousTasks()` Logic
The previous implementation always added `initializingTaskIds` to the
needed set, even when those tasks were already completed. This prevented
dependency tasks from being killed when the top-level task exited.
Fixed by:
- Only adding tasks from `initializingTaskIds` if they are still
incomplete
- Keeping dependencies of incomplete tasks alive
- This ensures continuous tasks are killed when no longer needed,
whether a dependency fails or a top-level task exits
### 3. Prevent Status Overwrites
Added a check in `onExit` handlers to only set status to `Stopped` if
the task hasn't already been completed. This prevents the async `onExit`
callback from overwriting the correct status (like 'skipped' or
'failure') with 'Stopped'.
### 4. Fix Signal Handling in `PseudoTtyProcess.kill()`
The Rust pseudo-terminal defaults to SIGINT when no signal is provided,
which does not reliably terminate child processes in PTY sessions.
Fixed by:
- Defaulting to SIGTERM in the JavaScript wrapper (rather than changing
the Rust default)
- The JS wrapper is the API boundary that should match Node.js
semantics, where `childProcess.kill(undefined)` defaults to SIGTERM
- The Rust default of SIGINT is appropriate for interactive use
(Ctrl-C), while programmatic cleanup needs SIGTERM
- This ensures child processes are properly killed when
`runningTask.kill()` is called
**File:** `packages/nx/src/tasks-runner/pseudo-terminal.ts`
## Technical Details
The fix leverages the existing task failure propagation mechanism in
`complete()` instead of using `process.exit(1)`, which:
- Allows proper cleanup through normal execution flow
- Respects the `--bail` flag configuration
- Works correctly with both TUI and non-TUI modes
- Maintains consistency with how other task failures are handled
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Older versions don't support the `nx mcp` command yet - but they CAN use
the `nx-mcp` package via npx
## Expected Behavior
We generatee the proper command into their MCP config by matching on
their version
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When multiple versions of the `nx` package are installed in a workspace
(e.g., due to a third-party package incorrectly depending on nx), users
have no visibility into
this issue through `nx report`.
## Expected Behavior
The `nx report` command now detects when other packages depend on a
different version of nx than the workspace version and reports this
clearly:
⚠️ Multiple Nx versions detected
Your workspace uses nx@20.0.0, but other packages depend on a different
version:
- some-package → @scope/tool → nx@19.0.0
These packages should not have nx as a dependency. Please report this
issue to the package maintainers.
Run pnpm why nx@19.0.0 for more details.
This helps users identify and report problematic packages that bundle
their own version of nx.
## Related Issue(s)
N/A - This is a proactive improvement to help users diagnose workspace
issues.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
nightly tests fail on gradle because of gradle parsing
## Expected Behavior
nightly tests should pass
## Current Behavior
We do not generate AI Instructions to aid with upgrading from Next 15 to
Next 16
## Expected Behavior
Add a migration generator to create a file containing instructions for
an LLM to upgrade Next 15 to Next 16
## Related Issue(s)
Closes NXC-3418
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
In TS Solution setups, we generate webpack config with
`generatePackageJson: true`. This is confusing and unneeded.
It should be set to false in TS Solution repos.
## Expected Behavior
Set `generatePackageJson: false` in webpack config for TS Solution
Setups
Closes NXC-3521
When generating NestJS applications in Angular workspaces, the base
tsconfig sets moduleResolution to 'bundler' which causes TS5095 errors
because 'bundler' requires module to be 'preserve' or 'es2015+'.
NestJS applications should use Node.js module resolution instead. This
fix sets moduleResolution to 'node' for NestJS applications (except when
using TS solution setup, which uses 'nodenext').
Fixes#33589
## Current Behavior
The ⚠️ emoji at the beginning of bc commits is duplicated in the bc
section of the changelog.
This is unneeded.
## Expected Behavior
Ensure the ⚠️ is not repeated in the bc section of the changelog
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
Close NXC-3516
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
1. **Socket Race Condition**: All daemon servers listen on the same
socket path, causing a race condition where shutting down daemons remove
sockets that newly started
daemons are listening on.
2. **Daemon Console Check Blocks**: The daemon availability check runs
synchronously and blocks the main thread.
3. **Version Mismatch Issues**: Packages using a different nx version
than what's installed in the workspace could still use the daemon,
leading to potential issues.
## Expected Behavior
1. Each daemon server creates a unique socket path based on its process
ID, preventing race conditions.
2. The daemon console check runs in the background without blocking.
3. The daemon is disabled when there's a version mismatch between the
running nx and the workspace's installed version.
## Changes
### 1. Unique Daemon Socket Paths
- Include `process.pid` in the socket directory hash to make each
daemon's path unique
- Store the socket path in `server-process.json` so clients know where
to connect
- Clients read the socket path from the file instead of calculating it
### 2. Backgroundable Daemon Check
- Reapplied #33491 which makes the Nx Console install check run on the
daemon in the background
- This was previously reverted due to the socket race condition (now
fixed by change 1.)
- Running in background also allows pulling the latest check logic from
npm
### 3. Version Mismatch Check
- Added `isNxVersionMismatch()` check in `DaemonClient.enabled()`
- Created shared utility `is-nx-version-mismatch.ts` for version
comparison
- Refactored server.ts to use the shared utility
- Uses `require.resolve('nx/package.json', { paths: [workspaceRoot] })`
to properly resolve the workspace's installed nx version
## Related Issue(s)
Fixes daemon socket path race condition and improves daemon reliability.
## Current Behavior
`copy-workspace-modules` executor only copies workspace dependencies 1
level deep.
If that workspace library depends on another workspace library, it is
not copied correctly.
## Expected Behavior
Copy transitive workspace modules
## Related Issue(s)
Fixes NXC-3466
When adding Cypress to a library, the generated commands.ts causes
TS2669 error because declare global requires the file to be a module.
Changed to use declare namespace Cypress directly.
Fixes#32930
## Current Behavior
PR #33491 introduced a daemon call into every command and caused
unexpected issues...
## Expected Behavior
the change is reverted while we investigate a proper fix
## Changes
This reverts commit 9471207767 from PR
#33491.
## Related Issue(s)
Fixes#33472
## Current Behavior
The manual DTE workflow explicitly sets the `ref` parameter to `${{
github.event.pull_request.head.sha }}` to checkout the actual branch
HEAD instead of the merge commit.
## Expected Behavior
Use GitHub's default ref behavior instead of explicitly overriding it,
as the default behavior now handles this correctly.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When generating a React component with --style=tailwind, the component
template incorrectly includes `className={styles['container']}` and
attempts to import CSS modules.
## Expected Behavior
Components generated with --style=tailwind should not include CSS
modules imports or `styles['container']` references, since Tailwind
doesn't use CSS modules.
## Related Issue(s)
Closes NXC-3511
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Stats don't come along with versions which makes it hard to see if it
was specific changes that make a difference.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stats are tagged with the version so we can compare stats between
versions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR fixes an issue where migrations can hang due to out invocation
of `storybook automigrate`. We are passing both `--config-dir` and
`STORYBOOK_PROJECT_ROOT`, the latter causes hanging with Storybook v9.
https://www.loom.com/share/39bbb350595c4a13aef86ec29f4b748f
## Current Behavior
Hangs
## Expected Behavior
Does not hang
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32492
This PR cleans up the markdown files under `packages/`. We previously
had to support Next.js docs and translate it for astro docs with proper
markdown syntax. This applies to generators, executors, and migrations.
Also removes the function to do the translation in astro app since it's
no longer needed.
## Code block (migrations)
<img width="1086" height="800" alt="Screenshot 2025-11-20 at 1 23 53 PM"
src="https://github.com/user-attachments/assets/bd9acb9b-7960-4e41-9d26-22d29da6658e"
/>
## Aside (generators)
<img width="802" height="443" alt="Screenshot 2025-11-20 at 1 43 17 PM"
src="https://github.com/user-attachments/assets/e2999821-8783-46ed-a984-2193f6f8eafa"
/>
## Current Behavior
During createNodes, if a file is imported and a function in said file
invokes the Nx project graph creation process, there's an infinite loop
that results in all nx commands hanging with little feedback.
Theoretically this loop would terminate at around the 10 minute mark,
but throughout the loop we would be digging deeper and deeper into
recursive territory so its possible that the node process could become
overwhelmed and hang.
## Expected Behavior
If recursive graph creation is detected, Nx terminates and logs the call
stack so it can be investigated properly.
## Related Issue(s)
Fixes#29618
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
This PR adds the ability for users to import ESLint rules from arbitrary
location in the workspace rather than storing them in
`tools/eslint-rules`. This is useful for monorepo not using
npm/yarn/pnpm workspaces and need a mechanism to load from any custom
rules location without them being installed/symlinked.
It also handles TS files automatically.
Demo: https://www.loom.com/share/3c32af4555614eeab4f81fce8db0c955
Example:
```js
import baseConfig from "../../eslint.config.mjs";
import { loadWorkspaceRules } from "@nx/eslint-plugin";
const customRules = await loadWorkspaceRules("foo/bar/eslint-rules");
export default [
...baseConfig,
{
ignores: ["**/out-tsc"],
},
{
files: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"],
plugins: {
custom: { rules: customRules },
},
rules: {
"custom/valid-command-object": "error",
},
},
];
```
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
Daemon command hangs at end instead of exiting
## Expected Behavior
Daemon command exits
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There's some issues with the jest configs in the repo, CJS files having
`import` in them, etc.
## Expected Behavior
CJS files don't have `import`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`cache: true` is overridden if task name is dev
## Expected Behavior
`cache: true` has priority
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32610
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Using .mts extension forces files to always be treated as ESM modules,
ensuring consistent behavior regardless of package.json or tsconfig
settings.
This matters for Node 24 because by default Node will strip types from
`.ts` files and then they are resolved through normal Node resolution.
In the past we can control CJS/ESM through tsconfig options, but now
only extension or `type` in `package.json` matters.
Changes:
- Updated all createOrEditViteConfig calls to pass useEsmExtension: true
- Updated normalizeViteConfigFilePathWithTree to check for .mts files
first
- Updated test files to expect .mts config files
- Updated snapshots to reflect new .mts extension
Closes NXC-3446
Flat config overrides util may fail when it isn't a plain JS object.
This PR makes the `hasOverrides` function more robust against these
cases.
Fixes#31796
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
the JSON parsing is broken because in verbose mode, the gradle plugin
returns more than just JSON.
## Expected Behavior
JSON parsing in the test should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We naively mark WholeFileChange for commits when getting the relevant
commits for projects.
There is already logic to perform better diff checking for lock files,
especially in the case of pnpm catalog usage
## Expected Behavior
Reuse existing logic to determine file changes more accurately
## Related Issue(s)
Fixes#33413
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
If no inputs or named inputs are defined, this area of code was hit:
```
const DEFAULT_INPUTS: ReadonlyArray<InputDefinition> = [
{
fileset: '{projectRoot}/**/*',
},
{
dependencies: true,
input: 'default',
},
];
export function getNamedInputs(
nxJson: NxJsonConfiguration,
project: ProjectGraphProjectNode
) {
return {
default: [{ fileset: '{projectRoot}/**/*' }],
...nxJson.namedInputs,
...project.data.namedInputs,
};
}
```
This resulted in weird behavior when the user would define `default` in
named inputs, but it would seemingly only be applied to the project's
deps and not the project itself
## Expected Behavior
The `default` input is the default for both
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #https://github.com/nrwl/nx/issues/32924
## Current Behavior
Every time a daemon connection is opened, we create a new interval and
unref it. This results in the daemon checking its process termination at
an ever increasing rate, which presents as increased memory usage and
practically means the daemon is just doing a lot more work than it needs
to in this area.
## Expected Behavior
The interval is registered only on initial server startup.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29836
This PR updates the guide here to also include type entries (which we
generate by default):
https://nx.dev/docs/technologies/typescript/guides/compile-multiple-formats
Update the content to account for the new inferred `@nx/rollup/plugin`
setup, but still mentions the executor. And also link to a tool that can
be used to check for types correctness.
Closes#33258
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
if there is an error parsing a schema file for generators/executors then
we should fully error out to prevent caching a "bad" build even if the
site techincally works with missing plugin info.
## Current Behavior
Metrics collection is currently disabled in the CI workflow via the
`NX_CLOUD_ENABLE_METRICS_COLLECTION` environment variable set to
'false'.
## Expected Behavior
Metrics collection should be enabled to gather build and performance
data from CI runs.
## Related Issue(s)
Reverts the change from #33497
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The `@nx/js:typescript-sync` generator never syncs external project
references to `tsconfig.json` files if a runtime tsconfig file exists.
## Expected Behavior
The `@nx/js:typescript-sync` generator should sync external project
references to `tsconfig.json` files if it includes any files or a
runtime tsconfig file doesn't exist.
## Summary
This PR fixes a critical deadlock issue in the metrics collector that
occurred due to inconsistent lock acquisition order between the
collection thread and registration threads. The fix involved
restructuring lock scopes across multiple functions to maintain a
consistent lock hierarchy.
## Changes
- Fixed lock acquisition order in 4 registration functions
(register_main_cli_process, register_main_cli_subprocess,
register_task_process, register_batch)
- Restructured collect_metrics() to minimize system lock scope and
release it before acquiring other locks
- Fixed collection helper methods to read PIDs in scoped blocks without
holding system lock
- Added comprehensive trace logging for debugging lock contentions
- Added concurrent test case to verify no deadlocks occur under stress
## Testing
- All 12 metrics tests pass
- Comprehensive concurrent stress test added:
test_concurrent_group_creation_with_subprocess_updates
- Lock ordering consistency test added:
test_lock_order_consistency_across_registration_threads
## Lock Ordering Rule
Established and enforced this hierarchy across all threads:
1. Acquire system lock first
2. Release system lock
3. Then acquire registration/PID locks
This prevents circular wait conditions (A→B / B→A) that cause deadlocks.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
When Storybook is installed with a version range like `^10.0.0` or
`~8.5.3`, the configuration generator fails with error:
```
NX Invalid Version: ^10.0.0
TypeError: Invalid Version: ^10.0.0
```
This occurs because `gte()` from semver doesn't accept version ranges on
the left-hand side - only valid semver versions are allowed there.
The Storybook configuration generator should work with version ranges by
extracting the actual version number before comparison.
Fixes#33514
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Env variables from the parent target are not propagated to the atomized
target e.g.
`.test-ci.env` will be only applied to **no-op** `test-ci` but not to
`test-ci--path/to/test/file`.
## Expected Behavior
Running an atomized target will load from the parent's env files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Gradle projects in Nx workspaces can only configure metadata through
Gradle's built-in mechanisms. There's no way to specify Nx-specific
project metadata (like tags) or customize task target configurations
other than overriding with `project.json`
## Expected Behavior
Developers can now configure Nx-specific metadata for both projects and
tasks using a type-safe Kotlin/Groovy DSL:
### Project-level metadata (in build.gradle.kts):
```
nx {
set("name", "my-service")
array("tags", "scope:backend", "type:api")
set("description", "Payment processing service")
}
```
### Task-level metadata (in build.gradle.kts):
```
tasks.named("integrationTest") {
nx {
set("cache", false)
array("tags", "integration", "slow")
}
}
```
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
## Current Behavior
In certain scenarios, Nx commands would hang between command completion
and process exit. This was caused by inefficient message end detection
in the
daemon socket communication, where the check for `MESSAGE_END_SEQ` could
fail when TCP packets were fragmented.
## Expected Behavior
With this PR, the message end detection is more robust and handles TCP
packet fragmentation correctly, preventing the hanging issue. The
changes also
add better performance tracking and logging to help diagnose similar
issues in the future.
## Changes Made
- **Improved message end detection**
(`consume-messages-from-socket.ts`): Added a preliminary check of the
last character's code point before checking
the full MESSAGE_END_SEQ, which prevents false negatives when TCP
packets are fragmented
- **Enhanced performance tracking** (`daemon/client/client.ts`,
`daemon-socket-messenger.ts`): Added message-type-specific performance
marks and
measures for better debugging
- **Added server-side logging** (`daemon/server/server.ts`): Added
logging for message receipt, serialization, and response to help
diagnose
communication issues
## Related Issue(s)
This fix addresses hanging issues observed in daemon communication when
commands complete but the process doesn't exit.
Add a skipDefaultTag option to the DockerTargetOptions interface that
allows users to opt out of the automatic default tag that is prepended
to build targets.
This is useful for multi-platform builds that need to push during build
(e.g., using --platform linux/amd64,linux/arm64 --push), where the
default tag causes build failures because it attempts to push a tag that
was not configured.
- Add skipDefaultTag?: boolean to DockerTargetOptions interface
- Modify buildTargetOptions to conditionally skip default tag when
skipDefaultTag is true
- Inherit skipDefaultTag from parent target in configurations
- Add comprehensive unit tests for skipDefaultTag functionality
- Add e2e test to verify skipDefaultTag works end-to-end
- Maintains backward compatibility (default behavior unchanged when
option not specified)
Fixes#33477
## Current Behavior
Loading local plugins that are relative paths from workspace root, that
point to a JS file, still require preliminary data from default plugins
despite being resolvable. This is because we aren't passing `paths` to
`require.resolve`, so it is trying to resolve relative to the nx package
instead of the workspace.
## Expected Behavior
The straight JS path resolves
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The metrics collector has several inefficiencies and architectural
issues:
- Complex hierarchical data structure (`ProcessTreeMetrics`) that
doesn't align with how the data is consumed
- Separate `MetadataStore` struct with unnecessary indirection
- Full metadata resent to all subscribers on every collection cycle
- Mutable parameters passed through collection functions instead of
functional return values
- Repeated allocations and clones across collection cycles
- `CollectionRunner` tightly coupled to NAPI, making it untestable in
pure Rust
## Expected Behavior
This PR restructures the metrics collector for better performance,
testability, and maintainability:
### Architectural Changes
1. **Flat Process Model**: Replaced hierarchical `ProcessTreeMetrics`
with a flat `Vec<ProcessMetrics>`, simplifying data flow
2. **Group-Based Organization**: Introduced `GroupInfo` and `GroupType`
to logically organize processes:
- `MainCLI` - Nx CLI process and its subprocesses
- `Daemon` - Nx daemon and its children
- `Task` - Individual task execution processes
- `Batch` - Batch execution with multiple tasks
3. **Incremental Metadata Updates**:
- Track which groups and processes have been sent using
`Arc<DashMap<String, GroupInfo>>` and `Arc<DashMap<String,
ProcessMetadata>>`
- Only send new metadata to subscribers instead of full state every
cycle
- New subscribers receive full metadata on first update via
`needs_full_metadata` flag
- Automatic cleanup of dead process/group metadata
4. **Shared State with Arc**:
- Metadata maps shared between `ProcessMetricsCollector` and
`CollectionRunner` using `Arc<DashMap>`
- Eliminated duplicate metadata storage
- Single source of truth for all metadata
5. **Functional Programming Pattern**:
- Collection functions now return `Result<MetricsCollectionResult>`
instead of mutating parameters
- Cleaner error handling with `inspect_err` and `map`
- Easier to reason about data flow
- Removed ~100 lines of code by consolidating logic
6. **Channel-Based Communication**:
- Decoupled `CollectionRunner` from NAPI using `crossbeam_channel`
- Collection thread sends metrics via channel to listener thread
- Listener thread receives metrics and notifies NAPI subscribers
- `CollectionRunner` is now NAPI-free and fully testable in pure Rust
- Non-blocking collection (subscriber callbacks don't block metrics
collection)
### Performance Optimizations
- Pre-allocated `Vec` capacity when combining metrics from different
sources
- Eliminated unnecessary `HashMap` clones during metadata updates
- Single-pass insertion into `DashMap` during string key conversion
- Reduced memory allocations in hot paths
- Collection thread never blocks on JavaScript callbacks
### Code Quality Improvements
- **Testability**: Added 7 pure Rust unit tests for `CollectionRunner`:
- Group creation with different registration types
- Incremental metadata updates
- Dead group cleanup
- All tests pass without requiring NAPI/Node.js runtime
- Clearer separation of concerns between collection and notification
- Better comments explaining incremental update strategy
- More idiomatic Rust patterns throughout
- Updated TypeScript type exports to match new structure
### Threading Model
**Before:**
```
CollectionRunner (mixed collection + NAPI notification)
```
**After:**
```
CollectionRunner (pure Rust, testable)
└─> Channel
└─> Listener Thread
└─> NAPI ThreadsafeFunction
└─> Subscribers
```
## Testing
- ✅ 241 Rust tests passing (including 7 new `CollectionRunner` tests)
- ✅ Native module builds successfully
- ✅ TypeScript types updated and exports verified
## Related Issue(s)
Part of ongoing metrics collector optimization work.
## Current Behavior
The Nx Console install check for the prompt happens in the main process,
adding some overhead to each invocation of nx.
## Expected Behavior
We want this check to happen on the daemon so that it's running in the
background. If it's still running when nx is invoked, we can just skip
the prompt since it's non-critical.
Running it in the background also allows us to pull the latest version
of the logic from npm when executing - that way we can keep the logic
older versions up-to-date even when ppl don't migrate to latest.
## Current Behavior
The Maven plugin is currently at version 0.0.9.
## Expected Behavior
This PR bumps the Maven plugin to version 0.0.10 and creates the
necessary migration for users to automatically update their pom.xml
files.
## Related Issue(s)
N/A - Routine version bump
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
https://www.loom.com/share/560ceccdad45462e9fd3e3f185fc9fa5
Node 24 has stricter readline behavior, and enquirer is not checking for
closed state when invoking operations, resulting in an
ERR_USE_AFTER_CLOSE error when users press Ctrl+C during interactive
prompts.
This commit fixes the issue by adding uncaughtException handler to
ignore ERR_USE_AFTER_CLOSE errors.
When users press Ctrl+C, the process now exits cleanly without showing
an ugly error stack trace.
Fixes NXC-3412
Co-authored-by: Claude <noreply@anthropic.com>
Updates the Nx Powerpack docs and marketing page to make it clear that
Powerpack packages are included with Nx Enterprise, and cannot be
purchased separately, and remove references to the Nx Powerpack trial.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
The recipe for switching to TS project references states "If you
reference a local library project with its own `build` task" which
caused confusion. Users thought only buildable libraries should be
included in devDependencies, leading them to create unnecessary path
aliases for non-buildable libraries.
Closes DOC-149
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Currently, telemetry stats are only recorded when `create-nx-workspace`
completes successfully. This doesn't capture how many times the command
is invoked vs completed.
## Expected Behavior
Record a stat when `create-nx-workspace` is first invoked (before any
prompts), enabling analysis of drop-off between initial invocation and
workspace completion.
## Changes Made
### Telemetry
- Added `recordStat()` call in `normalizeArgsMiddleware()` immediately
after welcome message and before any user prompts
- Records with command name `create-nx-workspace` and metadata
`['start']` to distinguish from completion stat
- Allows correlation of invocation and completion events for drop-off
analysis
### AI Agents Prompt
- This is being temporarily disabled because we noticed a dip in
create-nx-workspace completions that lines up when this was released.
Disabling it temporarily to see if the dip is recovered by disabling the
prompt.
### React Framework Selection
- Added early returns in `determineReactFramework()` for cases where
framework is already provided or interactive mode is disabled
- Improves performance by avoiding unnecessary prompt interactions
### Code Quality
- Reorganized imports in alphabetical order for better maintainability
- Removed unused import (`printSocialInformation`)
## Related Issue(s)
WIP - Draft for discussion
## Current Behavior
When `nx add @nx/s3-cache` fails due to incompatible peer dependencies
or other installation errors, users see only a generic error message
without the actual error details from the package manager.
## Expected Behavior
The command should display complete error messages from the package
manager (both stdout and stderr), including peer dependency conflicts
and other important diagnostic information.
## Changes
Fixed the exec callback in the `installPackage` function to:
1. Capture the `stderr` parameter (was previously ignored)
2. Log both stdout and stderr with a newline separator for clarity
3. Ensure users see all error information from package managers
## Why It Matters
Package managers write installation errors and peer dependency warnings
to stderr. By ignoring stderr, users had no visibility into what
actually failed, making it difficult to diagnose and fix issues.
Fixes issue with `nx add` not showing proper error messages.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `remove-redundant-ts-project-references` migration fails with an
error when run on workspaces that don't have a root `tsconfig.json`
file, such as nx-examples.
## Expected Behavior
The migration should skip workspaces that are not using TypeScript
solution setup instead of throwing an error.
## Related Issue(s)
Fixes the issue encountered when running the migration on
nrwl/nx-examples repo.
## Changes
- Added check to skip migration if workspace is not using TS solution
setup
- Updated test setup to properly configure TS solution for existing
tests
- Added new test cases to verify skip behavior
The migration now uses `isUsingTsSolutionSetup()` to detect if:
- `tsconfig.base.json` exists
- `tsconfig.json` exists and extends the base
- Package manager workspaces are configured
- Proper TS solution structure is in place
Workspaces missing any of these requirements will have the migration
skip silently.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The migration for removing redundant TypeScript project references is
set to version `22.1.0-beta.8`.
## Expected Behavior
The migration should be updated to version `22.1.0-rc.1` to align with
the release candidate version.
## Related Issue(s)
N/A - Version update as requested.
## Current Behavior
The `@nx/js:typescript-sync` generator adds project dependencies as
TypeScript project references to each project's `tsconfig.json` and
runtime tsconfig file (e.g., `tsconfig.app.json`, `tsconfig.lib.json`,
etc.). This is redundant since projects' `tsconfig.json` files already
reference the runtime tsconfig file, which would reference the
dependencies.
## Expected Behavior
The `@nx/js:typescript-sync` generator should add project dependencies
as TypeScript project references to each project's runtime tsconfig file
(e.g., `tsconfig.app.json`, `tsconfig.lib.json`, etc.). If the project
only has a `tsconfig.json` file, it should add them to it.
We've observed some performance improvement with this change while
running the `typecheck` tasks.
## Summary
This PR combines two critical performance optimizations for batch task
scheduling and task hashing:
### 1. Batch Scheduling Fix
Fixed a correctness bug in the batch scheduling optimization where the
`visitedInBatch` tracking happened too early. Now tasks are only marked
as visited AFTER all scheduling checks pass, ensuring tasks can be added
to the batch from any valid dependency path.
**Files Modified:**
- `packages/nx/src/tasks-runner/tasks-schedule.ts`
**Impact:**
- Prevents task splitting across unnecessary batch boundaries
- Maintains correctness while optimizing performance
- All batch scheduling tests pass
### 2. Task Output Hashing Optimization
Added a DashMap-based cache to the Rust TaskHasher to prevent redundant
hashing when multiple tasks depend on the same outputs.
**Files Modified:**
- `packages/nx/src/native/tasks/task_hasher.rs` - Added
task_output_cache field
- `packages/nx/src/native/tasks/hashers/hash_task_output.rs` - Implement
cache logic
## Root Cause of Issue #33366
Large project graphs with high dependency fanout exhibit slow
`hashMultipleTasks` because:
- 100+ tasks may depend on the same 10 build tasks' outputs
- This generates 1,000+ separate `TaskOutput` hash instructions
- Each instruction independently:
- Lists output files from disk (filesystem I/O)
- Builds glob patterns
- Hashes the same files
- Result: Same files hashed 100× redundantly
## Solution: Task Output Cache
The cache key combines glob pattern and sorted output paths. When
identical outputs are hashed with the same pattern:
- First task: computes hash (~milliseconds) and stores in cache
- Remaining 99 tasks: cache hits (~nanoseconds each)
### Cache Lifetime
- `TaskHasher` instantiated once per `hashMultipleTasks` call
- Cache persists for entire hashing session
- Discarded when `hashMultipleTasks` completes
- Optimal scope for cache hit maximization
## Performance Impact
**Expected Improvements:**
- Best case (100 tasks, 10 shared deps): 100× speedup
- Typical monorepo: 10-20× speedup
- No shared deps: No regression (cache lookup negligible)
**Issue #33366 Analysis:**
- Current: `Time for 'hashMultipleTasks' 49351.488518` (49 seconds)
- Expected with optimization: ~5-10 seconds (depending on actual
dependency structure)
## Testing
- ✅ All task scheduling tests pass (2262 passed, 0 new failures)
- ✅ Batch mode tests pass (6/6)
- ✅ Native build completed successfully
- ✅ No regressions in existing functionality
## Design Notes
- Task output cache follows same pattern as `workspace_files_cache`,
`external_cache`, `runtime_cache`
- Thread-safe using DashMap with Arc for Rayon parallel processing
- Instrumented with trace-level logging for cache hits/misses
- Cache automatically cleaned up when TaskHasher is dropped
Updates the `ng-packagr` executors to support a breaking change in v21.
This needs to be done in advance because we use the published
`@nx/angular` executors to build the `@nx/angular` source code. To
update to Angular v21, we need this change to be merged, released, and
installed in the Nx repository so that we can build the `@nx/angular`
package containing the support for Angular v21.
Users cannot import TypeScript schema definitions or schema.json files
from Nx packages due to strict package exports introduced in Nx 21.0.0.
Users can now import both TypeScript definitions and JSON schemas from
generator/executor/builder paths using wildcard export patterns. Both
first-level (`*`) and second-level (`*/*`) patterns are supported to
handle different import depths.
Note: For old plugins that had `src/...` deep imports we keep those in
`exports`, but for newer plugins that always used `exports` we skip
`src/` in the export path. So `@nx/nuxt/generators` instead of
`@nx/nuxt/src/generators`.
Fixes#33336
## Current Behavior
nx init is executed with whatever version is installed globally by npm
(might be outdated)
## Expected Behavior
we pull down the latest version from npm (if it has provenance) and run
that when executing.
Also introduced a new `NX_USE_LOCAL` env var that will be respected by
all commands that have this pulling-from-latest behaviour.
Update CI to Node 24. Note that the e2e-release changes are pulled from
the original PR.
Note: There are changes to NPM 11 (Node 24) to make it run slower than
NPM 10 (Node 20/22) for publish. (https://github.com/nrwl/nx/pull/31934)
e.g. https://github.com/npm/cli/releases/tag/v11.0.0-pre.1 (`Upon
publishing, in order to apply a default "latest" dist tag, the command
now retrieves all prior versions of the package.` which incurs more
network cost)
## Current Behavior
The typecheck target in graph/client/project.json only depends on
^typecheck targets from other projects.
## Expected Behavior
The typecheck target now includes nx:build-native as a dependency to
ensure native dependencies are built before type checking.
## Related Issue(s)
This fix resolves typecheck failures caused by missing native
dependencies.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
## Current Behavior
there is no way to generally influence how maven goals/phases are
represented as targets in nx. This could be useful though for organizing
targets in nx, for example through nx.json `targetDefaults`
## Expected Behavior
There's a `targetNamePrefix` plugin option that can be passed.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
After PR #33256 split lockfile parsing into separate node and dependency
caches, a regression occurred where dependencies could be regenerated
without nodes, leaving a shared module-level variable (`keyMap`) empty
and causing incorrect dependency resolution.
Changes:
- Serialize `keyMap` with nodes cache to maintain state between phases
- Remove module-level shared state from pnpm, npm, and yarn parsers
- Move `keyMap` creation inside `getNodes` functions for better
encapsulation
- Update `readCachedExternalNodes` to deserialize `keyMap` internally
Update from the macos-13 is in brownout and will be gone soon.
- macos-15-intel for x86_64-apple-darwin (Intel) builds
- macos-latest for aarch64-apple-darwin (ARM64) builds
Closes NXC-3444
## Current Behavior
We currently only generate vitest projects using Vitest 3
## Expected Behavior
Use Vitest 4 when generating new projects
## Related Issue(s)
Closes NXC-3343
Closes NXC-3379
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Clarifies some details of the Nx Cloud GitHub integration, such as which
features are available when you use the base integration vs a GitHub
powered organization.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
We do not render the commit title in the BC section of generated
changelogs.
## Expected Behavior
We should render the commit title in the BC section of generated
changelogs along with the Remote Release Client reference to the commit.
## Related Issue(s)
Closes NXC-3290
## Current Behavior
There may be a scenario when `cleanedAngularVersion` is of type `object`
rather than `string` which proceeds to error when passed to
`semver.major()`.
## Expected Behavior
If `cleanedAngularVersion` is not `string`, assume the latest version
will be installed. Similar to how no found angular version is handled.
## Related Issue(s)
Fixes#33347
- Fix for a bug with the external project references cache
- Add more caching for repeated operations
- Skip tsconfig files processing based on which targets should be
inferred
Fixes#33076
## Current Behavior
The library generator has an unused import and incorrect import pattern
for the vitest generator.
## Expected Behavior
Clean imports with the correct way to access the configurationGenerator
from @nx/vitest.
## Changes
- Removed unused imports (logger, readJson)
- Updated vitest generator import to use direct require instead of
ensurePackage pattern for accessing the generator
Fixes #
## Current Behavior
The Storybook 10 migration was originally intended to be optional.
## Expected Behavior
Make Storybook 10 migration add the migration generator to
migrations.json always. Users can remove it from here if they do not
want it, or they can use the Migrate UI from Nx Console to choose not to
run it.
Split entry point of `@nx/vitest` into `index.ts` for the Inference
Plugin, `generators.ts` for Generators, `executors.ts` for the
Executors.
Ensure the `README.md` is copied to the correct output directory
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
Split `vitest` out of `@nx/vite` and create a new `@nx/vitest`.
This allows for each plugin to have a single responsibility. One for
bundling, one for testing.
It should allow for lighter setups where Vite for Bundling is not
required, but users still want to use vitest for testing.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Storybook was accidentally downgraded to 9.1.9
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Storybook is upgraded back to 10.0
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cypress v15 is not supported.
## Expected Behavior
Cypress v15 should be supported.
## Related Issue(s)
Fixes#33304
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: leosvelperez <leosvelperez@users.noreply.github.com>
CI and nightlies can flake out during expo test if cypress or playwright
times out waiting for webserver. This makes is to the `export` that
powers `static-serve` is run before running e2e.
This is not usually a problem in new workspaces with inference, but this
legacy test uses executors so continuous task dependency isn't set up.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Nx plugin for Gradle is at version 0.1.8
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx plugin for Gradle is at version 0.1.9
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Track relevant CPU and memory system metrics.
- Link plugins to workers when possible.
- Refactor collector code by splitting it into two separate structs.
## Current Behavior
Maven plugin is currently at version 0.0.8.
## Expected Behavior
Maven plugin should be bumped to version 0.0.9 with a corresponding
migration for users.
## Changes Made
- Updated parent POM version to 0.0.9
- Updated package.json version to 0.0.9
- Updated mavenPluginVersion constant to 0.0.9
- Added new migration (0-0-9) to update user pom.xml files from 0.0.8 to
0.0.9
- Scheduled migration for Nx v22.1.0-beta.6
## Testing
- ✅ Maven package tests pass
- ✅ Build succeeds
- ✅ Linting passes
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Because `./nx` is passing args with `$@`, args are being split by
spaces. Reference for this behaviour:
https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html#Special-Parameters-1
This results in this set of process args when running `./nx start-ci-run
--distribute-on="3 linux-medium-jvm"`
```
[
"<user path>/.nvm/versions/node/v22.19.0/bin/node",
"<user path>/Projects/OTW/mm-test/.nx/nxw.js",
"start-ci-run",
"--distribute-on=3",
"linux-medium-jvm",
]
```
## Expected Behavior
the arg with whitespace should not be split before being passed to nx:
```
[
"<user path>/.nvm/versions/node/v22.19.0/bin/node",
"<user path>/.nx/nxw.js",
"start-ci-run",
"--distribute-on=3 linux-medium-jvm",
]
```
This PR is just for the repo itself to use `.cts` to explicitly use CJS
for jest config. Node 24 strip types so having `.ts` files with ESM
syntax even though we're previously transpiling them to CJS is a
problem.
Make run-one task terminal outputs in the TUI non-interactive by
default. Most tasks don't need interactivity, and it causes TUI to
ignore all its key bindings because it forwards them to the underlying
program. If interactivity is needed, users can press `i` to enable it.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently we detect if inputs are found in the build directory to
determine if they are considered dependent task output files. We can use
a simpler heuristic instead.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If an input is gitignored (and therefore not hashed by Nx), then we
consider it a dependant task output file. This gitignore classifier will
be a mirror of the class used within the Maven plugin. There will be
another PR to move this classifier into a shared kotlin project that can
be used between both projects.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Maven target dependencies are defined as simple strings that reference
other targets. Currently, parameters are not forwarded through these
dependencies when Maven goals are executed.
## Expected Behavior
Target dependencies in Maven should forward parameters (args) to their
dependency targets, enabling better parameter propagation through the
build pipeline.
## Changes Made
Modified `NxTargetFactory.kt` to transform simple string dependency
references into structured dependency objects with explicit parameter
forwarding:
- Install dependencies now forward parameters
- Phase dependencies now forward parameters
- Test dependencies now forward parameters
- CI target dependencies now forward parameters
This ensures that when a Maven goal executes, any parameters passed to
it are properly forwarded to all transitive target dependencies.
## Related Issue(s)
This change enables parameter passing through Maven target dependencies
via the new dependency object format with `"params": "forward"`.
When using Jest 30 with SWC, users are seeing an error where `__dirname`
is not defined for ESM modules. This is because the `.ts` extension is
type-stripped by Node 22.17/24+ via checking for
[`process.features.typescript`](https://github.com/jestjs/jest/blob/fe7f28c9d1941f5c2726831cd9d9e479b401610e/packages/jest-config/src/readConfigFileAndSetRootDir.ts#L46).
This means that instead of using the `commonjs` we set for `ts-node`,
normal Node resolution kicks in, and is now treating `jest.config.ts` as
ESM.
This PR fixes this issue by using an explicit `.cts` extension, which
forces CommonJS that we assume for Jest configs.
Note: For Jest 29 or earlier we need to keep `jest.config.ts` since the
`.cts` extension is not supported prior to Jest 30.
There's also a fix for an existing issue where using `module.exports` of
anything else from `@types/node` will error out if `tsconfig.json` has a
`types` field but does not include `node`. See:
https://www.loom.com/share/7ebe3c90a70e4ec7bfa53cbcccaaea7dFixes#32236
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
`@nx/vite` has a peerDep range of only `1 | 2 | 3` for `vitest`.
This will cause peer dep conflicts for using wishing to use Vitest 4.
## Expected Behavior
Add Vitest 4 to the peerDep range of `@nx/vite` to prevent conflicts.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
when trying to format with prettier while outside of the workspace (for
example in a `tmp` nx installation like is created during
`configure-ai-agents`), resolving prettier could fail even though it's
present in the actual workspace.
## Expected Behavior
resolving prettier works if it's available in either the proper
workspace or the tmp one by specifying `paths` in `require.resolve`
## Current Behavior
We currently support Next 14 and 15.
## Expected Behavior
Add support for Next 16, bringing support to 14, 15, 16.
Existing workspaces will continue to use the version they are on.
New workspaces will use Next 16.
Refer to Next 16 Migration Guide for migrating from Next 15 to 16
## Related Issue(s)
Fixes#33207
---------
Co-authored-by: Eric Büttner <eric.buettner@tuffz.com>
This pull request makes a minor update to the CI workflow configuration.
The change simplifies the `Start CI Run` step by removing the
`--fix-tasks="!*check-commit*"` option from the `npx nx-cloud@next
start-ci-run` command.
Updates @module-federation packages from 0.18.0 to 0.21.2 and
@module-federation/node from 2.7.11 to 2.7.21 to address Koa Open
Redirect vulnerability (CVE: GHSA-g8mr-fgfg-5qpc).
The vulnerability was in transitive dependencies:
@nx/react → @nx/module-federation → @module-federation/enhanced →
@module-federation/dts-plugin → koa@3.0.1-3.0.2
Changes:
- Updated package.json dependencies in @nx/module-federation and
@nx/rspack
- Updated version constants in Angular and React utils/versions.ts
- Added 22.2.0 migrations to all affected packages
Fixes#33285
This PR clarifies that Nx 22 removed SVGR support from Next.js and React
(Webpack/Rspack).
<img width="942" height="1185" alt="image"
src="https://github.com/user-attachments/assets/6ea8393f-b037-489f-804b-eb06d8d07e4c"
/>
Previously we had this option `svgr: true` but was configurable and
didn't align with current best practices like `import Logo from
'./logo.svg?react'`. We removed it from Nx 22, provided a migration, but
users will be confused by the docs.
Fixes DOC-326
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`createVitest` is looking at the full workspace every time. It should
only look at the directory with the config file.
## Expected Behavior
Pass the root as the projectRoot of the config file found.
## Current Behavior
The Nx TUI doesn't provide any visual feedback about task progress
outside of the terminal window itself. Users need to keep the terminal
visible to see task completion status.
## Expected Behavior
With this PR, the TUI now displays real-time task completion progress in
the terminal window chrome (tabs, title bars, dock icons) using the OSC
9;4 escape sequence. This provides at-a-glance progress feedback even
when the terminal is minimized or in the background.
## Related Issue(s)
N/A - This is a new feature enhancement
## Implementation Details
### What is OSC 9;4?
OSC 9;4 is a terminal escape sequence for displaying progress
indicators, originally from ConEmu and now supported by multiple modern
terminals.
### Key Changes
- Added `update_ghostty_progress()` method to calculate and display task
completion percentage
- Added `clear_ghostty_progress()` method to hide progress when done
- Integrated progress updates into task lifecycle (start, status update,
exit)
- Uses ST terminator (`\x1b\\`) for maximum terminal compatibility
- Writes to stderr to avoid conflicts with TUI rendering on stdout
### Supported Terminals
- **Ghostty** - Full support
- **Windows Terminal** (v1.6+) - Full support
- **VTE-based terminals** (GNOME Terminal, Ptyxis) - Full support
- **Other terminals** - Gracefully ignore sequences (no errors)
### Terminal Compatibility Note
The implementation uses the ST (String Terminator) escape sequence
rather than BEL, as this is preferred by Ghostty and required by
VTE-based terminals, while remaining compatible with Windows Terminal.
## Testing
Tested with:
- Building the native module successfully
- Rust formatting and linting passes
- Running nx commands with the TUI active
The progress indicator updates in real-time as tasks complete and clears
automatically when the TUI exits.
## Current Behavior
When processing scheduled batches, tasks are hashed one at a time even
though the hasher has a `hashTasks` method for batch hashing.
Results from a batch with 109 tasks.
```
hash batch: 8.297s
```
## Expected Behavior
Tasks without custom hashers should be batch-hashed using the hasher's
`hashTasks` method for better performance.
Results from a batch with 109 tasks.
```
hash batch: 991.725ms
```
## Related Issue(s)
This is a performance optimization for task hashing.
---
**Changes:**
- Added a new `hashTasks` function that intelligently separates tasks
with custom hashers from those without
- Tasks with custom hashers are hashed individually using `Promise.all`
- Tasks without custom hashers are batch-hashed using the hasher's
`hashTasks` method
- The function automatically filters out tasks that already have a hash
- Updated `processScheduledBatch` in task-orchestrator to use this new
function
## Current Behavior
Vitest's `createVitest` can be over-eager and include other projects in
the workspace when finding relevant test specifications.
This leads atomizer to look at relative paths outside the project root.
## Expected Behavior
Ensure that the plugin does not look at projects outside the project
root.
## Current Behavior
The Maven migration version was incorrectly set to `0.0.8-beta.0` in the
migrations.json file.
## Expected Behavior
The migration version should be set to `22.1.0-beta.4` to align with the
Nx release version.
## Related Issue(s)
Fixes the migration version discrepancy in the Maven plugin.
Embeds videos about self-healing CI into the corresponding feature doc
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
The Maven plugin is at version 0.0.7 with no automated migration path
for users to upgrade their pom.xml files.
## Expected Behavior
Users can upgrade to Maven plugin 0.0.8 and have their pom.xml files
automatically updated via the Nx migration system.
## Changes Made
- Updated Maven plugin version from 0.0.7 to 0.0.8 in:
- `packages/maven/package.json`
- `packages/maven/src/utils/versions.ts`
- `packages/maven/maven-plugin/pom.xml`
- Created `updateNxMavenPluginVersion()` utility function with:
- Proper XML parsing using `@xmldom/xmldom` DOM API
- Targeted updates only for `dev.nx.maven:nx-maven-plugin` elements
- Safe handling of all other version elements (dependencies, parent,
project, etc.)
- Comprehensive error handling
- Added migration `0-0-8/update-pom-xml-version.ts` that:
- Automatically runs when users upgrade to 0.0.8
- Updates root pom.xml files via the utility function
- Logs status of migrations performed
- Registered migration in `migrations.json`
- Added comprehensive unit tests (9 test cases):
- Updates only the nx-maven-plugin version
- Does not update other plugin versions
- Handles missing files gracefully
- Preserves XML formatting and structure
- Handles multiple plugin references
- Handles whitespace correctly
- Only updates plugins, not parent/project versions
- All tests passing (27/27)
## Test Plan
- [x] Unit tests pass (27 passing tests)
- [x] XML parsing correctly identifies and updates only
`dev.nx.maven:nx-maven-plugin`
- [x] Other version elements remain untouched
- [x] Migration registration validated
## Current Behavior:
Tui is working, but only able to be enabled on windows via env vars or
explicit command line config
## Expected Behavior:
Tui is default on
## Current Behavior
Maven and .NET use a bespoke script to handle skipping an optional
native target in case a system is not setup on a dev's machine.
.NET isn't in codeowners
## Expected Behavior
This pull request introduces improvements to the build and formatting
workflows for the `.NET` and Maven plugins, streamlining the execution
of native targets and updating code ownership assignments. The changes
focus on refactoring build scripts to use a unified runner, adding new
formatting capabilities for .NET projects, and updating the CODEOWNERS
file for clearer team responsibilities.
**Build and Format Workflow Improvements**
* Refactored the `.NET` analyzer build command in
`packages/dotnet/project.json` to use the new `run-native-target.js`
script, replacing the previous direct script invocation.
[[1]](diffhunk://#diff-036c1a7f2e7d98f5a3207441f2ff1cb25b5b5a03343672ce473f4ff0189a5946L25-R25)
[[2]](diffhunk://#diff-42d990ddcbf8d3585553503097ee8b8d1fff8cb6e25e0cd545a87e11d64c03a8L1-L7)
* Added new `format-native` and `_format-native` targets to
`packages/dotnet/project.json`, enabling verification and fixing of code
formatting for the .NET analyzer using `dotnet format`.
**Unified Native Target Runner**
* Introduced the `scripts/run-native-target.js` script to standardize
running native build and install targets, controlled by environment
variables for skipping builds.
**Maven Plugin Build Refactor**
* Updated the Maven plugin's install workflow in
`packages/maven/maven-plugin/project.json` to use the new native target
runner, and removed the obsolete `scripts/build-maven-analyzer.js`
script.
[[1]](diffhunk://#diff-2763fe8a7c2989643f53370a14a08c06616e85c29340fd5bcfa1a67d0deaee7aL11-R11)
[[2]](diffhunk://#diff-972edab06956ad35145cbc20b8e250e7067fbb288b1f99c92661c24f64d3e69dL1-L7)
**Ownership Updates**
* Updated the `CODEOWNERS` file to assign `.NET`-related directories to
`@FrozenPandaz` and `@AgentEnder`, clarifying team responsibilities.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We support Storybook 8 and 9
## Expected Behavior
Add support for Storybook 10, bringing Storybook support to 8, 9 and 10
## Related Issue(s)
Fixes#33141
## Current Behavior
Maven dependencies were not being resolved correctly from project roots,
which affected the dependency analysis in monorepos with Maven projects.
## Expected Behavior
Maven dependencies should be properly resolved from each project's root,
allowing Nx to correctly understand the project graph for Maven-based
projects.
## Changes Made
- Updated Maven plugin Kotlin code to properly resolve dependencies from
project roots
- Fixed devkit internal utilities to properly handle Maven dependency
resolution
- Updated TypeScript dependencies plugin to align with the new
resolution logic
## Files Changed
-
`packages/maven/maven-plugin/src/main/kotlin/dev/nx/maven/NxProjectAnalyzer.kt`
-
`packages/maven/maven-plugin/src/main/kotlin/dev/nx/maven/NxProjectAnalyzerMojo.kt`
- `packages/maven/src/plugins/dependencies.ts`
- `packages/dotnet/src/plugins/create-dependencies.ts`
- `packages/devkit/internal.ts`
- `packages/nx/src/devkit-internals.ts`
Fixes #XXXXX
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
CodeQL is not enabled for C#, but C# is in the nx repo
## Expected Behavior
CodeQL is enabled on C#
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR primes the cache for `@vitejs/plugin-vue`, similar to how we
already do for `esbuild`. When `vite.config.ts` is compiled into CJS,
then doing `require('@vitejs/plugin-vue')` may error with a race
condition if an `import` of the same module is in progress.
Fixes #NXC-3289
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
there are recommendations for using the CIPE fixing tools but they are
being removed
## Expected Behavior
removed tools should not be mentioned anymore.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Completed Maven documentation updates:
- [x] Add `nx show projects` command to display Maven projects after
initialization
- [x] Change example from `nx build` to `nx verify`
- [x] Simplify configuration section to use `plugins: ["@nx/maven"]`
with defaults
- [x] Update configuration description to accurately explain how targets
are created
## Summary
Successfully updated the Maven plugin documentation:
1. **Added `nx show projects` command** - Shows users how to list
discovered Maven projects after running `nx init`
2. **Changed example to `nx verify`** - Uses a more appropriate Maven
lifecycle phase that includes tests and verification
3. **Simplified configuration** - Updated the configuration section to
show the simpler string array syntax `plugins: ["@nx/maven"]`
4. **Corrected target creation description** - Updated the text to
accurately explain that `@nx/maven` automatically retrieves information
about projects from Maven and creates targets for each phase, goal, and
some additional targets for CI
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Expand this section
https://nx.dev/docs/technologies/java/maven/introduction#add-nx-to-a-maven-workspace
>
> With instructions to run the following
>
> nx show projects
>
> To see a list of Maven projects
>
> And change nx build Maven project to nx verify Maven project
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: FrozenPandaz <8104246+FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
devcontainer wasn't working reliably
## Expected Behavior
devcontainer should work reliably and reuse the configuration setup we
have for all these different tools that are needed
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
in a `.nx` installation, `require.resolve` won't find the `extends`
preset nx.json file because there are no root `node_modules`
## Expected Behavior
in a `.nx` installation, the nested `.nx/installation/node_modules` are
also used to try and resolve the preset.
This PR builds on the previous fix that ensured `eslint-config-next` was
correctly installed when using Next.js 15. #30258
Now, the logic has been further refined to dynamically determine the
installed Next.js version and install the corresponding
`eslint-config-next` version accordingly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
### Current Behavior
- `next@~15.1.4` is installed
- `eslint-config-next@14.2.16` is installed (incorrect for Next.js 15)
### Expected Behavior
If Next.js 15 is detected -> eslint-config-next@15.1.4 is installed
If Next.js 14 is detected -> eslint-config-next@14.2.16 is installed
### GitHub Repo
https://github.com/tuffz/new-nx-with-preset-nextjs
### Steps to Reproduce
1. Run the following command from the official documentation:
`npx create-nx-workspace@latest --preset=next`
3. Open `package.json` and check the installed dependencies
- `next@~15.1.4` is installed
- `eslint-config-next@14.2.16` is installed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30257 (& #30258)
guides couldn't be merged into one page w/ tabs and keep consistent
headers. so we're back to splitting them out. but all under a
source-control-integration parent route. so we don't need to do any
redirects and such as the index route will contain the links to each one
Removed duplicate information about installing Nx globally.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Duplicate line.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Removed duplicate line.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
the implementation is brittle and will fail if `contextFileName` is not
a string
## Expected Behavior
we should just not handle other things that folks are putting in there.
but not fail
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Dogfoods the Pnpm Catalogs feature in the Nx repo. This is the first
step to move all dependencies to Pnpm Catalogs definitions. More work
will be done incrementally later as we consolidate package versions
across the repository.
The initial list of dependencies moved to Pnpm Catalogs is:
- Angular packages
- React packages
- TypeScript packages
- Jest packages
- Rspack packages
- Some common utilities
## Current Behavior
We have tried to enable v8 serialization again... but it still seems
problematic. We don't want to revert again... so we evaluated some
options:
1. Disable by default
2. Disable for the single client method we think may be problematic
3. Fall back to JSON if v8 fails
4. Disable by default and still fall back if JSON fails
## Expected Behavior
We decided to update Nx such that the default behavior will be a
combination of #4, and #2. So by default we use JSON, if that
serialization fails we'll try v8... but there's an exception so the
method we know to be an issue will never try v8.
If you opt in to v8 by default, the combo changes to #3 + #2. So, by
default we'd use v8... if it fails try json... never try v8 for
processInBackground
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Docker plugin assumed `commitSha` was always non-null; when `null`,
`shortCommitSha.slice` caused a runtime error during target
interpolation.
## Expected Behavior
Plugin should succeed even if latest commit SHA cannot be resolved,
simply omitting shortCommitSha-based substitutions.
## Changes
- Added null guard: `shortCommitSha` now set to `commitSha ?
commitSha.slice(0,7) : null`.
- Added test "should not throw when commitSha is null" verifying node /
target creation succeeds.
- No breaking changes; only broadens safe input surface.
## Additional notes
Logic only executes when `commitSha` was previously null (error case);
normal paths unchanged. If consumers interpolate `{shortCommitSha}`,
they should handle possible null (unchanged if interpolation is already
optional).
This PR removes the need to check links during deploy and instead
enforces it in CI. This removes the need to build astro-docs when
building next.js app.
Reduces Vercel build from 10-11 mins to 6.5 mins.
<img width="1231" height="94" alt="image"
src="https://github.com/user-attachments/assets/ad5d4459-f917-4609-8c00-151f61dc29d6"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Update release notes entry tor 2025.07.3 - short link support for DTE
summary
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
You can see the issue here:
https://staging.nx.app/cipes/68fba96042d3126ee8ec0d19/analysis?runGroup=18785923031-1-linux
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes BAC-1387
This PR wraps one of the exports of `@nx/webpack` within a dynamic
function that ultimately requires `tsquery`. This causes an issue in
yarn v1 where `typescript` cannot be resolved thus causing an error when
`@nx/webpack` is imported.
The errors happens on every new workspace that starts from empty:
```
npx create-nx-workspace --preset=ts --pm=yarn
nx add @nx/web
nx g @nx/web:app apps/demo --bundler=webpack
```
Results in:
```
NX Cannot find module 'typescript'
Require stack:
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@phenomnomnominal/tsquery/dist/src/ast.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@phenomnomnominal/tsquery/dist/src/index.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/src/generators/convert-config-to-webpack-plugin/lib/extract-webpack-options.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/src/generators/convert-config-to-webpack-plugin/convert-config-to-webpack-plugin.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/index.js
- /private/tmp/web4/node_modules/@nx/devkit/src/utils/package-json.js
- /private/tmp/web4/node_modules/@nx/devkit/src/generators/to-js.js
- /private/tmp/web4/node_modules/@nx/devkit/public-api.js
- /private/tmp/web4/node_modules/@nx/devkit/index.js
- /private/tmp/web4/node_modules/@nx/web/src/generators/application/application.js
- /private/tmp/web4/node_modules/nx/src/config/schema-utils.js
- /private/tmp/web4/node_modules/nx/src/command-line/run/executor-utils.js
- /private/tmp/web4/node_modules/nx/src/project-graph/utils/project-configuration-utils.js
- /private/tmp/web4/node_modules/nx/src/utils/package-json.js
- /private/tmp/web4/node_modules/nx/bin/nx.js
Pass --verbose to see the stacktrace.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
Note: Other generators like React/Vue are fine since they have
dependency on tsquery, which installs typescript.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Summary
This PR includes three performance and correctness improvements:
1. **Split lockfile cache into separate node and dependency caches** -
Previously, both createNodes and createDependencies would read/write the
entire cache. Now each manages its own cache independently:
- `parsed-lock-file.nodes.json` for external nodes
- `parsed-lock-file.dependencies.json` for dependencies
2. **Prevent duplicate plugin resolution calls with promise cache** -
Added a promise cache to prevent concurrent duplicate calls to
`retrieveProjectConfigurationsWithoutPluginInference` when multiple
plugins fail to resolve simultaneously
3. **Normalize targets in separate loop after validation** - Moved
target normalization out of the validation loop to ensure proper
sequencing
## Test plan
- [ ] Tests pass (currently failing in CI - needs investigation)
- [ ] Build succeeds
- [ ] Lint passes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
When stringifying a pnpm v9 lockfile with workspace packages, Nx crashes
with: "Cannot destructure property 'specifiers' of 'projectSnapshot' as
it is undefined."
This occurs when:
- The lockfile has a root importer with `link:` references to workspace
packages
- But the lockfile is missing the workspace package importer entries
- The code tries to access `importers[importerPath]` which returns
undefined
- This undefined value gets added to the output lockfile
- During serialization, it crashes when trying to destructure undefined
Workspace packages with missing importers are now silently skipped
during lockfile serialization. This prevents the crash and allows Nx to
continue operating with out-of-sync lockfiles.
The fix adds a null check before adding workspace dependency importers
to the output lockfile.
Closes NXC-3244
This reverts commit 54db861b72.
## Current Behavior
Daemon messaging is all done over JSON messages
## Expected Behavior
Daemon messages use v8 serialization to avoid string length issues
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
With the Accept header in place during the retrieval of cache, the
client always expects an octet-stream from the server.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When the `Accept` header is missing, you might not get the correct data
depending on the underlying implementation of a self hosted cache
solution. We use AWS API Gateway which has a hard requirement for
`Accept` to determine how it should convert the data.
Fixes#33092
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We search for the gradle wrapper of a project by first looking at the
project root, then traversing upwards to the workspace root. If a
workspace has a separate gradle project defined that does not contain a
wrapper, then Nx will error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add a field to the gradle plugin that will allow users to specify a
custom gradle installation within their workspace. Nx will check for a
gradle wrapper that the specified location when executing gradle tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3147
## Current Behavior
When the Nx daemon returns a cached project graph from memory (without
recomputing), it does not write the graph to disk. This creates a
cache/daemon mismatch scenario:
1. Daemon has valid project graph in memory
2. A non-daemon process (fallback when daemon fails) encounters errors
and writes cache to disk with those errors
3. Parent process gets clean graph from daemon
4. Forked executor processes read from disk cache which contains errors
5. The errors cause `readProjectGraphCache()` to return `null` (when no
`minimumComputedAt` is provided)
6. This triggers a misleading "No cached ProjectGraph is available"
error instead of surfacing the actual errors
This issue manifests intermittently in CI environments, especially when:
- Daemon connection timeouts occur
- Multiple concurrent processes are running (DTE scenarios)
- File system latency is high
## Expected Behavior
The daemon should always write its current project graph to disk
whenever it returns it, ensuring the disk cache stays synchronized with
the daemon's in-memory cache. This prevents stale or errored caches from
persisting when the daemon has a valid graph.
## Related Issue(s)
Fixes NXC-3030
## Implementation Details
Modified `getCachedSerializedProjectGraphPromise()` in
`packages/nx/src/daemon/server/project-graph-incremental-recomputation.ts`
to write the project graph cache to disk after retrieving the result,
even when reusing the in-memory cached graph.
The fix ensures that:
- Any errored cache written by a non-daemon process gets overwritten by
the daemon's valid graph
- Forked executor processes always read a consistent cache that matches
what the daemon served to the parent process
- Real errors are properly surfaced instead of being hidden by a generic
"no cache available" message
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Local `tsconfig.app.json` is never picked up due to wrong resolved path.
## Expected Behavior
Local `tsconfig.app.json` is picked up and the path aliases are added to
Vite.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33231
Removed "Explain with AI" feature documentation and redirected all URLs
to Self-Healing CI. Added sunset notice to blog posts, updated
configuration files, and preserved historical content for reference.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When `Dockerfile` is at project root, we attempt to append `--tag .`
which is invalid for docker.
## Expected Behavior
Ensure that if `Dockerfile` is at project root, we use `workspaceRoot`
to determine the `--tag`.
Note, this tag is primarily used as a deterministic method for Nx to
find the correct docker image when calling `docker run` and `nx release`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When using `--output-style=stream-without-prefixes` nx incorrectly shows
the TUI instead of streaming
## Expected Behavior
When using `--output-style=stream-without-prefixes`, nx should stream
with no prefixes just like it does with `--output-style=stream`
## Related Issue(s)
Fixes#32535
Co-authored-by: Hugo Burton <hugo.burton@westpac.com.au>
## Current Behavior
`node_modules` are being copied during copy-local-native
## Expected Behavior
`node_modules` are not being copied during `copy-local-native`
## Current Behavior
Maven is installed as a global dependency for all e2e targets
(`e2e-local`, `e2e-ci--**/**`, and `e2e-macos-ci--**/*`), even when only
the Maven e2e tests need it.
## Expected Behavior
Maven should only be installed as a dependency for the Maven e2e tests
that actually use it, avoiding unnecessary installations for other e2e
test projects.
## Changes Made
- Removed `nx-maven-plugin:install` from the global e2e target defaults
in `nx.json`
- Added `nx-maven-plugin:install` as a specific dependency to the Maven
e2e project targets in `e2e/maven/project.json`
This optimization ensures Maven is only installed when needed, reducing
unnecessary build overhead for other e2e tests.
## Current Behavior
`nx init` does not search for `Dockerfile` patterns to suggest adding
the `@nx/docker` plugin.
## Expected Behavior
`nx init` finds and suggests `@nx/docker` plugin
Fixes NXC-3319
Fixes the order of the arguments in invocations to
`resolveCatalogReference` when resolving catalog references from the
filesystem (not using a `Tree`).
## Current Behavior
In some scenarios, when some processes terminate unexpectedly (e.g.
crashed due to OOM), the task runner will incorrectly determine their
exit code to be 0. This results in Nx storing the task results as a
success, which can cause cache hits with false positive successes.
## Expected Behavior
When processes terminate unexpectedly (e.g. crashed due to OOM), the
task runner should correctly determine their exit code from the signal,
and it should never be 0. The stored task result should not be marked as
successful.
## Related Issue(s)
Fixes#29204
## Current Behavior
When `@nx/docker` is registered via string only (`nxJson.plugins:
["@nx/docker"]`, project graph creation fails because we try to access
`options.buildTarget`.
## Expected Behavior
Handle undefined `options` gracefully, and still create the default
target.
## Related Issue(s)
Fixes NXC-3320
## Current Behavior
Dependencies are outdated and Rust tooling needs to be updated.
## Expected Behavior
Rust dependencies are updated to their latest compatible versions.
## Changes
- Updated Rust dependencies
- Rebased with latest `origin/master`
- Updated pnpm lock file
## Related Issue(s)
None
## Current Behavior
No docs describing migration path
## Expected Behavior
Docs describing migration path
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
.NET sometimes bails on a failed mutex in e2e
## Expected Behavior
it runs only 1 at a time
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
It was removed when the scripts were cleaned up during next.js->astro
migration. Adding this back since blog posts need to be synced first
before serving.
## Current Behavior
When project configuration errors occur due to invalid token usage
(e.g., `{workspaceRoot}` in the middle of a path), error messages don't
provide sufficient context about where the error occurred.
## Expected Behavior
Error messages should include:
- For project-level errors: the project and target context (e.g.,
"libs/my-app:build")
- For nx.json targetDefaults errors: the nx.json context (e.g.,
"nx.json[targetDefaults]:test")
This makes it much easier for users to locate and fix the configuration
issue.
## Changes
This PR adds comprehensive integration tests to verify the improved
error messaging:
- Test for project-level invalid token usage showing project:target
context
- Test for nx.json targetDefaults invalid token usage showing nx.json
context
Tests use mock plugins to simulate realistic scenarios where invalid
`{workspaceRoot}` token usage would occur, ensuring the error messages
contain the expected context information.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
by default code blocks will get text as the lang if not set or the lang
is not supported
but we should be so I don't have to look at the warnings in the terminal
output 😅
also remove the frame=none since the team preferred to have the terminal
frame
Example of invalid codeblock messages
Also added conformance rule for validating image pages for public and
src/assets/ directory
examples of incorrect absolute path ref from "public" folder and
incorrect absolute path:
fixes DOC-242
fixes DOC-259
## Current Behavior
Currently, when configuring the `@nx/docker` plugin, we only set the
target name and a basic command.
The intention was that targetDefaults might be able to be used to
configure additional args, but this falls short in some places.
## Expected Behavior
Allow setting additional args when configuring the `@nx/docker` plugin
that supports interpolated values, similar to `versionSchemes`.
This will allow additional flexibility when setting up the docker build
command such as:
```json
{
"plugin": "@nx/docker",
"options": {
"buildTarget": {
"name": "docker:build",
"args": ["-t {projectName}"]
}
}
}
```
This means that we can use `nx run-many -t docker:build` and it will
successfully add the name of the projects into the tag.
This is one example, other examples include being able to set individual
Docker Layer Caching where each registry needs a unique name.
## Current Behavior
The Maven plugin currently checks if a path is absolute by using
`outputFile.startsWith("/")`. This only works on Unix-like systems and
fails on Windows where absolute paths start with a drive letter (e.g.,
`C:\`).
## Expected Behavior
The Maven plugin should correctly identify absolute paths on all
platforms (Windows, macOS, Linux) using the platform-agnostic
`File.isAbsolute()` method.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A - This is a proactive bug fix for cross-platform compatibility.
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When Nx Cloud is used, but the Nx Cloud client is unavailable, an error
is thrown and commands are not run.
## Expected Behavior
When Nx Cloud is used, but the client is unavailable, continue execution
without Nx Cloud.
## Related Issue(s)
Fixes NXC-3175
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Tests either cause agents to run out of memory:
<img width="956" height="358" alt="image"
src="https://github.com/user-attachments/assets/e55bae05-7757-46e7-88ed-158f72411195"
/>
<img width="1278" height="336" alt="image"
src="https://github.com/user-attachments/assets/40dc8dd6-4409-461e-b75a-5c1c36551da5"
/>
Or setup tasks fail due to network flakiness:
https://staging.nx.app/runs/J1qWVZA7K5
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A fully affected, cache busted task graph should run without any
failures.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request updates the documentation for configuring .NET target
types in the `nx.json` file to provide clearer instructions and
examples. The changes make it easier to understand how to customize
target names and configurations for the `@nx/dotnet` plugin.
Improvements to configuration documentation:
* Added a section describing how each target type can be configured,
including renaming targets, customizing options, disabling targets, and
specifying additional properties.
* Updated the example configuration to show how to rename targets (e.g.,
"build" to "compile"), add configurations (e.g., production
optimization), set dependencies between targets, and disable targets
(e.g., disabling "pack").
* Clarified that targets are created with the configuration specified in
the `nx.json` `plugins` array, rather than just with custom names.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The first-class programmatic API of nx release is only documented within
the manage releases introduction and is incomplete (`ReleaseClient` is
not covered at all).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The programmatic API has its own in depth guide, which is then
cross-referenced from the manage releases guide. `ReleaseClient` is now
documented including its new Nx 22 features.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`run`/`watch` are not mentioned in docs
## Expected Behavior
`run`/`watch` docs are accurate
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Maven plugin targets are only created for goals explicitly bound to
executions in the POM. Goals defined in a plugin but not bound to any
execution are not available as Nx targets.
## Expected Behavior
All available Maven goals should be accessible as Nx targets, including:
- Goals bound to executions (existing behavior)
- Unbound goals defined in the plugin (new behavior)
## Changes Made
1. **Added unbound goal support**: The `NxTargetFactory` now creates
targets for goals defined in a plugin but not bound to any execution.
These targets are created with the format `goalPrefix:goalName` without
an execution ID.
2. **Added continuous build tracking**:
- Added `continuous` property to `NxTarget` data class to track whether
a goal supports continuous builds
- Updated `MojoAnalyzer` to detect continuous goals from the cache
configuration
- All targets now properly propagate continuous mode information
3. **Code improvements**:
- Improved formatting and indentation for consistency
- Made `execution` parameter optional in `createSimpleGoalTarget` to
support both bound and unbound goals
- Updated command generation to work with or without execution IDs
## Related Issue(s)
This change enables better Maven goal discovery and execution in Nx
monorepos.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When an invalid output exists we report:
```
NX The following outputs are invalid:
- foo.txt
Run `nx repair` to fix this.
```
Without specifying the reason, we tell to run `nx repair`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
More feedback provided to the user as to the error with their output:
```
NX The following outputs are invalid:
- foo.txt
** Reason: Outputs must start with either "{workspaceRoot}/" or "{projectRoot}/".
Run `nx repair` to fix this.
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes some pages that don't use the proper markdoc syntax for
line lighting in code blocks. The `{% meta %}` tag is needed and it is
missing in some places.
Closes DOC-2790
## Current Behavior
When the daemon is disabled due to an error, the reason isn't captured,
making it harder to debug why the daemon was disabled.
## Expected Behavior
The error message/reason is now stored when marking the daemon as
disabled, allowing better visibility into what caused the daemon to be
disabled.
## Related Issue(s)
Node tool executions (non-watch) were exiting before completing. This
change ensures they complete before exit.
closes#32385
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Node tool executions are not completing since #32356
## Expected Behavior
Node tool executions complete before exit
## Related Issue(s)
#32385Fixes#32385
## Current Behavior
When errors happen in earlier stages of compilation process, such as
processing global styles, these errors are not printed and the rspack
build process hangs at the Sealing phase.
## Expected Behavior
Ensure that errors that have occurred that would cause the process to
hang are printed and process exits correctly.
Part of this happens because the usual printing of errors happens in the
`afterDone` hook, which is never reached when the above occurs.
## Related Issue(s)
Fixes NXC-3268
## Current Behavior
Readme template files are being published to npm with inconsistent
naming conventions.
## Expected Behavior
Readme template files should be excluded from npm publication and
consistently named as `readme-template.md`.
## Changes
- Renamed all readme template files to `readme-template.md` across
angular-rspack-compiler, angular-rspack, dotnet, and maven packages
- Updated .npmignore files to exclude readme-template.md from npm
publication
- Updated package.json build commands to reference the new
readme-template.md paths
- Removed `!README.md__tpl__` exceptions from package.json files array
entries
add new page for the createNodes api compat
add callouts to extending project graph and tooling plugin page
fixes DOC-255
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Fixes the pnpm caching setup for the `main-macos` job. It can currently
fail when the pnpm cache directory doesn't exist. We need to handle the
pnpm cache conditionally and separately from the node setup.
…as testing projects<!-- Please make sure you have read the submission
guidelines before posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
- Microsoft.Testing.Platform projects are not detected as having a test
target
- `serve` does not have an equivalent
## Expected Behavior
- Test projects are properly detected
- `serve` has been split into 2 targets:
- `watch`
- `run`
The split of `serve` mirrors the`dotnet` cli in the same way that we
mirrored `vite` when adding `preview` and `dev` targets when we moved
with project crystal. `watch` can be used for a variety of cases, but
provides hot reload + run a 'la `dev` / `serve`. `run` is more of a fire
and forget target that starts up the app. Both targets would only really
be used in local dev.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…as testing projects
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-21 16:31:55 -04:00
1607 changed files with 49338 additions and 19929 deletions
description: Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
// 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
<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>
@@ -55,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.
@@ -14,7 +14,7 @@ Don't be too anxious about choosing the exact right folder structure from the be
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
```
@@ -22,7 +22,7 @@ nx g move --project booking-some-project shared/some-project
Similarly, if you no longer need a project, you can remove it with the [`@nx/workspace:remove` generator](/docs/reference/workspace/generators#remove).
@@ -51,7 +51,7 @@ Plugins are processed in the order that they appear in the `plugins` array in `n
To view the task settings for projects in your workspace, [show the project details](/docs/features/explore-graph) either from the command line or using Nx Console.
description: 'Explore the enterprise-focused features available in Nx Powerpack, including conformance rules and code ownership management.'
sidebar:
order: 5
pagefind: false
---
Nx PowerPack is a suite of paid extensions for the Nx CLI specifically designed for enterprises. Powerpack is available for Nx version 19.8 and higher.
The following features are available after you [activate a Powerpack license](/docs/enterprise/activate-powerpack):
{% aside title="Looking for self-hosted caching?" type="note" %}
Self-hosted caching has previously been part of Powerpack, but no more. It is now free for everyone to use. [Learn more about our self-hosted caching options.](/docs/guides/tasks--caching/self-hosted-caching)
description: 'Learn about Nx Powerpack free licenses for small teams and open source projects, as well as trial options and extended evaluation periods.'
sidebar:
order: 7
filter: 'type:Features'
---
{% callout type="deepdive" title="Looking for self-hosted caching?" %}
Self-hosted caching is now free for everyone. [Read more about remote caching options here](/docs/guides/tasks--caching/self-hosted-caching).
{% /callout %}
## Free Trial Licenses
You can get a free, 30-day license immediately if you want to try Nx Powerpack. We're here to support you—whether that means extending your trial or helping with the installation. [Learn more about Nx Powerpack trials.](/docs/powerpack/NxPowerpack-Trial-v1.1.pdf)
[Get Your Trial License Immediately](https://cloud.nx.app/powerpack/request/trial?utm_source=nx-docs&utm_medium=referral&utm_campaign=powerpack-trial&utm_content=link&utm_term=free-trial-license)
If you're having trouble, [reach out for help.](mailto:powerpack-support@nrwl.io)
## Extended Trial Periods
Nx Powerpack does not make any requests to external APIs, and activating Powerpack can be completed in just a few minutes. However, we understand that in many large organizations, approval processes can take a long time. We're here to help you. Need a trial extension or help with your business case? [Reach out and we'll help.](mailto:powerpack-support@nrwl.io)
## Powerpack for OSS Projects
We offer free, full-featured Nx Powerpack licenses to open source projects. This happens through Nx Cloud (which is free for OSS projects). Just apply [here](https://nx.dev/pricing#oss) and in the application form, make sure to confirm the Powerpack question.
If you're primarily looking for remote caching, then Nx Cloud is a great fit as it comes with a fully managed remote cache solution (among other CI features), free for OSS projects.
Make sure your application user profile exposes the email address under `user.mail`. This can be configured in `Users and Groups` in the Azure portal. Alternatively, you can always configure the `email` claim to use a different property under the `user` object.
11. Under `SAML Certificates`, click the pencil icon to edit
6. Click “Next”, and select the first option on the next screen.
7. Go to the assignments tab and assign the users that can login to the Nx Cloud WebApp:
1. **Note:** This just gives them permission to use the Nx Cloud web app with their own workspace. Users will still need to be invited manually through the web app to your main workspace.
3. See screenshot below. This is an important step, because Nx Cloud will expect the "email" property on each profile that logs in.
Make sure your application user profile exposes the email address under `user.mail`. This can be configured in `Users and Groups` in the Azure portal. Alternatively, you can always configure the `email` claim to use a different property under the `user` object.
11. Under `SAML Certificates`, click the pencil icon to edit
6. Click “Next”, and select the first option on the next screen.
7. Go to the assignments tab and assign the users that can login to the Nx Cloud WebApp:
1. **Note:** This just gives them permission to use the Nx Cloud web app with their own workspace. Users will still need to be invited manually through the web app to your main workspace.
8. Then in the Sign-On tab scroll down:
9. Scroll down and from the list of certificates, download the one with the "Active" status:
10. Extract the downloaded certificate value as a one-line string:
description: Learn how to obtain and register an Nx Enterprise plan extensions license to unlock enterprise features like conformance rules and code ownership.
sidebar:
order: 4
filter: 'type:Guides'
---
{% aside type="caution" title="Enterprise Plan Required" %}
The enterprise features, including Conformance and Owners, require an Nx Enterprise license.
{% /aside %}
Nx Enterprise plan includes features of Nx that are particularly useful for larger organizations. The features include the ability to:
- [Define code ownership at the project level](/docs/enterprise/owners)
{% callout type="deepdive" title="Looking for self-hosted caching?" %}
Self-hosted caching is now free for everyone. [Read more about remote caching options here](/docs/guides/tasks--caching/self-hosted-caching).
{% /callout %}
Activating your enterprise license is a two-step process.
## Step 1: Get an Activation Key
Talk to your Developer Productivity Engineer to get a license key for your workspaces.
## Step 2: Register the Activation Key
{% tabs %}
{% tabitem label="Closed Source Repository" %}
To register the activation key in your repository, run the `nx register` command.
```shell
nx register YOUR_ACTIVATION_KEY
```
The key will be saved in your repository and should be committed so that every developer has access to the enterprise features. **Only one developer needs to run this. The rest of the team will gain access to Nx Enterprise plan features once they pull the changes including the checked-in file.**
Another option is to use an environment variable in CI.
```ini
// .env
NX_KEY=YOUR_ACTIVATION_KEY
```
**Whether you use the `nx register <your-key>` command or set the environment variable, Nx does not make any requests to external APIs. No data is collected or sent anywhere.**
{% /tabitem %}
{% tabitem label="Open Source Repository" %}
Use an environment variable for your activation key such that it is not committed to the repository.
description: Learn how to obtain and register an Nx Powerpack license to unlock enterprise features like conformance rules and code ownership.
sidebar:
order: 4
filter: 'type:Guides'
---
Nx Powerpack unlocks features of Nx that are particularly useful for larger organizations. Powerpack is available for Nx version 19.8 and higher. The features include the ability to:
- [Define code ownership at the project level](/docs/enterprise/powerpack/owners)
{% callout type="deepdive" title="Looking for self-hosted caching?" %}
Self-hosted caching is now free for everyone. [Read more about remote caching options here](/docs/guides/tasks--caching/self-hosted-caching).
{% /callout %}
Activating Powerpack is a two-step process.
## Step 1: Get an Activation Key
You can [purchase a license](https://cloud.nx.app/powerpack/purchase?utm_source=nx-docs&utm_medium=referral&utm_campaign=powerpack-purchase&utm_content=link&utm_term=purchase-license) online.
If you're an existing Nx Cloud user, you can buy Nx Powerpack on [the Nx Cloud organization settings page](https://cloud.nx.app/go/organization/powerpack). The license will be available automatically.
{% callout type="deepdive" title="Need a trial?" %}
If you are unsure how to proceed, starting with a trial process is recommended, and we will accommodate your organization's needs. You can reach out here to [get a free trial license](https://cloud.nx.app/powerpack/request/trial?utm_source=nx-docs&utm_medium=referral&utm_campaign=powerpack-trial&utm_content=link&utm_term=free-trial-license-for-larger-teams) or read more [about how trials work](/docs/enterprise/powerpack/licenses-and-trials).
{% /callout %}
## Step 2: Register the Activation Key
{% tabs %}
{% tabitem label="Closed Source Repository" %}
To register the activation key in your repository, run the `nx register` command.
```shell {% frame="none" %}
nx register YOUR_ACTIVATION_KEY
```
The key will be saved in your repository and should be committed so that every developer has access to the Powerpack features. **Only one developer needs to run this. The rest of the team will gain access to Nx Powerpack features once they pull the changes including the checked-in file.**
Another option is to use an environment variable in CI.
```ini
// .env
NX_KEY=YOUR_ACTIVATION_KEY
```
**Whether you use the `nx register <your-key>` command or set the environment variable, Nx Powerpack does not make any requests to external APIs. No data is collected or sent anywhere.**
{% /tabitem %}
{% tabitem label="Open Source Repository" %}
Use an environment variable for your activation key such that it is not committed to the repository.
@@ -4,9 +4,9 @@ description: Configure and manage Nx Conformance rules across workspaces using t
filter: 'type:Features'
---
[Nx Cloud Enterprise](https://nx.dev/enterprise) allows you to publish your organization's [Nx Conformance](/docs/enterprise/powerpack/conformance) rules to your Nx Cloud Organization, and consume them in any of your other Nx Workspaces without having to deal with the complexity and friction of dealing with a private NPM registry or similar. Authentication is handled automatically through your Nx Cloud connection and rules are downloaded and applied based on your preferences configured in the Nx Cloud UI.
[Nx Cloud Enterprise](https://nx.dev/enterprise) allows you to publish your organization's [Nx Conformance](/docs/enterprise/conformance) rules to your Nx Cloud Organization, and consume them in any of your other Nx Workspaces without having to deal with the complexity and friction of dealing with a private NPM registry or similar. Authentication is handled automatically through your Nx Cloud connection and rules are downloaded and applied based on your preferences configured in the Nx Cloud UI.
To learn about how to create and publish custom rules to your Nx Cloud Organization, please refer to the [Publish Conformance Rules to Nx Cloud](/docs/enterprise/powerpack/publish-conformance-rules-to-nx-cloud) recipe.
To learn about how to create and publish custom rules to your Nx Cloud Organization, please refer to the [Publish Conformance Rules to Nx Cloud](/docs/enterprise/publish-conformance-rules-to-nx-cloud) recipe.
Once you have one or more rules published to your Nx Cloud Organization, you can configure your Nx Cloud Organization to use them in the Nx Cloud UI by visiting:
@@ -85,4 +85,4 @@ When `nx-cloud conformance` or `nx-cloud conformance:check` are run, any configu
By design, the workspace cannot choose to disable the rules configured in Nx Cloud - any conflict between local and cloud rules will result in the local configuration being overridden by the cloud configuration.
{% /aside %}
If the cloud rules were written to depend on a different version of Nx or Nx Powerpack than is installed within the current workspace, Nx Cloud will handle installing applicable versions dynamically at runtime.
If the cloud rules were written to depend on a different version of Nx than is installed within the current workspace, Nx Cloud will handle installing applicable versions dynamically at runtime.
description: 'Learn how to use Nx Powerpack and Nx Enterprise conformance rules to enforce organizational standards, maintain consistency, and ensure security across your workspace.'
description: 'Learn how to use Nx Enterprise conformance rules to enforce organizational standards, maintain consistency, and ensure security across your workspace.'
The [`@nx/conformance`](/docs/reference/powerpack/conformance/overview) plugin allows [Nx Powerpack](https://nx.dev/powerpack) and [Nx Enterprise](https://nx.dev/enterprise) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**. Powerpack is available for Nx version 19.8 and higher.
The [`@nx/conformance`](/docs/reference/conformance/overview) plugin allows [Nx Enterprise plan](https://nx.dev/enterprise) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**.
## Why Conformance?
@@ -22,21 +22,21 @@ The `@nx/conformance` plugin lets you write custom rules in TypeScript that enfo
The plugin also provides the following pre-written rules:
- **Enforce Project Boundaries**: Similar to the Nx [ESLint Enforce Module Boundaries rule](/docs/technologies/eslint/eslint-plugin/guides/enforce-module-boundaries), but enforces the boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
- **Ensure Owners**: Require every project to have an owner defined for the [`@nx/owners` plugin](/docs/reference/powerpack/owners)
- **Ensure Owners**: Require every project to have an owner defined for the [`@nx/owners` plugin](/docs/reference/owners)
## Setup
The `@nx/conformance` plugin requires an Nx Powerpack or [Nx Enterprise license](https://nx.dev/enterprise) to function. [Activating Powerpack](/docs/enterprise/activate-powerpack) is a simple process.
The `@nx/conformance` plugin requires an [Nx Enterprise plan](https://nx.dev/enterprise) to function. [Activating your license](/docs/enterprise/activate-license) is a simple process.
{% call_to_action title="Get a License and Activate Powerpack or Nx Enterprise" icon="nx" description="Unlock all the features of the Nx CLI" url="/docs/enterprise/activate-powerpack" /%}
{% call_to_action title="Get a License and Activate Nx Enterprise" icon="nx" description="Unlock all the features of the Nx CLI" url="/docs/enterprise/activate-license" /%}
Then, add the Conformance plugin to your workspace.
Conformance rules are configured in the `conformance` property of the `nx.json` file. You can use the pre-defined rules or reference [your own custom rule](/docs/reference/powerpack/conformance#custom-conformance-rules). See the [plugin documentation](/docs/reference/powerpack/conformance) for more details.
Conformance rules are configured in the `conformance` property of the `nx.json` file. You can use the pre-defined rules or reference [your own custom rule](/docs/reference/conformance#custom-conformance-rules). See the [plugin documentation](/docs/reference/conformance) for more details.
```jsonc
// nx.json
@@ -101,18 +101,18 @@ Use `npx nx-cloud record --` to capture the logs for `nx conformance:check` in t
run: npx nx-cloud record -- npx nx-cloud conformance:check
```
Here we are using the `nx-cloud` CLI to run the `conformance:check` command so that we can hook into the power of Conformance rules configured in your Nx Cloud Enterprise organization. Learn more about [conformance rules in Nx Cloud](/docs/enterprise/powerpack/configure-conformance-rules-in-nx-cloud).
Here we are using the `nx-cloud` CLI to run the `conformance:check` command so that we can hook into the power of Conformance rules configured in your Nx Cloud Enterprise organization. Learn more about [conformance rules in Nx Cloud](/docs/enterprise/configure-conformance-rules-in-nx-cloud).
{% /tabitem %}
{% /tabs %}
If a valid Powerpack license is not available to the workspace (either locally or via Nx Cloud), the `nx conformance` and `nx conformance:check` commands will fail without checking any rules.
If a valid license is not available to the workspace (either locally or via Nx Cloud), the `nx conformance` and `nx conformance:check` commands will fail without checking any rules.
## Taking things further with Nx Cloud Enterprise
Organizations on the Nx Cloud Enterprise plan can [publish custom conformance rules](/docs/enterprise/powerpack/publish-conformance-rules-to-nx-cloud) to their Nx Cloud organization without the friction of a custom registry, and then [configure the rules](/docs/enterprise/powerpack/configure-conformance-rules-in-nx-cloud) to apply to the workspaces in their organization automatically when `nx-cloud conformance` or `nx-cloud conformance:check` is run (note that the `nx-cloud` CLI is used in this case in order to handle the authentication with Nx Cloud).
Organizations on the Nx Cloud Enterprise plan can [publish custom conformance rules](/docs/enterprise/publish-conformance-rules-to-nx-cloud) to their Nx Cloud organization without the friction of a custom registry, and then [configure the rules](/docs/enterprise/configure-conformance-rules-in-nx-cloud) to apply to the workspaces in their organization automatically when `nx-cloud conformance` or `nx-cloud conformance:check` is run (note that the `nx-cloud` CLI is used in this case in order to handle the authentication with Nx Cloud).
The Powerpack license will be applied automatically via Nx Cloud in all contexts, and so there is zero setup required for the end developer.
The license will be applied automatically via Nx Cloud in all contexts, and so there is zero setup required for the end developer.
Simply add an appropriate invocation of the `nx-cloud conformance:check` command to your CI process and all cloud configured rules will be applied and merged with any local rules:
@@ -121,13 +121,13 @@ Simply add an appropriate invocation of the `nx-cloud conformance:check` command
run: npx nx-cloud record -- npx nx-cloud conformance:check
```
Learn more about [publishing](/docs/enterprise/powerpack/publish-conformance-rules-to-nx-cloud) and [configuring conformance rules in Nx Cloud](/docs/enterprise/powerpack/configure-conformance-rules-in-nx-cloud).
Learn more about [publishing](/docs/enterprise/publish-conformance-rules-to-nx-cloud) and [configuring conformance rules in Nx Cloud](/docs/enterprise/configure-conformance-rules-in-nx-cloud).
## Learn More
- [Conformance Plugin API Reference](/docs/reference/powerpack/conformance/overview) - Detailed documentation on configuration options and provided rules
- [Create a Custom Conformance Rule](/docs/reference/powerpack/conformance/create-conformance-rule) - Step-by-step guide to writing your own rules
- [Testing Conformance Rules](/docs/reference/powerpack/conformance/test-conformance-rule) - Learn how to test your conformance rules
- [Publish Conformance Rules to Nx Cloud](/docs/enterprise/powerpack/publish-conformance-rules-to-nx-cloud) - Share rules across your organization
- [Configure Conformance Rules in Nx Cloud](/docs/enterprise/powerpack/configure-conformance-rules-in-nx-cloud) - Manage rules via the Nx Cloud dashboard
- [Conformance Plugin API Reference](/docs/reference/conformance/overview) - Detailed documentation on configuration options and provided rules
- [Create a Custom Conformance Rule](/docs/reference/conformance/create-conformance-rule) - Step-by-step guide to writing your own rules
- [Testing Conformance Rules](/docs/reference/conformance/test-conformance-rule) - Learn how to test your conformance rules
- [Publish Conformance Rules to Nx Cloud](/docs/enterprise/publish-conformance-rules-to-nx-cloud) - Share rules across your organization
- [Configure Conformance Rules in Nx Cloud](/docs/enterprise/configure-conformance-rules-in-nx-cloud) - Manage rules via the Nx Cloud dashboard
- [Blog: Automating Consistency with Nx Cloud Conformance](https://nx.dev/blog/nx-cloud-conformance-automate-consistency) - Learn about the philosophy and benefits of conformance
@@ -45,7 +45,7 @@ Conformance based workflows allow running the pre-defined conformance rules for
1. Click **Polygraph** or **Conformance** for your repeating workflows provided by Nx Cloud
- if using **Conformance** action, then make sure you've already configured and [published a conformance rule](/docs/enterprise/powerpack/publish-conformance-rules-to-nx-cloud)
- if using **Conformance** action, then make sure you've already configured and [published a conformance rule](/docs/enterprise/publish-conformance-rules-to-nx-cloud)
title: 'Define Code Ownership at the Project Level'
description: 'Learn how to use Nx Powerpack owners plugin to manage code ownership at the project level and automatically generate CODEOWNERS files for GitHub, Bitbucket, or GitLab.'
description: 'Learn how to use Nx owners plugin to manage code ownership at the project level and automatically generate CODEOWNERS files for GitHub, Bitbucket, or GitLab.'
This plugin provides [Nx Powerpack](https://nx.dev/powerpack) users the ability to configure and maintain code owners for projects in an Nx workspace. Powerpack is available for Nx version 19.8 and higher.
This plugin provides [Nx Enterprise plan](https://nx.dev/enterprise) users the ability to configure and maintain code owners for projects in an Nx workspace.
The atomic unit of code in an Nx workspace is a project. Tasks, module boundaries and the Nx graph all train us to conceptualize the workspace as a collection of projects. The CODEOWNERS file, however, requires you to switch from a project mental model to a more low-level definition based on the folder structure of your workspace. The `@nx/owners` plugin enables you to stay in the mental model that your workspace is a collection of projects as you define the ownership rules for your workspace. Nx will take care of compiling the project ownership rules into file-based ownership rules that [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners), [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) or [GitLab](https://docs.gitlab.com/ee/user/project/codeowners/) can understand in the CODEOWNERS file.
## Setup
The `@nx/owners` plugin requires an Nx Powerpack license to function. [Activating Powerpack](/docs/enterprise/activate-powerpack) is a simple process.
The `@nx/owners` plugin requires an Nx Enterprise plan to function. [Activating your license](/docs/enterprise/activate-license) is a simple process.
{% call_to_action title="Get a License and Activate Powerpack" icon="nx" description="Unlock all the features of the Nx CLI" url="/docs/enterprise/activate-powerpack" /%}
{% call_to_action title="Get a License and Activate Nx Enterprise plan extensions" icon="nx" description="Unlock all the features of the Nx CLI" url="/docs/enterprise/activate-license" /%}
The ownership configuration is defined in the `nx.json` file or in individual project configuration files. Nx then uses a [sync generator](/docs/concepts/sync-generators) to automatically compile those settings into a valid CODEOWNERS file for GitHub, Bitbucket or GitLab. See the [plugin documentation](/docs/reference/powerpack/owners) for more details.
The ownership configuration is defined in the `nx.json` file or in individual project configuration files. Nx then uses a [sync generator](/docs/concepts/sync-generators) to automatically compile those settings into a valid CODEOWNERS file for GitHub, Bitbucket or GitLab. See the [plugin documentation](/docs/reference/owners) for more details.
Gain quick visibility across your organization's repositories without needing to migrate each repository as an Nx Workspace.
Easily onboard any repository as a **metadata-only** to immediately start contributing to the [Workspace Graph](#workspace-graph).
Metadata-only workspaces can still leverage [custom workflows](/docs/enterprise/polygraph#custom-workflows) and [conformance rules](/docs/enterprise/powerpack/conformance).
Metadata-only workspaces can still leverage [custom workflows](/docs/enterprise/polygraph#custom-workflows) and [conformance rules](/docs/enterprise/conformance).
Read more about [onboarding a workspace as metadata-only](/docs/enterprise/metadata-only-workspace).
@@ -108,9 +108,9 @@ Yes, rules can be set to _evaluate_ mode before enforcement, and you can schedul
- **Disabled**: Rule is turned off and won't run in any workspaces.
**Q: If I have Powerpack, can I use Conformance with Nx Cloud?**
**Q: Can I use Conformance with Nx Cloud?**
Powerpack enables conformance rules within individual workspaces. Polygraph extends this by publishing rules across your entire organization, configuring them across multiple workspaces, and tracking results at the organizational level. An Nx Cloud Enterprise license is required for Polygraph features.
Yes! Nx Enterprise plan enable conformance rules within individual workspaces. Polygraph extends this by publishing rules across your entire organization, configuring them across multiple workspaces, and tracking results at the organizational level. An Nx Cloud Enterprise license is required for Polygraph features.
{% aside type="tip" title="Ready to start using Polygraph? " %}
Existing enterprise customers should contact their assigned developer productivity engineer to get setup. Otherwise, reach out to us about [Nx Enterprise](https://nx.dev/enterprise) to unlock Polygraph's organizational scaling features.
@@ -4,17 +4,17 @@ description: Create and publish custom Nx Conformance rules to your Nx Cloud org
filter: 'type:Guides'
---
[Nx Cloud Enterprise](https://nx.dev/enterprise) allows you to publish your organization's [Nx Conformance](/docs/enterprise/powerpack/conformance) rules to your Nx Cloud Organization, and consume them in any of your other Nx Workspaces without having to deal with the complexity and friction of dealing with a private NPM registry or similar. Authentication is handled automatically through your Nx Cloud connection and rules are downloaded and applied based on your preferences configured in the Nx Cloud UI.
[Nx Cloud Enterprise](https://nx.dev/enterprise) allows you to publish your organization's [Nx Conformance](/docs/enterprise/conformance) rules to your Nx Cloud Organization, and consume them in any of your other Nx Workspaces without having to deal with the complexity and friction of dealing with a private NPM registry or similar. Authentication is handled automatically through your Nx Cloud connection and rules are downloaded and applied based on your preferences configured in the Nx Cloud UI.
Let's create a custom rule which we can then publish to Nx Cloud. We will first create a new library project to contain our rule (and any others we might create in the future):
The Nx Cloud distribution mechanism expects each rule to be created in a named subdirectory in the `src/` directory of our new project, and each rule directory to contain an `index.ts` and a `schema.json` file. You can read more about [creating a conformance rule](/docs/reference/powerpack/conformance/create-conformance-rule) in the dedicated guide. For this recipe, we'll generate a default rule to use in the publishing process.
The Nx Cloud distribution mechanism expects each rule to be created in a named subdirectory in the `src/` directory of our new project, and each rule directory to contain an `index.ts` and a `schema.json` file. You can read more about [creating a conformance rule](/docs/reference/conformance/create-conformance-rule) in the dedicated guide. For this recipe, we'll generate a default rule to use in the publishing process.
```shell {% frame="none" %}
```shell
nx g @nx/conformance:create-rule --name=test-cloud-rule --directory=cloud-conformance-rules/src --category=reliability --description="A test cloud rule" --reporter=non-project-files-reporter
```
@@ -22,7 +22,7 @@ nx g @nx/conformance:create-rule --name=test-cloud-rule --directory=cloud-confor
If you get an error resolving the `@nx/conformance` plugin, you may need to add it. You can do this by running `nx add @nx/conformance` in your workspace.
{% /aside %}
We now have a valid implementation of a rule and we are ready to build it and publish it to Nx Cloud. The [`@nx/conformance` plugin](/docs/reference/powerpack/conformance) provides a [dedicated executor called `bundle-rules`](/docs/reference/powerpack/conformance/executors#bundle-rules) for creating appropriate build artifacts for this purpose. We will replace the existing build target and wire up that executor in our `cloud-conformance-rules` project's `project.json` file:
We now have a valid implementation of a rule and we are ready to build it and publish it to Nx Cloud. The [`@nx/conformance` plugin](/docs/reference/conformance) provides a [dedicated executor called `bundle-rules`](/docs/reference/conformance/executors#bundle-rules) for creating appropriate build artifacts for this purpose. We will replace the existing build target and wire up that executor in our `cloud-conformance-rules` project's `project.json` file:
```jsonc
// cloud-conformance-rules/project.json
@@ -50,7 +50,7 @@ We can now run `nx build cloud-conformance-rules` to build our rule and create t
Our final step is to publish the rule artifacts to Nx Cloud. We achieve this by running the `publish-conformance-rules` command on the `nx-cloud` CLI, passing the output path location as the first positional argument:
@@ -17,7 +17,7 @@ These packages are used to set up a new project in some form.
Customizing your initial project setup is already possible with an [Nx Preset generator](/docs/extending-nx/create-preset). By creating and shipping a generator named `preset` in your Nx plugin, you can then pass it via the `--preset` flag to the `create-nx-workspace` command:
```shell {% frame="none" %}
```shell
npx create-nx-workspace --preset my-plugin
```
@@ -29,13 +29,13 @@ There are a few methods to create a package that will work with `create-nx-works
You can setup a new Nx plugin workspace and immediately pass the `--create-package-name`:
Alternatively, if you already have an existing Nx plugin workspace, you can run the following generator to set up a new create package:
```shell {% frame="none" %}
```shell
nx g create-package create-my-plugin --project my-plugin
```
@@ -118,7 +118,7 @@ _(If you don't have such a `local-registry` target, refer to the following [docs
By running
```shell {% frame="none" %}
```shell
npx nx local-registry
```
@@ -130,7 +130,7 @@ Note, after terminating the terminal window where the `nx local-registry` comman
Next, you can **publish** your packages to your new local registry. All of the generated packages can use `nx release` to publish whatever is in your `build` output folder, so you can simply run:
When setting up the workspace, you should also have gotten a `my-plugin-e2e` package. This package contains the e2e tests for your plugin, and can be run with the following command:
@@ -20,7 +20,7 @@ All first-party Nx presets are built into Nx itself, but you can [create your ow
To use a concrete example, let's look at the [`qwik-nx`](https://www.npmjs.com/package/qwik-nx) Nx community plugin. They include a [preset generator](https://github.com/qwikifiers/qwik-nx/tree/main/packages/qwik-nx/src/generators/preset) that you can use to create a new Nx workspace with Qwik support.
@@ -18,7 +18,7 @@ You can create a new sync generator by hand or use the built-in generator that N
Make sure you have `@nx/plugin` installed or add it to your workspace:
```shell {% frame="none" %}
```shell
nx add @nx/plugin
```
@@ -26,7 +26,7 @@ nx add @nx/plugin
Create a new local plugin where we can add our new sync generator. You can also add it to an existing local plugin if you already have one. In that case you can skip this step.
```shell {% frame="none" %}
```shell
nx g @nx/plugin:plugin tools/my-plugin
```
@@ -34,7 +34,7 @@ nx g @nx/plugin:plugin tools/my-plugin
Create a sync generator the same way you would [create any generator](/docs/extending-nx/local-generators).
```shell {% frame="none" %}
```shell
nx g @nx/plugin:generator --path=tools/my-plugin/src/generators/my-sync-generator
```
@@ -181,7 +181,7 @@ For projects using [inferred targets](/docs/concepts/inferred-tasks) (no project
{% aside type="caution" title="Verify the name of your plugin" %}
You might have to adjust the name of your plugin based on your specific workspace scope. Verify the name in `tools/my-plugin/package.json`. If the name there is `@myorg/my-plugin` you have to register it as:
description: Understand which createNodes API version is used by different Nx versions and how to write plugins that support multiple Nx versions.
filter: 'type:References'
---
This is a reference for knowing how Nx versions and the `createNodes`/`createNodesV2` APIs interact. If you plan on supporting multiple Nx versions with a custom plugin, then it's important to know which APIs to use.
## Which CreateNodes Version Does Nx Call?
The following table shows which export Nx will call based on the Nx version:
| Both with v2 signature (Nx 22+) | ❌ Not Supported | ❌ Not Supported | ✅ Supported | ✅ Supported |
## Recommended Implementation Pattern
### Plugin Support for Nx 21 and later
For plugins targeting **Nx 21 and later**, the recommended pattern is to export both `createNodes` and `createNodesV2` using the same v2 implementation:
@@ -70,7 +70,7 @@ We're returning the `callbackAfterFilesUpdated` function because the `@nx/react:
To try out the generator in dry-run mode, use the following command:
```shell {% frame="none" %}
```shell
npx nx g @myorg/recommended:library test-library --dry-run
```
@@ -139,7 +139,7 @@ The schema files not only provide structure to the CLI, but also allow [Nx Conso
Notice how we made the `description` argument optional in both the JSON and type files. If we call the generator without passing a directory, the project will be created in a directory with same name as the project. We can test the changes to the generator with the following command:
```shell {% frame="none" %}
```shell
npx nx g @myorg/recommended:library test-library --directory=nested/directory/test-library --dry-run
We can check that the scope logic is being applied correctly by running the generator again and specifying a scope.
```shell {% frame="none" %}
```shell
npx nx g @myorg/recommended:library test-library --scope=shared --dry-run
```
@@ -316,7 +316,7 @@ We updated the generator to use some new helper functions from the Nx devkit. He
Now let's check to make sure that the `clearMocks` property is set correctly by the generator. First, we'll commit our changes so far. Then, we'll run the generator without the `--dry-run` flag so we can inspect the file contents.
```shell {% frame="none" %}
```shell
git add .
git commit -am "library generator"
npx nx g @myorg/recommended:library store-test --scope=store
@@ -35,6 +35,10 @@ You can register a plugin by adding it to the plugins array in `nx.json`:
You can add nodes to the project graph with [`createNodesV2`](/docs/reference/devkit/CreateNodesV2). This is the API that Nx uses under the hood to identify Nx projects coming from a `project.json` file or a `package.json` that's listed in a package manager's workspaces section.
{% aside type="note" title="CreateNodes API Versions" %}
Nx has evolved its plugin API over time. Different Nx versions call different `createNodes` exports (`createNodes` vs `createNodesV2`). If you need to support multiple Nx versions see the [CreateNodes Compatibility Guide](/docs/extending-nx/createnodes-compatibility).
{% /aside %}
### Identifying Projects
Looking at the tuple, you can see that the first element is a file pattern. This is a glob pattern that Nx will use to find files in your workspace. The second element is a function that will be called for each file that matches the pattern. The function will be called with the path to the file and a context object. Your plugin can then return a set of projects and external nodes.
@@ -10,7 +10,7 @@ In this tutorial, we'll create a plugin that helps to integrate the _Astro_ fram
To create a plugin in a brand new repository, use the `create-nx-plugin` command:
```shell {% frame="none" %}
```shell
npx create-nx-plugin nx-astro
```
@@ -75,6 +75,10 @@ If the `astro.config.mjs` for a project looks like our example in the previous s
To create an inferred task, we need to export a `createNodesV2` function from the plugin's `index.ts` file. The entire file is shown below with inline comments to explain what is happening in each section.
Different Nx versions call different `createNodes` exports. If you need to support Nx versions before 21 see the [CreateNodes Compatibility Guide](/docs/extending-nx/createnodes-compatibility).
{% /aside %}
```ts
// src/index.ts
import {
@@ -193,7 +197,7 @@ If you create a generator named `init`, Nx will automatically run that generator
To create the generator run the following command:
@@ -211,7 +211,7 @@ This drastically improves the speed of your CI and reduces the amount of compute
To leverage this feature, use the following command when running your tasks, particularly on CI:
```shell {% frame="none" %}
```shell
nx affected -t <task>
```
@@ -225,7 +225,7 @@ Once the projects are identified, Nx runs the tasks you specified on that subset
You can also visualize the affected projects using the [Nx graph](/docs/features/explore-graph). Simply run:
```shell {% frame="none" %}
```shell
nx graph --affected
```
@@ -244,14 +244,14 @@ To understand which projects are affected, Nx uses the Git history and the [proj
The affected command takes a `base` and `head` commit. The default `base` is your `main` branch, and the default `head` is your current file system. This is generally what you want when developing locally, but in CI, you need to customize these values.
```shell {% frame="none" %}
```shell
nx affected -t build --base=origin/main --head=$PR_BRANCH_NAME # where PR_BRANCH_NAME is defined by your CI system
nx affected -t build --base=origin/main~1 --head=origin/main # rerun what is affected by the last commit in main
```
You can also set the base and head SHAs as environment variables:
@@ -29,7 +29,7 @@ Nx Agents offer several key advantages:
To enable task distribution with Nx Agents, make sure your Nx workspace is connected to Nx Cloud. If you haven't connected your workspace to Nx Cloud yet, run the following command:
```shell {% frame="none" %}
```shell
npx nx@latest connect
```
@@ -37,7 +37,7 @@ Check out the [connect to Nx Cloud recipe](/docs/guides/nx-cloud/setup-ci) for m
Then, adjust your CI pipeline configuration to **enable task distribution**. If you don't have a CI config yet, you can generate a new one using the following command:
description: Get AI-powered explanations and resolution steps for failed tasks in Nx Cloud
sidebar:
order: 17
badge: beta
filter: 'type:Features'
---
{% youtube
src="https://youtu.be/g2m9cHp-O-Q"
title="Explain with AI"
/%}
"Explain with AI" helps you understand complex errors more quickly by providing AI-powered error resolution steps. This is made possible by using additional context from Nx targets and metadata, allowing for more accurate and relevant responses.
## Enable Explain with AI
To use the "Explain with AI" feature, you need to [enable AI features for your organization](/docs/guides/nx-cloud/enable-ai-features). In the **settings** menu, locate the "AI Features" section and toggle it to "On".
{% aside type="note" title="AI Features Availability" %}
AI features are available on Hobby, Team and Enterprise [Nx Cloud plans](https://nx.dev/pricing).
@@ -16,7 +16,7 @@ Flaky Task Detection is enabled by default if your workspace is connected to Nx
To connect your workspace to Nx Cloud run:
```shell {% frame="none" %}
```shell
npx nx@latest connect
```
@@ -39,12 +39,60 @@ In this image, the `e2e-ci--src/e2e/app.cy.ts` task is a flaky task that has bee
When a flaky task fails in CI with [distributed task execution](/docs/features/ci-features/distribute-task-execution) enabled, Nx will **automatically send that task to a different agent** and run it again (up to 2 tries in total). Its important to run the task on a different agent to ensure that the agent itself or the other tasks that were run on that agent are not the reason for the flakiness.
## Manually Mark a Task as Flaky or Not Flaky
## Flaky Task Analytics
If you suspect that a task is flaky, but Nx has not confirmed it yet, you can manually **mark it as likely flaky** from the run details screen. Failed tasks that are not flaky will have a button that says **"Mark task as likely flaky"**.
Workspace flaky task analytics is currently available for organizations on the Enterprise plan. Reach out if your organization is [interested in Nx Enterprise](https://nx.dev/enterprise?utm_source=nx.dev&utm_medium=callout&utm_campaign=flaky-task-analytics).
{% /aside %}
Nx Cloud provides analytics to help you understand and manage flaky tasks across your workspace. The analytics dashboard gives you insights into which tasks are flaky, how often they fail, and how much time is being wasted on reruns.
Once you've resolved the issue that caused a task to be flaky, you can immediately mark the task as not flaky by clicking on **"Mark task as no longer flaky"** on the same run details screen.
The dashboard displays key metrics over the time range selected (7 days vs 30 days) to give you a quick overview of your workspace health.
- **Active flaky tasks** - The total number of tasks in your workspace that have a flake rate greater than 0 within the selected time window.
- **Average flake rate** - A weighted average flake rate across all tasks in your workspace. This metric uses the sample size to weight each task's flake rate proportionally, so a task that ran 1000 times with 5% flake rate has more impact than one that ran 10 times with 50% flake rate.
- **High risk tasks** - The number of tasks with a flake rate higher than 20%, indicating severe reliability issues that need immediate attention.
The chart shown provides a visual representation of your flaky tasks, helping you quickly identify which tasks need the most attention.
Tasks are plotted based on their **impact score**, which is calculated as `flake_rate × sample_size`. This means frequently-run flaky tasks are weighted higher than rarely-run flaky tasks.
Priority levels are determined using percentile-based thresholds that scale across organizations of any size:
- **High priority** (red) - Top 10% of tasks by impact score (90th percentile and above). These tasks have severe flakiness and should be addressed immediately.
- **Medium priority** (yellow) - Next 23% of tasks by impact score (67th-90th percentile). These tasks have moderate flakiness with sufficient data.
- **Low priority** (gray) - Bottom 67% of tasks by impact score. These tasks have minor flakiness or not enough data to be concerning.
Tasks on the right side of the chart typically represent the highest priority items that need attention. The scatter plot shows up to 50 results, sorted by most recent flaked tasks.
### Flaky Task Table
The table provides detailed information about each flaky task in your workspace:
By default, the table loads your most recent flaky tasks. Each row includes:
- **Task** - The project and target combination (e.g., `my-app:test`)
- **Flake rate** - Measures how often a task succeeds due to flakiness. Specifically, it represents the percentage of total successes that came from unreliable (flaky) task hashes: `flaky_successes / (flaky_successes + non_flaky_successes)`. This tells you: "Of all the times this task succeeded, how many successes came from unreliable code?"
- **Total reruns** - The number of times a task was executed more than once due to flakiness. This counts the "extra" executions that happened because the task failed and needed to be retried. Calculated as: `total_executions - unique_hash_count`
- **Time wasted** - An estimate of the total time spent on reruns, calculated by multiplying the total reruns by the average task duration
- **Last failure** - The timestamp of the most recent failure across all contributing task hashes
#### Flaky Task Detail View
Click on any row in the table to view detailed information about a specific flaky task.
The **Overview** tab shows summary statistics and trends for the selected task such as flake rate, time wasted and automatic deflake counts
The **Environments** tab provides insights into the different environments where the task was executed, helping identify if certain environments contribute to flakiness.
Any CI tool requires tight integration with your existing version control system. Nx Cloud offers first class integration with GitHub in the following ways.
## Easy Onboarding
## Easy Workspace Setup
Get started with Nx Cloud in no time with our GitHub connection process. Connect your workspace, and Nx Cloud will create a pull request with everything you need. Select your workspace and organization, and Nx Cloud takes care of the rest. User access is automatically connected to GitHub, and a PR is created to connect your workspace. Your repo now has [distributed caching](/docs/features/ci-features/remote-cache) in less than 5 minutes.
Get started quickly with Nx Cloud with our GitHub connection process. Connect your workspace by selecting your repo and organization from GitHub, and Nx Cloud will create a pull request with all the necessary configuration. User access is automatically connected to GitHub, and a PR is created to connect your workspace. Your repo now has [distributed caching](/docs/features/ci-features/remote-cache) in less than 5 minutes.
You can also create a new workspace from a template for experimentation. This workspace will come pre-configured with Nx Cloud and examples of core Nx concepts. [Create a new Nx workspace](https://cloud.nx.app/create-nx-workspace) to get started.
[Connect your Nx Cloud account to GitHub](/docs/features/ci-features/github-integration#connect-to-github) to use this feature.
## Pull Request Insights
@@ -20,21 +24,27 @@ Get started with Nx Cloud in no time with our GitHub connection process. Connect
Good CI checks require fast and easy access to results. That's why Nx Cloud will update your PR with the current running status of your tasks and a convenient link to your Nx Cloud results and logs. Take advantage of the enhanced developer experience of structured and searchable logs. Quick insight to PR task progress, so you're not stuck waiting for every task to complete. And with Nx Replay, developers can quickly replay tasks locally to avoid running tasks that CI has already completed.
This feature is available in workspaces with the [Nx Cloud GitHub App installed](/docs/guides/nx-cloud/source-control-integration/github#install-the-app).
## Access Control
Nx Cloud organizations can use their existing GitHub access controls to manage Nx Cloud as well. This allows Nx Cloud to fit in to any existing on-boarding or off-boarding process. There's no need to manually manage users separately. Get your engineers Nx Cloud access right alongside their GitHub access so they can get to work fast. Use [personal access tokens](/docs/guides/nx-cloud/personal-access-tokens) to further enhance your security.
Nx Cloud organization access can be linked to a Github organization, so that memberships are automatically synced. This allows Nx Cloud to fit in to any existing on-boarding or off-boarding process. There's no need to manually manage users separately. Get your engineers Nx Cloud access right alongside their GitHub access so they can get to work fast. Use [personal access tokens](/docs/guides/nx-cloud/personal-access-tokens) to further enhance your security.
## Get Started
[Connect your Nx Cloud account to GitHub](/docs/features/ci-features/github-integration#connect-to-github) to use this feature. Members of your GitHub organization will also need to connect their GitHub accounts to access the organization.
First, you'll want to connect your Nx Cloud account to GitHub. You can use your regular username and password or log in via Google or GitHub, connecting to GitHub is a separate step.
## Connect to GitHub
{% call_to_action title="Connect to GitHub" url="https://cloud.nx.app/profile/vcs-integrations" icon="nxcloud" description="Connect your Nx Cloud account to GitHub via your profile settings" %}
Get started by connecting your Nx Cloud account to GitHub. This will allow you to access GitHub-powered organizations that you're a member of, easily connect workspaces, and configure automatic access control through GitHub.
{% call_to_action title="Connect to GitHub" url="https://cloud.nx.app/profile/vcs-integrations" icon="nxcloud" description="Connect your Nx Cloud account to GitHub in your profile settings" %}
Connect to GitHub
{% /call_to_action %}
## Connect a New Workspace and Organization
Note that it doesn't matter what method you use to log into Nx Cloud, connecting your GitHub account is a separate step.
## Connect to GitHub during Initial Setup
1. Visit [Nx Cloud](https://cloud.nx.app) and click **Connect a workspace** at the top.
2. Select **Connect existing repository** from the dropdown.
@@ -46,15 +56,15 @@ Connect to GitHub
Connect an Nx workspace in GitHub to Nx Cloud
{% /call_to_action %}
## Connect an Existing Organization
## Connect an Organization to GitHub after Initial Setup
If you've already created an organization in Nx Cloud, and you'd like to use your GitHub organization to manage access to it:
If you already have an organization in Nx Cloud, and you'd like to use your GitHub organization to manage access to it:
1. Go to the organization in Nx Cloud while logged in as an admin user.
2. Click on **Settings** in the top menu
3. Go to **Connect GitHub organization in the sidebar**
4. Follow the prompts there to connect to GitHub.
4. Follow the prompts there to connect to GitHub. Note that for every workspace in the Nx Cloud organization, there must be a corresponding repo in the GitHub organization.
## Connect an Existing Workspace
## Connect a Workspace to GitHub after Initial Setup
If you already have a workspace connected to Nx Cloud, and you'd like to connect it to a GitHub repo to enable PR insights, [see our recipe for more details.](/docs/guides/nx-cloud/source-control-integration)
If you already have a workspace connected to Nx Cloud, and you'd like to connect it to a GitHub repo to enable PR insights, [install the Nx Cloud GitHub App](/docs/guides/nx-cloud/source-control-integration/github#install-the-app).
@@ -29,7 +29,7 @@ To enable Self-Healing CI in your workspace, you'll need to connect to Nx Cloud
If you haven't already connected to Nx Cloud, run the following command:
```shell {% frame="none" %}
```shell
npx nx@latest connect
```
@@ -56,6 +56,11 @@ jobs:
### Enable Auto-fixing
{% youtube
src="https://youtu.be/EmZcENiCG64"
title="Enable Auto-fixing"
/%}
By default, Self-Healing CI proposes a fix for you to review and only applies it automatically to your PR after you confirm it. However, for some tasks, it makes sense to have them be auto-fixed without waiting for manual approval. Auto-fixes are only applied if the verification phase passes.
Below is an example of enabling auto-fixing for the Nx `format` command and `lint` tasks using the [`--auto-apply-fixes`](/docs/reference/nx-cloud-cli#--auto-apply-fixes) flag:
@@ -78,6 +83,11 @@ Tasks are passed to the `--auto-apply-fixes` as `<project>:<task-name>:<configur
### Specify Which Tasks to Fix
{% youtube
src="https://youtu.be/KSb48zHbaHg"
title="Specify Which Tasks to Fix"
/%}
By using the [`--fix-tasks`](/docs/reference/nx-cloud-cli#--fix-tasks) flag you can fine-tune which tasks should be considered by the Nx Cloud self-healing CI. Below is an example of running self-healing on all tasks except `deploy` and `test` tasks.
```yaml
@@ -99,6 +109,48 @@ Similarly, if you only want to self-heal linting tasks you'd use `--fix-tasks="*
Tasks are passed to the `--fix-tasks` as `<project>:<task-name>:<configuration>`. Commands like `nx format` which you configure with `nx-cloud record --` are passed as `nx-cloud record -- <params>`.
### Customize Self-Healing Behavior
You can customize how Self-Healing CI behaves in your workspace by creating a `CLAUDE.md` file in your repository root. This file allows you to define custom classification rules and predefined fixes tailored to your project's specific needs.
#### Customize Failure Classification
Before proposing a fix, the Self-Healing CI agent classifies each failure into one of three categories:
- **`code_change`** - Failures directly caused by PR changes. Self-Healing will _propose and implement code fixes_.
- **`environment_state`** - Failures caused by environmental issues (network errors, service outages, resource constraints). Self-Healing will _not propose fixes_.
- **`flaky_task`** - Non-deterministic failures from timing issues or race conditions. Self-Healing _detects the flakiness and retriggers a pipeline run for the flaky task_.
You can override the default classification behavior with custom rules in `CLAUDE.md` by describing the nature of the error as well as one of the before mentioned categories:
```markdown
// CLAUDE.md
## Self-Healing CI
### Classification Customization
When analyzing failures, override the default classification in these cases:
- If there are errors about missing environment variables (like API_KEY, DATABASE_URL, etc.) classify them as 'environment_state'.
```
#### Define Predefined Fixes
For common, deterministic failures, you can define predefined fixes that Self-Healing CI should apply automatically. This is particularly useful for tasks that have standard, repeatable solutions. Here's an example to trigger `lint --fix` instead of having the AI attempt to implement the fix:
```markdown
// CLAUDE.md
## Self-Healing CI
Predefined fix:
- If a failed task id contains ":lint", fix it by running linting on the project where it failed with the `--fix` flag. Example: `nx run myapp:lint --fix` where "myapp" is the app the task failed on.
```
These predefined fixes allow Self-Healing CI to apply deterministic solutions without needing to analyze the code, speeding up the fix generation process for common scenarios.
## How Self-Healing CI works
Here's what happens when you push a PR with Self-Healing CI enabled:
@@ -26,7 +26,7 @@ Manually splitting these slow tasks can be complex and require ongoing maintenan
To use **automated task splitting**, you need to connect your workspace to Nx Cloud (if you haven't already).
```shell {% frame="none" %}
```shell
npx nx@latest connect
```
@@ -39,28 +39,35 @@ Run this command to set up inferred tasks and enable task splitting for each plu
{% tabs syncKey="test-runner" %}
{% tabitem label="Cypress" %}
```shell {% frame="none" %}
```shell
nx add @nx/cypress
```
{% /tabitem %}
{% tabitem label="Playwright" %}
```shell {% frame="none" %}
```shell
nx add @nx/playwright
```
{% /tabitem %}
{% tabitem label="Jest" %}
```shell {% frame="none" %}
```shell
nx add @nx/jest
```
{% /tabitem %}
{% tabitem label="Vitest" %}
```shell
nx add @nx/vitest
```
{% /tabitem %}
{% tabitem label="Gradle" %}
```shell {% frame="none" %}
```shell
nx add @nx/gradle
```
@@ -82,12 +89,13 @@ If you upgraded Nx from an older version, ensure that [inferred tasks](/docs/con
## Update an Existing Project to use Automated Task Splitting
If you are already using the `@nx/cypress`, `@nx/playwright`, `@nx/jest`, or `@nx/gradle` plugin, you need to manually add the appropriate configuration to the `plugins` array of `nx.json`. Follow the instructions for the plugin you are using:
If you are already using the `@nx/cypress`, `@nx/playwright`, `@nx/jest`, `@nx/vitest`, or `@nx/gradle` plugin, you need to manually add the appropriate configuration to the `plugins` array of `nx.json`. Follow the instructions for the plugin you are using:
@@ -20,7 +20,7 @@ Keeping your tooling up to date is crucial for the health of your project. Tooli
To update your workspace, run:
```shell {% frame="none" %}
```shell
npx nx@latest migrate latest
```
@@ -66,7 +66,7 @@ You can intervene at each step and make adjustments as needed for your specific
First, run the `migrate` command:
```shell {% frame="none" %}
```shell
nx migrate latest
```
@@ -89,7 +89,7 @@ Now, you can **inspect `package.json` to see if the changes make sense**. Someti
You can now run the actual code migrations that were generated in the `migrations.json` in the previous step.
```shell {% frame="none" %}
```shell
nx migrate --run-migrations
```
@@ -109,13 +109,13 @@ Note: You may want to keep the `migrations.json` until every branch that was cre
If you have any [Nx community plugins](/docs/plugin-registry) installed you need to migrate them individually (assuming they provide migration scripts) by using the following command:
```shell {% frame="none" %}
```shell
nx migrate my-plugin
```
For a list of all the plugins you currently have installed, run:
@@ -21,7 +21,7 @@ Nx offers two complementary approaches to enforce module boundaries:
**ESLint Integration** - For JavaScript/TypeScript projects, enforce boundaries on code imports using the `@nx/enforce-module-boundaries` ESLint rule. This checks TypeScript imports and `package.json` dependencies during linting.
**Language-Agnostic Conformance** - For any project type (e.g. Java, Python, PHP, JavaScript, etc.), use the [Conformance plugin's Enforce Project Boundaries rule](/docs/enterprise/powerpack/conformance). This rule checks dependencies in the Nx graph during `nx conformance:check`. Requires [Nx Powerpack or Enterprise](https://nx.dev/enterprise).
**Language-Agnostic Conformance** - For any project type (e.g. Java, Python, PHP, JavaScript, etc.), use the [Conformance plugin's Enforce Project Boundaries rule](/docs/enterprise/conformance). This rule checks dependencies in the Nx graph during `nx conformance:check`. Requires [Nx Enterprise plan](https://nx.dev/enterprise).
Both approaches use the same tag-based constraint system described below.
@@ -103,7 +103,7 @@ Once you have tagged your projects, configure the dependency constraints based o
For JavaScript/TypeScript projects, configure the `@nx/enforce-module-boundaries` ESLint rule:
```shell {% frame="none" %}
```shell
nx add @nx/eslint-plugin @nx/devkit
```
@@ -201,7 +201,7 @@ Read more about [ESLint rule options](/docs/technologies/eslint/eslint-plugin/gu
For any project type or to enforce boundaries on the complete dependency graph, use the Conformance plugin:
```shell {% frame="none" %}
```shell
nx add @nx/conformance
```
@@ -243,7 +243,7 @@ Run conformance checks in CI:
run: npx nx conformance:check
```
Learn more about [Conformance rules](/docs/enterprise/powerpack/conformance).
Learn more about [Conformance rules](/docs/enterprise/conformance).
@@ -43,7 +43,7 @@ These are some of the available tools which the Nx MCP server exposes:
To configure Nx for AI agents and AI-Assistants, run the following command:
```shell {% frame="none" %}
```shell
npx nx configure-ai-agents
```
@@ -79,7 +79,7 @@ For other MCP-compatible clients (that do not have Nx Console available) like Cl
Here's an example of how to register it for Claude Code:
```shell {% frame="none" %}
```shell
claude mcp add nx-mcp npx nx-mcp@latest
```
@@ -91,7 +91,7 @@ claude mcp add nx-mcp npx nx-mcp@latest
Ask your AI assistant about your workspace structure and get detailed, accurate responses about projects, their types, and relationships:
```
```text
What is the structure of this workspace?
How are the projects organized?
```
@@ -107,7 +107,7 @@ With Nx MCP, your AI assistant can:
You can also get informed suggestions about where to implement new functionality:
```
```text
Where should I implement a feature for adding products to cart?
```
@@ -140,7 +140,7 @@ Learn more about CI integration in our blog post [Save Time: Connecting Your Edi
Nx generators provide predictable code scaffolding, while AI adds intelligence and contextual understanding. Instead of having the AI generate everything from scratch, you get the best of both worlds:
```
```text
Create a new React library into the packages/orders/feat-cancel-orders folder
and call the library with the same name of the folder structure. Afterwards,
also connect it to the main shop application.
@@ -163,7 +163,7 @@ This approach ensures consistent code that follows your organization's best prac
Get accurate guidance on Nx configuration without worrying about hallucinations or outdated information:
```
```text
Can you configure Nx release for the packages of this workspace?
Update nx.json with the necessary configuration using conventional commits
as the versioning strategy.
@@ -184,7 +184,7 @@ Learn more about documentation-aware configuration in our blog post [Making Curs
Understand the impact of changes across your monorepo with questions like:
```
```text
If I change the public API of feat-product-detail, which other projects
@@ -282,7 +282,7 @@ It always stays up to date without having to actively maintain a document as it
To launch the project graph visualization for your workspace, use [Nx Console](/docs/getting-started/editor-setup) or run:
```shell {% frame="none" %}
```shell
npx nx graph
```
@@ -545,7 +545,7 @@ Try playing around with a [fully interactive graph on a sample repo](https://nrw
If you prefer to analyze the underlying data of the project graph with a script or some other tool, you can run:
```shell {% frame="none" %}
```shell
nx graph --file=output.json
```
@@ -566,7 +566,7 @@ Some moments which you may want to share these images are:
Nx uses the project graph of your workspace to determine the order in which to [run tasks](/docs/features/run-tasks). Pass the `--graph` flag to view the **task graph** which is executed by Nx when running a command.
```shell {% frame="none" %}
```shell
nx build myreactapp --graph # View the graph for building myreactapp
nx run-many --targets build --graph # View the graph for building all projects
nx affected --targets build --graph # View the graph for building the affected projects
@@ -14,7 +14,7 @@ Nx provides a set of tools to help you manage your releases called `nx release`.
> We recommend always starting with --dry-run, because publishing is difficult to undo
```shell {% frame="none" %}
```shell
nx release --dry-run
```
@@ -34,12 +34,12 @@ By default, when you run `nx release` it will prompt you for a version keyword (
When trying it out for the first time, you need to pass the `--first-release` flag since there is no previous release to compare against for changelog purposes. It is strongly recommended to use the `--dry-run` flag to see what will be published in the first release without actually pushing anything to the registry.
By default, the version follows semantic versioning (semver) rules. To disable this behavior, set `release.releaseTagPatternRequireSemver` to `false` in your `nx.json` file. This allows you to use custom versioning schemes.
By default, the version follows semantic versioning (semver) rules. To disable this behavior, set `release.releaseTag.requireSemver` to `false` in your `nx.json` file. This allows you to use custom versioning schemes.
{% /aside %}
## Set Up Your Workspace
@@ -75,73 +75,18 @@ See the [configuration reference](/docs/reference/nx-json#release) for all avail
## Using the Programmatic API for Nx Release
For maximum control, use the programmatic API to create custom release workflows:
A powerful feature of Nx Release is the fact that it is designed to be used via a Node.js programmatic API in addition to the `nx release` CLI.
```ts
// tools/scripts/release.ts
import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';
import * as yargs from 'yargs';
Releases are a hugely complex and nuanced process, filled with many special cases and idiosyncratic preferences, and it is impossible for a CLI to be able to support all of them out of the box. By having a first-class programmatic API, you can go beyond the CLI and create custom release workflows that are highly dynamic and tailored to your specific needs.
(async () => {
const options = await yargs
.version(false) // don't use the default meaning of version in yargs
.option('version', {
description:
'Explicit version specifier to use, if overriding conventional commits',
type: 'string',
})
.option('dryRun', {
alias: 'd',
description:
'Whether or not to perform a dry-run of the release process, defaults to true',
type: 'boolean',
default: true,
})
.option('verbose', {
description:
'Whether or not to enable verbose logging, defaults to false',
@@ -38,14 +38,14 @@ Please verify closely that you have the following setup:
Clone your repository to your local machine:
```shell {% frame="none" %}
```shell
git clone <your-repository-url>
cd <your-repository-name>
```
Install dependencies:
```shell {% frame="none" %}
```shell
npm install
```
@@ -84,7 +84,7 @@ Now, let's build some features and see how Nx helps get us to production faster.
To serve your new Angular app, run:
```shell {% frame="none" %}
```shell
npx nx serve angular-demo
```
@@ -151,7 +151,7 @@ The most critical parts are:
To view all tasks for a project, look in the [Nx Console](/docs/getting-started/editor-setup) project detail view or run:
```shell {% frame="none" %}
```shell
npx nx show project angular-demo
```
@@ -256,7 +256,7 @@ Nx allows you to separate this logic into "local libraries." The main benefits i
Let's create a reusable design system library called `ui` that we can use across our workspace. This library will contain reusable components such as buttons, inputs, and other UI elements.
```shell {% frame="none" %}
```shell
npx nx g @nx/angular:library packages/ui --unitTestRunner=vitest
```
@@ -281,13 +281,13 @@ Running the above command should lead to the following directory structure:
Just as with the `angular-demo` app, Nx automatically infers the tasks for the `ui` library from its configuration files. You can view them by running:
```shell {% frame="none" %}
```shell
npx nx show project ui
```
In this case, we have the `lint` and `test` tasks available, among other inferred tasks.
```shell {% frame="none" %}
```shell
npx nx lint ui
npx nx test ui
```
@@ -433,7 +433,7 @@ Nx automatically detects the dependencies between the various parts of your work
Just run:
```shell {% frame="none" %}
```shell
npx nx graph
```
@@ -475,7 +475,7 @@ You should be able to see something similar to the following in your browser.
Let's create a git branch with the new hero component so we can open a pull request later:
Our current setup not only has targets for serving and building the Angular application, but also has targets for unit testing, e2e testing and linting. The `test` and `lint` targets are defined in the application `project.json` file. We can use the same syntax as before to run these tasks:
```shell {% frame="none" %}
```shell
npx nx test angular-demo # runs the tests for angular-demo
npx nx lint ui # runs the linter on ui
```
More conveniently, we can also run tasks in parallel using the following syntax:
```shell {% frame="none" %}
```shell
npx nx run-many -t test lint
```
@@ -533,7 +533,7 @@ In this section, we'll explore how Nx Cloud can help your pull request get to gr
The `npx nx fix-ci` command that is already included in your GitHub Actions workflow (`github/workflows/ci.yml`) is responsible for enabling self-healing CI and will automatically suggest fixes to your failing tasks.
```yaml {32,33}
```yaml {% meta="{32,33}" %}
# .github/workflows/ci.yml
name: CI
@@ -575,7 +575,7 @@ You will also need to install the [Nx Console](/docs/getting-started/editor-setu
Now, let's push the `add-hero-component` branch to GitHub and open a new pull request.
```shell {% frame="none" %}
```shell
git push origin add-hero-component
# Don't forget to open a pull request on GitHub
```
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.
Jack Hsu
