Add PluginCache<T> class with explicit get/set API that tracks access
order for LRU eviction. Dedup and capping happen at write time, not
per-access. All plugin cache writes are now wrapped in try/catch so
failures never crash the project graph calculation.
Migrated consumers: cypress, playwright, dotnet, gradle (v1+v2),
maven, package-json, js/lockfile, nx-deps-cache.
## Current Behavior
The Nx native module (Rust cdylib loaded by Node.js) uses the system
allocator. The daemon process retains a large RSS footprint after the
initial project graph build, even though most of that memory is no
longer in use. On macOS and Linux, the system allocator doesn't
aggressively return freed pages to the OS.
## Expected Behavior
The daemon's steady-state RSS drops significantly after graph build by
using jemalloc with tuned page purge timers. Peak RSS and wall time are
unaffected.
## Changes
Adds [tikv-jemallocator](https://github.com/tikv/jemallocator) as the
global allocator on Linux and macOS, with two compile-time settings:
- **`dirty_decay_ms:1000`** — returns freed pages to the OS after 1s
instead of the default 10s. Tuned to Nx's phase-separated workload
(graph build → idle → task execution), where transitions happen every
~30-60s. Benchmarked against 5s and 10s — both too slow to purge between
phases.
- **`muzzy_decay_ms:0`** — skips the lazy purge phase (`MADV_FREE`) and
goes straight to `MADV_DONTNEED`. Required on macOS and Linux ≥ 4.5
where `MADV_FREE` doesn't actually reduce RSS.
Windows and WASI continue using the system allocator. Windows is
excluded because `tikv-jemalloc-sys` fails to build with MSVC (spaces in
`cl.exe` path break the autoconf configure script). Tracked upstream in
[tikv/jemallocator#99](https://github.com/tikv/jemallocator/pull/99).
### Other Settings Considered
Tested narenas reduction, tcache_max, extent fit tuning, background
threads, and decay timer values. Only the decay timer configuration
improved steady-state RSS without wall time regression.
closed#32190
## Current Behavior
eslint crashes when tsconfig.base.json path includes a * and you have an
import going to that project
## Expected Behavior
The plugin shouldn't crash and it should auto fix to a working import
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/issues/32190Fixes#32190
## Current Behavior
The `replace-removed-matcher-aliases` migration uses `tsquery.replace()`
which reprints the entire AST through TypeScript's Printer. This causes
two problems:
1. **Syntax corruption**: Valid TypeScript files are mangled:
- Destructuring patterns: `{ result }` becomes `{result}:`
- Arrow functions: missing opening braces
- Nested callbacks: collapsed/merged code blocks
2. **Unnecessary file changes**: Every test file is written back to disk
even when no matchers are replaced. This triggers `formatFiles()` to
reformat unchanged files, creating large whitespace-only diffs. In large
codebases, this can result in hundreds or thousands of files being
modified unnecessarily, making the migration PR difficult to review.
**Why I care a Lot**
I was running this on a multi-million-LOC monorepo and ran into two
issues:
* I got ~10k modified files with whitespace-only changes from the
removal of newlines. These changes couldn't be fixed with Prettier
because it didn't care about the number of newlines, so the diff was
unmergeable.
* I got ~8 files with malformed Typescript, causing commit hooks, CI,
etc. to fail without manual intervention.
## Expected Behavior
The migration should:
1. Only replace the deprecated matcher names (e.g., `toBeCalled` →
`toHaveBeenCalled`)
2. Preserve all surrounding code exactly as written
5. Only touch files that actually contain deprecated matchers
## Solution
Replace AST-reprinting with surgical text replacement:
- Use `tsquery.query()` to find matching AST nodes
- Collect text positions (start/end) for each node to replace
- Apply replacements in reverse order using string slicing
- Only write files that actually changed
This pattern is already used successfully in other Nx migrations (e.g.,
`rename-cy-exec-code-property.ts` in the Cypress package).
**Additional improvements:**
- Single AST parse with regex selector vs. 11 separate passes
- Quick string check skips parsing files without deprecated matchers
- New regression test covers complex patterns that triggered corruption
## Related Issue(s)
Fixes#32062
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Current Behavior
E2E tests may timeout without clear error messages, making it difficult
to diagnose test failures.
## Expected Behavior
E2E test utilities should provide better timeout handling and logging to
help diagnose test failures.
## Changes
- Add timeout handling to e2e test utilities (`runCLI` and
`runLernaCLI`)
- Add command logging to track execution time
- Improve timeout error messages with process output
- Bump cache bust value
## Related Issue(s)
CI stability and debugging improvements
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`@nx/eslint` relies on ESLint internals that changed in ESLint v10
(`use-at-your-own-risk`), which causes failures.
It looks like https://github.com/nrwl/nx/pull/24632 originally attempted
to use `loadESLint()` which would've been forward compatible with v10,
but it was later removed in https://github.com/nrwl/nx/pull/27404 in
favor of the `use-at-your-own-risk` import.
## Expected Behavior
`@nx/eslint` supports ESLint v10.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#34415
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
If you specify both the `all` and `initialRun` options when running `nx
watch`, `initialRun` have no effect.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The command should be called once at the beginning even if there are no
file changes.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32281
## Current Behavior
nx-maven-plugin 0.0.12 is also changing the base directory along with
the pom file when the plugins like flatten-maven-plugin /
maven-shade-plugin produces pomFile in different directory other than
the base directory
## Expected Behavior
plugin should only update the pom file and not the base directory
location
## Related Issue(s)
Fixes#34181https://github.com/mojohaus/flatten-maven-plugin/issues/50
Co-authored-by: anurag.ag <anuragagarwal561994@users.noreply.github.com>
## Current Behavior
Technology introduction pages have inconsistent or missing version
requirements information. Some pages have no Requirements section,
others use ad-hoc formats (asides, bullet lists under Prerequisites),
and page titles follow different naming conventions ("Overview of the Nx
X Plugin", "Nx X Plugin Overview", "Introduction - X", etc.).
## Expected Behavior
Every technology introduction page now has a standardized Requirements
section with:
- A version support table using consistent semver range format
- Code-formatted package names in the `Package` column
- An intro sentence identifying the Nx plugin (e.g. "The `@nx/react`
plugin supports the following package versions.")
- A note linking to [code generation docs](/docs/features/generate-code)
for auto-installed packages
- Consistent **"X Plugin for Nx"** page title pattern across all intro
pages
Additional changes:
- Deleted the standalone Node.js/TypeScript compatibility page, inlining
its content into the respective plugin intro pages
- Created a proper introduction page for Angular Rsbuild (previously
linked directly to `createConfig` API reference)
- Added Requirements tables to Java, Gradle, and Maven pages with system
dependency versions
- Updated sidebar links and redirects for removed/moved pages
- Applied style guide fixes across all edited pages (removed "allows you
to", "easily", product possessives, etc.)
## Related Issue(s)
Fixes DOC-423
## Current Behavior
After #34580, `determineNxCloudV2()` returns `'skip'` in non-interactive
mode, but the caller remaps it to `nxCloud = 'yes'` with
`skipCloudConnect = true`. This causes `setupCI()` to run and generate
`.github/workflows/ci.yml` in new workspaces — which didn't happen
before.
This breaks the `extras.test.ts` e2e snapshot test because
`.github/workflows/ci.yml` now appears in the expanded default task
inputs.
## Expected Behavior
Keep `nxCloud = 'skip'` when the cloud choice is `'skip'`, which
prevents CI file generation in non-interactive mode. This restores the
behavior prior to #34580.
## Related Issue(s)
Fixes the `extras.test.ts` e2e snapshot failure introduced by #34580.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump project graph plugin version.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Current Behavior
`build_glob_set` recompiles identical glob pattern sets on every call,
even when the same set of patterns has been compiled before.
## Expected Behavior
Compiled `NxGlobSet` instances are cached in a static `DashMap` keyed by
sorted glob strings. Repeated calls with the same patterns return a
shared `Arc<NxGlobSet>` instead of recompiling. Profiling `nx run-many
-t build lint test --parallel 8` in the Nx repo measured 95.6% cache hit
rate (9,758 of 10,202 calls) with only 444 unique pattern sets, reducing
hashing-phase CPU by ~40%.
## Current Behavior
All 1,200+ redirect rules are processed by the Next.js serverless
function via the `redirects()` config in `next.config.js`. Every
redirect request requires a cold start of the serverless function, which
contributed to the 10-minute outage reported in DOC-415.
## Expected Behavior
Redirects are handled at the Netlify CDN edge via a plain `_redirects`
file, which is faster and doesn't depend on the Next.js serverless
function being healthy.
- Converted all redirect rules from `redirect-rules.js` and
`redirect-rules-docs-to-astro.js` into Netlify `_redirects` format
(1,231 rules)
- Expanded Next.js regex group patterns (e.g. `/(l|latest)/...`) into
individual Netlify rules since Netlify doesn't support regex
- Converted `:path*` wildcards to Netlify `*`/`:splat` syntax
- Rewrites (Astro docs proxy) remain in `next.config.js` as they require
server-side processing
- Original JS redirect files kept for reference (can be removed in
follow-up)
## Related Issue(s)
Fixes DOC-415
## Current Behavior
`TargetProjectLocator.findProjectFromImport` stores `null` for
unresolved imports using a bare `importExpr` key, but
`findNpmProjectFromImport` looks up cache entries using
`${packageName}__${dirPath}`. The key mismatch means repeated lookups
for the same import+directory re-run the full resolution waterfall
(typescript + require.resolve) instead of returning the cached `null`.
## Expected Behavior
Store `null` for unresolved imports using the same
`${packageName}__${dirPath}` key that `findNpmProjectFromImport` uses
for lookups. Repeated lookups for already-failed imports skip the
expensive resolution steps.
Also removes an unused cache write for builtin module imports as a minor
cleanup.
## Current Behavior
After migrating from chalk to picocolors (#34305), `FORCE_COLOR=0` no
longer disables colors. picocolors checks `!!env.FORCE_COLOR`, and since
`!!"0"` is `true` in JavaScript, it treats `FORCE_COLOR=0` as "enable
colors."
This breaks CI environments and tools like Homebrew that set
`FORCE_COLOR=0` to get plain text output.
## Expected Behavior
`FORCE_COLOR=0` should disable ANSI color output, matching the previous
chalk behavior and the [FORCE_COLOR spec](https://force-color.org/).
## Related Issue(s)
Fixes#34387
Upstream issue filed:
https://github.com/alexeyraspopov/picocolors/issues/100
## Current Behavior
When processing Gradle tasks, Nx tracks dependent task output files by
recording individual file paths for each output. This can lead to
incorrect cache invalidation behavior since we are prefixing the paths
unnecessarily. We will therefore never match.
## Expected Behavior
Nx now consolidates dependent task output files using glob patterns
based on file extensions (e.g., **/*.jar, **/*.class). This focuses on
the types of files produced rather than their specific paths. The
approach groups all output files by extension and generates a single
glob pattern per extension, reducing the complexity of input tracking
while maintaining correctness.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #Q-247
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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
-->
The dependsOn of atomized tasks should match the base non-atomized task.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes Q-174
## Current Behavior
The CNW cloud prompt is locked to auto-select deferred connection
(CLOUD-4255), always generating a short URL but never writing nxCloudId
to nx.json. Users have no explicit choice.
## Expected Behavior
The cloud prompt now offers three explicit choices:
- Yes: connect now, generate nxCloudId in nx.json, show strong
completion message
- Skip for now: deferred connection (no nxCloudId), still show short URL
and update README
- No: full opt-out, set neverConnectToCloud: true in nx.json, no URL, no
README update, no cloud messaging
**CLI args:** `--nxCloud=skip`, `--nxCloud=never` (new),
`--nxCloud=yes`. Non-interactive defaults to skip.
Closes CLOUD-4242
## Current Behavior
PR #34523 fixed the macOS file watcher issue (#34522) but did not
include comprehensive test coverage.
## Expected Behavior
Tests should verify that the fix works correctly and catch any future
regressions.
## Related Issue(s)
Adds test coverage for #34523 and #34522
---
## Changes
**TypeScript integration test**
(`packages/nx/src/native/tests/watcher.spec.ts`):
Added **"should detect file changes in large directory structures"** - a
comprehensive integration test that:
1. Creates 10,000+ directories simulating a monorepo-scale workspace
2. Starts a real `Watcher` instance
3. Creates and modifies files deep in the directory tree
4. Verifies that file change events are actually delivered
This test validates the actual behavior users care about - that file
watching works reliably in large repos - rather than testing
implementation details. It would catch any regression where events fail
to be delivered at scale.
## Testing
TypeScript integration test validates the actual bug fix - that file
events are delivered reliably in large directory structures with 10,000+
directories.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Given the following Vite config:
```ts
import { defineConfig } from 'vite';
export default defineConfig((config) => {
console.log(config);
return {};
});
```
`npx nx preview` logs:
```ts
{
mode: 'development',
command: 'build',
isSsrBuild: false,
isPreview: false
}
```
## Expected Behavior
`npx nx preview` should log:
```ts
{
mode: 'development',
command: 'build',
isSsrBuild: false,
isPreview: true
}
```
## Related Issue(s)
https://github.com/vitejs/vite/issues/15694
Fixes #
## Current Behavior
`BatchProcess` accumulates all stdout/stderr output in
`terminalOutputChunks` and exposes it via `getTerminalOutput()`, but
nothing ever calls `getTerminalOutput()`. The accumulated strings are
unique allocations (created via `chunk.toString()`), not shared with the
output callbacks or `process.stdout.write`.
For verbose batched tasks (e.g., Maven/Gradle with hundreds of tasks),
this can hold tens to hundreds of MB for the entire batch duration.
## Expected Behavior
Remove the dead accumulation code. stdout/stderr chunks are still
forwarded to `process.stdout`/`process.stderr` and output callbacks as
before — only the unused storage is removed.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When generating a library with vitest as the test runner and a non-vite
bundler (e.g. `tsc`), the js library generator creates two config files:
- `vitest.config.mts` (from the vitest `configurationGenerator`) with
`root: __dirname`
- `vite.config.ts` (from a second `createOrEditViteConfig` call) with
`root: import.meta.dirname`
The redundant `vite.config.ts` uses ESM-only `import.meta.dirname`
syntax, which causes TS1470 when the project targets CommonJS output:
```
vite.config.ts:5:9 - error TS1470: The 'import.meta' meta-property is not allowed in files which will build into CommonJS output.
5 root: import.meta.dirname,
~~~~~~~~~~~
```
## Expected Behavior
Only `vitest.config.mts` should be generated. The vitest
`configurationGenerator` already handles creating the correct config
file with `root: __dirname`. The second `createOrEditViteConfig` call
from `@nx/vite` was redundant and produced the conflicting file.
## Related Issue(s)
Fixes#34399
## Current Behavior
Since Nx 22.5.0, the daemon's native file watcher silently drops all
file change events on macOS in large monorepos (~5,250+ watched
directories). `nx watch`, `nx serve`, and any daemon-dependent file
watching is broken.
The root cause is that #34329 switched all watched paths to
`WatchedPath::non_recursive()`. On macOS, the `notify` crate uses
**kqueue** for non-recursive watches instead of **FSEvents**. kqueue
silently fails at scale due to vnode table pressure (`kern.num_vnodes ==
kern.maxvnodes`), causing the daemon to never detect file changes.
This is a **scale-dependent** bug: it works fine in small workspaces
(~30 directories) but breaks silently in large ones.
| | **Nx 22.4.5** | **Nx 22.5.0+** |
|---|---|---|
| **Small repo (~30 dirs)** | Works (FSEvents) | Works (~30 kqueue
watches) |
| **Large repo (~5,250+ dirs)** | Works (FSEvents) | **Broken** (kqueue
silently drops all events) |
## Expected Behavior
The macOS file watcher should detect file creates, modifications, and
deletions at any scale, matching the behavior of Nx 22.4.x.
## Fix
Use platform-conditional watch modes:
- **macOS:** Single recursive watch on the workspace root (uses FSEvents
natively)
- **Linux/Windows:** Non-recursive per-directory watches (preserves the
#33781 inotify fix)
On macOS, FSEvents handles recursive watching from a single root path,
so directory enumeration and dynamic registration are skipped entirely.
This also improves daemon startup time on macOS from ~10 minutes to <1
second in a 354-project monorepo.
### What changed in `watcher.rs`
1. **Initial pathset:** On macOS, watch only the root directory
recursively via FSEvents instead of enumerating all directories for
non-recursive kqueue watches.
2. **Dynamic directory registration (`on_action`):** Wrapped in
`#[cfg(not(target_os = "macos"))]` since FSEvents already watches the
full tree.
Linux/Windows behavior is completely unchanged.
### Why the event filter is fine as-is
We verified that with recursive FSEvents watches, macOS emits specific
`FileEventKind` variants (`Create(File)`, `Modify(Data(Content))`,
`Remove(File)`, `Modify(Name(Any))`) that the current
`watch_filterer.rs` already handles correctly. Zero events were rejected
by the catch-all. The `Modify(Any)` / `Create(Any)` variants are kqueue
artifacts that are not needed with FSEvents.
### Why kqueue fails silently
Apple's [File System Events Programming
Guide](https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/FSEvents_ProgGuide/KernelQueues/KernelQueues.html)
explicitly recommends FSEvents over kqueue for large hierarchies: *"If
you are monitoring a large hierarchy of content, you should use file
system events instead."* kqueue requires `open(path, O_EVTONLY)` per
watched directory. Under vnode table pressure, the kernel recycles
vnodes with kqueue watches attached without notifying the watcher. There
is no error, no partial delivery, and no diagnostic signal.
## Tested on
- macOS 26.3 (Tahoe), Apple Silicon (arm64), APFS
- 354-project pnpm monorepo (~19,865 non-ignored directories)
- Verified: file modifications, file creates, and file deletes all
detected
- Daemon init time: ~10 min (with enumeration) -> <1s (with root-only
FSEvents watch)
## Related Issue(s)
Fixes#34522
Co-authored-by: Amp <amp@ampcode.com>
## Current Behavior
When nx release runs with docker-configured projects (either via
explicit config or
@nx/docker plugin inference), git tags are created with the literal
string {version}
instead of the actual version number (e.g., v{version} instead of
v1.0.6, or
app-3@{version} instead of app-3@1.0.0).
This happens because:
1. If ANY project in a release group has docker config,
preferDockerVersion is auto-set to
true for the ENTIRE group
2. createGitTagValues() then blindly selects
projectVersionData.dockerVersion, which is
null for non-docker projects (or projects with no changes)
3. The interpolate() function receives null for {version} and returns
the literal
placeholder unchanged
Commit messages are unaffected because createCommitMessageValues() only
uses newVersion and
already guards against null. The changelog code (changelog.ts:1117-1121)
also already has
the correct null-safe pattern.
## Expected Behavior
When preferDockerVersion is true but dockerVersion is null, git tags
should fall back to
using newVersion instead of producing literal {version} placeholders.
When both versions
are null, no tag should be created.
For mixed release groups (some projects have docker config, some don't),
the auto-enable
logic should use 'both' mode instead of true, which already has proper
null-safe checks for
each version type.
## Changes
- shared.ts: Added null-safe fallback (??) in createGitTagValues() for
both independent and
fixed group code paths, plus a guard to skip tag creation when both
versions are null
- config.ts: Refined auto-enable logic to check whether ALL or only SOME
projects have
docker config — mixed groups now get 'both' mode instead of true
- shared.spec.ts: Added 5 test cases covering null version fallback
scenarios for fixed
groups, independent groups, both-null, reverse fallback, and mixed
groups
## Related Issue(s)
Fixes#34382Fixes#33890Fixes#34391
## Current Behavior
The "7. Thriving Community" section on
`nx.dev/docs/guides/adopting-nx/from-turborepo` displayed an outdated Nx
download statistic (~5 million downloads per week).
## Expected Behavior
The "7. Thriving Community" section on
`nx.dev/docs/guides/adopting-nx/from-turborepo` now reflects the latest
Nx download statistic (~9 million downloads per week).
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
When we optimized the `process.env` values to not embed the full object
unnecessarily, we also regressed in cases where users do use
`process.env` instead of `process.env["NX_PUBLIC_FOO"]`.
## Current behavior
Users cannot use `process.env` and must access each key individuall.
Although the serializing the full object can bloat bundle sizes, we also
don't want to break existing apps unnecessarily.
## Expected behavior
Existing apps should continue to work as usual.
## Related issues
Fixes#34279
## Current Behavior
When running `@nx/js:prune-lockfile` on a monorepo with transitive
dependencies that have multiple versions where neither version is
reachable from a direct dependency in package.json, the executor throws:
```
NX An error occurred while creating pruned lockfile
Original error: Cannot read properties of undefined (reading 'name')
TypeError: Cannot read properties of undefined (reading 'name')
at switchNodeToHoisted (node_modules/nx/src/plugins/js/lock-file/project-graph-pruning.js:165:31)
```
## Expected Behavior
The lockfile pruning should complete without crashing, even when some
transitive dependencies cannot be traced back to a direct dependency.
## Root Cause
In `rehoistNodes()`, when there are multiple nested nodes for a package,
the code finds the "closest" node by computing `pathLengthToIncoming()`
for each. However, when none of the nested nodes have a path to any
direct dependency in package.json, `pathLengthToIncoming()` returns
`undefined` for all of them. Since `undefined < Infinity` is `false` in
JavaScript, `closest` remains `undefined`, and then
`switchNodeToHoisted(undefined, ...)` crashes.
## Fix
Add a guard to only call `switchNodeToHoisted()` when a closest node was
actually found:
```typescript
if (closest) {
switchNodeToHoisted(closest, builder, invBuilder);
}
```
This allows the pruning to continue - the nested nodes simply won't be
rehoisted if no closest node can be determined.
## Related Issue
Fixes#34322
## Test Added
Added a unit test that verifies `rehoistNodes()` doesn't crash when
nested nodes have no path to package.json dependencies.
## Current Behavior
When importing a `package.json` file in an Angular application built
with `@nx/angular-rspack`, the build fails with a Babel syntax error if
the `package.json` contains `@angular/*` dependencies:
```
SyntaxError: /path/to/package.json: Missing semicolon. (2:10)
1 | {
> 2 | "name": "@org/app",
| ^
3 | "version": "4.0.2",
4 | "dependencies": {
5 | "@angular/platform-browser": "20.3.7",
```
This happens because the `JS_ALL_EXT_REGEX` pattern
`/\.[cm]?(js)[^x]?\??/` incorrectly matches `.json` files. When the JSON
file content contains `@angular` strings, the
`angular-partial-transform-loader` attempts to process it through Babel,
which fails because JSON is not valid JavaScript.
**Root cause:** The regex `[^x]?` (optional character that is NOT 'x')
allows `.json` to match because 'o' is not 'x'.
## Expected Behavior
- `.json` files should NOT match `JS_ALL_EXT_REGEX` or
`TS_ALL_EXT_REGEX`
- Importing `package.json` in Angular applications should work correctly
- All existing matches for `.js`, `.jsx`, `.mjs`, `.cjs` (and TypeScript
equivalents) should continue to work
## Related Issue(s)
https://github.com/nrwl/nx/issues/32649
## Current Behavior
Documentation bugfix on
https://nx.dev/docs/concepts/typescript-project-linking#set-up-typescript-project-references
In the section about setting up TypeScript project references, the
documentation currently states:
"Each project's tsconfig.lib.json file extends the project's
tsconfig.json file and adds references to the tsconfig.lib.json files of
project dependencies."
## Expected Behavior
In a standard Nx workspace configuration, tsconfig.lib.json extends the
workspace-level tsconfig.base.json, not the project-level tsconfig.json
(and the example provided just after is correct).
Suggested correction:
"Each project's tsconfig.lib.json file extends the workspace
tsconfig.base.json file and adds references to the tsconfig.lib.json
files of project dependencies."
## Related Issue(s)
Fixes #34118
---------
Co-authored-by: Aude Planchamp <aude.planchamp@ekino.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
When a plugin worker process exits unexpectedly, the exit handler
previously sent synthetic `loadResult` messages to all pending response
handlers. If any handler was waiting for a different result type (e.g.
`createNodesResult`), the type validation would reject with a confusing
"Expected createNodesResult, got loadResult" error instead of surfacing
the actual cause.
Split response handlers into `onMessage` / `onError` callbacks so the
exit handler can reject each pending promise directly with a clear
"Plugin worker exited unexpectedly" error.
Also use unique transaction IDs for `load` messages (via `generateTxId`)
to avoid potential handler overwrites during worker restarts.
Fixes#34564
## Summary
Testing CI behavior with continuous assignment disabled and cache bust
set to 4.
This is part of investigating flakiness potentially related to
continuous assignment in CI.
## Test plan
- Monitor CI execution behavior
- Compare with other test branches (bust=2, bust=3)
## Current Behavior
Documentation pages across Getting Started, How Nx Works, and Platform
Features sections contain:
1. Duplicated content — mental-model.mdoc has a ~70-line caching section
and a ~20-line DTE section that are near-verbatim
copies of how-caching-works.mdoc and distribute-task-execution.mdoc
respectively. remote-cache.mdoc re-explains local caching
in its intro instead of linking to the canonical page.
2. Missing cross-reference links — Key concepts like "affected command",
"remote cache", "project graph", and "task pipeline
configuration" are mentioned without linking to their dedicated pages.
3. Style guide violations — Trust-undermining words ("simply", "just",
"straightforward"), anti-AI phrases ("Let's take",
"Whether you're..."), product possessives ("Nx's"), customer perspective
issues ("allows you to"), and em dashes appear
across Getting Started and How Nx Works pages.
## Expected Behavior
1. Content consolidation — mental-model.mdoc is trimmed by ~85 lines,
keeping the concept + images and linking to dedicated
pages for details. remote-cache.mdoc intro references the canonical
caching page. publish-conformance-rules-to-nx-cloud.mdoc
deduplicates its intro. maintain-typescript-monorepos.mdoc shortens its
inferred tasks re-explanation.
2. Cross-reference links added — First-mention links for affected,
remote cache, computation caching, task pipeline
configuration (in mental-model) and project graph (in self-healing-ci).
3. Style guide compliance — 18 fixes across 10 Getting Started and How
Nx Works pages, removing banned phrases and aligning
with the new STYLE_GUIDE.md.
4. Sidebar improvements — Cache Task Results added after Run Tasks in
Platform Features; Maintain TypeScript Monorepos moved
to first in KB > TypeScript.
## Pages changed
```
┌─────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Section │ Pages │
├─────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Getting Started │ intro, index, nx-cloud, ai-setup, start-with-existing-project │
├─────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ How Nx Works │ mental-model, how-caching-works, task-pipeline-configuration, nx-plugins, nx-daemon │
├─────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Features │ remote-cache, self-healing-ci, maintain-typescript-monorepos, cache-task-results (sidebar only) │
├─────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Enterprise │ publish-conformance-rules-to-nx-cloud │
└─────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────┘
```
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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. Continuous tasks missing from `postTasksExecution` hook
When running continuous tasks (e.g., `nx serve app`) and stopping them
with Ctrl+C, the `postTasksExecution` lifecycle hook does not include
them in `taskResults`. This breaks plugins that rely on post-run
statistics (e.g., uploading task stats to DataDog).
### 2. Confusing TUI status when sibling continuous task exits
When multiple continuous tasks run together and one exits unexpectedly,
its sibling is marked as "failed" even though it was intentionally
terminated/stopped by the task orchestrator.
## Expected Behavior
1. All tasks, including continuous ones, are included in `taskResults`
for the `postTasksExecution` hook
2. Continuous tasks that are intentionally stopped (because dependent
tasks completed or during graceful shutdown) report as `success` with
`Stopped` display status
3. Continuous tasks that exit unexpectedly (crash) report as `failure`
4. TUI summary shows correct status: success when all tasks completed
successfully, square icon for stopped tasks
## Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/33561
Supersedes:
- https://github.com/nrwl/nx/pull/33562
- https://github.com/nrwl/nx/pull/34132
Add NX_CLOUD_IO_TRACING_DIRECTORY environment variable.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 Q-245
## Current Behavior
No documentation exists explaining the concept of synthetic monorepos —
how they bridge polyrepo and monorepo setups by connecting separate
repositories into a unified dependency graph.
https://deploy-preview-34565--nx-docs.netlify.app/docs/concepts/synthetic-monorepos
## Expected Behavior
New concept page under "How Nx Works" that explains:
- What synthetic monorepos are (unified graph across separate repos
without moving code)
- Why they matter for humans (visibility, cross-repo coordination) and
AI agents (seeing beyond repo boundaries)
- What they provide (cross-repo graph, actionable tooling, AI agent
enablement)
- How they serve as a gradual entry point toward deeper monorepo
adoption
## Related Issue(s)
N/A — new documentation page based on existing content from webinars and
internal knowledge.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: juristr <juristr@users.noreply.github.com>
## Current Behavior
When users hit the `generatePackageJson: true` error with TS Solution
Setup, the error tells them to "unset the option" but gives no guidance
on the replacement workflow.
## Expected Behavior
The error message now includes a link to the pruning guide at
https://nx.dev/docs/technologies/node/guides/deploying-node-projects so
users can immediately find the migration steps.
## Related Issue(s)
Related #30146
When plugin isolation is off, concurrent createNodesV2 invocations share
the same module instance. The module-level mutable `cache` variable
caused
invocation A's `finally` block to null it out while invocation B was
still
reading from it, resulting in "Cannot read properties of null (reading
'configContexts')".
Replace the shared mutable `cache` with a Symbol-keyed Map so each
invocation gets its own isolated cache. The tsconfig disk cache is
shared
across invocations with an idempotent initialization guard.
CLOSES NXC-3971
## Summary
- Updated version of the classic "Misconceptions about Monorepos"
article
- New sections on AI compatibility, scaling strategies (affected,
caching, distribution, atomization), and `@nx/owners`
- Custom SVG diagrams for project graph illustrations (replacing old
Medium images)
- Authors: Victor Savkin, Juri Strumpflohner
## Test plan
- [ ] Verify blog post renders correctly on preview
- [ ] Check all images load (SVGs + avif)
- [ ] Verify internal doc links resolve
- [ ] Check TOC renders properly
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: juristr <juristr@users.noreply.github.com>
## Current Behavior
folks had to type in `nx-cloud apply-locally`
## Expected Behavior
now `nx apply-locally` works
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
### Current Behavior
nx list <plugin> shows generator/executor names and descriptions in text
format only. It does not show where the plugin or its
generators/executors are located on disk, and there is no
machine-readable output option.
### Expected Behavior
- nx list --json outputs all local and installed plugins with their
paths and capability types
- nx list <plugin> --json outputs detailed structured JSON including
resolved paths to each generator/executor implementation and schema
- nx list <plugin> (text mode) now also shows the plugin's root path
## Current Behavior
In TS Solution Setup, the esbuild executor forces `runTypeCheck` even
when `skipTypeCheck: true` and `declaration: false`, due to the `||
options.isTsSolutionSetup` condition in `esbuild.impl.ts` (lines 139-140
and 195).
When `declaration: false`, this type check runs in `noEmit` mode with
`ignoreDiagnostics: true` — making it **completely pointless** (no
declarations emitted, no diagnostics reported). Its only observable
effect is writing a poisoned 19-byte tsbuildinfo file that causes race
conditions with `tsc --build`.
## Expected Behavior
When `skipTypeCheck: true` and `declaration: false`, the esbuild
executor should not run type checking at all. The `isTsSolutionSetup`
override should only force type checking when declarations actually need
to be generated.
## Fix
### Primary: Skip unnecessary type check (`esbuild.impl.ts`)
```diff
// Non-watch mode (line 195)
- if (!options.skipTypeCheck || options.isTsSolutionSetup) {
+ if (!options.skipTypeCheck || (options.isTsSolutionSetup && options.declaration)) {
// Watch mode (lines 139-140)
- options.isTsSolutionSetup
+ (options.isTsSolutionSetup && options.declaration)
```
Only force type checking in TS Solution Setup when declarations need to
be generated. This eliminates the pointless type check entirely.
### Defense-in-depth: Prevent tsbuildinfo in `noEmit` mode
(`run-type-check.ts`)
```diff
- : { noEmit: true };
+ : { noEmit: true, composite: false };
```
Setting `composite: false` alongside `noEmit: true` prevents TypeScript
from writing tsbuildinfo files, protecting against this class of bug
from any caller of `runTypeCheck`.
## Why This is Safe
| Scenario | Before | After |
|----------|--------|-------|
| `skipTypeCheck: false`, `declaration: false`, `isTsSolutionSetup:
true` | Runs type check (noEmit) | Still runs (`!false \|\| ...` = true)
|
| `skipTypeCheck: false`, `declaration: true`, `isTsSolutionSetup: true`
| Runs type check (emitDeclarationOnly) | Still runs |
| `skipTypeCheck: true`, `declaration: true`, `isTsSolutionSetup: true`
| normalize.ts overrides skipTypeCheck to false; runs type check | Still
runs (same normalization) |
| **`skipTypeCheck: true`, `declaration: false`, `isTsSolutionSetup:
true`** | **Runs pointless type check (noEmit + ignoreDiagnostics),
writes poisoned tsbuildinfo** | **Skipped entirely** |
The only behavior change is in the last row — the case where the type
check was doing nothing useful but causing harm.
## Related Issue(s)
Fixes#34492
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Current Behavior
Users migrating to Nx 20's TS Solution Setup lose `generatePackageJson`
support and have no documentation on the replacement prune workflow
(`prune-lockfile`, `copy-workspace-modules`). The error message tells
them to "unset the option" but doesn't explain what to do instead.
## Expected Behavior
A dedicated guide at
`/docs/technologies/node/guides/deploying-node-projects` covers the full
prune workflow: when to use pruning vs bundling, target configuration,
Dockerfile setup, and step-by-step migration from `generatePackageJson`.
Also updated the existing bundling guide to match the same structure
(intro table, cross-links, style guide compliance). The two articles are
sister guides covering the two ways to deploy Node.js apps: bundle
everything into a single file, or prune dependencies for a
`node_modules`-based install.
Cross-links added from the bundling guide and ci-deployment guide.
## Related Issue(s)
Closes#30146
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
The `checkAllBranchesWhen` option is documented as type `string` with a
minimal description, which does not match the actual implementation.
## Expected Behavior
Document the correct type (`boolean | string[]`) and explain the default
branch resolution behavior, the three value modes (true, false,
string[]), and when this option is useful.
## Related Issue(s)
Closes DOC-414
---------
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
When multiple Nx processes (task hasher, daemon, workers) access the
SQLite database concurrently, the `NxDbConnection::transaction()` method
only retries the BEGIN step using the `retry_db_operation_when_busy!`
macro. Operations executed inside the transaction and the COMMIT are not
retried, so if the database is busy during those steps, the task crashes
with:
```
Error: DB transaction operation error: SqliteFailure(Error { code: DatabaseBusy, extended_code: 5 }, Some("database is locked"))
```
This is particularly common during parallel task hashing with continuous
tasks, where `TaskDetails.recordTaskDetails()` and `RunningTasksService`
compete for write access.
## Expected Behavior
The entire transaction (begin, execute, commit) is retried as a single
unit when any step encounters a `DatabaseBusy` error. If the database is
busy during the operation or commit, the transaction is automatically
rolled back (via drop) and retried with the same exponential backoff
used everywhere else.
## Related Issue(s)
<!-- No public issue linked -->
## Current Behavior
The NPM audit CI job is failing due to a critical XSS vulnerability
(CVE-2026-25896) in `fast-xml-parser` version 4.5.3.
## Expected Behavior
The NPM audit should pass with no critical vulnerabilities.
## Related Issue(s)
Fixes the failing NPM audit CI run:
https://github.com/nrwl/nx/actions/runs/22288455713
---
This PR upgrades `fast-xml-parser` from `^4.2.7` to `^5.3.7` to address
GHSA-m7jm-9gc2-mpf2, a critical XSS vulnerability that allows entity
encoding bypass via regex injection in DOCTYPE entity names.
The package is only used in
`scripts/documentation/internal-link-checker.ts` for parsing XML
sitemaps, so the risk of this upgrade is low.
## Current Behavior
Batch mode is binary:
- `--batch` flag → batch ALL executors that support it
- No flag → batch NOTHING
This means users of gradle/maven must always remember to pass `--batch`
to get the performance benefits.
## Expected Behavior
Plugin authors can now set `preferBatch: true` in their executor config
to indicate batch mode should be used by default. Users can still
opt-out with `--no-batch`.
Three states:
- `--batch` → batch everything
- `--no-batch` → batch nothing
- (not specified) → use each executor's `preferBatch` preference
| `--batch` flag | `preferBatch` | Result |
|----------------|---------------|--------|
| `true` | any | Batch |
| `false` | any | No batch |
| not set | `true` | Batch |
| not set | `false`/undefined | No batch |
## Changes
- Added `preferBatch?: boolean` to `ExecutorJsonEntryConfig` and
`ExecutorConfig` interfaces
- Updated `--batch` default from `false` to `undefined` to allow
`preferBatch` to decide
- Modified batch scheduling logic to respect `preferBatch`
- Enabled `preferBatch: true` for gradle and maven executors
- Added 5 unit tests covering all `preferBatch` scenarios
## Related Issue(s)
<!-- Link any related issues here -->
PR #30826 introduced a fallback definition for `process.env`:
```ts
{ 'process.env': '{}' }
```
Since `DefinePlugin` performs raw textual replacement, this can generate
invalid JavaScript when user code accesses environment variables via dot
notation:
```ts
process.env.SOME_KEY
```
becomes:
```js
{}.SOME_KEY
```
`{}` is parsed as a block statement (not an object literal), resulting
in:
> Unexpected token: punc (.)
This PR updates the fallback to a parenthesized object literal:
```ts
{ 'process.env': '({})' }
```
which produces valid output:
```js
({}).SOME_KEY
```
This preserves the intended bundle-size optimization while ensuring
syntactically correct output for standard `process.env.X` access
patterns.
## Related Issue(s)
Refs #30826Fixes#34460
//CC @Coly010 @coolassassin
## Current Behavior
`nx import` relies on interactive prompts (enquirer) and spinners (ora)
for user interaction. AI agents cannot parse this output or respond to
prompts, making `nx import` unusable in agent workflows.
## Expected Behavior
When `isAiAgent()` is true, `nx import` now:
- Skips all interactive prompts and spinners
- Emits NDJSON progress to stdout (`starting`, `cloning`, `filtering`,
`merging`, `detecting-plugins`, `complete`)
- Returns structured `needs_input` when required args are missing (all
at once to minimize round-trips)
- Returns structured `needs_input` for plugin selection when `--plugins`
flag is not provided
- Returns structured success/error results with hints and next steps
- Supports new `--plugins` flag (`skip`/`all`/comma-separated list)
Shared AI output types extracted from `init` into
`packages/nx/src/command-line/ai/ai-output.ts` for reuse across
commands.
## Current Behavior
Running `configure-ai-agents` overwrites the entire `source` object in
`extraKnownMarketplaces['nx-claude-plugins']`, removing any user-added
properties like `ref`.
## Expected Behavior
User-added source properties (e.g. `ref`) are preserved, while `source`
and `repo` are always set to the correct values.
The nx-welcome component inline styles were always using CSS/SCSS syntax
(with braces and semicolons) regardless of the selected style option.
When --style=sass is chosen, the component now correctly uses SASS
indented syntax (no braces or semicolons) matching the expected
behavior for the .sass file format.
Fixes#33489
## Current Behavior
When `configure-ai-agents` is invoked from within an AI agent (e.g.
Claude Code), it either shows an interactive multi-select prompt (which
the agent can't interact with) or requires `--agents` and
`--no-interactive` flags to work correctly. This makes the experience
awkward when AI agents call the command as part of workspace setup.
## Expected Behavior
When an AI agent is detected (via environment variables like
`CLAUDECODE`), the command now:
1. **Auto-configures the detected agent** if it's not yet configured,
partially configured, or outdated — no prompts needed
2. **Auto-updates any other outdated agents** alongside the detected one
3. **Reports non-configured agents** with a suggested `nx
configure-ai-agents --agents ...` command
4. **Reports up-to-date status** if the detected agent is already fully
configured
When `--agents` is explicitly passed, detection is ignored entirely
(existing behavior preserved). `--check` mode also works with detection
— it checks the detected agent plus all other configured agents.
Additionally:
- Strips AI agent detection env vars (`CLAUDECODE`, `CLAUDE_CODE`,
`OPENCODE`, `GEMINI_CLI`, etc.) from e2e subprocess environments to
prevent the test runner's environment from leaking into tests
- Fixes e2e tests to use `AGENTS.md` (not `GEMINI.md`) for gemini
assertions, matching what the gemini generator actually creates for
fresh installations
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
- Cypress `start-dev-server.ts` file creates a port lock file next to
the source code
- Native temp DB files created by tests are not properly ignored
- Astro config timestamp file is not ignored
These all trigger watch file change events, which cause the project
graph to be recomputed unnecessarily.
## Expected Behavior
Output files should not trigger watch file change events. The project
graph should not be recomputed unnecessarily.
## Current Behavior
Several Nx packages directly depend on a minimatch version with a
high-severity vulnerability
(https://github.com/advisories/GHSA-3ppc-4f35-3m26).
## Expected Behavior
Several Nx packages should depend directly on a minimatch version that
does not include the reported high-severity vulnerability.
Note: unsafe `minimatch` versions can still be pulled in transitively.
Upstream deps need to be updated, and then we need to update the Nx
packages to newer versions.
## Related Issue(s)
Fixes#34507
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
Users specifying directory paths in `inputs` without a trailing slash or
glob pattern find that files are not matched. For example,
`{projectRoot}/src` does not match any files, while `outputs` allows
naked directory paths without issue.
## Expected Behavior
Documentation clearly explains that directory paths in `inputs` require
a trailing slash or glob pattern:
```jsonc
{
"inputs": [
"{projectRoot}/src/", // ✓ Works (trailing slash)
"{projectRoot}/src/**/*", // ✓ Works (glob pattern)
"{projectRoot}/src" // ✗ Does NOT work
]
}
```
### Changes
- **Reference doc** (`reference/inputs.mdoc`): Added "Directory Paths"
section explaining the requirement with examples
- **Guide** (`configure-inputs.mdoc`): Added callout warning at top
alerting users to this behavior
- Both docs note the difference from `outputs`, which do support naked
directory paths
## Related Issue(s)
Fixes
https://linear.app/nxdev/issue/NXC-2102/clarify-trailing-slash-requirement-for-inputs-in-directory-paths
Co-authored-by: Steven Nance <steven@nrwl.io>
## Current Behavior
When creating a new workspace using `create-nx-workspace` with the
"custom" preset flow, an `nxCloudId` is generated and added to
`nx.json`. This happens even though the onboarding flow is supposed to
handle Cloud setup separately via a short URL.
## Expected Behavior
New workspaces created via `create-nx-workspace` should not have
`nxCloudId` set in `nx.json`. Instead, a short URL is provided for users
to finish Cloud onboarding on their own. The `nxCloud: 'skip'` option is
now passed for the custom flow to prevent the ID from being generated.
E2E tests are updated to verify that `nxCloudId` is undefined in the
generated `nx.json` across all workspace presets.
## Related Issue(s)
N/A - internal fix for workspace creation behavior.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
`--help` on commands that hit yargs help are hanging
## Expected Behavior
It doesn't hang. This contains a quick fix in adding the process.exit
call, but also adds the unref needed to maintain previous working
behavior. We'll need to investigate long term if additional areas keep
commands alive, but adding this unref theoretically allows removing the
process.exit calls from `nx show`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
14 e2e test suites were disabled (`xdescribe`) due to an ESM import
issue in `@microsoft/api-extractor@7.57.0` (see
https://github.com/qmhc/unplugin-dts/issues/461).
## Expected Behavior
With the upstream issue resolved, all 14 e2e test suites are re-enabled
(`describe`) and should pass normally.
## Related Issue(s)
Reverts #34516
## Current Behavior
Running `nx test` for Next.js projects causes Jest to hang with:
```
Jest did not exit one second after the test run has completed.
```
This happens because `next/jest` loads `next.config.js`, which calls
`withNx` → `createProjectGraphAsync()`. The daemon client socket
connection is left open, keeping the Node.js event loop alive and
preventing Jest from exiting. Non-Next.js projects are unaffected since
they don't trigger this code path.
## Expected Behavior
Jest exits cleanly after tests complete for Next.js projects, without
needing `forceExit: true`.
## Fix
Pass `resetDaemonClient: true` to `createProjectGraphAsync()` in
`packages/next/plugins/with-nx.ts`. This tells the project graph
function to call `daemonClient.reset()` after fetching the graph, which
closes the socket and allows Jest to exit.
### Verification
| Scenario | Before | After |
|----------|--------|-------|
| `nx test next-app` | Hangs | Exits cleanly |
| `NX_DAEMON=false nx test next-app` | Exits cleanly | Exits cleanly |
| Direct `npx jest` | Exits cleanly | Exits cleanly |
| Non-Next.js `nx test react-lib` | Exits cleanly | Exits cleanly |
## Related Issue(s)
Fixes#32880
## Current Behavior
The Maven plugin is on version `0.0.13`.
## Expected Behavior
The Maven plugin is bumped to version `0.0.14`, with a migration
generated for Nx `22.6.0-beta.1`.
## Current Behavior
Agents are silent and hard to diagnose
## Expected Behavior
Agents should print debug logs without making all of Nx print debug logs
## Current Behavior
14 e2e tests are failing across master with "Failed to process project
graph" errors. The root cause is `@microsoft/api-extractor@7.57.0` which
has a broken ESM export (`ConsoleMessageId`). When `@nx/vite/plugin` or
`@nx/vitest` plugins load `vite.config.mts` files, they transitively
import api-extractor which crashes.
## Expected Behavior
Broken e2e tests are disabled via `xdescribe` so they no longer block
CI. Tests should be re-enabled once the upstream api-extractor ESM issue
is fixed.
## Disabled Tests
| Project | Test File |
|---------|-----------|
| e2e-vite | `vite.test.ts`, `vite-legacy.test.ts`,
`vite-ts-solution.test.ts` |
| e2e-vue | `vue.test.ts`, `vue-legacy.test.ts`,
`vue-ts-solution.test.ts` |
| e2e-js | `js-ts-solution.test.ts` |
| e2e-web | `web-vite.test.ts` |
| e2e-react | `react-vite.test.ts`, `react-ts-solution.test.ts` |
| e2e-next | `next-ts-solutions.test.ts` |
| e2e-release | `release-publishable-libraries.test.ts`,
`release-publishable-libraries-ts-solution.test.ts` |
| e2e-storybook | `storybook-nested.test.ts` |
## Related Issue(s)
Upstream: https://github.com/qmhc/unplugin-dts/issues/461
## Current Behavior
The `maven-shade-plugin` at version 3.5.0 intermittently fails on CI
with:
```
Could not replace original artifact with shaded artifact!
```
This is a file-locking race condition where the plugin fails to
atomically replace the original JAR with the shaded JAR.
## Expected Behavior
Upgrading to 3.6.0 resolves the intermittent CI failures by using
improved file-handling logic with better retry behavior during the
artifact replacement step.
## Related Issue(s)
N/A - fixes intermittent CI flakiness in `maven-batch-runner` builds.
Closes#19779
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/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
When targeting Windows the resulting binary (nx.dll) dynamically links
against Microsoft Visual C++ runtime (msvcrt140.dll). This means nx
won't be able to run on Windows systems without this runtime installed.
## Expected Behavior
I'd like to avoid this dependency by linking the runtime statically into
the nx binary. (This is also how e.g. cargo.exe for Windows is built.)
## Related Issue(s)
Fixes#19779
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
## Current Behavior
Terminal output in the task runner is accumulated via repeated string
concatenation (`terminalOutput += chunk`). Each `+=` on a growing string
causes V8 to allocate a new, larger string and copy the old contents,
resulting in O(n²) allocation behavior for tasks with large output.
Additionally, `PseudoTtyProcess.onExit` didn't pass `terminalOutput` to
its callbacks, forcing callers like `TaskOrchestrator` to duplicate
output accumulation logic with a separate `onOutput` listener.
## Expected Behavior
- Terminal output is collected in `string[]` arrays and joined once at
the end, reducing intermediate allocations from O(n²) to O(n)
- `PseudoTtyProcess.onExit` now passes `terminalOutput` as a second
argument, matching the signature of other `RunningTask` implementations
- `TaskOrchestrator` no longer needs a special code path for
`PseudoTtyProcess` — unified `onExit` handling for all task types
- `tui-summary-life-cycle` accumulates output in chunks during execution
and stores the finalized string on task completion, allowing chunk
arrays to be GC'd
- `SeriallyRunningTasks` and `RunningNodeProcess` similarly switched to
chunk-based accumulation
- `BatchProcess` and `NodeChildProcessWithNonDirectOutput` lazily join
and cache their terminal output
Work on making a tech intro pages more consistent with each other and
focus on "answering the 80%" for the given technology.
Focusing on
- Angular
- Maven/Gradle
- react
- TS
- Vite
- Vitest/Jest
The changes are based around answering the following, where each
"category" of page might have a different set of depth for the answer.
1. Why do I want to use this plugin?
- Plugins are considered fully optional and are aimed at providing
better DX for a technology, such as inferred setup, generators,
migrations.
- some plugins (like TSC) might have special call outs in some of this,
but generally the same for all plugins.
2. How do I use this plugin in my workspace?
- also pretty commonly the "same" for all plugins in terms of "setup"
- where they differ is mostly for frameworks, e.g. Angular, React.
You're looking at setting up a project to use these tools
- For Build/Test tools you're looking at adding to an existing project,
or converting from one to another.
- Build/Test tools are "means to an end", so should callout if the goal
is tool + framework in a "new" context point to the framework based
plugin page. Otherwise, show adding to an existing project like React
project.
3. What do I need to know about using this plugin?
- understanding finer details of a plugin options, e.g. buildable &
publishable
- extra generators for the plugin. e.g. "convert-to-swc"
- generally I like the idea of having a "CI considerations" where we
talk about CI setups that can help, e.g. options or batch mode etc.
closes DOC-407
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: barbados-clemens <barbados-clemens@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
navigation of the breadcrumbs could lead to confusing state since they
were based around the folder structure.
Breadcrumbs are now based around the sidebar structure so they match the
hierarchy of content.
Note: I left the existing index file based route pages in place in case
there are any links people have booked marked/linked to in other
locations. these will get cleaned up when we finally rewrite all the
URLs to their new content locations
## Current Behavior
When file changes arrive rapidly, the daemon triggers multiple
concurrent project graph recomputations that all run to completion —
wasting CPU/memory on redundant work and returning stale results.
Additionally, after processing file changes, the daemon clears all
tracked files indiscriminately. Files that changed mid-recomputation are
silently lost and never reflected in the project graph until another
unrelated file change arrives.
## Expected Behavior
Stale recomputations detect when a newer one has started and exit early,
chaining to the newer promise so callers always get the freshest result.
File change tracking now uses versioned maps. Each batch of file watcher
events gets a unique version, and only files matching the snapshotted
version are cleared after processing. Files that changed
mid-recomputation are preserved and picked up by the next cycle.
## Current Behavior
Two categories of e2e CI failures were observed in run
https://github.com/nrwl/nx/actions/runs/22127884259:
1. **`e2e-nx-init` and `e2e-js` fail on Node 22.12.0** with:
```
error eslint-visitor-keys@5.0.0: The engine "node" is incompatible with
this module.
Expected version "^20.19.0 || ^22.13.0 || >=24". Got "22.12.0"
```
Node 22.12.0 is one minor version short of the `^22.13.0` range required
by `eslint-visitor-keys@5.0.0`.
2. **`e2e-nx` tests fail because `[isolated-plugin]` / `[plugin-worker]`
verbose messages leak into captured stdout**, causing:
- `JSON.parse(runCLI('show project --json'))` to throw `SyntaxError:
Unexpected token 'i', "[isolated-p"...`
- `expect(runCLI('show projects')).toEqual('')` to fail with worker
spawn noise
- The `@nx/workspace:infer-targets` test to unexpectedly find
`@nx/remix` in output (from a worker spawn message)
Root cause: in `isolated-plugin.ts`, the plugin worker's stdout was
piped directly to `process.stdout`, so `[plugin-worker]` verbose
messages written by the worker ended up in the stdout captured by
`runCLI` in e2e tests.
## Expected Behavior
1. The CI matrix uses a Node 22.x version that satisfies `^22.13.0`.
2. Plugin worker verbose/diagnostic messages go to `process.stderr` (not
`process.stdout`), so they don't contaminate output captured by `runCLI`
in e2e tests. Both worker stdout and stderr now pipe to
`process.stderr`, and the max listener bump is consolidated to `+2` on
stderr.
## Related Issue(s)
N/A — identified from CI run
https://github.com/nrwl/nx/actions/runs/22127884259
## Current Behavior
When running in maven 4 batch mode, the build state is recorded only
after the full batch is done.
This means that nx caching records the state of a task before build
state is recorded to disk.
When running another maven task that depends on this partially recorded
cache, the build state file is missing and we get errors.
## Expected Behavior
build state should be recorded after every task is done and before nx
caching can kick in. This way we can ensure that nx cache is correct.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Current Behavior
When running generators or migrations, Nx automatically skips Prettier
formatting if no root Prettier config is detected (added in #30426).
However, there's no way to explicitly skip Prettier formatting when a
config IS present but the user wants to bypass it for specific
operations.
This can be needed when:
- When running something like Oxfmt that may treat prettier slightly
differently, even with the same config (this is the main thing I ran
into)
- Running migrations where Prettier reformatting causes unintended side
effects (e.g., breaking `eslint-disable` comments)
- Temporarily disabling formatting for debugging purposes
- Using a formatter that coexists with Prettier in the workspace but
should take precedence for certain files
## Expected Behavior
Users can set `NX_SKIP_FORMAT=true` to explicitly skip Prettier
formatting in generators and migrations, regardless of whether Prettier
is configured. TSConfig path sorting (controlled by
`sortRootTsconfigPaths` or `NX_FORMAT_SORT_TSCONFIG_PATHS`) continues to
work independently.
```bash
NX_SKIP_FORMAT=true nx migrate --run-migrations
NX_SKIP_FORMAT=true nx g @nx/react:app my-app
```
## Related Issue(s)
Related to #30403 and #30426. This enhancement adds explicit user
control for cases where auto-detection of Prettier configuration isn't
sufficient.
## Current Behavior
When publish fails due to missing OTP code, its not clear as a user who
is using the top level command what to do next.
## Expected Behavior
Add the --otp flag to the top-level `nx release` command so users can
provide a one-time password for 2FA-enabled registries when running the
full release orchestration (version + changelog + publish).
When publish fails due to an expired or missing OTP (EOTP error),
display a helpful warning listing affected projects and the exact
command to re-run the publish step in isolation with a new OTP.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Codex has only basic MCP/AGENTS.md support right now. Also, because it
used to have only global-level config files, we had some extra logic
around configuring that.
We want Codex to get the latest skills too (they don't support custom
subagents yet, though) and use project-level config files that they now
support.
After running nx build (or any task), the daemon now shows a hint if
your AI agent configuration is outdated: "Your AI agent configuration is
outdated. Run nx configure-ai-agents to update."
The daemon computes and caches the full agent configuration status
(fully configured, outdated, partially configured, non-configured) using
latest Nx from npm, so the check is always against the newest available
configuration. Running nx configure-ai-agents resets the daemon's cache
so the message disappears on the next build.
Key changes
- Daemon agent status endpoint: New GET_CONFIGURE_AI_AGENTS_STATUS /
RESET_CONFIGURE_AI_AGENTS_STATUS message types. The handler fires off
computation in the background and returns immediately (never blocks the
request). Results are cached for the daemon's lifetime.
- Shared latest-nx module: Extracted the "install nx@latest to tmp"
logic from nx-console-operations into daemon/server/latest-nx.ts so both
Nx Console and AI agents handlers share a single cached installation.
Includes a race-condition guard (in-flight promise deduplication).
- Post-task outdated hint: run-command.ts queries the daemon after task
execution and prints a single dim line if agents are outdated.
- Daemon reset from configure-ai-agents: The CLI sets NX_DAEMON=false
for configure-ai-agents, so we bypass daemonClient.enabled() and use
isServerAvailable() directly to reach an already-running daemon. The
socket is closed in a finally block so the process exits cleanly.
- Async editor detection (Rust): Made isEditorInstalled,
canInstallNxConsoleForEditor, installNxConsole, and related napi
functions async so they run on the libuv thread pool instead of blocking
Node's event loop. This prevents the daemon from stalling for ~3.5s when
checking editor extensions.
- output.logRawLine: New helper that prints a single line without the NX
prefix.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
We want to minimize prompts for people and agents. But we also want to
help them by setting up nx config for them so their agents can work
optimally.
If they're executing `nx init` or `create-nx-workspace` from within an
agent, it's a reasonable assumption that they'll want the best AI config
for that specific agent - so we set it up for them.
## Current Behavior
The `nx watch` file watcher uses the `ignore-files` and
`watchexec-filterer-ignore` crates to handle `.gitignore` matching.
These crates use a trie-based approach that has a bug with
path-component matching — certain gitignore patterns (e.g., prefix
patterns) don't match correctly, causing files that should be ignored to
trigger unnecessary watch events.
## Expected Behavior
Gitignore patterns are matched correctly using per-directory `Gitignore`
instances from the `ignore` crate — the same crate already used by the
file walker. Each `.gitignore` file is scoped to its directory, and
matching is done deepest-first so that nested gitignores take priority —
matching standard git behavior.
### What changed
- Replaced `ignore-files` + `watchexec-filterer-ignore` with direct use
of `ignore::gitignore::{Gitignore, GitignoreBuilder}`, aligning the
watcher with the approach already used by the file walker
- Each `.gitignore` is now compiled as a standalone instance tied to its
parent directory
- Gitignore evaluation walks deepest-first; first match wins
- `.nxignore` matching now uses `matched_path_or_any_parents` for
correct ancestor checking
- `create_filter` is now synchronous (no longer `async`) since the new
approach doesn't need async I/O
- Removed 2 crate dependencies (`ignore-files`,
`watchexec-filterer-ignore`)
## Current Behavior
When a project-level `tsconfig.json` (e.g., `apps/aurora/tsconfig.json`)
inherits `paths` via `extends` from `tsconfig.base.json` at the
workspace root and no explicit `baseUrl` is set, Nx incorrectly resolves
`./`-prefixed path mappings relative to the project tsconfig directory
instead of the workspace root where the paths were defined.
This causes errors when loading TypeScript config files (e.g.,
`rspack.config.ts`) that import workspace libraries using path aliases:
NX Cannot find module './libs/plugins/rspack/src'
`@swc-node/register`'s `readDefaultTsConfig` auto-sets `baseUrl` to
`dirname(tsConfigPath)` (the project directory) when not explicitly
configured, causing SWC to rewrite imports to incorrect relative paths
during transpilation.
## Expected Behavior
Path aliases defined in `tsconfig.base.json` (e.g.,
`"@trellis/plugins/rspack": ["./libs/plugins/rspack/src/index.ts"]`)
should resolve relative to the workspace root when no `baseUrl` is
configured.
This is needed so that when using `tsgo` and needing to prefix all paths
with `./` (no more `baseUrl` allowed) the paths are still resolved from
the right spot.
I tested this fix against our codebase on the branch I was trying to
switch to tsgo on and it seemed to work.
## Related Issue(s)
Fixes
https://discord.com/channels/1143497901675401286/1471627045694865581
## Current Behavior
CONTRIBUTING.md contains an outdated "How to Get Started Video" section
and references Stack Overflow for general questions.
## Expected Behavior
Remove outdated video section and point users to the Discord community
instead of Stack Overflow for general questions.
## Related Issue(s)
N/A
When switching from inline mode to full-screen TUI (or during window
resize), the PTY resize operation reparsed ALL raw terminal output
through a new vt100 parser synchronously on the event loop. For tasks
with large output, this caused a noticeable hang.
Add `resize_async()` which moves the expensive reparse to a background
thread using a snapshot-and-replay pattern:
1. Quick snapshot of raw output (brief read lock)
2. Expensive reparse on background thread (no locks held)
3. Quick swap with replay of any new output (brief write lock)
A generation counter prevents stale resizes from overwriting newer ones.
Also combine two separate O(n) scrollback processing calls in inline
mode into a single pass.
## Current Behavior
Copyright year shows 2017-2025 and README uses older tagline.
## Expected Behavior
Copyright reflects current year 2026 and README uses updated repository
description.
## Changes
- **LICENSE**: Updated copyright year from `2017-2025` to `2017-2026`
- **README.md**: Replaced heading and description
- New heading: "The Monorepo Platform that amplifies both developers and
AI agents. Nx optimizes your builds, scales your CI, and fixes failed
PRs automatically. Ship in half the time."
- Removed redundant description line below heading
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
> ## Update License and README
>
> Please make the following changes:
>
> 1. **Update LICENSE file**: Change the copyright year from `2017-2025`
to `2017-2026`
> - File: `LICENSE`
> - Line 3: Update `Copyright (c) 2017-2025 Narwhal Technologies Inc.`
to `Copyright (c) 2017-2026 Narwhal Technologies Inc.`
>
> 2. **Update README.md description**: Replace the current description
with the repository's official description
> - File: `README.md`
> - Line 22: Change the heading from `# Smart Monorepos · Fast Builds`
to `# The Monorepo Platform that amplifies both developers and AI
agents. Nx optimizes your builds, scales your CI, and fixes failed PRs
automatically. Ship in half the time.`
> - Line 24: Remove the current description line: `Get to green PRs in
half the time. Nx optimizes your builds, scales your CI, and fixes
failed PRs. Built for developers and AI agents.`
>
> The new README should have the repository description as the main
heading, followed immediately by the "Create a new Nx workspace with"
section.
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
*This pull request was created from Copilot chat.*
>
<!-- 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>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
`tui_logger::init_logger()` and `TuiTracingSubscriberLayer` are
initialized unconditionally in `initialize_logger()`. This spawns a
background thread, causing unnecessary allocation churn and increased
processing.
## Expected Behavior
`tui_logger` is only initialized when `NX_TUI=true`, avoiding the
background thread and allocation overhead for all non-TUI contexts.
## Current Behavior
We have ~1,657 redirect rules across `redirect-rules.js` and
`redirect-rules-docs-to-astro.js`, getting close to Netlify's limit and
we need room for more as the Astro migration continues.
## Expected Behavior
Reduced to **1,139 rules** (~31% reduction) by:
- Resolving duplicate/conflicting source paths across sections
- Flattening multi-hop redirect chains to point directly to final
destinations
- Consolidating groups of individual rules into wildcard patterns
(tutorials, CLI, helm, concepts, recipes, etc.)
- Removing old 2022-era sections (`schemaUrls`, `overviewUrls`,
`packagesIndexes`, `packagesDocuments`) whose destinations chain 3-5
hops deep and are long superseded by newer redirects
- made sure old links in nx code base still have redirects (will update
in future PR)
Build, tests, and internal link check all pass with no issues.
## Related Issue(s)
Fixes DOC-403
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: barbados-clemens <barbados-clemens@users.noreply.github.com>
## Current Behavior
When AI agents (Claude Code, Cursor, Windsurf, etc.) run `nx init`, the
command works but:
- Uses interactive prompts that AI agents can't handle
- Outputs human-readable text that AI agents must parse
- Doesn't provide structured progress or error information
## Expected Behavior
When `nx init` detects an AI agent (via environment variables like
`CLAUDE_CODE=1`), it should:
- Skip interactive prompts and use sensible defaults
- Output structured NDJSON for progress updates, success, and errors
- Include detailed context for AI agents to understand and fix issues
## Changes
This PR adds agentic mode to `nx init`:
### `nx init` Changes
- Detect AI agents via `isAiAgent()` native function
- Auto-defaults: `interactive=false`, `nxCloud=false`, auto-detect `.nx`
installation
- NDJSON output with `type: progress|success|error`
- Error logs written to `.nx/ai-errors/` with full context
- Cursor restoration escape sequence skipped for AI agents (prevents
NDJSON corruption)
### Output Format
```jsonl
{"type":"progress","step":"starting","message":"Initializing Nx..."}
{"type":"success","nxVersion":"22.5.0","projectsDetected":1,"pluginsInstalled":["@nx/vite"]}
```
Or on error:
```jsonl
{"type":"error","message":"Failed to install","code":"INSTALL_ERROR","errorLogPath":".nx/ai-errors/nx-init-error-2025-01-15T10-30-00.log"}
```
## Current Behavior
we pull from latest all the time even if the current version is already
latest
## Expected Behavior
we can skip this extra work sometimes
## Current Behavior
Pages proxied from Framer contain canonical URLs pointing to the Framer
domain (`ready-knowledge-238309.framer.app`), causing duplicate indexing
issues in search engines.
## Expected Behavior
Canonical URLs and other references in Framer-proxied pages now point to
`nx.dev`, ensuring proper SEO indexing.
### Implementation
Consolidated all Framer logic into a single Netlify edge function
(`rewrite-framer-urls.ts`) that:
1. Checks if the request path matches a Framer-proxied path (using
`FRAMER_REWRITES` env var)
2. Fetches directly from Framer (using `FRAMER_URL` env var)
3. Rewrites all Framer URLs to `nx.dev` in the HTML response (handles
`<link rel="canonical">`, `og:url`, etc.)
4. For non-Framer paths, passes through to Next.js
The edge function uses the `accept: ['text/html']` config to only run on
HTML requests, matching the pattern from `track-page-requests.ts` in
astro-docs.
The Next.js middleware has been removed since all Framer routing is now
handled by the edge function.
### Environment Variables
The edge function expects these env vars in Netlify (already added
previously):
- `NEXT_PUBLIC_FRAMER_URL`: e.g.,
`https://ready-knowledge-238309.framer.app`
- `NEXT_PUBLIC_FRAMER_REWRITES`: comma-separated list of paths, e.g.,
`/pricing,/enterprise`
## Demo
1. Go to https://deploy-preview-34445--nx-dev.netlify.app/
2. View source and look for canonical
3. See it is nx.dev not framer domain
<img width="1347" height="161" alt="image"
src="https://github.com/user-attachments/assets/d4a515da-e39f-41cb-a7b4-668fe0bedbbd"
/>
## Related Issue(s)
Closes CLOUD-4148
## Current Behavior
The `release` function returned by `createAPI` has a return type of
`Promise<NxReleaseVersionResult | number>`. The `| number` union member
is inaccurate since the function always returns
`NxReleaseVersionResult`, which can mislead consumers of the
programmatic API.
## Expected Behavior
The return type is narrowed to `Promise<NxReleaseVersionResult>`,
accurately reflecting what the function actually returns and giving API
consumers correct type information.
Co-authored-by: Andreas Hörnicke <andreas.hoernicke@contentful.com>
Blog post draft about the evolution from MCP tools to agent skills.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
Co-authored-by: Juri Strumpflohner <juri.strumpflohner@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
`^` and `dependencies: true` only work for fileset inputs
## Expected Behavior
Adds support for inputs of the form `^{projectRoot}/**/*.ts` as
syntactic sugar for specifying a fileset input that should be collected
from dependency projects.
Previously, only named inputs could use the `^` prefix to include
dependencies (e.g., `^production`). Now filesets can also use this
syntax directly without needing to define a named input first.
Examples:
- `^{projectRoot}/**/*.ts` - include .ts files from all dependencies
- `^{workspaceRoot}/tools/**/*` - include workspace tools from
dependencies
- `{ fileset: '{projectRoot}/**/*.ts', dependencies: true }` - object
form
Detection is deterministic: if the string after `^` starts with
`{projectRoot}` or `{workspaceRoot}`, it's treated as a dependency
fileset; otherwise, it's treated as a named input reference.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
- In some `nx run-many` executions, terminal output can appear staggered
or visually misaligned instead of updating cleanly in place.
- For `run-many` cases that end up running a single task (especially
when TUI is not active), the spinner/status line can be rendered twice.
## Expected Behavior
- Dynamic terminal output updates should remain stable and aligned, with
clean in-place refreshes.
- Single-task `run-many` should display a single spinner/status line
with no duplicate rendering.
Add uncaughtException handler for ERR_USE_AFTER_CLOSE to prevent
ugly stack trace when pressing Ctrl+C during enquirer prompts
(Node 24 stricter readline behavior). Matches existing pattern
used in nx init and create-nx-workspace.
## Current Behavior
The publish workflow uses `sudo npm install -g npm@11.5.2` which was
added in #34409. This causes issues with OIDC token permissions in the
release pipeline since `sudo` runs as a different user context.
## Expected Behavior
The publish workflow should use `npm install -g npm@11.5.2` without
`sudo`, matching the standard approach used elsewhere and avoiding
permission context issues during release.
## Related Issue(s)
Reverts #34409
## Current Behavior
The publish workflow uses `addnab/docker-run-action@v3` which is based
on `docker:20.10` (Docker API 1.41). GitHub's `ubuntu-24.04` runners now
ship Docker Engine 28.x which requires minimum API version 1.44, causing
all 4 Linux Docker builds to fail:
```
docker: Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version.
```
Failed run: https://github.com/nrwl/nx/actions/runs/21961139962
## Expected Behavior
Linux Docker builds (x86_64-gnu, x86_64-musl, aarch64-gnu, aarch64-musl)
complete successfully using the host's modern Docker CLI.
https://github.com/nrwl/nx/actions/runs/21996143819
## Related Issue(s)
The `addnab/docker-run-action` repo is abandoned (last release March
2021, last commit May 2021) with open issues about this exact problem.
## Current Behavior
There's a chance that windows can falsely flag our native binaries as a
threat. We do not use the shellapi feature from winapi.
## Expected Behavior
We hope that removing this API doesn't break things, and the threat
messaging goes away
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #https://github.com/nrwl/nx/issues/34186
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Pressing `[1]` or `[2]` on a task that's already pinned to that slot
**focuses** the pane instead of unpinning it. This means there's no way
to unpin a single pane via keyboard — you can only nuke everything with
`[0]`.
This regression was introduced in #34175, which fixed a real problem:
pressing Enter on an already-pinned task would unpin it, leaving focus
on an invisible pane (a ghost pane — you're staring at nothing but the
TUI thinks you're looking at output). The fix was to make the "already
pinned to this pane" branch focus instead of unpin. The problem is that
`[1]`, `[2]`, and Enter all flowed through the same function
(`assign_current_task_to_pane`), so changing behavior for Enter changed
it for everyone. One lock got swapped out, and every door started
behaving the same way.
## Expected Behavior
`[1]` and `[2]` are **toggles**: press once to pin, press again to
unpin. Enter is a **display** action: show me this task's output and put
my cursor there — if it's already visible somewhere, just take me to it.
After this change:
- **`[1]` / `[2]`** on an already-pinned task → unpins it (pane
disappears, layout adjusts, focus returns to task list if no panes
remain)
- **Enter** on an already-pinned task → focuses whichever pane it's in
(even if it's in pane 2 and you'd normally expect pane 1)
- **Init** (startup restore of pinned tasks) → pure assignment, no
toggling, no focusing
## Approach
The old code had one function trying to serve three masters. Rather than
adding a flag parameter (`should_toggle: bool`) — which would just be a
boolean that lies about its intentions at every call site — the function
was split along the actual semantic boundaries:
| Function | Used by | "Already pinned here" behavior |
|---|---|---|
| `toggle_current_task_in_pane` | `[1]` / `[2]` keys | **Unpin** (toggle
off) |
| `assign_current_task_to_pane` | `init()` | No-op (task is where it
should be) |
| `display_and_focus_current_task_in_terminal_pane` | Enter key |
**Focus** the existing pane |
The shared logic — exiting spacebar mode, moving a task between panes,
fresh-pinning — lives in two small helpers (`exit_spacebar_and_pin`,
`move_or_pin_selection`) that both `toggle` and `assign` delegate to.
The only code that differs is the "what do we do when it's already
here?" branch, which is exactly the part that *should* differ.
**Why not keep one function with a mode parameter?** Because the three
behaviors aren't variations of the same action — they're genuinely
different user intents. A toggle is "I changed my mind." A focus is
"Take me there." An assignment is "Put this here." Encoding that as an
enum parameter just moves the branching somewhere less obvious and makes
the call sites harder to read. The function names now document the
intent at the point of use, and there's no shared state to accidentally
couple.
**Why does Enter check all panes, not just pane 0?** Because if you
pinned a task to pane 2 via `[2]` and then press Enter on it, the least
surprising thing is to jump to where it already lives — not to silently
duplicate it into pane 1 or ignore you. The task is already on screen;
Enter means "show me."
## Related Issue(s)
Fixes the regression introduced by #34175.
## Current Behavior
CNW (Create Nx Workspace) has A/B testing logic that randomly selects
between variants 0, 1, and 2 for the Nx Cloud connection flow. Each
variant shows different prompts and banners.
## Expected Behavior
Lock in variant 2 as the permanent behavior:
- **No cloud prompt** - users are not asked about Nx Cloud during
workspace creation
- **Deferred connection** - no `nxCloudId` is written to `nx.json` (uses
`skipCloudConnect: true`)
- **Variant 2 banner** - shows "Enable remote caching and automatic
fixes when CI fails" with a link to complete setup later
### Changes
- Simplified `ab-testing.ts` - removed caching, random selection;
`getFlowVariant()` always returns `'2'`
- `shouldShowCloudPrompt()` always returns `false`
- `determineNxCloudV2()` returns `'github'` with `skipCloudConnect:
true` for deferred connection
- Removed variant 1 banner logic from `messages.ts`
- Updated tests to reflect the locked-in behavior
## Demo
https://www.loom.com/share/7f688eed6052428cbe91dd9db837cbbd
## Related Issue(s)
Closes CLOUD-4255
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Simplified form targeting by replacing the global `reactHubspotForm` ID
with a deterministic `targetId` that incorporates portal, form, and
calendly IDs. This improves scalability and avoids potential ID
collisions.
## Current Behavior
When banner content changes in Framer, the nx-docs and nx-dev sites need
to be manually redeployed to pick up the new content.
## Expected Behavior
A scheduled workflow monitors the banner URL every 15 minutes and
automatically triggers Netlify production deploys when content changes.
## How it works
1. Fetches `BANNER_URL` content (from repository variable)
2. Computes SHA256 hash
3. Compares to cached hash from previous run
4. If different → triggers both Netlify deploys, updates cache
5. If unchanged → no-op
## Required Setup
1. **Repository variable** (`Settings → Secrets and variables → Actions
→ Variables`):
- `BANNER_URL` = Framer banner API URL
2. **Repository secret** (`Settings → Secrets and variables → Actions →
Secrets`):
- `NETLIFY_AUTH_TOKEN` = Netlify personal access token
## Related Issue(s)
Fixes DOC-405
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Negation patterns are ignored in plugin configuration for the `include`
and `exclude` properties.
## Expected Behavior
- Negation patterns should work in the same way that they do for other
`include`/`exclude` configurations
**Example: Excluding all e2e projects except one**
```jsonc
// nx.json
{
"plugins": [
{
"plugin": "@nx/jest/plugin",
"exclude": ["**/*-e2e/**/*", "!**/toolkit-workspace-e2e/**/*"],
},
],
}
```
This will exclude all e2e projects except `toolkit-workspace-e2e`.
**Example: Including packages except legacy ones**
```jsonc
// nx.json
{
"plugins": [
{
"plugin": "@nx/vite/plugin",
"include": ["packages/**/*", "!packages/legacy/**/*"],
},
],
}
```
**How negation patterns work:**
- Patterns are processed in order from first to last
- A pattern starting with `!` removes files from the match set
- A pattern without `!` adds files to the match set
- The last matching pattern determines if a file is included
- If the first pattern is a negation, all files are matched initially
---------
Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
## Current Behavior
There is currently no plugin.md file for Gradle.
Other plugin.md files can be improved
## Expected Behavior
Add plugin.md file for Gradle to aid with verification with Agents.
Add plugin.md file for Vite for workspaces that have not migrated to
@nx/vitest.
## Related Issue(s)
CLOSES NXC-3843
---------
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 Playwright executor does not support configuring a custom cache
directory for Playwright's internal cache (browser binaries, etc.).
Users who need to control where Playwright stores its cache, for example
in CI environments with specific disk constraints like not being able to
DTE tasks or shared caching setups, have no way to set this through the
executor configuration.
## Expected Behavior
A new `cacheDir` option is available on the Playwright executor. When
provided, it sets the `PWTEST_CACHE_DIR` environment variable on the
forked Playwright process, allowing users to control where Playwright
stores its internal cache.
```json
{
"targets": {
"e2e": {
"executor": "@nx/playwright:playwright",
"options": {
"cacheDir": "/tmp/playwright-cache"
}
}
}
}
```
## Related Issue(s)
Replaces #34397
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Current Behavior
The SECURITY.md file does not clarify what types of reports should be
sent to the security email, leading to reports about outdated
dependencies and vulnerability scanner output.
## Expected Behavior
The file now clarifies that the security email is for demonstrable,
verified vulnerabilities in the Nx codebase itself, not for:
- Outdated dependency reports
- Dependencies with CVEs that don't directly affect Nx
- General vulnerability scanner output
## Related Issue(s)
Fixes NXC-3898
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
The `npm install -g npm@11.5.2` step in the publish workflow fails with
`EACCES: permission denied, mkdir '/usr/local/share/man/man5'` on newer
GitHub Actions runner images.
## Expected Behavior
The global npm install step completes successfully regardless of runner
image permissions on `/usr/local/share/man/`.
## Related Issue(s)
This is a known issue with GitHub Actions runners:
https://github.com/actions/runner-images/issues/9644
Add isSandbox() utility that checks for sandbox environment variables
(SANDBOX_RUNTIME, GEMINI_SANDBOX, CODEX_SANDBOX, CURSOR_SANDBOX) and
use it to disable the daemon and plugin isolation in sandbox
environments.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: meeroslav <meeroslav@users.noreply.github.com>
## Current Behavior
Running ai agents in sandbox mode causes issues with Nx's daemon and
plugin isolation
## Expected Behavior
Running ai agents in sandbox mode should work
## Related Issue(s)
CLOSES NXA-828
## Current Behavior
We do not include NxVersion when creating short urls.
## Expected Behavior
Include NxVersion when creating short urls.
## Related Issue(s)
CLOSES NXC-3879
When cache outputs include both glob patterns and directory patterns
containing symlinks, the cache restore fails with EEXIST (os error 17).
This happens because `fs_extra::remove_items` silently skips dangling
symlinks (since `is_dir()`/`is_file()` follow links and return false),
leaving stale symlinks that cause `symlink()` to fail.
The fix makes symlink creation idempotent by checking for and removing
any existing symlink at the destination before creating a new one, using
`symlink_metadata()` which correctly detects dangling symlinks.
Fixes#34013
## Current Behavior
The Maven plugin's `createNodes` and `createDependencies` functions both
independently compute a hash of all pom.xml directories, then use that
hash to look up cached Maven analysis data from disk. When Maven
projects have `<includes>` or `<excludes>` in their plugin config, the
hash can differ between the two calls, causing `createDependencies` to
fail to find the data that `createNodes` stored.
## Expected Behavior
`createDependencies` reliably receives the Maven analysis data from
`createNodes` regardless of hash differences, by reading it from a
module-level variable instead of re-hashing and looking it up from disk.
This matches the pattern already used by the Gradle plugin
(`getCurrentGradleReport`).
## Related Issue(s)
## Current Behavior
Runtime cache keys could be nondeterministic because the order of
environment variables varied, leading to inconsistent cache hits across
runs.
## Expected Behavior
Runtime cache keys are deterministic regardless of the insertion order
of env variables, improving cache stability.
## Current Behavior
Cycles in the task graph could remove unrelated `continuousDependencies`
when the cycle exists only in `dependencies`, leading to missing
continuous task edges.
## Expected Behavior
Cycle removal only removes the specific cyclic edge from the list where
it appears, preserving unrelated continuous dependencies.
## Current Behavior
When running Nx tasks in CI environments (e.g., Buildkite) where the
host's /tmp is mounted to containers, intermittent EADDRINUSE errors
occur in PseudoIPCServer.init(). This happens because:
1. PseudoIPCServer doesn't clean up its Unix socket file before calling
listen()
2. ForkedProcessTaskRunner.createPseudoTerminal() instantiates
PseudoTerminal directly instead of using the createPseudoTerminal()
helper, bypassing shutdown callback registration
When a new container starts with the same PID as a previous run (PID
recycling), it generates the same socket path and hits EADDRINUSE
because the stale socket file still exists.
## Expected Behavior
No EADDRINUSE errors should occur. The PseudoIPCServer should
defensively remove any stale socket file before attempting to listen,
similar to how the daemon server handles this.
## Related Issue(s)
Fixes#34233
Streamlined analytics tracking by removing Cookiebot and direct GA
(gtag.js) integrations. Consolidated event logging through GTM's
dataLayer for consistency and maintenance simplicity.
## Current Behavior
Batch IDs are generated in two places: the task scheduler uses an
incremental counter (`executorName N`) while the forked process task
runner generates its own using the process PID (`executorName-pid`).
This means the batch ID registered in metrics doesn't match the one used
everywhere else.
## Expected Behavior
Batch IDs are only created by the task scheduler. The forked process
task runner uses the scheduler-assigned ID to ensure consistency across
the system.
## Current Behavior
right now if users modify their mcp params like `--minimal`, we will
override them on `configure-ai-agents`
## Expected Behavior
We want to bring users up to latest without overriding their valid
configurations
## Current Behavior
The Bun package manager config uses `--frozen-lockfile` for
`updateLockFile`:
```typescript
updateLockFile: 'bun install --frozen-lockfile',
```
However, `--frozen-lockfile` **prevents** changes to the lockfile,
causing `nx release` to fail when trying to update the lockfile after
version bumps.
## Expected Behavior
Use `--lockfile-only` which generates/updates the lockfile without
installing dependencies:
```typescript
updateLockFile: 'bun install --lockfile-only',
```
This is consistent with other package managers:
- npm: `npm install --package-lock-only`
- pnpm: `pnpm install --lockfile-only`
- yarn berry: `yarn install --mode update-lockfile`
## Background
When Bun support was added in PR #22602 (April 2024), `--lockfile-only`
didn't exist in Bun. Bun has since added this flag.
Closes#34344
Co-authored-by: Kai Gritun <kai@kaigritun.com>
## Current Behavior
Several GitHub Actions workflows hardcode pnpm version `10.11.1`, while
`package.json` specifies `pnpm@10.28.2` in the `packageManager` field.
This causes CI failures with:
```
Error: Multiple versions of pnpm specified:
- version 10.11.1 in the GitHub Action config with the key "version"
- version pnpm@10.28.2 in the package.json with the key "packageManager"
```
## Expected Behavior
All pnpm version references across CI workflows should match the
`packageManager` field in `package.json` (`10.28.2`).
## Related Issue(s)
N/A — Fixing CI breakage from version mismatch.
## Changes
Updated pnpm version from `10.11.1` → `10.28.2` in:
- `.github/workflows/npm-audit.yml` — `pnpm/action-setup` version
- `.github/workflows/publish.yml` — `PNPM_VERSION` env var and FreeBSD
install
- `.github/workflows/issue-notifier.yml` — `pnpm/action-setup` version
- `.github/workflows/generate-embeddings.yml` — `pnpm/action-setup`
version
## Current Behavior
The Windows build (`aarch64-pc-windows-msvc`) fails to compile with:
```
error[E0433]: failed to resolve: use of undeclared type `FileType`
--> packages\nx\src\native\watch\types.rs:128:55
```
The `FileType` type is used inside a `#[cfg(target_os = "windows")]`
block but was not imported.
## Expected Behavior
The Windows build compiles successfully. The `FileType` import is scoped
inside the `#[cfg(target_os = "windows")]` block (matching the existing
pattern in the macOS block) so there are no unused imports on any
platform.
## Related Issue(s)
N/A — build breakage discovered during CI publish workflow.
## Current Behavior
The daemon's file watcher uses watchexec 3.0.1 which hardcodes
`RecursiveMode::Recursive` when registering inotify watches. This means
**every** directory gets an inotify watch — including all of
`node_modules`, `.git`, and other ignored trees.
On a typical workspace with a large `node_modules`, this can consume
thousands of inotify watches, eating kernel memory and CPU. The
`WatchFilterer` only filters **events** after watches are already
registered — the watches themselves are never prevented.
## Expected Behavior
Only non-ignored directories (workspace source code) get inotify
watches. Ignored directories like `node_modules`, `.git`, `.nx/cache`,
`.nx/workspace-data`, and `.yarn/cache` are skipped entirely at the
watch registration level.
This dramatically reduces:
- **inotify watch count** (from thousands to hundreds)
- **Memory usage** (each watch consumes kernel memory)
- **CPU overhead** (fewer watches = less kernel bookkeeping)
### How it works
- Upgraded watchexec 3.0.1 → 8.0.1 which supports
`WatchedPath::non_recursive()`
- Added `create_watch_walker()` using `ignore::WalkBuilder` (same
pattern as `walker.rs`) to enumerate only non-ignored directories
- Each directory is watched with `NonRecursive` mode — like putting
security cameras only in the rooms you care about instead of every room
in the building
- New directories created at runtime are dynamically added to the watch
set via the `on_action` handler
- Event-level filtering via `WatchFilterer` is unchanged — same behavior
for gitignore/nxignore patterns
### macOS Support for Dynamic Directory Registration
The initial implementation worked on Linux and Windows but failed tests
on macOS because macOS FSEvents doesn't always provide the same
`FileEventKind` tags as Linux inotify or Windows ReadDirectoryChangesW.
**Three changes to support macOS:**
1. **watcher.rs**: On macOS, check all events for directory creation
(not just events with specific FileEventKind tags) and verify via
filesystem
2. **types.rs**: Filter directory events from JavaScript callbacks on
macOS (similar to Windows behavior)
3. **watch_filterer.rs**: Allow macOS directory events (`Create(Folder)`
and `Modify(Metadata)`) through the filter so the action handler can
register them
All changes use `#[cfg(target_os = "macos")]` for compile-time
conditional compilation, so Linux/Windows behavior is completely
unchanged and there's zero runtime overhead.
### Additional notes
- Pinned `serde` to `<1.0.220` because serde 1.0.220+ moved `__private`
to `serde_core`, breaking `swc_common 0.31.22`
- No TypeScript changes — the napi interface is identical
- `watch_filterer.rs`, `types.rs`, `utils.rs` required no changes (APIs
are compatible)
## Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/33781
Fixes https://github.com/nrwl/nx-console/issues/2468
<!-- No specific issue linked yet -->
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Re-enabling tests and putting back kotlin e2e tests for gradle.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Flaky task detection warns about all tasks that have different exit
codes for the same hash, including non-cacheable tasks. This is
misleading because the flaky task warning message points users to Nx
Cloud's flaky task retry feature, which is only relevant for cached
tasks.
## Expected Behavior
Flaky task detection should only consider tasks where `task.cache ===
true`, making the warning more meaningful and avoiding noise for
non-cacheable tasks.
## Related Issue(s)
N/A - Internal improvement
## Changes Made
###
`packages/nx/src/tasks-runner/life-cycles/task-history-life-cycle.ts`
1. Added `cacheable: boolean` to the `TaskRun` interface
2. In `endTasks`, now tracks `cacheable: taskResult.task.cache === true`
for each task
3. In `endCommand`, filters to only check flaky tasks among cacheable
tasks
###
`packages/nx/src/tasks-runner/life-cycles/task-history-life-cycle-old.ts`
1. Added `cacheableHashes: Set<string>` to track which task hashes are
cacheable
2. In `endTasks`, tracks cacheable tasks by adding their hash to the set
3. In `endCommand`, only checks for flaky tasks among cacheable task
hashes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A new version compatibility table is added to help users understand
which versions of the Gradle plugin work with which versions of the Nx
plugin. The targetNamePrefix configuration option is now documented with
an explanation of its use case in polyglot workspaces where target name
collisions may occur.
## 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
-->
Gradle plugin to 0.1.12
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- No way to run the batch executor in debug mode
- Any flags passed into the nx gradle batch command get forwarded into
the `gradlew` command.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- Allow for an env variable to be set for debug flags so that the batch
runner jar can be run with a debugger hooked in.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-3797
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
In some resize/background scenarios, the TUI could crash while rendering
output panes, displaying a "Scrollbar area is empty" message.
## Expected Behavior
The TUI remains stable during resizes and backgrounding. Output panes no
longer crash when a scrollbar would render in an invalid area.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When Nx processes Gradle subprojects, task dependencies reference the
wrong project names. For a subproject structure like :app or :lib:core,
the generated task dependencies use only the simple project name (app or
core) instead of the full build tree path (:app or :lib:core). This
causes dependent tasks to be generated with incorrect project
references, breaking the task graph for multi-project Gradle builds.
## Expected Behavior
Task dependencies should use the full Gradle build tree path for
subprojects. When a task in :app depends on a task in :lib, the
dependency should be correctly referenced as :lib:taskName.
The fix introduces a getNxProjectName() utility function that correctly
resolves the Nx project name based on the Gradle project's
buildTreePath, and applies it consistently across all dependency
resolution logic in ProjectUtils.kt and
TaskUtils.kt. New tests verify the fix works for both single and nested
subproject structures.
Also removed --rerun-tasks from the batch and non batch runners, we
found that during parallel task executions with the non batch runner,
the flag would cause cache conflicts that would fail tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When a task has outputs at different path depths, some outputs may not
be tracked. This causes:
- Deleted output files not being detected
- Cache restoration being skipped with message "existing outputs match
the cache, left as is"
- Files not being restored even though they exist in cache
## Expected Behavior
All task outputs are tracked regardless of their path depth, ensuring:
- Deleted outputs are correctly detected
- Cache restoration happens when outputs are missing
## Current Behavior
When a task output directory contains a nested `.gitignore` that hides
its contents, Nx can treat the outputs as already present and skip
restoring them from cache. This can result in generated files being
missing from disk, even though the cache entry is valid.
## Expected Behavior
Nx should restore cached outputs regardless of ignore rules inside the
output directory.
## Related Issue(s)
Fixes#32620
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Disabling Gradle e2e tests until foojay toolchain service back online.
Ensures that gradle within the Nx repo uses mise to download java
toolchain, but gradle workspaces within the e2e environments download
their own toolchain.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #Q-175
AI agents are detected via environment variables (CLAUDECODE, OPENCODE)
and receive NDJSON streaming output, non-interactive mode, structured
JSON results with explicit GitHub setup instructions.
Related NXC-3628
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add documentation for batch mode. Remove references to removed custom
overrides for intTest.
## 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 -->
The only way to download the cloud client is to run a specific cloud
command or a task with cloud configured.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A new command is added where we only download the cloud client with:
```
nx download-cloud-client
```
## 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>
add guide to clarify various ways to bundle a node app for different
bundlers
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: barbados-clemens <barbados-clemens@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
In the TUI, when any standalone task finishes,
`handle_standalone_task_finished` unconditionally switches the user's
selection to another in-progress task — even if the finished task wasn't
the one the user had selected. This causes the selection to jump
unexpectedly while the user is watching a different task.
## Expected Behavior
Selection should only change when the task the user is actively viewing
finishes. If an unrelated background task finishes, the user's selection
should remain on whatever they chose.
## Related Issue(s)
N/A — discovered during development testing.
---------
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
NX_NATIVE_LOGGING is hardcoded and can't be customized on the daemon
server
## Expected Behavior
Log settings can be customized by changing them in the env of the first
command to spawn the daemon
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
we were including native binaries in the final netlify function build
for nextjs which was fine until we reach the limit of 250mb causing a
failure to upload the function (AWS imposed lambda limit)
Now we strip out any deps we know we don't need for the app which are
dev deps and not runtime required.
## Current Behavior
- Canary releases calculate their base version by incrementing the minor
of `nx@latest`, or using `nx@next` major when majors differ
- PR releases always use `0.0.0` as their base version (e.g.
`0.0.0-pr-1234-abc1234`)
- This means canary and PR versions don't clearly relate to the current
beta release line
## Expected Behavior
- Both canary and PR releases derive their base version directly from
`nx@next`
- If next is `22.5.0-beta.5`, then:
- Canary: `22.5.0-canary.20260204-abc1234`
- PR: `22.5.0-pr.1234.abc1234`
- All prerelease channels now share the same base version, making it
clear which release line they belong to
## Related Issue(s)
N/A - internal improvement to release infrastructure
## Current Behavior
The Maven plugin version is `0.0.12` across all pom.xml files and the
versions.ts constant. The `bump-maven-version` generator does not update
the `batch-runner-adapters` pom files, causing version mismatches.
## Expected Behavior
The Maven plugin version is bumped to `0.0.13` in **all** pom.xml files
(including batch-runner-adapters), with a migration created for users
upgrading to Nx `22.5.0-beta.4`. The bump generator now includes the
batch-runner-adapters pom files so future bumps won't miss them.
### Changes
- Updated version from `0.0.12` to `0.0.13` in all pom.xml files (root,
maven, maven-plugin, shared, batch-runner, batch-runner-adapters,
maven3-adapter, maven4-adapter)
- Updated `mavenPluginVersion` constant in
`packages/maven/src/utils/versions.ts`
- Added `update-0-0-13` migration entry in
`packages/maven/migrations.json` targeting Nx `22.5.0-beta.4`
- Created migration file
`packages/maven/src/migrations/0-0-13/update-pom-xml-version.ts`
- Fixed `bump-maven-version` generator to include
`batch-runner-adapters` pom files
## Current Behavior
The FreeBSD build in CI can fail silently or with unclear error messages
when:
- Disk space runs low during the build process
- The build command fails without proper error propagation
- Unnecessary files consume valuable disk space
## Expected Behavior
With these changes:
- Additional disk space is freed by removing docs/astro-docs/nx-dev
directories before building
- Build exit codes are properly captured and propagated
- Disk usage is logged after the build completes for debugging purposes
- Build failures are clearly reported with explicit error messages
This improves reliability and makes it easier to diagnose issues when
they occur.
## Related Issue(s)
<!-- No specific issue, general CI improvement -->
We're getting requests to `favicon.svg.md` that are being tracked,
ignore these. Also for the server page views, we should only count them
if `text/html` is in the accept header. Browsers will send these, and AI
agents, curl, etc. do not. This allows us to compare browser traffic vs
AI/curl traffic more accurately.
## Current Behavior
When a client disconnects while the daemon is writing a response, a
`socket.write` call triggers an EPIPE error. The old error handler used
`console.error`, which caused the error to propagate through
`respondWithErrorAndExit` and crash the daemon process via
`process.exit(1)`. The client would then see an `internalDaemonError`
and permanently disable the daemon via `markDaemonAsDisabled`, requiring
`nx reset` to recover.
Additionally, disconnected sockets were not cleaned up from the file
watcher and project graph listener registries on socket error events,
only on `close` events. This left a window where the daemon could
attempt to write to dead sockets during notifications.
## Expected Behavior
When a client disconnects mid-response:
- The `socket.write` callback logs the error gracefully via
`serverLogger` instead of `console.error`
- The daemon process stays alive and continues serving other clients
- The `socket.on('error')` handler cleans up registered file watcher and
project graph listener sockets immediately, matching the existing
`close` handler behavior
- The daemon is never permanently disabled due to EPIPE errors
## Related Issue(s)
<!-- No linked issue -->
### Current Behavior
The nx configure-ai-agents command output is minimal - just "AI agents
set up successfully" with a
bullet list of agent names. Users don't understand what was actually
configured (plugin vs MCP,
skills, which files were created/modified).
### Expected Behavior
Clearer feedback about what gets configured for each agent:
Selection prompt improvements:
- Agents needing updates show (update available) tag
- Footer always shows result state: what will be configured
- Agent-specific descriptions (e.g., "Installs Nx plugin (MCP + skills +
agents). Updates
CLAUDE.md.")
Post-configuration output:
- Compact summary per agent showing what was set up
- Example: Claude Code: Nx plugin (MCP + skills + agents) + CLAUDE.md
Claude .mcp.json cleanup:
- When configuring Claude, removes nx-mcp from .mcp.json since it's now
handled by the plugin
- Deletes the file entirely if nx-mcp was the only entry
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR fixes two issues:
1. When the README changes are amended, there's an edge case where we
don't have a commit to amend (e.g. `--skipGit`), and this fails the
entire CNW flow.
2. When user opts out of Cloud, we strip the entire `<!-- BEGIN:
nx-cloud -->` block in README rather than just the comments and leaving
the content.
Closes NXC-3812
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
There's not an easy to use service to track PIDs being registered to nx
tasks
## Expected Behavior
There's a service to track this stuff
## Related Issue(s)
## Current Behavior
The `getNpmPackageVersion` function in
`packages/workspace/src/generators/utils/get-npm-package-version.ts`
uses `execSync` with direct string interpolation of the `packageName`
parameter. When a user runs `create-nx-workspace` with a custom
`--preset` value that doesn't match a known preset, the value flows
unsanitized into a shell command:
```js
execSync(`npm view ${packageName}... version --json`)
```
This allows arbitrary command execution via shell metacharacters (e.g.,
`--preset='pkg$(malicious command)'`).
## Expected Behavior
User-supplied package names are validated against a strict npm package
name regex before being passed to any shell command. The function now
uses `execFileSync` with an args array instead of `execSync` with string
interpolation, providing defense in depth:
1. **Input validation** — rejects anything that isn't a valid npm
package name
2. **Safe execution** — arguments are passed as an array so Node.js
handles escaping, rather than concatenating into a raw shell string
## Current Behavior
Given a project name like `:foo`, you can run tasks like `nx test foo`
(note `foo` vs `:foo`), but passing --help throws an error
## Expected Behavior
`--help` works the same with the shortname vs full name
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
- `pom.xml` is only included as an input when a mojo uses default inputs
- Mojos with specific input configurations (like
`maven-compiler-plugin:compile`) don't get `pom.xml` in their inputs
- Parent `pom.xml` files aren't tracked as inputs
This can lead to stale cache hits when:
1. `pom.xml` changes but a mojo has specific input config
2. A parent `pom.xml` changes (affecting inherited properties,
dependency versions, plugin config)
## Expected Behavior
- Every target should include its own `pom.xml` as an input
- Every target should include ancestor `pom.xml` files (within the
workspace) as inputs
- Cache should invalidate when any relevant `pom.xml` changes
## Related Issue(s)
N/A - discovered during code review
## Changes
- **CacheConfig.kt**: Removed `pom.xml` from `defaultInputs` (now always
added explicitly)
- **MojoAnalyzer.kt**: Added `workspaceRoot` parameter and logic to walk
up the parent chain, adding all in-workspace ancestor `pom.xml` files as
inputs
- **NxProjectAnalyzerMojo.kt**: Pass `workspaceRoot` to `MojoAnalyzer`
## Current Behavior
When the daemon dies while processing a request, the reconnect logic
adds the retry back to the promise-based queue. However, the original
request is still blocked in the queue waiting for a response that will
never come (the socket is dead). This creates a deadlock:
1. Original request (`fn1`) is blocked awaiting a promise that will
never resolve
2. Retry request (`fn2`) is queued but can't execute until `fn1`
completes
3. `fn1` can't complete because it's waiting on the dead socket
## Expected Behavior
When reconnecting after daemon death, the retry should resolve the
pending promise that the original queue entry is waiting on, allowing
the queue to proceed normally.
## Related Issue(s)
<!-- No specific issue, discovered during development -->
## Solution
Instead of re-queuing the retry through `sendToDaemonViaQueue` (which
adds to the end of the queue), we now call `sendMessageToDaemon`
directly. This resolves the pending promise that `fn1` is waiting on,
allowing it to complete naturally and the queue to proceed.
Also removed the now-unused `decrementQueueCounter` method from
`PromisedBasedQueue`.
## Current Behavior
Only markdown and text file requests are tracked server-side via the
`track-asset-requests` edge function. HTML page views are not tracked on
the server, missing requests from AI tools and curl.
## Expected Behavior
Track all doc page views server-side with a new edge function that:
- Sends `server_page_view` events to GA4 with `content_type` param to
differentiate HTML/markdown/text
- Uses Netlify's `excludedPath` config for efficient path filtering
(zero compute for excluded paths)
- Skips non-HTML requests via Accept header check
### Changes
| File | Change |
|------|--------|
| `track-page-requests.ts` | **NEW** - Edge function for HTML page view
tracking on `/docs/*` |
| `track-asset-requests.ts` | Changed event name to `server_page_view`,
added `content_type` param |
| `add-link-headers.ts` | Refactored to use `excludedPath` config
instead of runtime path checks |
| `netlify.toml` | Added edge function declaration for
`track-page-requests` |
### GA Event Schema
```javascript
{
name: 'server_page_view',
params: {
content_type: 'text/html' | 'text/markdown' | 'text/plain',
file_extension: '.html' | '.md' | '.txt',
is_ai_tool: 'true' | 'false',
// ... other params
}
}
```
## Other Notes
This PR also removes the edge function entries from `netlify.toml` since
it's auto detected from `astro-docs/netlify/edge-functions`. This makes
all the configuration in the actual `.ts` file, not duplicated in the
`netlify.toml` file.
## Related Issue(s)
Closes DOC-395
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The Gradle executor accepts a taskName option that *should not* contain
multiple space-separated tasks. When multiple tasks are provided, the
batch runner misinterprets the space-separated string as containing
project names rather than treating it as a single task argument, leading
to execution errors and confusion.
This only occurs if the taskName is manually overridden and should not
occur when task names are generated by the project graph plugin.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Gradle executor now validates that taskName contains only a single
task without spaces. If multiple tasks are passed, it throws a clear
error message: "Task '[taskName]' contains spaces. Only a single Gradle
task is allowed per executor invocation." This prevents the batch runner
from misinterpreting the task name and provides immediate feedback to
users about the correct usage.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running Gradle tasks in batch mode with atomized targets, if the
same task appears multiple times in the output (which happens when tasks
are atomized and executed separately), the batch runner only captures
the output from the last execution. Previous executions' output gets
overwritten because the splitOutputPerTask function replaces the entire
output for each task name it encounters.
## Expected Behavior
All output from a task should be preserved, even when the task appears
multiple times in the batch output. When the same task name is
encountered multiple times, the outputs should be concatenated rather
than replaced, ensuring developers can see the complete execution
history for atomized targets.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Plan for fixing .NET incremental builds documentation
- [x] Update the "Target dependencies" section to remove `restore` from
the `dependsOn` array
- [x] Add explanation about why `restore` cannot be run through Nx for
solutions using custom frameworks
- [x] Improve explanation clarity based on review feedback
- [x] Verify the "Target configuration" section is consistent with the
changes
- [x] Complete code review and address feedback
- [x] Run security checks (no issues found)
- [x] Address PR feedback: Use JSX `<Aside>` component with import
statement instead of Markdoc tag
## Summary
Successfully fixed the documentation issue in the .NET incremental
builds guide. The changes made:
1. **Removed `restore` from the build target's `dependsOn` array** - The
documentation now correctly shows `"dependsOn": ["^build"]` instead of
`"dependsOn": ["restore", "^build"]`, matching the actual implementation
in the plugin code.
2. **Added a clear explanation** - Included an aside box explaining why
`restore` is not in the `dependsOn` array: because Nx requires NuGet
package restoration to be completed before running any tasks, and
including it would create a circular dependency.
3. **Verified consistency** - Checked that the "Target configuration"
section already showed the correct configuration, ensuring all
documentation is now consistent.
4. **Used correct Starlight component** - Changed from Markdoc `{% aside
%}` tag to JSX `<Aside>` component with proper import statement per
Starlight documentation standards.
The changes align with the actual implementation in
`packages/dotnet/analyzer/Utilities/TargetBuilder.Build.cs` where the
build target's `dependsOn` is set to `[$"^{targetName}"]` (line 56).
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>docs(dotnet): implied conflict in dependsOn of inferred
build task</issue_title>
> <issue_description>### Documentation issue
>
> <!-- (Update "[ ]" to "[x]" to check a box) -->
>
> - [ ] Reporting a typo
> - [ ] Reporting a documentation bug
> - [ ] Documentation improvement
> - [x] Documentation feedback
>
> <!--
> If your issue is not regarding the documentation, please choose an
issue type:
> https://github.com/nrwl/nx/issues/new/choose
> -->
>
> ### Is there a specific documentation page you are reporting?
>
>
https://nx.dev/docs/technologies/dotnet/guides/incremental-builds#target-dependencies
>
> ### Additional context or description
>
> The code sample provides in this doc includes `"dependsOn":
["restore", "^build"]`, but the automatically inferred `build` target
from this plugin does not actually include the `restore` target in the
dependsOn array. I assume this is by design? The docs seem to confuse it
a bit.
> </issue_description>
>
> <agent_instructions>Remove the `restore` target from the dependsOn
block. Add a small explanation that we can't run restore through Nx
because Nx requires restore to have been completed prior to running
tasks if the solution uses a custom framework</agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixesnrwl/nx#34150
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
## Current Behavior
When socket data chunks split a multibyte UTF-8 character (e.g., CJK
characters like Korean, Chinese, Japanese) at an arbitrary byte
boundary, `Buffer.toString()` decodes incomplete byte sequences as
replacement characters (�), causing message corruption.
This can occur when:
- File paths contain non-ASCII characters
- Project names include multibyte characters
- Any JSON message contains international text
## Expected Behavior
Multibyte UTF-8 characters should be properly decoded even when split
across multiple socket data chunks. The fix uses Node.js `StringDecoder`
which buffers incomplete multibyte sequences until the remaining bytes
arrive.
## Related Issue(s)
Fixes socket message corruption for paths/names containing multibyte
characters.
- fix(nx-dev): always link headers regardless of mdoc or markdown
content source (generated vs static file)
- fix(nx-dev): make option/property columns in table linkable
- the table column header is matched on `options`, `option`,
`properties`, and property` (case insensitive)
https://github.com/user-attachments/assets/7250b9d5-1030-4ebc-9e21-0a05f295bbf5
Note bc mdoc and `renderMarkdown` go through 2 different rendering
pipelines, this logic must bc within the markdoc config and rehype
(markdown) processing logic. tried to shared logic where I could
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
After completing the CNW (Create Nx Workspace) flow with Nx Cloud, users
see a plain text completion message with a link to finish setup.
## Expected Behavior
Users now see one of four completion message variants controlled by
`NX_CNW_FLOW_VARIANT`:
- **Variant 0**: Plain link (control) - always used for enterprise URLs
- **Variant 1**: "Try the full Nx platform" decorative ASCII banner
- **Variant 2**: "Unlock 70% faster CI" decorative ASCII banner
- **Variant 3**: "Reclaim your team's focus" decorative ASCII banner
Key changes:
- Added enterprise URL detection (non-standard Nx Cloud URLs always get
variant 0)
- Locked the cloud prompt to always show "Try the full Nx platform?" (no
longer varies by flow variant)
- Flow variant now only affects the completion banner, not the prompt
- Added `snapshot.nx.app` to standard Nx Cloud hosts
- Removed variant 2 auto-connect behavior (all variants now prompt)
## Screenshots
Variant 0:
<img width="1392" height="1065" alt="variant0"
src="https://github.com/user-attachments/assets/0b18686e-1481-4fc0-995e-1577052887ff"
/>
Variant 1:
<img width="1392" height="1065" alt="variant1"
src="https://github.com/user-attachments/assets/e5909e2e-e1d8-4d04-9721-ba6186d06891"
/>
Variant 2:
<img width="1392" height="1065" alt="variant2"
src="https://github.com/user-attachments/assets/7e9f819f-e3c0-44d7-9760-0cab1d5dd9ac"
/>
Variant 3:
<img width="1392" height="1065" alt="variant3"
src="https://github.com/user-attachments/assets/83f0499f-d807-4dc8-9390-c7eec93590a9"
/>
## Related Issue(s)
Closes CLOUD-4147
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Enable Gradle executor to run tasks in batch mode in CI.
## 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 #
We're showing over 8 GB of memory usage on Netlify, and 11+ GB on
Agents. Let's test out a few ways to reduce the memory footprint.
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Preload vitest/node ESM module early in
buildViteTargets/buildVitestTargets
functions before parallel processing occurs. This prevents the
ERR_INTERNAL_ASSERTION error that occurs when multiple vitest.config
files
are processed in parallel on Node 24+.
Fixes#34028Fixes#33091
## Current Behavior
The `runCommandUntil` e2e utility function waits indefinitely for the
expected output to appear. If the output never appears (e.g., server
fails to start, different output format, port conflict), the test hangs
forever, causing CI jobs to run for hours before being killed.
## Expected Behavior
The function should timeout after a configurable duration and fail with
a clear error message showing what output was received.
## Related Issue(s)
Fixes hanging e2e tests observed in CI (e.g.,
`e2e-node:e2e-ci--src/node-server.test.ts` hung for 1h 21m).
## Changes
- Added optional `timeout` parameter to `runCommandUntil` opts (default:
5 seconds)
- On timeout: kills the process, logs the collected output, and rejects
with a clear error
- Existing call sites work unchanged; tests needing more startup time
can pass `{ timeout: 30000 }`
---------
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: FrozenPandaz <8104246+FrozenPandaz@users.noreply.github.com>
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
1. The `check-links` task cache inputs only included `sitemap.xml` (the
index
file) and `sitemap-index.xml`, but not the actual `sitemap-0.xml` files
that
contain the URL data. This meant that when pages were added or removed,
the
cache wasn't properly invalidated - the check-links task would return a
cached "passing" result even when broken links existed.
2. The `/launch-nx` page was removed in #34183 but one link in
`astro-docs/src/content/docs/reference/Nx Cloud/release-notes.mdoc`
still
pointed to it. This link was masked by being in the `validate-links.ts`
ignore list.
## Expected Behavior
1. The `check-links` task cache is invalidated when sitemap URLs change
by
using glob patterns (`sitemap*.xml`) to include all sitemap files.
2. All links point to valid pages. The `/launch-nx` link now redirects
to
`/blog/launch-nx-week-recap`.
## Changes
- **astro-docs/release-notes.mdoc**: Updated `/launch-nx` link to
`/blog/launch-nx-week-recap`
- **astro-docs/validate-links.ts**: Removed `/launch-nx` from ignore
list (no longer needed)
- **nx-dev/project.json**: Fixed cache inputs to use `sitemap*.xml` glob
patterns
## Related Issue(s)
Fixes DOC-385
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
With Vite now providing additional options (environments etc) for
framework authors, vite.config files can be much more simple for the
user.
However, this often assumes that the `root` property will be set and
provided during `Vite CLI` invocation.
When we run `resolveConfig` to determine inputs and outputs, we do not
set this `root` and expect the user to have it in their vite config
file.
For some plugins/frameworks such as Tanstack Start - this causes the
plugin to error.
The `isBuildable` conditions is also not inclusive enough and can skip
projects that should be marked as buildable.
## Expected Behavior
Ensure that sophisticated vite plugins are supported with Nx
## Related Issue(s)
CLOSES NXC-3637
## Current Behavior
Template-generated workspaces use a generic link in the README instead
of a per-workspace short link for Nx Cloud setup.
## Expected Behavior
When users opt into Nx Cloud (or are auto-connected via variant 2), the
template README is updated with a personalized connect URL section that
helps them finish setting up their workspace.
---
BEFORE:
<img width="762" height="460" alt="image"
src="https://github.com/user-attachments/assets/58900071-1727-49d1-aa19-279c488b5037"
/>
AFTER:
<img width="1032" height="599" alt="image"
src="https://github.com/user-attachments/assets/a6e3a122-5807-4ba2-90dd-441e41a3280e"
/>
---
## Related Issue(s)
Closes NXC-3783
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
deno worker.stdout is a Readable/Writeable. To provide better deno
support an error should not be thrown
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
If `worker.stdout` or `worker.stderr` are not instanceof Socket then nx
throws an error. This is problematic in Deno where `stdout` and `stderr`
are Readable/Writable and not Socket.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`startupPluginWorker` function should work in Deno runtime
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
- https://github.com/denoland/deno/issues/31961
- https://github.com/oven-sh/bun/issues/26505
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
## Current Behavior
Plugin workers occasionally fall over during the start up steps.
## Expected Behavior
Improves some issues with the error handling when loading plugin workers
and adds some more logs to help understand what's went wrong here.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remove redundantly placed period and make error message construction
more readable when facing AggregateError
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3766
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
--rerun is not tooling api compatible and therefore will break usage of
the batch executor. Replaced the flag with --rerun-tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Maven batch runner bundles Maven 4 classes at compile time, which:
- Creates a large JAR file (~50+ MB)
- Only works with Maven 4
- Has classloader conflicts with Maven's own SLF4J
## Expected Behavior
The batch runner loads Maven classes at runtime from `MAVEN_HOME`,
which:
- Creates a small JAR (~2 MB) with no bundled Maven dependencies
- Works with both Maven 3.x and Maven 4.x
- Avoids classloader conflicts by isolating Maven in its own ClassRealm
- Outputs clean Maven-style logs (`[INFO]`, `[WARNING]`, etc.)
## Implementation
### Architecture
```
batch-runner.jar (NO Maven dependencies)
├── MavenClassRealm → Loads Maven JARs from MAVEN_HOME at runtime
├── ResidentMavenExecutor → Maven 4 executor (reflection-based)
├── CachingMaven3Invoker → Maven 3 executor (reflection-based)
└── nx-maven-adapters/ → Pre-compiled adapter JARs (embedded as resources)
├── batch-runner-adapters-maven3.jar
└── batch-runner-adapter-maven4.jar
```
### Key Changes
1. **Removed compile-time Maven dependencies** from batch-runner module
2. **Created batch-runner-adapters** modules for Maven 3 and Maven 4
specific code
3. **Implemented MavenClassRealm** to load Maven JARs from MAVEN_HOME at
runtime
4. **Implemented reflection-based executors** that load adapter JARs
into ClassRealm
5. **Fixed SLF4J logging** with System.out redirection for clean
Maven-style output
6. **Added shared module** for BuildStateManager, BuildStateApplier, and
BuildStateRecorder
### Benefits
- **Version agnostic**: Same JAR works with Maven 3.x and 4.x
- **Graph caching**: Project dependency graph built once, reused across
tasks
- **Build state persistence**: compile → package → install works
correctly
- **No classloader conflicts**: Maven's classes isolated in their own
ClassRealm
- **Clean output**: Standard Maven log format without SLF4J noise
## Related Issue(s)
N/A - Internal refactoring for better Maven version support
---------
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
LLMs and CLI tools must explicitly request the `.md` URL suffix to get
raw markdown content from documentation pages.
## Expected Behavior
When a client requests a docs page with `Accept: text/markdown` header,
the edge function rewrites to serve the `.md` version directly (no
redirect). This enables LLM tools to get markdown content by requesting
the standard URL.
Behavior:
- `Accept: text/markdown` → serves .md content (via rewrite, no
redirect)
- Default (browsers) → serves HTML with Link headers (unchanged)
Examples:
```
curl -H 'Accept: text/markdown' https://deploy-preview-34239--nx-docs.netlify.app/docs/getting-started/intro
curl -H 'Accept: text/markdown' https://deploy-preview-34239--nx-docs.netlify.app/docs/getting-started/tutorials/angular-monorepo-tutorial
```
Uses Netlify Edge Function rewrite (returns URL object) instead of
redirect for single-request response that works with all HTTP clients.
## Related Issue(s)
Closes DOC-389
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
broken links
## Expected Behavior
links aren't broken any more and are updated to expected pages from docs
page.
## Related Issue(s)
Fixes DOC-391
This PR adds:
1. `llms-full.txt` that is a full copy of our docs in markdown.
2. HTTP `Link` headers to our docs HTML pages so that they point to the
`.md` (markdown) version, and also to `llms.txt` and `llms-full.txt`.
The `llms-full.txt` is currently at 2.7 MB, which is much less than
other sites that are up to 5MB or more.
<img width="569" height="35" alt="Screenshot 2026-01-27 at 12 11 10 PM"
src="https://github.com/user-attachments/assets/61be02b4-2813-4c39-951c-d831af83e823"
/>
First 100 lines of `llms-full.txt`:
````
# Nx Documentation
> Complete Nx documentation compiled into a single file for LLM consumption.
Nx is a powerful, open source, technology-agnostic build platform designed to efficiently manage codebases of any scale. From small single projects to large enterprise monorepos, Nx provides intelligent task execution, caching, and CI optimization.
This file was generated from 503 documentation pages.
Individual pages are available at: https://nx.dev/docs/{slug}.md
# Quickstart
---
<!-- source: https://nx.dev/docs/quickstart.md -->
## Quickstart with Nx
Get up and running with Nx in just a few minutes by following these simple steps.
{% steps %}
1. Install the Nx CLI
Installing Nx globally is **optional** - you can use `npx` to run Nx commands without installing it globally, especially if you're working with Node.js projects.
{% tabs syncKey="install-method" %}
{% tabitem label="npm" %}
```shell
npm add --global nx
```
**Note:** You can also use Yarn, pnpm, or Bun
{% /tabitem %}
{% tabitem label="Homebrew (macOS, Linux)" %}
```shell
brew install nx
```
{% /tabitem %}
{% tabitem label="Chocolatey (Windows)" %}
```shell
choco install nx
```
{% /tabitem %}
{% tabitem label="apt (Ubuntu)" %}
```shell
sudo add-apt-repository ppa:nrwl/nx
sudo apt update
sudo apt install nx
```
{% /tabitem %}
{% /tabs %}
2. Start fresh or add to existing project
For JavaScript-based projects you can **start with a new workspace** using the following command:
```shell
npx create-nx-workspace@latest
```
**Add to an existing project: (recommended also for non-JS projects)**
```shell
npx nx@latest init
```
**Get the complete experience:**
For a fully integrated development workflow with AI-powered CI features, [start directly from Nx Cloud](https://cloud.nx.app/get-started).
Learn more: [Start New Project](/docs/getting-started/start-new-project) • [Add to Existing](/docs/getting-started/start-with-existing-project) • [Complete Nx Experience](https://cloud.nx.app/get-started)
3. Run Your First Commands
Nx provides powerful task execution with built-in caching. Here are some essential commands:
**Run a task for a single project:**
```shell
nx build my-app
nx test my-lib
```
**Run tasks for multiple projects:**
```shell
nx run-many -t build test lint
```
Learn more: [Run Tasks](/docs/features/run-tasks) • [Cache Task Results](/docs/features/cache-task-results)
4. What's next?
Now that you've experienced the Nx basics, choose how you want to continue:
````
## Related Issue(s)
Closes DOC-236
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This design refresh emphasizes the contrast variant aesthetic across all
hero sections, pricing cards, and primary call-to-actions.
- Change 47 instances of variant="primary" to variant="contrast"
- Update ui-courses to use variant="secondary" for GitHub link
- Prefer high-contrast inverted style for primary CTAs
- Maintain proper visual hierarchy with secondary actions
- Replace all slate-* classes with zinc-* equivalents (1,158 instances)
- Replace all sky-* classes with blue-* equivalents (210 instances)
- Update opacity variants, gradients, rings, and borders
- Maintain full dark mode compatibility
## Current Behavior
If something is in `package.json#dependencies`, we still suggest it to
be `nx add`-ed during `nx import`
## Expected Behavior
If a plugin is already installed, we don't suggest it anymore
`@nx/web:app` generator is incorrectly calling `createOrEditViteConfig`
when bundler != vite and unitTestRunner = vitest.
Ensure it is using the correct file
## Current Behavior
The migration for svgr requires using file-loader which is unmaintained.
## Expected Behavior
Use asset/resource instead of file-loader
## Related Issue(s)
CLOSES NXC-3667
## Summary
- When `/tmp` is mounted with `noexec`, loading native modules from the
cache fails silently and causes Nx to hang indefinitely
- This adds a fallback to load from `node_modules` when permission
errors occur
## Problem
Users with `/tmp` mounted with `noexec` (a common security hardening
practice) experience Nx hanging forever, even for simple commands like
`nx --version`.
The root cause:
1. Nx copies native `.node` files to `/tmp` to avoid Windows file
locking issues
2. On `noexec` mounts, execution fails with `EACCES`/`EPERM`
3. The error wasn't caught, leading to broken native bindings and
infinite loops
## Solution
Catch permission errors when loading from the cache and fall back to the
original `node_modules` location. This:
- Works automatically without user config
- Preserves Windows file locking fix (only falls back when needed)
- No error messages for users
Closes#33991
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Schema validation (done, for instance, when calling an executor) fails
when an option has value "null" and schema accepts null values. I had it
in a custom executor for `nx-release-publish`, that understands that
`nxReleaseVersionData` is implicitly passed, so I define its schema:
```json
"newVersion": {
"type": ["string", "null"],
"description": "The new version of the project, null if no changes detected"
}
```
My code calls `getReleaseClient().releaseVersion(options)`, which gets
me a `projectsVersionData` object with version info. It contains `null`
values (allowed). I then pass it, and ends up in:
```typescript
// nx/src/tasks-runner/task-orchestrator.ts:531-539
const combinedOptions = combineOptionsForExecutor(
task.overrides, // ← Contains nxReleaseVersionData with null values
task.target.configuration,
targetConfiguration,
schema, // ← Schema from executor
task.target.project,
relativeCwd,
isVerbose
);
```
which fails inside:
```typescript
// nx/src/utils/params.js:126-201
function validateObject(opts, schema, definitions) {
// Line 191-200: Iterate through all properties
Object.keys(opts).forEach((p) => {
validateProperty(
p, // "nxReleaseVersionData"
opts[p], // { foo: { newVersion: null, ... }}
(schema.properties ?? {})[p], // schema for nxReleaseVersionData
definitions
);
});
}
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
`null` values should be considered, as they are valid in JSON schemas. It was probably not considered, because we never think that `typeof null === "object"`, but it's unfortunately the case.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
I will create one
Fixes https://github.com/nrwl/nx/issues/34169
Transpiling through SWC or ts-node is slow compared to the native type
stripping that Node.js provides.
This PR adds `NX_PREFER_NODE_STRIP_TYPES` to allow users to use Node.js
built-in TypeScript support. There are some features that need
transpilation that won't work with type stripping:
- Enum declarations
- namespace with runtime code
- legacy module with runtime code
- parameter properties
- path aliases
See: https://nodejs.org/api/typescript.html#full-typescript-support
The speed-up is significant. My test workspace went from 22s to ~2s to
compute from cold cache.
Demo: https://www.loom.com/share/ce1db29e501b46d58109ffeec8a7a649
In the future we should enable this by default, and users have to turn
it off to use SWC/ts-node.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
Right now GA only collects page views. This PR allow us to see which
`.md` files are being used. There are mostly useful for AI agents to
fetch without using too many tokens. We want to track usage so we can
see what techniques to guide agents actually work.
## Related Issue(s)
Closes DOC-386
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
This PR makes it so Cloud commands like `npx nx record` and `npx nx
fix-ci` still work without `nxCloudId`. We'll log a warning so that
`ci.yml` using these commands will still work. The warning let's users
know that these do not work without being connected.
Closes #NXC-3753
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Commit linting does not mention requirement for commit message to be
lowercase.
<!-- This is the behavior we have today -->
## Expected Behavior
Hook message should instruct user to use all lowercase for commit
message.
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Self-healing docs only reference being supported for GitHub, Azure, and
GitLab.
<!-- This is the behavior we have today -->
## Expected Behavior
We should show instructions for all currently supported vcs providers,
including Bitbucket.
<!-- 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
Resizing the TUI while in inline view kinda breaks things. Its
unfortunate, I'm not sure there's a ton to be done, but this PR explores
some solutions
## Expected Behavior
The TUI is less sensitive to resize events with inline mode
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The create-nx-workspace (CNW) command includes A/B testing variant 1
which skips the cloud prompt under certain conditions.
## Expected Behavior
Revert to the previous behavior where the cloud prompt flow is
consistent without the A/B testing variant.
## Related Issue(s)
This reverts commit 2039a5e119 from PR
#34106.
## Current Behavior
The internal link checker reports 3 broken links pointing to
`/launch-nx`:
- `/blog/2024-02-05-nx-18-project-crystal.md`
- `/blog/2024-02-15-launch-week-recap.md`
- `/changelog/18_0_0.md`
The `/launch-nx` page was a temporary page for the Nx 18 launch event in
February 2024 and no longer exists.
## Expected Behavior
All internal links should point to valid pages. Links to the old launch
page now redirect to the Launch Nx Week recap blog post.
## Related Issue(s)
Fixes the internal link checker errors.
## Current Behavior
There's a hard to reproduce hang that happens occasionally when running
the TUI
## Expected Behavior
We think this should fix it
## 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>
The `banner.json` was committed as a fallback if we're not using Framer
to control the banner yet on nx.dev. Now that it is verified we can
remove the committed file.
Closes DOC-381
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Previously, `nx reset --onlyDaemon` would only stop the daemon process
but not clean up the daemon files in `.nx/workspace-data/d`. This change
ensures the daemon workspace data directory is also removed when using
the `--onlyDaemon` flag, consistent with the behavior of a full reset.
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
This PR updates the releases page so v22 is included.
Closes #DOC-382
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
1. When running a task with dependencies (e.g., `nx serve app` where app
depends on app2:serve), the initiating task might not be selected on
startup. Additionally, the auto-select logic could switch selection to
the initiating task at any time when it started running - even minutes
later - which felt "random" to the user.
2. When pressing Enter on an already-pinned task, it would unpin the
task, causing the pane to disappear while focus remained on it
(invisible-but-focused state).
## Expected Behavior
1. The initiating task (the one the user actually requested) should be
selected during init, and selection should never unexpectedly change
later when tasks start.
2. Pressing Enter on an already-pinned task should focus the pane, not
unpin it.
## Changes
- **Select initiating task during init**: Moved initiating task
selection to `init()` in app.rs. This only applies in `RunOne` mode
since in `RunMany` there's no single initiating task to prioritize.
Removed the "switch to initiating task" logic from `start_tasks()` in
tasks_list.rs.
- **Focus pane on Enter**: Changed behavior so pressing Enter on an
already-pinned task focuses the pane instead of unpinning it.
## Related Issue(s)
N/A - discovered during TUI testing
# Current Behavior
The `beforeCompile` hook is registered inside the `watchRun` hook,
causing a new handler to be added on every recompilation. This leads to
handler accumulation, where setup operations (building static remotes,
starting file server, starting proxies) are triggered multiple times
during watch mode.
# Expected Behavior
Hooks should be registered once, outside of other hooks, to prevent
accumulation. Setup operations should only run once, not on every
recompilation.
# Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/34141
# Current Behavior
1. **Performance bottleneck**: `statsValue.toJson()` is called with no
options, causing full serialization of all stats data on every build.
This is expensive and unnecessary when only budget checking is needed.
2. **Redundant work**: Budget checking code runs even when no budgets
are configured or when targeting server platform.
3. **User stats config ignored**: Custom stats configuration provided
via `rspackConfigOverrides` is not respected by the stats logger.
4. **Double serialization**: `rspackStatsLogger` calls `stats.toJson()`
without passing the stats options, ignoring user preferences.
# Expected Behavior
1. Only serialize what's needed for budget checking (`assets` and
`chunks`), significantly reducing overhead.
2. Early exit when budgets are not configured or on server platform,
skipping expensive `toJson()` entirely.
3. User's stats configuration is merged with defaults and respected
throughout the build output.
4. `rspackStatsLogger` uses the provided `statOptions` when serializing
stats.
# Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/34145
## Current Behavior
CNW always shows the "Try the full Nx platform?" prompt and connects to
Nx Cloud to generate an onboarding URL with a token.
## Expected Behavior
For A/B testing variant 1:
- Skip cloud prompt
- Skip connectToNxCloudForTemplate() - no nxCloudId in nx.json
- Skip readNxCloudToken() - no misleading spinner
- Use GitHub flow for URL generation (accessToken: null)
- Show github.com/new hint when user hasn't pushed
Also fixes:
- Expired cache file bug: now deletes with unlinkSync() instead of
ignoring, which caused 50-50 randomization after 1-week expiry
- Adds variant-X to short URL meta property for cloud analytics
## Related Issue(s)
Closes NXC-3628
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
`getNxRequirePaths` returns paths in the order `[root,
getNxInstallationPath(root)]`, which means the workspace root is checked
first when resolving modules.
## Expected Behavior
The nx installation path (`.nx/installation`) should be prioritized and
checked first before falling back to the workspace root. This ensures
that modules from the nx installation directory take precedence.
## Related Issue(s)
N/A
# Current Behavior
The Angular Rspack compiler's `ComponentStylesheetBundler` does not
receive Tailwind or PostCSS configuration. This means Tailwind
directives (like `@apply`, `@tailwind`) in component stylesheets are not
processed, resulting in broken styles.
# Expected Behavior
Component stylesheets should support Tailwind CSS and PostCSS
configurations, matching the behavior of the standard Angular CLI build
process.
# Related Issue(s)
https://github.com/nrwl/nx/issues/34098
# Current Behavior
1. **Handler accumulation**: The `compilation`, `beforeCompile`, and
`done` hooks are registered inside `watchRun`, causing new handlers to
be added on every rebuild cycle. This leads to performance degradation
and duplicate operations during watch mode.
2. **Double rebuilds**: Rapid filesystem events (e.g., editor
backup/swap files) trigger multiple rebuilds because there's no
aggregation timeout configured.
3. **No watchOptions configuration**: Users cannot customize watcher
behavior (aggregateTimeout, ignored patterns, etc.).
# Expected Behavior
1. Hooks should be registered once outside of `watchRun` to prevent
accumulation. Shared state is used to pass data between watch cycles and
compilation hooks.
2. A default `aggregateTimeout: 50` batches rapid filesystem events to
prevent double rebuilds.
3. Users can provide custom `watchOptions` to configure watcher
behavior, with user options taking precedence over defaults.
# Related Issue(s)
https://github.com/nrwl/nx/issues/34142#issuecomment-3767571208
## Current Behavior
New task processes show 0% CPU on their first measurement because no
baseline exists. Accurate readings only appear on the second collection
cycle (~1s later).
## Expected Behavior
New task processes get accurate CPU readings on their first measurement.
The collector establishes CPU baselines for newly registered processes
~250ms before collection, giving `sysinfo` enough time to calculate
accurate CPU deltas.
## Technical Details: Baselining & Collection Flow
The collection loop runs in 4 phases:
```
T=0ms T=750ms T=1000ms T=1750ms T=2000ms
| | | | |
v v v v v
Collect → Sleep(750ms) → Baseline → Sleep(250ms) → Collect → ...
```
1. **Collect**: Refresh all processes and gather metrics
2. **Post-collection sleep**: Wait until baseline time (interval -
250ms)
3. **Baseline**: Bulk CPU refresh for newly registered PIDs (if any)
4. **Pre-collection sleep**: Wait 250ms for accurate CPU delta
calculation
## Current Behavior
if inline tui init fails, we panic
## Expected Behavior
If inline tui init fails, inline mode is disabled. We show the reason
its disabled when someone tries to use it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When exiting the TUI (especially via Ctrl+C), escape sequences leak to
the terminal:
```
^[]11;rgb:2121/2121/2121^[\^[[55;1R^[[?62;22;52c
```
This happens because the TUI queries terminal background color via OSC
11 to detect dark/light mode. The terminal responds with an escape
sequence, but if the program exits before fully consuming the response,
it appears in the terminal output.
## Expected Behavior
Clean terminal state after TUI exits, with no escape sequence artifacts.
## Related Issue(s)
N/A - discovered during development
## Solution
Added `drain_stdin()` function that polls and consumes any pending
terminal events before disabling raw mode. This clears any lingering OSC
responses (like the background color query response) before the terminal
is restored.
```rust
fn drain_stdin() {
use std::time::Duration;
while crossterm::event::poll(Duration::from_millis(5)).unwrap_or(false) {
let _ = crossterm::event::read();
}
}
```
The 5ms timeout is long enough to catch pending responses but short
enough not to noticeably delay exit.
## Current Behavior
When the daemon encounters a project graph error during task hashing, it
extracts the partial project graph from the error and continues hashing
tasks. This can produce incorrect hashes since the graph is incomplete.
## Expected Behavior
The error should be thrown immediately, preventing any hashing attempts
with an invalid project graph. This ensures we don't produce incorrect
task hashes that could lead to cache issues.
## Related Issue(s)
N/A - Bug fix discovered during development
## Current Behavior
The `rollup-plugin-postcss` has not released a new version in 4 years.
The deps it depends on are outdated and starting to cause problems with
peer-dep conflicts.
## Expected Behavior
Recreate the plugin within the `@nx/rollup` package to maintain the
functionality/behaviour and manage dependencies ourselves.
## Related Issue(s)
Closes NXC-3644
---------
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
Running `nx test` with Vitest browser mode fails with error:
> "The browser configuration must have a 'name' property"
Array configs like `browser.instances` and `reporters` get duplicated,
breaking tests.
## Expected Behavior
Vitest browser mode and array configurations work correctly without
duplication.
## Related Issue(s)
Fixes#33591
## Current Behavior
Nx's AI agent detection currently identifies Claude Code, Repl.it, and
Cursor AI agents via environment variables, but does not detect
OpenCode.
## Expected Behavior
Nx should also detect when running under OpenCode AI agent by checking
for the `OPENCODE` environment variable, which OpenCode sets to `1` when
active.
## Related Issue(s)
N/A - Feature addition to improve AI agent detection coverage.
## Changes
- Added `is_opencode_ai()` function in
`packages/nx/src/native/utils/ai.rs`
- Updated `is_ai_agent()` to include OpenCode detection
- Added corresponding unit tests
## Current Behavior
For optional packages that are not installed when using yarn, we
currently add the package version to the key for the hash. NPM and PNPM
do not do this.
The results in inconsistent hashes for package dependencies when running
in different environments. For example, trying to use the cache created
in CI on linux on a mac where native dependencies are used.
**yarn on arm mac**
_note how the key has the version in it for the linux and x64 versions
that are not installed_
```
$ nx test foo | grep @nx/nx-
...
"npm:@nx/nx-darwin-x64@22.3.3": "14042642002999097748",
"npm:@nx/nx-linux-x64-gnu@22.3.3": "12169496858981304476",
"npm:@nx/nx-darwin-arm64": "1683411334940043113",
```
**npm on arm mac**
```
$ nx test foo | grep @nx/nx-
...
"npm:@nx/nx-darwin-x64": "14042642002999097748",
"npm:@nx/nx-darwin-arm64": "1683411334940043113",
"9980946580833020728",
"npm:@nx/nx-linux-x64-gnu": "12169496858981304476",
```
**pnpm on arm mac**
```
$ nx test foo | grep @nx/nx-
...
"npm:@nx/nx-darwin-arm64": "1683411334940043113",
"npm:@nx/nx-darwin-x64": "14042642002999097748",
"npm:@nx/nx-linux-x64-gnu": "12169496858981304476",
```
## Expected Behavior
Optional dependencies should be handled the same way from a hashing
perspective as installed dependencies.
**yarn on arm mac**
```
$ nx test foo | grep @nx/nx-
...
"npm:@nx/nx-darwin-x64": "14042642002999097748",
"npm:@nx/nx-linux-x64-gnu": "12169496858981304476",
"npm:@nx/nx-darwin-arm64": "1683411334940043113",
```
On test repo reduces the
`nx/js/dependencies-and-lockfile:createDependencies`:
- from `10506ms`
- to `3665ms`
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
CPU metrics collection can report inaccurate values where:
- Individual processes show inflated CPU usage
- Total CPU aggregation across all processes exceeds the system's
maximum available CPU
- This leads to confusing and misleading metrics data
## Expected Behavior
CPU metrics accurately reflect actual resource usage:
- Process CPU values are accurate
- Total CPU aggregation stays within system limits
- Metrics data is reliable and trustworthy
### Additional Notes
- **Root cause**: When registering a new process, we established a CPU
baseline by refreshing only that single process via `sysinfo`.
Internally, `sysinfo` calculates CPU% as `(process_cpu_time_delta /
wall_time_delta) * 100`. Refreshing a single process updates the wall
time reference but leaves the CPU time baselines of other processes
unchanged. In the next metrics collection, these other processes appear
to have consumed their CPU time over a shorter wall time period (based
on the last baseline), resulting in inflated percentages (e.g., 200%+
for single-threaded processes).
- This PR also improves initialization performance by only loading
necessary system data (processes, CPU, memory) instead of all system
information
- Upgrades `sysinfo` dependency to v0.37.2, which includes upstream CPU
measurement improvements.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Marketing pages (homepage, /react, /java, etc.) do not track scroll
depth. Only docs pages have scroll tracking via the ScrollableContent
component.
## Expected Behavior
Marketing pages now track scroll depth and fire scroll_0, scroll_25,
scroll_50, scroll_75, scroll_90 events to Google Analytics, matching the
existing docs page behavior.
## Related Issue(s)
Closes DOC-376
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
The inline tui runs some terminal escape codes to check cursor position,
these break when stdin isn't a tty (like in a git hook)
## Expected Behavior
The inline tui is disabled if stdin isn't a tty
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The `migrations.json` file in the `@nx/maven` package is not included in
the `files` array in `package.json`. This means when the package is
published to npm, the migrations file is not included, preventing users
from running migrations.
## Expected Behavior
The `migrations.json` file should be included in the published package
so that Nx can discover and run migrations when users upgrade.
## Related Issue(s)
N/A - discovered during development
Exclude some handwritten files from the native build outputs. When those
files are updated in isolation, the build can replace them with stale
cached outputs. This is because they are not inputs of the native
builds, but are incorrectly stored as outputs of the native builds.
## Current Behavior
When using pnpm aliases, the project graph may miss the actual
dependency node (the aliased package overwrites it), resulting in
incomplete or confusing dependency graphs.
## Expected Behavior
The project graph should include both the alias and the actual
dependency node, matching the behavior of other package managers.
## Current Behavior
No daemon info is provided in `nx report`, but some issues are
exasperated by the daemon or may only show if the daemon is disabled.
This is useful context that we currently lack.
## Expected Behavior
`nx report` includes if the daemon is available, enabled but not
started, or disabled.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Running `nx show project` without specifying a project name fails, even
when inside a project directory:
```bash
cd packages/my-lib
nx show project
# Error: requires projectName argument
```
## Expected Behavior
When run from within a project directory, `nx show project` infers the
project from the current working directory:
```bash
cd packages/my-lib
nx show project # Shows my-lib configuration and targets
nx show project --json # Outputs JSON for my-lib
```
Explicit project name still works:
```bash
nx show project other-project
```
If cwd is not within any project, shows a helpful error with usage
instructions.
### Changes
- `command-object.ts`: Make `projectName` positional arg optional
(`[projectName]`)
- `project.ts`: Infer project from cwd using `findProjectForPath` when
no project specified
- `project.spec.ts`: Add unit tests for cwd inference, nested
directories, root projects, and error cases
## Related Issue(s)
Fixes#31055
> [!WARNING]
>
> <details>
> <summary>Firewall rules blocked me from connecting to one or more
addresses (expand for details)</summary>
>
> #### I tried to connect to the following addresses, but was blocked by
firewall rules:
>
> - `repo.gradle.org`
> - Triggering command: `/usr/lib/jvm/temurin-17-jdk-amd64/bin/java
/usr/lib/jvm/temurin-17-jdk-amd64/bin/java
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.lang.invoke=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED
--add-opens=java.base/java.nio.charset=ALL-UNNAMED
--add-opens=java.base/java.net=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED
--add-opens=java.xml/javax.xml.namespace=ALL-UNNAMED
-XX:MaxMetaspaceSize=384m -XX:+HeapDumpOnOutOfMemoryError -Xms256m
-Xmx512m -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en` (dns
block)
> - `staging.nx.app`
> - Triggering command: `/usr/local/bin/node node ./bin/post-install`
(dns block)
> - Triggering command: `/usr/local/bin/node /usr/local/bin/node
/home/REDACTED/work/nx/nx/node_modules/.pnpm/nx@22.2.0-beta.1_@swc-node+register@1.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@swc+typ_e0638a3d25d549ce0cdd3a7d8bad3b61/node_modules/nx/src/project-graph/plugins/isolation/plugin-worker
/tmp/plugin3517-16-424.353971.sock @nx/enterprise-cloud` (dns block)
> - Triggering command: `/usr/local/bin/node /usr/local/bin/node
/home/REDACTED/work/nx/nx/node_modules/.pnpm/nx@22.2.0-beta.1_@swc-node+register@1.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@swc+typ_e0638a3d25d549ce0cdd3a7d8bad3b61/node_modules/nx/src/project-graph/plugins/isolation/plugin-worker
/tmp/plugin4274-16-431.526748.sock @nx/enterprise-cloud` (dns block)
>
> If you need me to access, download, or install something from one of
these locations, you can either:
>
> - Configure [Actions setup
steps](https://gh.io/copilot/actions-setup-steps) to set up my
environment, which run before the firewall is enabled
> - Add the appropriate URLs or hosts to the custom allowlist in this
repository's [Copilot coding agent
settings](https://github.com/nrwl/nx/settings/copilot/coding_agent)
(admins only)
>
> </details>
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>Feature: allow `nx show targets` to infer project from
the cwd</issue_title>
> <issue_description>### Description
> When I'm already working inside a project's folder (for example
`github/abapify/packages/adk` that has its own `project.json`), I would
love to ask Nx to list the targets that belong to that project without
having to remember or type the project name. Ideally `npx nx show
targets` could detect the `project.json` in the current working
directory and operate on that project automatically.
>
> ### Current behavior
> Running the command from inside a project directory fails because the
CLI insists on a `--project` argument:
>
> ```
> $ cd github/abapify/packages/adk
> $ npx nx show targets
> Please provide a project name via --project=<name>
> ```
>
> ### Expected behavior
> If the current directory (or one of its ancestors) contains a
`project.json`, Nx should infer the project from that file and list the
targets without extra flags. This would make it much easier to explore
available targets while staying focused on a single project, especially
in large workspaces with many similarly named packages.
>
> ### Environment
> - Nx: 21.6.3
> - Node: 24.10.0
> - Package manager: bun 1.3.1
> - OS: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
> </issue_description>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> </comments>
>
</details>
- Fixesnrwl/nx#33503
<!-- START COPILOT CODING AGENT TIPS -->
---
✨ Let Copilot coding agent [set things up for
you](https://github.com/nrwl/nx/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
The `prettier` module is being resolved twice during the `format`
command execution and using a mix of `import`/`require`.
## Expected Behavior
The `prettier` module should be resolved once and reused.
## Current Behavior
The `central-publishing-maven-plugin` with `extensions=true` does not
work with Maven 4. Running `./mvnw deploy -Prelease` completes the build
but never triggers the deploy/publish phase - it stops at install.
This is a known issue tracked as
[MNG-8584](https://issues.apache.org/jira/browse/MNG-8584).
## Expected Behavior
Running `./mvnw deploy -Prelease -pl packages/maven/maven-plugin -am`
should publish the nx-maven-plugin to Maven Central.
## Related Issue(s)
Related to Maven 4 compatibility:
https://issues.apache.org/jira/browse/MNG-8584
## Changes
- Add explicit execution binding for `central-publishing-maven-plugin`
to the deploy phase (workaround for broken extensions mechanism in Maven
4)
- Remove `extensions=true` that doesn't work with Maven 4
- Update `central-publishing-maven-plugin` from 0.9.0 to 0.10.0
- Skip standard `maven-deploy-plugin` for nx-maven-plugin module (we use
central-publishing instead)
## Current Behavior
the plugins are disabled on vercel and netlify but there's no easy way
to disable them otherwise.
## Expected Behavior
there's an env var to disable each of the plugins: `NX_GRADLE_DISABLE` /
`NX_MAVEN_DISABLE` just like there is one for dotnet.
## Current Behavior
Maven e2e tests fail with two issues:
1. Spring Initializr rejects Spring Boot 3.4.0 (now requires >=3.5.0)
2. Parent POMs (`nx-parent` and `nx-maven-parent`) aren't installed
locally, causing Maven to fail when resolving `nx-maven-plugin:0.0.12`
since it's not yet published to Maven Central
## Expected Behavior
Maven e2e tests pass successfully by:
1. Using Spring Boot 4.0.0 which is supported by Spring Initializr
2. Installing parent POMs to local Maven repository so the plugin can
resolve its dependencies
## Related Issue(s)
Fixes the CI failures in maven e2e tests after the 0.0.12 version bump.
## Current Behavior
The prebuild-banner script requires an `enabled` boolean field that the
Framer API does not return, causing validation failures.
## Expected Behavior
Validation matches the actual API response format which uses
`activeUntil` for determining banner visibility instead of `enabled`.
Closes #CLOUD-4071
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
After running commands which spawn plugin workers on the main process
(`nx show project`, or any command with the daemon disabled) some users
(and notably @FrozenPandaz) experienced terminal issues that resulted in
↑ / ↓ printing escape codes instead of scrolling command history.
## Expected Behavior
This pull request updates how plugin worker processes handle their
input/output streams to improve terminal behavior and debugging
capabilities. The main change is switching the worker's stdio from
`inherit` to `pipe`, and then manually piping the worker's stdout and
stderr to the main process. This avoids terminal state issues and
enables better debugging.
**Plugin worker process I/O handling:**
* Changed the worker process `stdio` option from `'inherit'` to `'pipe'`
in `startPluginWorker`, preventing terminal state issues (such as broken
arrow key functionality) after Nx execution.
* Added logic to pipe the worker's `stdout` and `stderr` to the main
process, making it easier to debug and allowing plugins to communicate
metrics. Increased the max listener count on `process.stdout` and
`process.stderr` to avoid warnings from multiple listeners.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We dont validate the size of the native file cache after copying it,
which sometimes fails and corrupts the data. This failure results in a
different size, so we can detect it. In certain situations, the
corruption causes node to hang instead of throw.
## Expected Behavior
We detect the corruption
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30653Fixes#31300
I found regression in `replaceOverride` behavior that isn't guarded
against. There is migration from v17
(https://github.com/nrwl/nx/blob/20.8.x/packages/next/src/migrations/update-17-2-7/remove-eslint-rules-patch.ts#L17)
that shows that when `update` function returns `undefined`, then that
override entry should be removed.
We had no other unit tests to cover this case previously, so it was
missed until I tried cherry-picking the fix to `20.8.x` branch.
There was also a bug with flat config in v20 and v21 where not passing
`update` function for flat config leads to an error due to
`update(data)` being called without checking if `update` exists (since
it's optional). We never actually skip on passing `update` (which makes
`replaceOverride` useless since it's noop), so I marked it as required
arg now.
## Current Behavior
When `replaceOverride` is called with an update function that returns
`undefined`, the override block is not removed. This is inconsistent
with the JSON code path which uses `splice` to remove the override.
## Expected Behavior
When the update function returns `undefined`, the entire override block
should be deleted from the flat config, matching the JSON path behavior.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
When running a task graph with continuous tasks and one of them is
terminated, the reverse continuous task deps that have no other tasks
that depend on them are also automatically terminated. This is fine in a
non-DTE context, but when running in a DTE context, the DTE task runner
must own the lifecycle of the continuous tasks, and Nx shouldn't
automatically terminate them.
## Expected Behavior
Nx shouldn't automatically terminate continuous tasks when running in a
DTE context.
## Current Behavior
The `create-nx-workspace` incorrectly offers `Vitest & Angular` as a
valid unit test runner choice when the bundler is something other than
`esbuild`.
## Expected Behavior
The `create-nx-workspace` should only offer `Vitest & Angular` as a
valid unit test runner choice when the bundler is `esbuild`.
## Related Issue(s)
Fixes#34014
## Current Behavior
On systems under heavy load, plugin loading can fail with:
```bash
Plugin Worker exited because no plugin was loaded within 10 seconds of starting up.
```
The initialization of the process metrics collection could potentially
cause this by blocking the loading of the plugin.
## Expected Behavior
Process metrics initialization no longer blocks critical startup paths,
allowing plugin loading to succeed regardless of system load.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Shared running tasks (tasks running in another process) do not appear in
the In Progress section of the TUI. They show the throbber as being in
progress, but are located in the Pending/Completed section.
## Expected Behavior
Shared running tasks (tasks running in another process) should appear in
the In Progress section of the TUI.
## Current Behavior
package installation does not set `windowsHide` so it flashes a terminal
window
## Expected Behavior
there should be no flashing terminal window
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Adds a sm utility script to ease quickly checking changes against local
repos. Not a replacement for local registry + install, but good for
quick checks
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump gradle project graph plugin version to 0.1.11
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We have a hard coded list of task targets to not exclude depends on.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We resolve a gradle task such that we can identify if there are provider
dependency relationships involved. If there are, then do not exclude
depends on since Gradle needs the dependsOn tasks to fulfill providers.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When processing Kotlin Multiplatform (KMP) projects, the Nx Gradle
plugin encounters ConcurrentModificationException errors because KMP
dynamically modifies the Gradle project's task and configuration
containers during dependency resolution. The plugin was resolving
configuration dependencies before processing tasks, which triggered
KMP's hierarchy finalization and dynamic task creation while the plugin
was still iterating over these collections.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Gradle plugin should handle Kotlin Multiplatform projects without
errors by:
1. Processing tasks before resolving configuration dependencies,
preventing KMP from modifying task containers during iteration
2. Creating immutable snapshots of task and configuration collections
before iteration to avoid concurrent modification issues
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3633
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The Nx Plugin uses Nx as the backing mechanism, but Gradle still does
some caching behind the scenes. When using Nx and Gradle's caching at
the same time, there can be times where Gradle does not recognize input
changes and will not execute tasks that it mistakenly deems unchanged.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure that the batch executor always reruns tasks and is not impacted
by the Gradle build cache.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3649
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
For 0.x versions, shift semver bump types down to follow the common
convention where breaking changes bump minor, and new features bump
patch:
- major -> minor
- premajor -> preminor
- minor -> patch
- preminor -> prepatch
- patch -> patch (unchanged)
This ensures that `nx release` with a breaking change on a 0.x package
(e.g., 0.1.0) bumps to 0.2.0 instead of 1.0.0.
Fixes NXC-3638
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
The migration generator (`@nx/plugin:migration`) fails when due to
ESLint flat config not being parsed correctly, leading to an error.
This happens because `replaceOverride` uses `parseTextToJson` to parse
the config, which fails for non-JSON-serializable JavaScript
expressions.
This PR fixes the issue by using AST parsing, like we did for
`hasOverrides` here https://github.com/nrwl/nx/pull/33548.
Fixes#34010
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
When adding a non-buildable JS library (`bundler: 'none'`) to a
workspace with an existing `@nx/js/typescript` plugin registration that
has build options configured, a duplicate plugin entry is unnecessarily
created in `nx.json`.
## Expected Behavior
Non-buildable libraries reuse the existing plugin registration when
`skipBuildCheck: true` is not specified, thereby avoiding duplicate
entries in `nx.json`. The `@nx/js/typescript` plugin will infer the
project as non-buildable because the library's `package.json` will have
entry points pointing to source files, so there's no need for a separate
plugin registration.
## Related Issue(s)
Fixes#33981
## Current Behavior
Rspack 1.7.0 is failing to create factories for internals with Module
Federation.
## Expected Behavior
Pin Rspack to 1.6.8 for now to ensure continued functioning of Module
Federation
## Current Behavior
PR #32915 changed how conventional commits determine version, making
them rely on commit scope:
commits with types configured to bump minor / major version bumps only
patch if commit scope exists and it does not include project name
## Expected Behavior
In our project we do not use projectName as commit scope, so we would
like to bring back old behavior, this can be achieved by adding option
to opt-out such behavior
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
- The `skipTypeChecking` option is a simple boolean that only allows
enabling/disabling type checking
- Rspack executor is missing the `runtimeDependencies` option that
webpack has
- The `cache` configuration is hardcoded and cannot be overridden by
users
## Expected Behavior
- New `typeCheckOptions` option allows configuring type checking with `{
async: true }` to run type checking in a separate process without
blocking the build
- The deprecated `skipTypeChecking` option is maintained for backward
compatibility
- Rspack now supports `runtimeDependencies` option for adding runtime
dependencies to generated `package.json` (useful for Docker installs)
- New `cache` option allows users to override webpack/rspack caching
behavior while maintaining backward-compatible defaults
## Related Issue(s)
N/A - Standalone feature
## Changes Made
### typeCheckOptions (webpack & rspack)
- Added `TypeCheckOptions` interface with `async` property
- Added `typeCheckOptions` option to plugin options interfaces
- Updated `apply-base-config.ts` to normalize `typeCheckOptions` from
deprecated `skipTypeChecking` for backward compatibility
- Added schema definitions to `schema.json` and `schema.d.ts`
### runtimeDependencies (webpack & rspack)
- Added `runtimeDependencies` option to `NxAppRspackPluginOptions`
- Updated `GeneratePackageJsonPlugin` to resolve and include runtime
dependencies
- Added schema definitions to `schema.json` and `schema.d.ts`
### cache (webpack & rspack)
- Added `cache` option to plugin options interfaces
- Updated `apply-base-config.ts` to check `'cache' in options` before
applying defaults
- Allows explicit `cache: undefined` to force cache to be disabled
- Maintains backward-compatible defaults:
- Webpack: `{ type: 'memory' }` for Node targets in watch mode
- Rspack: `true` for Node targets in watch mode, `true` in dependent
config
## Files Changed
**Webpack:**
-
`packages/webpack/src/plugins/nx-webpack-plugin/nx-app-webpack-plugin-options.ts`
-
`packages/webpack/src/plugins/nx-webpack-plugin/lib/apply-base-config.ts`
- `packages/webpack/src/executors/webpack/schema.json`
- `packages/webpack/src/executors/webpack/schema.d.ts`
- `packages/webpack/src/plugins/generate-package-json-plugin.ts`
**Rspack:**
- `packages/rspack/src/plugins/utils/models.ts`
- `packages/rspack/src/plugins/utils/apply-base-config.ts`
-
`packages/rspack/src/plugins/utils/plugins/generate-package-json-plugin.ts`
- `packages/rspack/src/executors/rspack/schema.json`
- `packages/rspack/src/executors/rspack/schema.d.ts`
**Documentation:**
- `astro-docs/.../webpack/Guides/webpack-plugins.mdoc`
- `packages/webpack/docs/webpack-build-executor-examples.md`
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
When generating Cypress component testing in Angular workspaces, the
base tsconfig sets moduleResolution to 'bundler' which causes TS5095
errors because 'bundler' requires module to be 'preserve' or 'es2015+'.
Cypress runs in Node.js and should use Node.js module resolution
instead. This fix sets moduleResolution to 'node' for Cypress
tsconfig.json templates.
## Current Behavior
When generating Cypress component testing configuration in Angular
workspaces, the generated `cypress/tsconfig.json` inherits
`moduleResolution: "bundler"` from the workspace base config. Since
Cypress uses `module: "commonjs"` for Node.js runtime, this causes
TypeScript compiler error TS5095: "Option 'bundler' can only be used
when 'module' is set to 'preserve' or to 'es2015' or later."
## Expected Behavior
The generated `cypress/tsconfig.json` should explicitly set
`moduleResolution: "node"` to match the `module: "commonjs"` setting,
preventing TS5095 errors. This aligns with how NestJS applications
handle the same issue (see #33607).
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Summary
Adds comprehensive Docker development guidance to the Nx Daemon
documentation.
Related to #33263, #30359, #14126
## What's included
This PR expands the existing Nx Daemon docs with a new "Running Nx in
Docker" section that covers:
- **Why the daemon often fails in Docker** - ephemeral filesystems,
inode/mtime changes from volume mounts, container restarts, IPC issues
- **Recommended approach** - disable daemon with `NX_DAEMON=false`
- **Example docker-compose setup** - minimal reproducible configuration
for local development
- **CI/CD best practices** - when to prefer stateless builds over daemon
caching
## Context
Several issues have been opened around daemon behavior in containers,
but the existing docs only briefly mention socket location
customization. Users are left wondering:
- Why doesn't the daemon work reliably in Docker?
- What's the recommended workflow for containerized development?
- How should CI pipelines handle this?
Issue #33263 specifically describes daemon crashes when running nx
between Docker and non-docker environments - this PR documents the
recommended workaround (`NX_DAEMON=false`) and explains why.
## Preview
The new section appears under the existing "Customizing the socket
location" heading and includes:
- Explanation of Docker-specific challenges
- Code examples for Dockerfile, docker-compose, and CLI
- Rule of thumb callout for quick reference
Open to feedback on structure or placement.
---------
Co-authored-by: kazuki <kazuki@kazukinoMacBook-Air.local>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Adds a new peerDepsVersionStrategy option that allows configuring how
peer dependencies versions are set when auto-fixing. When set to
'workspace', peer dependencies will use 'workspace:*' instead of the
installed or root package version. Defaults to 'installed' to maintain
backward compatibility.
## Current Behavior
A concrete peer dependency version is being fixed.
## Expected Behavior
User can choose between `installed` and `workspace` version strategies.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Plan to Fix Inputs Documentation
Based on the issue, I need to correct the inputs documentation at
`/astro-docs/src/content/docs/reference/inputs.mdoc`. The problems are:
- [x] Fix the invalid syntax in "Source Files" section - currently shows
inputs as an object instead of an array
- [x] Document the `{ input: someNamedInput, projects: [] }` format for
referencing named inputs from specific projects
- [x] Document the `{ input: someNamedInput, dependencies: true }`
format for referencing named inputs from dependencies
- [x] Document the object form for fileset inputs (e.g., `{ fileset:
string }`)
- [x] Ensure all documented formats match the TypeScript type definition
- [x] Fix typo found in code review (to to -> to)
- [x] Remove targetDefaults wrapper from examples (per review feedback)
- [x] Use string syntactic sugar forms in examples and explain
equivalence to object forms
- [x] Fix comment to show object form equivalence instead of repeating
string form
## Changes Made
1. **Fixed Source Files section syntax**:
- Changed from invalid object syntax to correct array syntax
- Removed unnecessary targetDefaults wrapper per review feedback
- Added documentation for the object format with fileset property
2. **Added new section "Named Inputs from Other Projects"**:
- Documents `{ input: "production", projects: "mylib" }` format
- Documents `{ input: "production", projects: ["mylib", "myapp"] }`
format for multiple projects
- Uses string syntactic sugar `"production"` and `"^production"` in
examples
- Explains equivalence: `"production"` is shorthand for `{ "input":
"production" }`, `"^production"` is shorthand for `{ "input":
"production", "dependencies": true }`
3. **Fixed typo**: Changed "to to not invalidate" to "to not invalidate"
All changes validated with prettier formatting checks.
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Issue Title: Docs: correct inputs syntax and document missing formats
> Issue Description: The inputs docs appear inaccurate at
[nx.dev/docs/reference/inputs#source-files](https://nx.dev/docs/reference/inputs#source-files).
>
> * The shown inputs syntax isn’t valid; it should be an array.
> * The page doesn’t mention the `{ input: someNamedInput, projects: [\]
}` format.
> * It also doesn’t cover the object form for `deps`/`self` inputs.
>
> Valid types reference:
[https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206](https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206)
>
> Working with \[GitHub
Copilot\](User:d484ef82-7f7d-4a95-be09-9d82ca3905dc) on this.
> Fixes
https://linear.app/nxdev/issue/NXC-3369/docs-correct-inputs-syntax-and-document-missing-formats
>
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> [https://github.com/nrwl/nx](https://github.com/nrwl/nx)
>
> Comment by User d484ef82-7f7d-4a95-be09-9d82ca3905dc:
> 📋 I wasn't able to determine which GitHub repository to work in.
>
> I think it's one of these, but can you tell me which one is right?
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Side not, copilot assignment didn't work. Would have been neat 🙂
>
> Comment by User d484ef82-7f7d-4a95-be09-9d82ca3905dc:
> Waiting for https://linear.app/nxdev/profiles/craigory to link their
GitHub account. [Click to authorize
→](https://linear.business.githubcopilot.com/linear/auth)
>
> Comment by User :
> This thread is for an agent session with githubcopilot.
>
> Comment by User :
> Created issue
[NXC-3369](https://linear.app/nxdev/issue/NXC-3369/docs-correct-inputs-syntax-and-document-missing-formats)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> This comment thread is synced to a corresponding [thread in
Slack](https://nrwl.slack.com/archives/CT3CQ2F0D/p1761762896195989?thread_ts=1761762896.195989&cid=CT3CQ2F0D).
All replies are displayed in both locations.
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> @Linear create a docs issue, assign it to me and copilot
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> Send a PR? 🙏
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> See these valid types:
[https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206](https://github.com/nrwl/nx/blob/master/packages/nx/src/config/workspace-json-project-json.ts#L206)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Also on the same page, I don't see any mention of the `{ input:
someNamedInput, projects: [] }` format, nor the object form for deps /
self inputs
>
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
## Current Behavior
The GitHub Actions DTE example includes a redundant conditional checkout
step that has separate configurations for pull request and default
branch events, both performing the same checkout operation.
## Expected Behavior
The GitHub Actions example should use a single, simpler checkout
configuration that works for both pull request and default branch
events, removing redundant code.
## Related Issue(s)
This change simplifies the documentation example by removing redundant
checkout steps while maintaining the same functionality.
Updated Turborepo section to include robust browser-based graph
visualizations and Graphviz image exports.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
TypeScript’s module resolution stop at project's root when resolving
modules.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
TypeScript’s module resolution will walk up to the workspace root when
resolving modules
## Changes Made
Convert the filePath to an absolute path inside findProjectFromImport
before calling resolveImportWithTypescript, because TypeScript’s module
resolution will not correctly traverse up the directory tree toward the
workspace root when given a relative path.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33985
When a vitest config file is at the workspace root and contains a
`projects` property in the test configuration, the plugin now skips
inferring test targets for that config. This is because root workspace
configs act as orchestrators - the actual tests live in the individual
project configs referenced by `projects`.
Fixes#32471
## Current Behavior
The dev-server builder throws an error about the "define" option not
being supported in Angular < 21, even when users don't configure it. The
validation uses a truthy check that treats empty objects `{}` as true.
## Expected Behavior
The error should only throw when users explicitly configure define with
actual keys.
## Related Issues
Fixes#33964
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: leosvelperez <12051310+leosvelperez@users.noreply.github.com>
## Current Behavior
There is no straight-forward way to use the cwd as part of a tasks hash
## Expected Behavior
You can use `{workingDirectory: 'absolute'}` to factor the working
directory into the hash
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33684
On test repo, the
`package-json:createNodes:isInPackageManagerWorkspacesTime` takes:
- Before the PR: 2356ms
- With PR: 23ms
This is achieved by avoiding unnecessary use of `minimatch` when a
direct string comparison is sufficient.
It also makes creation and logging of entire graph come down from
`23.6s` down to `18.5s`
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: meeroslav <meeroslav@users.noreply.github.com>
Add support for ESLint's new bulk suppression features introduced in
v9.24.0.
- Add `suppressAll` option to suppress all existing violations
- Add `suppressRule` option to suppress specific rule(s)
- Added `suppressionsLocation` option to specify custom location for the
suppressions file (defaults to eslint-suppressions.json)
- Include proper version checking for ESLint v9.24.0+
- Add related tests and documentation
- Update schema and TypeScript types
This allows teams to incrementally adopt stricter lint rules without
being overwhelmed by legacy violations.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The `@nx/eslint` package currently doesn't support ESLint's bulk
suppression features. When teams want to enable new lint rules, they
must fix all existing violations first, which can be a significant
barrier to adopting stricter linting standards.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The @nx/eslint package now supports ESLint v9.24.0+'s bulk suppression
features through new flags:
- `suppressAll`: Suppresses all existing violations
- `suppressRule`: Suppresses specific rules
- `suppressionsLocation`: specifies a custom location for the
suppressions file (defaults to eslint-suppressions.json)
```json
{
"lint": {
"executor": "@nx/eslint:lint",
"options": {
"suppressAll": true
}
}
}
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/discussions/30620
This PR removes the variant check for deciding whether to use GitHub
templates for CNW. Moving forward, the first-level options are all
`nrwl/*` templates. The `Custom` option allows users to go back to the
previous presets.
Explains how to configure Tailwind CSS so that classes used in remote
applications are properly compiled by the host application. Covers both
Tailwind v3 (content array) and v4 (@source directive) configurations.
This PR fixes the `/changelog` page.
With `getStaticProps`, files were read at build time when copy-docs had
already copied them. With `getServerSideProps`, files are read at
request time on serverless functions where those files don't exist.
This PR reverts the changes to use `getServerSideProps` and uses a
middleware instead. This also has the benefit of keeping the pages
static, so we do not need edge functions to run their server function.
Fixed: https://nx-dev-git-doc-372-nrwl.vercel.app/changelog
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
Cypress Component Testing for zoneless Angular projects is not
supported.
## Expected Behavior
Cypress Component Testing for zoneless Angular projects should be
supported.
## Current Behavior
When generating Angular apps/libs with `setParserOptionsProject`, the
ESLint flat config output did not include the project-level
`parserOptions.project`, so type-aware lint rules still fail unless
users edit the config manually.
## Expected Behavior
Enabling `setParserOptionsProject` produces the appropriate
project-level `parserOptions.project` configuration in both flat ESLint
config and legacy `.eslintrc.json`, so type-aware linting works out of
the box.
## Related Issue(s)
Fixes#33944
## Current Behavior
When migrating Angular packages the `@angular/cli` package is not
updated as part of the `nx migrate` initial package updates to the
`package.json` file. Instead, it's updated at a later stage with a
migration generator. This happens for a couple of reasons:
- Angular CLI package group will update all the packages using a `^`,
which can result in workspaces getting a minor version of the packages
installed before Nx adds support for that minor version.
- Angular CLI migrations can error due to some assumptions that are not
always correct in Nx workspaces.
- The `nx migrate` command currently doesn't have the ability to ignore
the package group or migrations of a given package.
This is why the `@angular/cli` package is migrated "manually" in a
migration generator.
## Expected Behavior
The `@angular/cli` package should be updated as part of the package
updates performed by the `nx migrate` command while ignoring its package
group and migrations. The `@nx/angular` package already provides the
same set of migrations and more.
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Current Behavior
Creating a new Angular workspace with Vitest results in no test setup
being generated. This happens because the `vitest` option is no longer
available, and instead, there are two options: `vitest-angular` and
`vitest-analog`.
## Expected Behavior
Creating a new Angular workspace should prompt for Vitest with Angular
or Vitest with Analog to set up the tests.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: leosvelperez <leosvelperez@users.noreply.github.com>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
The getDependentPackagesForProject function was crashing when processing
projects with non-npm external nodes (e.g., cargo: prefixed nodes from
@monodon/rust plugin). The code only handled npm: prefixed externals and
treated everything else as workspace libraries, causing undefined access
errors when cargo externals were encountered.
This fix adds a check to skip external nodes that aren't npm-prefixed by
detecting the presence of a colon in the dependency target. Only npm:
prefixed externals are processed as npm packages, and other external
prefixes (cargo:, maven:, etc.) are now properly skipped.
Fixes#32819
## Current Behaviour
The ignorePatternsForPlanCheck configuration option in nx.json for
version plans lacks
documentation about the pattern syntax. Users attempting to use negation
patterns (e.g.,
["*", "!src/"]) may experience unexpected behavior because gitignore
semantics don't work
as intuitively expected with such patterns.
## Expected Behaviour
The documentation and JSDoc comments now clearly explain:
- That ignorePatternsForPlanCheck follows gitignore semantics
- Working patterns like ["**/*.spec.ts"] and ["**/*.ts", "!**/src/**"]
- Non-working patterns like ["*", "!src/"] and why they don't work as
expected
- Recommended approach of using file extension patterns instead of
wildcards when trying to
ignore all files except those in specific directories
## Related Issues
Fixes#30324
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
When running single tasks we have a "minimal" tui, but that minimal tui
still makes it really hard / impossible to use some of the terminals
built in features... like:
- Find (can only find what's currently rendered by tui)
- Text select + copy (can only select what's rendered to screen, copied
text includes the frame around the tui / scrollbar)
## Expected Behavior
When running single tasks we can use an inline viewport to render some
tui widgets at the bottom of the viewport, and terminal output can be
printed above.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Disabling Maven e2e tests since something with e2e setup breaks when we
try to update the spring boot version.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
make sure canonical always points to nx.dev and not a subdomain preview
incase they're index.
<img width="1728" height="863" alt="image"
src="https://github.com/user-attachments/assets/8e7d91c1-277b-4a2a-91ec-732f7f4f37ae"
/>
also confirm that robots.txt still has deny for non prod builds.
this is done via middleware since canonical url is controlled via astro
config 'site' property. which is used to control other aspects that we
do want to be preview URL domains (like navigation). so we have a
middleware to always override the url to match prod.
also nextjs side was already overriding this in `_app.tsx`
This PR adds the ability to consumer banner data for nx.dev (both astro
and next.js) from a remote JSON file. This is only enabled if
`BANNER_URL` environment variable is set.
The `banner-config.json` files are committed for both astro and next.js,
so before we consume banner JSON from Framer, we can use this as the
source of truth rather than update the component code.
Once we switch completely to Framer CMS, we can remove the committed
JSON files.
Note: A redeploy is required for banner changes to take effect. In the
future we may be able to do this dynamically in Astro.
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Maven plugin was complaining about Spring-boot version being behind 3.5
when running e2e suite. Also bumped down maven plugin version since
version 0.0.12 could not be found at the time of this PR.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The inferred tasks documentation at
https://nx.dev/docs/concepts/inferred-tasks does not mention the
`include` or `exclude` options on plugins, even though this is a common
and useful feature for scoping plugins to specific projects.
## Expected Behavior
The inferred tasks documentation now includes a new section called
"Scope Plugins to Specific Projects" that explains:
- How to use `include` and `exclude` properties in plugin configuration
- What the glob patterns match against
- Use cases for this feature (scoping plugins, applying different
options to different projects)
This aligns with the existing documentation in the nx.json reference
guide.
## Related Issue(s)
Fixes DOC-367
## Current Behavior
When generating a React Module Federation remote with webpack bundler in
a TypeScript
Solution setup, the generator incorrectly sets the production webpack
config path in the
project configuration. Additionally, the sourceRoot property is not
being set in
package.json for TS Solution setups, which causes issues with module
federation's ability
to locate source files correctly.
## Expected Behavior
When using a TypeScript Solution setup:
- The production webpack config should not be explicitly set in the
build target's
production configuration (it will be inferred correctly)
- The sourceRoot property should be set in package.json under the nx
configuration to
properly identify the project's source directory
- The typecheck target should be added as a dependency for both build
and serve targets
## Related Issue(s)
Fixes#31029
## Current Behavior
The `replace-removed-matcher-aliases` migration from `@nx/jest` is not
run when migrating to Angular v21 (and updating Jest to v30). That
migration targets the original package update for Jest v30 (Nx 21.3.0),
which was incompatible with Angular < 21, so it wouldn't have run for
Angular workspaces at the time. Now that Angular is being updated to
v21, Jest is updated to v30, but the migration generator is not running.
## Expected Behavior
The `replace-removed-matcher-aliases` migration from `@nx/jest` should
run when migrating to Angular v21 (and updating Jest to v30).
## Current Behavior
The Maven version used for development dependencies is currently set to
3.9.11 in both pom.xml and mise.toml.
## Expected Behavior
The Maven version should be updated to 4.0.0-rc-5 to align with the
Maven 4 version already used in the batch-runner component.
## Related Issue(s)
N/A - This is a dependency version update to ensure consistency across
the Maven plugin ecosystem.
## Changes
- Updated `maven.version` property in pom.xml from 3.9.11 to 4.0.0-rc-5
- Updated maven tool version in mise.toml from 3.9.11 to 4.0.0-rc-5
This ensures that developers working on the Nx Maven plugin use the same
Maven 4.0.0-rc-5 version across all components.
## Current Behavior
The Maven plugin version is currently at 0.0.11.
## Expected Behavior
This PR bumps the Maven plugin version to 0.0.12 and creates a migration
for Nx 22.4.0-beta.0. This allows users to automatically update their
pom.xml files when they upgrade to the next version of Nx.
## Related Issue(s)
N/A - Version bump
## Current Behavior
The daemon currently depends on client requests failing with a
`LOCK_FILES_CHANGED` error to trigger a restart. This creates several
issues:
- The daemon may stay running with stale dependencies if no requests
come in
- The client must wait for a request to fail to trigger reconnection
- Special-case error handling is scattered across the client code
## Expected Behavior
The daemon should proactively restart itself when lock files change, and
the client should gracefully reconnect with exponential backoff for any
server shutdown scenario.
## Changes
### Client-Side: Exponential Backoff Reconnection
- Add `handleConnectionError()` method that retries with exponential
backoff (10ms → 5000ms, 30 attempts max)
- Preserve pending messages during reconnection and resend them once the
new daemon is available
- Remove special-case handling for `LOCK_FILES_CHANGED` and
`NX_VERSION_CHANGED` errors
- Remove `retryMessageAfterNewDaemonStarts()` method as it's no longer
needed
### Server-Side: Self-Restart on Lock File Changes
- Add `startNewDaemonInBackground()` to spawn a replacement daemon
before shutdown
- Add `handleServerProcessTerminationWithRestart()` for restartable
shutdown scenarios
- Detect lock file changes and proactively start a new daemon before
responding with an error
- Keep version change handling simple (just exit, no restart)
## Benefits
- **More Resilient**: Client recovers from any server shutdown, not just
specific errors
- **Cleaner Architecture**: Server manages its own lifecycle, client
doesn't need special cases
- **No Request Dependency**: Daemon doesn't wait for requests to detect
changes
- **Reduced Error Spam**: Exponential backoff prevents connection error
floods
- **Future-Proof**: Foundation for other restart scenarios (plugins,
config changes)
## Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/30514
Fixes https://github.com/nrwl/nx/issues/29118
## Summary
Adds a batch executor for Nx Maven that enables parallel multi-task
execution with significant performance improvements. The batch runner
keeps Maven resident in memory, avoiding cold start overhead for each
task.
## Changes
### 1. Batch Runner JAR (`packages/maven/batch-runner`)
- **ResidentMavenExecutor**: Uses Maven 4.x's `ResidentMavenInvoker` to
keep Maven in memory
- **NxMaven**: Custom Maven wrapper that caches project graphs and
sessions across invocations
- **CachingResidentMavenInvoker**: Preserves session state so artifacts
from `jar:jar` are visible to `install:install`
- **BuildStateManager**: Applies/records build states for
cross-invocation caching
- Maven 4.x dependencies are shaded into the JAR for standalone
execution
### 2. TypeScript Executors (`packages/maven/src/executors/maven`)
- **maven.impl.ts**: Single-task executor using `mvnw`/`mvn`
- **maven-batch.impl.ts**: Batch executor that invokes the batch runner
JAR
- Automatic Maven version detection and executable resolution
### 3. Shared Utilities (`packages/maven/shared`)
- `BuildState`, `BuildStateApplier`, `BuildStateRecorder` for
cross-invocation state
- `MavenCommandResolver` for detecting Maven executable
- Reusable across batch-runner and maven-plugin modules
### 4. Maven Plugin Updates (`packages/maven/maven-plugin`)
- Updated to use `@nx/maven:maven` executor (batch-aware)
- Improved `GitIgnoreClassifier` for nested .gitignore handling
- Cache config tweaks for compiler inputs
## Performance
| Scenario | Before | After |
|----------|--------|-------|
| Cold start per task | 100-500ms | N/A (one-time init) |
| Per-task execution | 100-500ms | ~1.3ms (cached) |
| Improvement | - | **75-385x faster** |
## Version Support
- **Maven 4.x**: Full support with ResidentMavenExecutor (optimized)
- **Maven 3.x**: Falls back to ProcessBasedMavenExecutor (subprocess)
## Testing
- E2E tests for Maven 4.0.0-rc-4, 4.0.0-rc-5
- Unit tests for TypeScript executors
- Tests for GitIgnoreClassifier
## Current Behavior
Uses subprocess execution via `mvnw`/`mvn` for each task.
## Expected Behavior
Batch execution keeps Maven resident, dramatically reducing per-task
overhead.
## Related Issue(s)
Part of Maven integration improvements.
---------
Co-authored-by: Max Kless <maxk@nrwl.io>
## Current Behavior
The tui shouldn't show for single tasks
## Expected Behavior
The tui isn't shown for single tasks
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Two issues with the .NET dependency graph:
1. Issue #33653: When a .NET project uses multi-targeting
(<TargetFrameworks> plural), its project reference dependencies
disappear from the Nx graph.
2. Issue #33397: Transitive dependencies are incorrectly shown as direct
dependencies. For example, if A → B → C, the graph shows A depending on
both B and C, when it should only show A → B.
## Expected Behavior
1. Multi-targeting projects should correctly show their dependencies in
the graph.
2. Only direct dependencies should be shown, not transitive ones. Nx
handles transitive dependencies through the dependency chain.
### Solution
Multi-targeting fix (#33653)
MSBuild creates multiple nodes for multi-targeting projects:
- An "outer build" with TargetFrameworks set but TargetFramework empty
- "Inner builds" for each target framework with TargetFramework set
The fix groups nodes by project file path and prefers inner builds
(which have properly resolved references) over outer builds.
### Transitive dependency fix (#33397)
Changed from using ProjectGraphNode.ProjectReferences (which includes
transitive dependencies in multi-targeting scenarios) to
ProjectInstance.GetItems("ProjectReference") which returns only direct
references defined in the project file.
## Related Issue(s)
Fixes#33653Fixes#33397
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Templates use `"*"` for workspace dependencies in individual
package.json files. This works for npm but breaks pnpm, yarn, and bun
which require the `workspace:` protocol for proper symlinking.
For pnpm, yarn, and bun: automatically convert `"*"` dependencies to
`"workspace:*"` in all workspace package.json files. npm is left
unchanged since it handles `"*"` natively.
Also adds support for 2-level nested projects (e.g.,
`libs/shared/models/package.json`).
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
Sync generators are processed in the background by the daemon server.
Their results are cached and reprocessed when the project graph is
recomputed. There are currently two issues:
- The cache is only invalidated after the project graph finishes
recomputing, which means that there's an interval between files changed
(triggering the project graph recomputation) and the recomputation
finishes, where the cache is not invalidated, and it's stale. During
that interval, any request to get the sync generator changes will use
the stale cache.
- Sync generators are scheduled to be processed after the project graph
is recomputed, so a quick succession of recomputations can be coalesced.
The problem is that the scheduled closure uses the project graph from
the initial scheduling, rather than the latest available project graph
at the time it runs. This results in the usage of stale data to process
the sync generators.
## Expected Behavior
Getting sync generators changes should always return up-to-date
information.
## Current Behavior
When database initialization fails due to filesystem issues, permission
problems, or environment incompatibilities (like WAL mode not being
supported), Nx shows generic error messages that don't provide
actionable guidance to users. For example:
- "Unable to create db lock file: PermissionDenied"
- "Unable to set journal_mode: <sqlite error>"
This makes it difficult for users to diagnose and resolve issues,
especially in restricted environments like Docker containers, network
filesystems, or WSL1.
## Expected Behavior
With this PR, database initialization errors now provide:
1. **Context-specific error messages** - Different guidance based on the
error type:
- Permission denied: Instructions about file ownership, Docker volume
permissions, and read-only filesystems
- Storage full: Suggestions to free disk space
- Already exists: Guidance about stale files from crashed processes
2. **Automatic WAL mode fallback** - When WAL journal mode is not
supported by the filesystem, Nx now automatically falls back to DELETE
journal mode instead of failing. This improves compatibility with:
- Network filesystems (NFS, CIFS)
- Some Docker volume configurations
- Other environments with limited locking support
3. **WSL1 detection** - Proactively detects WSL1 environments (which
have known WAL incompatibilities) and uses DELETE mode from the start,
avoiding failed attempts and retries.
4. **Better cleanup on retry** - When database initialization fails and
needs to retry, all auxiliary files (WAL and SHM files) are also cleaned
up, not just the main database file.
5. **Actionable reporting instructions** - All error messages now
include:
- How to capture detailed logs
(`NX_NATIVE_FILE_LOGGING=nx::native::db=trace`)
- Link to create an issue
- Suggestion to run `nx reset`
## Current Behavior
When users press unhandled keys in the TUI (e.g., pressing `i` on a
completed task, or typing in a non-interactive terminal pane), nothing
happens and there's no feedback explaining why.
Similarly, when users press certain key bindings like `c` to copy
output, the action succeeds but there's no visual confirmation.
## Expected Behavior
### Hint Popups for Unhandled Keys
Users now see helpful hint popups when pressing keys that don't work in
the current context:
- Pressing `i`, `c`, or `Ctrl+A` in the dependency view (task hasn't
started yet)
- Pressing `i` on a task that doesn't support interactive mode
- Pressing character keys in a terminal pane that's not in interactive
mode
The hints explain what's happening and guide users on how to proceed.
### Status Messages for "Invisible" Actions
When users perform actions without obvious visual feedback, a status
message now appears in the terminal pane's bottom border:
- `Output copied` when pressing `c` to copy
- `Sent to assistant` when pressing `Ctrl+A`
### Configuration Option
Users who prefer not to see hint popups can disable them in `nx.json`:
```json
{
"tui": {
"suppressHints": true
}
}
```
Current Behavior
When using pnpm catalogs to manage dependency versions, the Storybook
utilities and ESLint version-utils read package.json directly using
readJson() or readJsonFile(). This approach doesn't resolve catalog
references like catalog:default, causing version detection to fail or
return incorrect values.
For example, if package.json contains:
{
"devDependencies": {
"storybook": "catalog:default"
}
}
The current code would return "catalog:default" as the version string
instead of resolving it to the actual version (e.g., "8.5.0").
Expected Behavior
Use the getDependencyVersionFromPackageJson() helper from @nx/devkit
which properly handles pnpm catalog resolution. This ensures that
version detection works correctly regardless of whether dependencies are
specified directly or via pnpm catalogs.
The helper:
- Resolves catalog: references to their actual versions
- Falls back gracefully when catalogs aren't in use
- Maintains consistent behavior across different package managers
Related Issue(s)
Fixes issues with pnpm catalog compatibility in Storybook generators and
ESLint utilities.
Related to #29772
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Nx doesn't generate projects with Prettier v3.
## Expected Behavior
Nx should generate projects with Prettier v3.
## Related Issue(s)
Fixes#30801
## Current Behavior
There's a deadlock between the Angular and Jest package updates
requirements (`requires` and `incompatibleWith`) that prevents updating
Jest to v30 and `jest-preset-angular` to v16.
## Expected Behavior
Updating to Angular v21 should result in updating Jest to v30 and
`jest-preset-angular` to v16.
This is ensured by moving the `jest-preset-angular` package update
definition to the `@nx/jest` package and processing the `@nx/angular`
package updates before `@nx/jest`. That way, by the time `@nx/jest` is
processed, the migrator would have collected the Angular v21 updates,
and the requirements will be met.
## Current Behavior
The nx-dev Next.js app can only serve pages from its own codebase or
proxy to Astro docs.
## Expected Behavior
Support proxying specific pages to a Framer site via environment
variables:
- `NEXT_PUBLIC_FRAMER_URL`: Base URL of the Framer site
- `NEXT_PUBLIC_FRAMER_REWRITES`: Comma-separated paths for new pages
For existing pages like `/ai`, the proxy is handled in
`getServerSideProps`.
## Related Issue(s)
Closes DOC-349
Co-authored-by: Claude <noreply@anthropic.com>
Removed 'node_modules' from the ignore list for asset copying.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Updating Nx to v22 breaks my app. Some projects use generated Prisma
clients which, because of how Prisma binaries work, have to be generated
to `node_modules` in order to work both locally and in Docker context.
With Nx v22 Prisma client is not copied when project is built using
`@nx/esbuild:esbuild` (or any other executor supporting `assets`
property) without any error or warning. It took mi couple of hours to
pinpoint the exact line of code responsible for this. `node_modules` dir
is hardcoded there without any possibility to be overridden.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Prisma client can be copied from `node_modules` to project output
directory when building.
Ignoring `node_modules` is removed **or can be overridden**. I'm open to
any solution which will let me update Nx in my repository.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
This PR adds a validation to the directory prompt, so users should not
hit the error as often. Only possible now if they pass the arg from CLI
_and_ they are in non-interactive mode.
We also added some more data to help debug problems, such as node
version, template/preset chosen, etc. And updated the message in
"custom" preset prompt to align with the more effective "full platform"
prompt.
Note: Also update the error message (if it hits) to be the same in new
flow and old flow.
## Related Issue(s)
Closes NXC-3624
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
The `argv` field was already implemented in `PreTasksExecutionContext`
and `PostTasksExecutionContext` but lacked tests and documentation for
plugin authors to discover and use it.
## Changes
- **Added unit tests**
(`packages/nx/src/daemon/server/handle-tasks-execution-hooks.spec.ts`)
validating that `argv` flows correctly through hook handlers for
different command patterns (direct, affected, run-many)
- **Enhanced existing documentation** in
`astro-docs/src/content/docs/extending-nx/task-running-lifecycle.mdoc`
with a new section covering:
- Context property definitions showing the `argv` field
- Examples showing how to detect command types (direct execution,
affected, run-many)
- Example demonstrating conditional analytics based on the original
command
- Common command patterns reference
- Best practices for defensive argv parsing
## Usage
```typescript
import type { NxPlugin, PostTasksExecutionContext } from '@nx/devkit';
export const myPlugin: NxPlugin = {
name: 'my-plugin',
postTasksExecution: async (options, context: PostTasksExecutionContext) => {
// Distinguish between nx build my-app vs nx affected -t build
if (context.argv.includes('affected')) {
console.log('Running in affected mode');
}
}
};
```
Fixes
https://linear.app/nxdev/issue/NXC-3382/add-contextargv-to-task-execution-hook-contexts
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Issue Title: Add context.argv to task execution hook contexts
> Issue Description: Expose the original CLI arguments on the plugin
worker so hooks can distinguish how execution was started (e.g., `nx
build nx-api` vs `nx affected -t build`). Proposal: include the invoking
argv on the hook context (e.g., `context.argv`).
> Fixes
https://linear.app/nxdev/issue/NXC-3382/add-contextargv-to-task-execution-hook-contexts
>
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> [https://github.com/nrwl/nx](https://github.com/nrwl/nx)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Aha! that worked - so you can tell it to assign to copilot instead of
"me and copilot"
>
> Comment by User d484ef82-7f7d-4a95-be09-9d82ca3905dc:
> 📋 I wasn't able to determine which GitHub repository to work in.
>
> I think it's one of these, but can you tell me which one is right?
>
> Comment by User :
> Created issue
[NXC-3382](https://linear.app/nxdev/issue/NXC-3382/add-contextargv-to-task-execution-hook-contexts)
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> This comment thread is synced to a corresponding [thread in
Slack](https://nrwl.slack.com/archives/C070BJ2JYLW/p1761928859857989?thread_ts=1761928859.857989&cid=C070BJ2JYLW).
All replies are displayed in both locations.
>
> Comment by User :
> This thread is for an agent session with githubcopilot.
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> @Linear make a ticket and assign it to copilot
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> Makes sense to me
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Sure, context.argv?
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> We can add them as `argv`?
>
> Comment by User f5ae6d50-28e9-4ee7-ad51-3da8208d5914:
> Yeah they would run on the plugin worker so it's not there
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> @jason we could add `originalArgv` to the contexts?
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Eh, probably not... they run on the plugin worker
>
> Comment by User 4215f3ef-50bd-4f09-85a0-b489c88057b6:
> Yeah, I don't think the hooks know.... I'd be curious if process.argv
would just have that info though
>
> Comment by User 439b15a6-827b-4258-971a-d86133ad59de:
> payfit does
>
> Comment by User 74901385-a023-4825-8470-fe68b1b55664:
> I can’t see anything about that in the docs - so I would assume the
hooks are agnostic to how the tasks were triggered?
>
> Comment by User 74901385-a023-4825-8470-fe68b1b55664:
> so they’re asking is there’s a way to tell the difference between `nx
build nx-api` or `nx affected -t build` in the task hook?
>
> Comment by User 74901385-a023-4825-8470-fe68b1b55664:
> > I’ve been playing around with the Task Execution Hooks, specifically
the postTasksExecution hook, and I think it will be really useful for me
to grab some detailed metrics for our specific use cases.
> > What I feel like it’s missing is a way to see what command actually
started the task execution, whether it was a specific target or an
affected command. As long as it was a specific target, I think the tasks
are sorted in order so the last taskResult will probably be the actual
target of the command but for affected it seems a bit more random what
the last result will be.
> > Is there a way to know exactly which command kicked off the ‘task
execution’?
>
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Copilot <Copilot@users.noreply.github.com>
## Current Behavior
The same task can be pinned in multiple terminal panes of the TUI. This
causes one pane to scroll the other because they share the same data.
## Expected Behavior
The same task can only be pinned in a single terminal pane of the TUI.
## Current Behavior
The e2e test `should emit decorator metadata when using --compiler=swc`
fails because the regex `/Foo=.*?_decorate/` expects the old transpiled
output format where classes were assigned to variables.
## Expected Behavior
The test should pass by matching the current SWC output format which
uses native ES class syntax.
## Solution
Updated the regex from `/Foo=.*?_decorate/` to `/class
Foo.*_ts_metadata/` which:
- Matches `class Foo` (native ES class syntax)
- Verifies `_ts_metadata` is present (decorator metadata)
## Current Behavior
When `NX_NATIVE_COMMAND_RUNNER=false` is set, tasks running in the TUI
don't display any output in the terminal pane. The pane remains empty
even though the task is running.
## Expected Behavior
Task output is displayed in the TUI terminal pane regardless of the
`NX_NATIVE_COMMAND_RUNNER` setting.
## Related Issues
Fixes#32803
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When upgrading to Angular 21 with Jest, users may encounter TypeScript
compilation issues because their `tsconfig.spec.json` files don't have
`isolatedModules: true` set, which is required for compatibility with
Jest and `jest-preset-angular`.
## Expected Behavior
After running `nx migrate`, Angular projects using Jest will
automatically have `isolatedModules: true` added to their
`tsconfig.spec.json` files (or custom test tsconfig files referenced by
`@nx/jest:jest` tasks) if not already set or inherited from a parent
tsconfig.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Update references to disablement variable for metrics collection for Nx
Cloud enterprise users.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
When using `@nx/node:library` generator with `--compiler=swc`, the
generator
was incorrectly adding `tslib` as a dependency instead of
`@swc/helpers`.
This change fixes two issues:
1. Pass the correct bundler (matching the compiler) to
jsLibraryGenerator
so it adds the correct helper dependency to the project's package.json
2. Update ensureDependencies to only add tslib when compiler is tsc
Fixes#31202
Fixes#32069
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
The Azure Pipelines schema requires fetchDepth to be a string, but the
generator was outputting a number.
This fix changes the value to a string to match the official schema
specification.
## Current Behavior
The generator creates `azure-pipelines.yml` with `fetchDepth: 0`
(number), which causes YAML schema validation error because the Azure
Pipelines schema expects `fetchDepth` to be a string.
According to the [Azure Pipelines
schema](https://raw.githubusercontent.com/microsoft/azure-pipelines-vscode/master/service-schema.json),
`fetchDepth` is defined as:
```json
"fetchDepth": {
"description": "Depth of Git graph to fetch",
"$ref": "#/definitions/string"
}
```
## Expected Behavior
The generator should output `fetchDepth: '0'` (string) to match the
schema specification and prevent validation errors.
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
If a workspace uses pnpm and adds a local patch to a dependency (e.g.
`vitest`), this patch is not taken into account when computing that
dependency's hash for purposes of determining cache changes. In
practice, you could patch vitest locally, and tests would pull from the
cache.
## Expected Behavior
Patches can alter behavior in the same way that updating the version
could, it's just that the version is not created and the patch is
applied locally.
This updates the pnpm lockfile parsing functionality to read the patches
field into a map and then combine the patch hash with the integrity
hash. The integrity hash ONLY represents the remote / tarball
intergrity, so these have to be combined in order to create a proper
key.
## Related Issue(s)
(Could not find any, but saw this in my work today)
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Due to this PR https://github.com/swc-project/pkgs/pull/53 at SWC, it is
not possible to use the latest version of @swc/cli in NX.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
stdout and stderr are now handled more precisely, allowing you to update
to the latest version of @swc/cli.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
When a project has a `project.json` file but no `name` field, the
`addBuildAndWatchDepsTargets` function in
`packages/js/src/plugins/typescript/util.ts` returns early without
creating build and watch deps targets, even if the project has a valid
name in its `package.json`.
## Expected Behavior
The function should fall back to checking `package.json` for the project
name when `project.json` exists but has no `name` field, allowing the
build and watch deps targets to be created properly.
## Related Issue(s)
This fixes an issue where projects with `project.json` files missing the
`name` field would not get proper build and watch dependency targets
generated.
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
`getProjectPathsAffectedByDependencyUpdates` in
`@packages/nx/src/plugins/js/project-graph/affected/lock-file-changes.ts`
doesn't return projects affected when updating `pnpm.overrides` or
`overrides` in package.json.
## Expected Behavior
When `overrides`, `resolutions`, or `pnpm.overrides` fields are changed
in package.json, the affected projects should be properly detected and
returned.
## Related Issue(s)
This addresses reports that affected project detection isn't working
properly when package manager override configurations are changed.
## Changes Made
- Enhanced `getTouchedNpmPackages` function to detect changes to
`overrides`, `resolutions`, and `pnpm.overrides` fields
- When a known package is changed in overrides, only that specific
package is marked as affected
- When an unknown package is changed in overrides, all projects are
marked as affected (since overrides can affect transitive dependencies)
- Added comprehensive tests for all override scenarios
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
### Summary:
This PR updates the Nx documentation for the Storybook migration
generator to ensure clear and accurate guidance for migrating to
Storybook version 9. It replaces outdated references to version 8,
corrects migration links, and updates example configurations for Angular
and React (Vite) projects to reflect Storybook v9. These improvements
help users follow the correct steps and avoid confusion when upgrading
their workspace to the latest major release.
### Key Updates:
- Updated all migration documentation links and text to target Storybook
v9 resources.
- Corrected example .storybook/main.js|ts file descriptions for Angular
and React projects to reference version 9.
[[1]](diffhunk://#diff-2bd0403b5cc6e0c92d83a89400b36d55ad50eb0f82688aa976ecb3c93ff69eceL44-R44)
[[2]](diffhunk://#diff-2bd0403b5cc6e0c92d83a89400b36d55ad50eb0f82688aa976ecb3c93ff69eceL61-R61)
- Ensured users will be directed to the right guides and migration steps
for a smoother upgrade experience.
### Type of Change:
Documentation only; no changes to code or functionality.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
N/A - Docs update
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
N/A - Docs update
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A
## Current Behavior
The `pageGenerator` has the option `fileName`, but it is not affecting
anything.
## Expected Behavior
The `pageGenerator` has the option `fileName`, it will define the page
file name.
## Current Behavior
The `recordStat` telemetry for `create-nx-workspace` and
`create-nx-plugin` completion events does not include the Nx Cloud
connect URL.
## Expected Behavior
The connect URL (e.g., `https://cloud.nx.app/connect/{shortlinkId}`) is
now included in the completion metadata sent to `/nx-cloud/stats`.
## Related Issue(s)
N/A - Internal telemetry enhancement
NODE_VERSION was set only on the mise-action step, so subsequent steps
defaulted to the wrong node version and corepack couldn't create the
pnpm shim.
Also update corepack first, otherwise you might run into intermittent
integrity check issues:
- https://github.com/nodejs/corepack/issues/612
- https://vercel.com/kb/guide/corepack-errors-github-actions
---
Before (NODE_VERSION at step-level):
1. mise-action runs with NODE_VERSION=20
- mise installs Node 20
- mise adds /home/runner/.local/share/mise/installs/node/20.x.x/bin/ to
PATH
2. corepack enable runs - NODE_VERSION is NOT set anymore (step env is
gone)
- corepack shim calls mise
- mise reads mise.toml template: node = "{{ env['NODE_VERSION'] |
default(value='24.11.0') }}"
- NODE_VERSION is unset → defaults to 24.11.0
- mise runs corepack from Node 24's install
- corepack creates pnpm shim in Node 24's bin directory
3. pnpm install runs
- PATH has Node 20's bin (from step 1)
- pnpm is in Node 24's bin (from step 2)
- pnpm not found!
After (NODE_VERSION at job-level):
1. mise-action runs with NODE_VERSION=20 (from job env)
- mise installs Node 20, adds its bin to PATH
2. corepack enable runs - NODE_VERSION=20 is still set
- corepack shim calls mise
- mise sees NODE_VERSION=20
- corepack runs from Node 20's install
- pnpm shim created in Node 20's bin
3. pnpm install runs
- PATH has Node 20's bin ✓
- pnpm is in Node 20's bin ✓
- Works!
---
Closes NXC-3620
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
The `linkTaskDetails` parameter was removed from the `NxCache`
constructor in #33843, which broke Nx Cloud since it still passes this
parameter.
## Expected Behavior
The `NxCache` constructor should accept the `linkTaskDetails` parameter
(even if unused) to maintain backwards compatibility with Nx Cloud.
## Related Issue(s)
Fixes
https://github.com/nrwl/nx/commit/ed09ee1daed597b7be60255f0cebe52efdd1ae69#r172894152
Updates CNW messages and removes `cancel` event from being recorded in
SIGINT handler, since it didn't work.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
When multiple MF dev servers run concurrently and share the same remote,
they would both attempt to start proxies on the same port, causing
EADDRINUSE errors.
This fix checks if a port is already in use before attempting to start
a proxy. If the port is occupied (likely by another MF dev server that
started earlier), the proxy is skipped for that remote since it's
already being served.
Uses the existing `waitForPortOpen` utility with retries: 0 to perform
an immediate check.
Fixes#33470
Update the programmatic API documentation to clarify that the dryRun
option for releasePublish does not prevent the underlying commands
from being executed. Instead, it forwards the flag to the executor
and sets the NX_DRY_RUN environment variable.
This makes it clear that:
- The built-in @nx/js:release-publish executor handles dryRun correctly
- Custom nx-release-publish executors must implement dryRun support
themselves
Fixes#33443
The publish workflow template was designed for fixed versioning strategy
(where all packages share the same version). This commit adds:
- A callout explaining that the template works best with fixed
versioning
- A new section covering considerations for independent versioning
- Documentation of GitHub's 3-tag event limitation
- Alternative approaches: workflow_dispatch, branch-based triggers, or
batch tag pushing
Fixes#33502
## Current Behavior
The `printTaskTerminalOutput` callback in the TUI summary life cycle
overwrites terminal output for all tasks when output is provided. This
causes the command line information (the actual command that was run) to
be lost for non-cached tasks because non-cached tasks stream their
output via `appendTaskOutput`, which includes the command information.
## Expected Behavior
For non-cached tasks (those with 'failure' or 'success' status), the
output should be preserved from the streaming via `appendTaskOutput`
which includes the complete command line that was executed. Only cached
tasks should have their output overwritten by `printTaskTerminalOutput`
since they don't go through the streaming path.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
## Current Behavior
NestJs libraries are generated with output path pointing to workspace
level dist folder. With TS Soln setups, we expect the dist folder to be
local to the project.
## Expected Behavior
Ensure the outputPath generated is correct
## Related Issue(s)
Fixes#32060
## Current Behavior
`nx format:write` fails with Prettier 4+ (and Prettier 3.6+ with the
experimental CLI enabled) with the error:
```bash
Incompatible options: "write" and "list-different" cannot be used together
```
## Expected Behavior
`nx format:write` works seamlessly across all Prettier versions (2.x,
3.x, and 4.x).
## Related Issue(s)
Fixes#33658Fixes#31951
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Root Maven and Gradle build files (pom.xml, build.gradle.kts,
settings.gradle.kts) are not explicitly assigned to the Java reviewers
in CODEOWNERS.
## Expected Behavior
With this PR, the Java reviewers (@FrozenPandaz @MaxKless @lourw) will
be automatically added as reviewers when changes are made to:
- `/pom.xml` - Root Maven build file
- `/build.gradle.kts` - Root Gradle build file
- `/settings.gradle.kts` - Gradle settings file
This ensures the Java team has visibility into changes affecting the
root Java build configuration.
## Related Issue(s)
N/A - Maintenance improvement to CODEOWNERS
## Current Behavior
The `/ci/recipes/enterprise/on-premise/auth-single-admin` and
`/ci/recipes/on-premise/auth-single-admin` paths redirect to
`https://github.com/nrwl/nx-cloud-helm`, but the documentation that
should exist at these paths no longer has a target location.
## Expected Behavior
These redirect rules are removed so the broken links don't mislead users
with incorrect redirects.
## Related Issue(s)
Fixes CLOUD-4007
#### Current Behavior
When creating a new Nx workspace with Angular v20 and selecting Vitest
as the unit test runner, the installation fails with an npm peer
dependency conflict:
```bash
npm error ERESOLVE could not resolve
npm error peerOptional vitest@"^3.1.1" from @angular/build@20.3.13
npm error Found: vitest@4.0.15
```
## Expected Behavior
Workspace creation completes successfully when selecting Angular with
Vitest as the unit test runner.
## Related Issue(s)
Fixes#33770
## Current Behavior
The publish workflow was installing `aarch64-apple-darwin` Rust target
but attempting to build for `x86_64-apple-darwin`, causing the build to
fail with:
```
error[E0463]: can't find crate for `core`
= note: the `x86_64-apple-darwin` target may not be installed
= help: consider downloading the target with `rustup target add x86_64-apple-darwin`
```
## Expected Behavior
The workflow should install the correct Rust target
(`x86_64-apple-darwin`) before attempting to build for it.
## Related Issue(s)
N/A - Bug found during publish workflow debugging
## Current Behavior
When running `nx g @nx/angular:cypress-component-configuration` on an
Angular project that uses esbuild (the default bundler since Angular
17), users receive a confusing error message:
```bash
Unable to find a valid build configuration. Try passing in a target for an Angular app.
```
This doesn't explain why the configuration fails or what the actual
limitation is.
## Expected Behavior
Users now receive a clear, informative error message that explains:
- Cypress Component Testing for Angular requires a webpack-based build
target
- Their project uses an esbuild-based executor (and which one)
- Cypress only supports webpack as the bundler for Angular component
testing
This helps users understand the limitation and make informed decisions
about how to proceed.
## Related Issue(s)
Fixes#33329
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The `//` comment in the styled template [is not valid
css](https://stackoverflow.com/questions/12298890/is-it-bad-practice-to-prefix-single-lines-of-css-with-as-a-personal-comment-s/20192639#20192639)
and is causing [stylelint](https://stylelint.io/) to throw errors upon
creating new apps
## Expected Behavior
It should be valid css
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/issues/33579
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
When running `nx serve` with a NestJS project (and other node apps using
`runBuildTargetDependencies`), the node executor attempts to resolve the
`nx` binary using `require.resolve('nx')`. This fails with because
`nx/package.json` does no longer has a `main` field.
## Expected Behavior
The node executor should correctly resolve and use the `nx` binary from
the workspace where it's always installed.
This is fixed by using `nx/bin/nx.js` instead of just `nx` -- as we do
in other places.
## Related Issue(s)
Fixes#33776
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Current Behavior
<!-- This is the behavior we have today -->
When a workspace library has a `name` field set in its `nx`
configuration (e.g., `"nx": { "name": "buildable" }`), the
`@nx/js:prune-lockfile` executor fails to include transitive
dependencies from that library in the pruned lockfile.
The issue occurs because `addNodesAndDependencies` attempts to retrieve
workspace nodes using `graph.nodes[name]` where `name` is the package
name from `package.json`, but `graph.nodes` is keyed by the project name
(from `nx.name`). When these differ, the lookup fails and transitive
dependencies are not traversed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/js:prune-lockfile` executor should include all transitive
dependencies from workspace libraries regardless of whether the library
has a `name` field set in its `nx` configuration.
The fix uses the workspace node from the `workspacePackages` map (which
is keyed by package name) instead of attempting to look it up in
`graph.nodes` (which is keyed by project name).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33582
## Current Behavior
When terminating a task using the `@nx/js:swc` executor before it ever
got to execute its post-compilation logic, a `TypeError: disposeFn is
not a function` error is thrown.
## Expected Behavior
Terminating a task using the `@nx/js:swc` executor should not error.
## Related Issue(s)
Fixes#31938
## Current Behavior
The `update-21-2-0/update-module-resolution migration` doesn't process
any tsconfig files of non-buildable libraries.
## Expected Behavior
The `update-21-2-0/update-module-resolution migration` should process
common/known tsconfig files of non-buildable libraries.
## Related Issue(s)
Fixes#33705
Currently, when SWC compilation fails, Nx logs only a generic message:
"SWC compilation failed"
There is no `error.message`, no `stderr` and no `stdout` printed.
In many cases the actual cause of failure is completely hidden, which
makes debugging very difficult, especially in CI.
This PR improves the logging by printing:
- error.message (or the error itself)
- stderr if available
- stdout if available
This makes SWC failures visible and debuggable again.
## Current Behavior
Only a generic "SWC compilation failed" message is logged. No error
message or stdout are shown.
## Expected Behavior
Include error.message, stderr, and stdout (when available) so developers
can understand and debug failures.
We're missing messages and variant when errors happen during CNW. This
will help us track down potential problems.
We also want to know when CNW is cancelled in order to know that we're
not missing any events.
Description update for @berenddeboer/nx-aws-cdk plugin: this has become
self-inferring.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
The `getModuleFederationConfig` function is implemented separately in 4
places with 70-80% duplicate code:
- `with-module-federation/webpack/utils.ts` (161 lines)
- `with-module-federation/rspack/utils.ts` (150 lines)
- `with-module-federation/angular/utils.ts` - async version (~80 lines)
- `with-module-federation/angular/utils.ts` - sync version (~80 lines)
Each implementation repeats the same core logic:
1. Get project from graph
2. Get and filter dependencies
3. Share workspace libraries and npm packages
4. Apply eager packages
5. Map remotes
## Expected Behavior
A single shared implementation with framework-specific configuration via
a `FrameworkConfig` interface. Each bundler utility becomes a thin
wrapper that provides its specific configuration.
### Changes
| File | Before | After | Change |
|------|--------|-------|--------|
| `webpack/utils.ts` | 161 lines | 54 lines | -107 lines |
| `rspack/utils.ts` | 150 lines | 51 lines | -99 lines |
| `angular/utils.ts` | 273 lines | 119 lines | -154 lines |
| **NEW** `module-federation-config.ts` | - | 289 lines | +289 lines |
**Net reduction**: 41 lines, with significantly improved maintainability
### New Shared Utility
Created
`packages/module-federation/src/utils/module-federation-config.ts` with:
- `FrameworkConfig` interface for bundler-specific customization
- `ModuleFederationConfigResult` interface for type-safe return values
- `getModuleFederationConfigAsync()` - for webpack/angular async configs
- `getModuleFederationConfigSync()` - for rspack/angular sync configs
- `createDefaultRemoteUrlResolver()` - shared remote URL generation
- Caching for `NX_MF_DEV_SERVER_STATIC_REMOTES` env variable parsing
(performance)
### Benefits
1. **Single source of truth**: Bug fixes and improvements only need to
be made once
2. **Better maintainability**: Framework-specific behavior is clearly
separated via config
3. **Performance**: Added caching for env variable parsing
4. **Type safety**: New interfaces provide better IntelliSense and
compile-time checks
5. **Backward compatible**: All existing exports and behavior preserved
## Related Issue(s)
N/A - This is a refactoring for improved code maintainability and
performance.
## Merge Dependencies
**Must be merged AFTER:** #33734
---
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
With the new tsgo `baseUrl` has been completely removed, this breaks
compilation of plugins using swc when calling them with nx due to swc
needing the baseUrl. I patched my company workspace with this fix and it
did resolve it, not sure if its the right fix or what the ramifications
are so happy to discuss that more. Since `baseUrl` is removed in tsgo
(and recommended against in general), we need to find a way to provide
it to swc (potentially through an `.swcrc` alternatively, I tried adding
that to my workspace though and it didn't do anything).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Expo CLI 54.0.12+ changed how originModulePath is determined in Metro
resolvers - from workspace root to project root. This caused the Nx
custom resolver to double-path modules when resolving workspace
libraries.
This fix:
- Adds projectRoot: workspaceRoot to the Metro config to ensure
originModulePath remains workspace-relative
- Adds defensive path normalization in pnpmResolver to handle edge cases
Fixes#33597
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Self-healing docs only reference being supported for GitHub.
<!-- This is the behavior we have today -->
## Expected Behavior
We should show instructions for all currently supported vcs providers,
including GitLab and Azure Devops.
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Replace process.exit(1) calls with typed CnwError exceptions for
structured error reporting and telemetry tracking. Update recordStat
meta to use typed JSON objects with named keys instead of arrays.
Examples of what's sent as `meta`.
```
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-remote-cache-visit","nxCloudArg":"skip","nxCloudArgRaw":"","pushedToVcs":"SkippedGit","template":"nrwl/empty-template"}
{"type":"start","flowVariant":"1"}
{"type":"start","flowVariant":"0"}
{"type":"complete","flowVariant":"0","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"enable-caching2","nxCloudArg":"skip","nxCloudArgRaw":"","pushedToVcs":"SkippedGit","template":"custom"}
{"type":"start","flowVariant":"1"}
{"type":"error","errorCode":"DIRECTORY_EXISTS"}
{"type":"start","flowVariant":"1"}
{"type":"error","errorCode":"DIRECTORY_EXISTS"}
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-green-prs-visit","nxCloudArg":"yes","nxCloudArgRaw":"","pushedToVcs":"FailedToPushToVcs","template":"nrwl/empty-template"}
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-fast-ci-visit","nxCloudArg":"yes","nxCloudArgRaw":"","pushedToVcs":"FailedToPushToVcs","template":"nrwl/empty-template"}
{"type":"start","flowVariant":"1"}
{"type":"start","flowVariant":"1"}
{"type":"complete","flowVariant":"1","setupCIPrompt":"which-ci-provider","setupCloudPrompt":"cloud-v2-green-prs-visit","nxCloudArg":"skip","nxCloudArgRaw":"","pushedToVcs":"SkippedGit","template":"nrwl/typescript-template"}
{"type":"start","flowVariant":"1"}
{"type":"error","errorCode":"WORKSPACE_CREATION_FAILED"}
```
Known errors like "directory exists" does not print stack trace:
<img width="1061" height="362" alt="image"
src="https://github.com/user-attachments/assets/8f29f303-3839-4297-b789-d23ac3af6d52"
/>
Another known error (invalid custom preset):
<img width="1091" height="391" alt="image"
src="https://github.com/user-attachments/assets/c7f6e586-42a8-493b-b595-f7d77743683f"
/>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When using Nx React Module Federation with Rspack, running `nx run-many
-t e2e` before `nx run-many -t typecheck`, it causes typecheck to fail.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx run-many -t typecheck` should succeed regardless of whether Rspack
(via `nx preview`) was executed before it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/33445
The CopyAssetsHandler was logging every copied file to the console,
causing noisy output when a project copies many files. This could
cause build errors to be cut off in terminals with scroll limits.
Change logger.log() to logger.verbose() so per-file logging only
appears when --verbose is passed or NX_VERBOSE_LOGGING=true.
Fixes#33521
The release-publish executor was only displaying npm-style errors
(error.summary
and error.detail), but pnpm returns errors with a different format
(error.code
and error.message). This caused pnpm publish errors to be invisible
unless users
passed the --verbose flag.
This fix adds handling for pnpm's error format so that error messages
are
properly displayed to users without requiring --verbose.
Fixes 33537
Adds a 'compiler' option to the @nx/js/typescript plugin configuration,
with options 'tsc' and 'tsgo'. Affects both typecheck and build targets.
## Current Behavior
The `@nx/js/typescript` plugin always uses `tsc` as the compiler, with
no way to use the native `tsgo` preview.
## Expected Behavior
The `@nx/js/typescript` plugin can be configured to use `tsgo` for
building and typechecking.
## Related Issue(s)
Related discussion #32591.
This pull request introduces a new option to the Nx Webpack plugin that
allows users to control whether the plugin should merge its external
dependencies configuration with any existing Webpack externals
configuration. This provides greater flexibility when customizing how
external dependencies are handled during the build process.
Configuration enhancements:
* Added a new `mergeExternals` boolean option to the
`NxAppWebpackPluginOptions` interface, allowing users to specify whether
to combine the plugin's externals configuration with the existing
Webpack config.
* Updated the logic in `apply-base-config.ts` so that the `externals`
array is set based on the new `mergeExternals` option, defaulting to not
merging unless specified.
---------
Co-authored-by: David Antoon <davidmantoon@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Currently the template flow will only set up `npm`, even if you run
`yarn create` or `pnpx create-nx-workspace`. This PR adds support back
for other package managers.
## Current Behavior
When we prepare ENVs for the DefinePlugin, we are creating the
`process.env` object.
For example:
```
// .env
NX_PUBLIC_VALUE1=1
NX_PUBLIC_VALUE2=2
NX_PUBLIC_VALUE3=3
```
As result we will have:
```js
{
'process.env': {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}
}
```
As a result, in the final bundle, we will replace process.env with this
object.
The issue:
If I use all 3 values in my application DefinePlugin will inject this
object 3 times, instead of injecting it once.
It will look like that:
```js
const a = {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}.NX_PUBLIC_VALUE1
const b = {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}.NX_PUBLIC_VALUE2
const c = {
"NX_PUBLIC_VALUE1": "1",
"NX_PUBLIC_VALUE2": "2",
"NX_PUBLIC_VALUE3": "3"
}.NX_PUBLIC_VALUE3
```
## Expected Behavior
DefinePlugin injects values instead of env object in each place
```js
const a = "1"
const b = "2"
const c = "3"
```
## Fixes
- fixed this issue for webpack
- fixed this issue for storybook
- fixed this issue for rspack
TLDR:
now we have object like so:
```js
{
"process.env.NX_PUBLIC_VALUE1": "1",
"process.env.NX_PUBLIC_VALUE2": "2",
"process.env.NX_PUBLIC_VALUE3": "3"
}
```
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
NodeNext is not recognized as ESM. This causes this warning message to
be logged, even when you have `"type": "module",` in the `package.json`
file and are compile TypeScript to `"module": "NodeNext"`.
```
Package type is set to "module" but "cjs" format is included. Going to use "esm" format instead. You can change the package type to "commonjs" or remove type in the package.json file.
```
## Expected Behavior
Don't log this message. It is incorrect.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
This pull request refactors the `dependsOn` configuration for Jest
targets in the Nx plugin to improve flexibility and maintainability. The
changes replace string-based dependencies with structured objects,
ensuring better alignment with Nx's target configuration standards.
This PR updates the `dependsOn` configuration for Jest `ciTarget` to
ensure that top-level args are passed on if the parent target has a
dependsOn for other targets.
For example if i pass `nx run-many e2e-ci -- --json
--outputFile=my-test-results.json` the options:
- `--json`
- `--outputFile`
Should be forwarded to the dependent targets.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
The check should be for `GITHUB_ACTIONS` since that is the intention.
The token may not be set due to Trusted Publisher flow.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
…new convention
## Current Behavior
Currently, the @nx/vite plugin generates a `vite.config.ts` file where
the worker configuration is commented out, but uses the old format:
```ts
// worker: {
// plugins: [ nxViteTsPaths() ],
// }
```
If uncomment, this format triggers a warning from Vite, as the worker
configuration should now be a function that returns an array of plugins.
While Vite automatically converts the old format for compatibility, it
is not ideal to rely on this behavior.
## Expected Behavior
With the changes in this PR, the @nx/vite plugin will generate a Vite
configuration where the worker configuration follows the new convention,
avoiding warnings and ensuring compatibility with future versions of
Vite. The updated configuration will look like this:
```ts
// worker: {
// plugins: () => [ nxViteTsPaths() ],
// }
```
This change ensures that the generated configuration aligns with Vite's
recommended practices and eliminates unnecessary warnings.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
The NxAppWebpackPlugin option 'verbose' should show chunk output during
webpack build when true, and hide them when false. It's currently the
reverse, causing a lot of console spam during dev, and the hiding the
info during ci/cd.
## Current Behavior
Setting the NxAppWebpackPlugin option 'verbose' to false shows chunk
output.
<img width="848" alt="chunky"
src="https://github.com/user-attachments/assets/4cd5502d-d059-4ace-9e42-28eb160bc1d0"
/>
## Expected Behavior
Setting the NxAppWebpackPlugin option 'verbose' to false hides chunk
output.
Resolve issue when
projectRoot was created from
join workspaceRoot and projectNode.data.root
but method createTmpTsConfig also make join
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
```
method withNx create
const projectRoot = join(workspaceRoot, projectNode.data.root);
```
method createTmpTsConfig
apply also join
```
const tmpTsConfigPath = join(
workspaceRoot,
'tmp',
projectRoot,
process.env.NX_TASK_TARGET_TARGET ?? 'build',
`tsconfig.generated.${randomUUID()}.json`
);
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31522
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
No option to manage opening html report after run.
## Expected Behavior
Added option to manage opening html report after run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
The nightly-2025-12-10 Rust version removed `mtim()` from the WASI
`MetadataExt` trait, causing the WASM build to fail with:
```
error[E0599]: no method named `mtim` found for reference `&std::fs::Metadata` in the current scope
```
## Expected Behavior
WASM builds should compile successfully.
## Solution
Revert to `nightly-2025-05-09` which still has the `mtim()` API
available in the WASI `MetadataExt` trait.
## Current Behavior
The `build:wasm` script uses `rustup override set nightly-2025-12-10` to
set the Rust toolchain. However, when mise is configured to manage Rust
(e.g., `rust = "1.90.0"` in `mise.toml`), it sets the `RUSTUP_TOOLCHAIN`
environment variable which has higher precedence than directory
overrides.
This causes the WASM build to fail with:
```
error[E0554]: `#![feature]` may not be used on the stable release channel
```
## Expected Behavior
WASM builds should use nightly Rust regardless of mise configuration.
## Solution
Set `RUSTUP_TOOLCHAIN=nightly-2025-12-10` directly in the script, which
overrides any existing env var from mise or other sources.
## Current Behavior
The Nx Console settings reference lacks explanation of VSCode's user vs
workspace settings and incorrectly states that Project Viewing Style is
unavailable in JetBrains IDEs.
## Expected Behavior
Nx consoles are documented for vscode/jetbrains editors
https://deploy-preview-33363--nx-docs.netlify.app/docs/reference/nx-console-settings
fixes: DOC-315
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
After the mise migration (#33772), the `publish.yml` workflow fails
during the "Build Wasm" step with:
```
error[E0554]: `#![feature]` may not be used on the stable release channel
--> packages/nx/src/lib.rs:2:33
|
2 | #![cfg_attr(target_os = "wasi", feature(wasi_ext))]
```
The WASM build requires nightly Rust because it uses the unstable
`wasi_ext` feature. The `build:wasm` script attempts to switch to
nightly via `rustup override set`, but after the mise migration, the
nightly toolchain is no longer pre-installed, causing the build to fail
with the stable compiler.
## Expected Behavior
The WASM build should successfully compile using nightly Rust with the
`wasi_ext` feature.
## Related Issue(s)
Fixes the publish workflow regression introduced in #33772
| | Before | After |
| ---- | ----- | ---- |
| Total createNodes | 812 | 104 |
| Total matchPropValue | 672 | 2 |
## Current Behavior
The `createNode` function is slow for pnpm due to suboptimal
`matchPropValue` function.
## Expected Behavior
The `createNode` function should be fast and not slowdown the graph
creation.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When some tasks fail during execution, it can result in a cryptic:
```bash
Failed to convert JavaScript value 'Undefined' into rust type 'String'
```
This happens because the reported `terminalOutput` for the errored tasks
can be `undefined`, and it hides the actual error that occurred.
## Expected Behavior
Error handling paths should always provide a valid string for
`terminalOutput`, using the error stack/message, or an empty string as a
fallback.
## Related Issue(s)
Fixes#32675
## Current Behavior
The inline `mise_toml` config in `e2e-matrix.yml` was overwriting the
entire `mise.toml` file, causing rust, dotnet, bun, and java to NOT be
installed by mise. This resulted in slow package installs as these tools
were downloaded during `pnpm install` instead.
## Expected Behavior
All tools from `mise.toml` (rust, dotnet, bun, java) should be installed
by mise, with only the node version varying based on the matrix.
## Solution
Use mise's template syntax to make node version configurable via
`NODE_VERSION` env var while preserving all other tools from
`mise.toml`:
```toml
node = "{{ env['NODE_VERSION'] | default(value='24') }}"
```
Then in the workflow, set the env var instead of overriding the entire
config:
```yaml
- name: Setup dev tools with mise
uses: jdx/mise-action@v3
env:
NODE_VERSION: ${{ matrix.node_version }}
```
## Related Issue(s)
Fixes slow install times in nightly e2e-matrix workflow after #33772.
## Current Behavior
The mise vfox-dotnet plugin fails on Windows with:
```
mise ERROR Failed to install vfox:mise-plugins/vfox-dotnet@9:
0: error converting Lua table to PreInstall (no version returned from vfox plugin)
```
This prevents dotnet from being installed via mise on Windows CI
runners.
## Expected Behavior
Dotnet should install successfully on all platforms including Windows.
## Related Issue(s)
Related upstream issue: https://github.com/jdx/mise/discussions/4738
## Solution
1. **mise.toml** - Made dotnet installation conditional on Linux/macOS
only using the `os` option
2. **.github/workflows/publish.yml** - Added `winget install` to install
.NET SDK 9 on Windows CI runners
This approach works around the buggy vfox plugin by using the native
Windows package manager instead.
## Current Behavior
When building Angular libraries with `ng-packagr` >20.3.0, the build
fails with:
```bash
TypeError: Cannot read properties of undefined (reading 'outputCache')
```
This occurs because `ng-packagr` v20.3.1 introduced a memory
optimization
([ng-packagr#3172](https://github.com/ng-packagr/ng-packagr/pull/3172))
that calls `dispose()` on entry points after they're processed, setting
`entry.cache = undefined`.
Nx's custom `writeBundlesTransform` was iterating over **all** entries
in the graph, including already-disposed entry points, causing the crash
when accessing their cache.
## Expected Behavior
Angular library builds should succeed with `ng-packagr` >20.3.0,
including libraries with secondary entry points. Workspaces using lower
versions of `ng-packagr` should remain unaffected.
## Solution
Align with `ng-packagr`'s own pattern by using
`graph.find(isEntryPointInProgress())` to process only the currently
in-progress entry point, rather than iterating over all graph entries.
**Key changes:**
- Use `isEntryPointInProgress()` instead of iterating all entries with
`isEntryPoint()`
- Remove unused `BuildGraph` import (no longer creating a new graph)
- Update package node only when processing the primary entry point (more
efficient)
- Return nothing from the transform (original graph passes through, same
as ng-packagr)
This approach:
- Matches `ng-packagr`'s `writeBundlesTransform` implementation pattern
- Only accesses cache of the in-progress entry point (guaranteed not to
be disposed)
- Works with all supported `ng-packagr` versions (v19+) since
`isEntryPointInProgress()` has been available since v19
## Related Issue(s)
Fixes#33560
This PR fixes an issue with CNW where the initial `recordStat` call is
not working due to a logic error on passing `directory` that isn't
initialized yet.
## Current Behavior
If there are issues with values passed to generators via prompt, we
still see a green output and exit code 0.
A colleague found out about this by pressing `Ctrl+C` when being
prompted for parameters for a generator, and this led to the CLI simply
continuing execution and showing no issue.
## Expected Behavior
CLI fails.
Allows setting a default output style instead of having to include it on
every command
Closes#27490
## Current Behavior
We must specify --outputStyle on every command
## Expected Behavior
Should allow overriding the default with an environment variable
## Related Issue(s)
#27490Fixes#27490
When 8+ dependent tasks exist, each adds an `exit` listener to track
completion. This listener attaches to `process`. So we apply the same
fix that worked for `stdout` and `stderr`, and was merged through [PR
16693](https://github.com/nrwl/nx/pull/16993)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
For `nx` targets with 8+ dependent targets, we encounter
`maxListenersExceededWarning`:
```
(node: 22553) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit.
(node: 22553) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit.
(node: 22553) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGHUP listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit.
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
No `MaxListenersExceededWarning` should be thrown on account of the nx
run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32439
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
In `filterAffectedProjects`, a **new visited Set is created for each
touched project**:
```typescript
ctx.touchedProjects.forEach((p) => {
addAffectedNodes(p, reversed, result, new Set()); // NEW Set per project!
});
ctx.touchedProjects.forEach((p) => {
addAffectedDependencies(p, reversed, result, new Set()); // NEW Set per project!
});
```
This defeats the purpose of the visited Set for deduplication. If
projects A and B both depend on shared project C, then C gets visited
**twice**.
## Expected Behavior
Share a single visited Set across all touched projects:
```typescript
const visitedNodes = new Set<string>();
const visitedDeps = new Set<string>();
for (const p of ctx.touchedProjects) {
addAffectedNodes(p, reversed, result, visitedNodes); // SHARED Set
}
for (const p of ctx.touchedProjects) {
addAffectedDependencies(p, reversed, result, visitedDeps); // SHARED Set
}
```
## Performance Impact
```
Before (separate Sets): After (shared Sets):
┌─────────────────────────┐ ┌─────────────────────────┐
│ touchedProjects: [A,B] │ │ touchedProjects: [A,B] │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
┌───────┴───────┐ ┌───────┴───────┐
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ A │ │ B │ │ A │ │ B │
│visited│ │visited│ │ │ │ │
│= {} │ │= {} │ │ shared visitedNodes │
└───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘
│ │ │ │
▼ ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────────────────────┐
│visit C│ │visit C│ │ visit C (ONCE) │
│(dup!) │ │(dup!) │ │ skip C from B │
└───────┘ └───────┘ └───────────────────────┘
Complexity: Complexity:
O(touched × shared_deps) O(total_nodes)
```
**Example**: With 50 touched projects sharing 100 common dependencies:
- Before: 50 × 100 = 5,000 node visits
- After: ~150 node visits (each node visited once)
## Why Accept This PR
1. **Bug-like behavior**: The current code defeats the purpose of the
visited Set
2. **Significant impact**: Affects every `nx affected` command
3. **Zero risk**: Same traversal logic, just shared deduplication
4. **Common scenario**: Monorepos often have shared dependencies (utils,
types, etc.)
## Related Issue(s)
Contributes to #32265
## Merge Dependencies
This PR has no dependencies and can be merged independently.
---
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: khalilou88 <32600911+khalilou88@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Summary
Migrates GitHub workflows to use [mise](https://mise.jdx.dev/) for
managing development tool installations instead of individual setup
actions.
## Changes
- **mise.toml**: Added pnpm@10.11.1 to tool configuration
- **ci.yml**: Replaced pnpm, node, rust, and java setup actions with
`mise-action@v3` in both Linux and macOS jobs
- **e2e-matrix.yml**: Replaced all tool setup actions with mise-action
in preinstall and e2e jobs
- **publish.yml**: Replaced tool setup actions with mise-action in build
and publish jobs
- **codeql workflows**: Updated to use `mise-action@v3`
## Benefits
- **Single source of truth**: All tool versions defined in `mise.toml`
- **Faster CI setup**: Mise provides better caching than individual
actions
- **Consistency**: Same tool versions across local dev and CI
- **Easier maintenance**: Update versions in one place
## Test Plan
- [ ] CI workflow passes on Linux
- [ ] CI workflow passes on macOS
- [ ] E2E matrix builds successfully
- [ ] Publish workflow can run (test with dry-run if possible)
- [ ] CodeQL scans complete successfully
Fixes #ISSUE_NUMBER
## Current Behavior
We do not have a guide showing how to use Vitest with custom conditions
## Expected Behavior
Add a guide showing how to use Vitest with custom conditions
The Plugin Registry page in astro-docs displays a static grid of plugins
without any search or filtering capabilities, making it hard to find
specific plugins.
Users can search plugins by name or description, and sort by release
date, npm downloads, GitHub stars, or Nx version compatibility.
<img width="975" height="1059" alt="image"
src="https://github.com/user-attachments/assets/a08e2a12-697e-4e3b-b9c0-2983d50fdad8"
/>
Closes DOC-343
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
The fileURLToPath and dirname imports are only used in the
getAbsolutePath function, which is only generated for non-Angular
Storybook projects.
## Expected Behavior
This change prevents unnecessary imports from being added to Angular
Storybook configurations.
## Current Behavior
When using pnpm with workspace protocol (`workspace:*`, `workspace:^`,
etc.), module federation sets `requiredVersion` to the raw protocol
string (e.g., `workspace:*`) instead of resolving it to the actual
semver version from the library's package.json.
This causes issues like:
- `requiredVersion: "workspace:*"` which is not a valid semver
- Module federation failing to properly share workspace libraries
- Warnings about unable to find required versions
Example of the broken output:
```json
{
"version": "*",
"singleton": true,
"requiredVersion": "^*"
}
```
## Expected Behavior
When a workspace protocol version is detected, it should be resolved to
the actual version from the library's package.json:
```json
{
"version": "2.0.0",
"singleton": true,
"requiredVersion": "2.0.0"
}
```
## Changes Made
1. **Added helper functions** in `share.ts`:
- `isWorkspaceProtocolVersion()` - Detects workspace protocol versions
(`workspace:*`, `workspace:^`, `*`, `file:`)
- `normalizeWorkspaceProtocolVersion()` - Resolves protocol versions to
actual semver by looking up the library's package.json
2. **Applied normalization in `shareWorkspaceLibraries()`**:
- After getting version from `getDependencyVersionFromPackageJson`,
normalize it if it's a workspace protocol
- Simplified the `workspaceLibrariesAsDeps` loop by using the helper
function (removed duplicated logic)
3. **Updated `getNpmPackageSharedConfig()`**:
- Added a check to warn and return undefined when workspace protocol
versions are passed
- Helps users understand that workspace libraries should be configured
properly
4. **Added comprehensive tests** (13 new tests):
- 6 tests for workspace protocol version normalization in
`shareWorkspaceLibraries`
- 7 tests for `getNpmPackageSharedConfig` handling workspace protocol
versions
## Related Issue(s)
Fixes#31397
## Merge Dependencies
This PR has no dependencies and can be merged independently.
**Must be merged BEFORE:** #33734
---
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We would add the gradle project graph plugin to your build.gradle files
if we did not already detect it. However, this did mechanism did not
recognize aliases for the project graph plugin that came from version
catalogs.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When adding the project graph plugin to build.gradle.kts, we check if a
version catalogue exists, and if it does we add the alias for the
project graph plugin.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
The `hasPath` function in `graph.ts` uses an array with `indexOf()` for
tracking visited nodes during recursive graph traversal:
```typescript
function hasPath(graph, target, node, visited: string[]) {
for (let d of graph.dependencies[node] || []) {
if (visited.indexOf(d.target) > -1) continue; // O(n) lookup
visited.push(d.target);
// recursive call...
}
}
```
This results in O(n) lookups per node visited, making worst-case
traversal O(n²).
## Expected Behavior
Use `Set` for O(1) visited node tracking:
```typescript
function hasPath(graph, target, node, visited: Set<string>) {
for (const d of graph.dependencies[node] || []) {
if (visited.has(d.target)) continue; // O(1) lookup
visited.add(d.target);
// recursive call...
}
}
```
## Performance Impact
```
Before (Array + indexOf): After (Set + has):
┌─────────────────────────┐ ┌─────────────────────────┐
│ hasPath() called │ │ hasPath() called │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐
│ visited.indexOf(target) │ │ visited.has(target) │
│ O(n) lookup │ │ O(1) lookup │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐
│ visited.push(target) │ │ visited.add(target) │
│ O(1) │ │ O(1) │
└───────────┬─────────────┘ └───────────┬─────────────┘
│ │
▼ ▼
Complexity: O(n²) Complexity: O(n)
for full traversal for full traversal
```
**Example with 500 nodes:**
- Before: 500 nodes × avg 250 indexOf lookups = ~125,000 comparisons
- After: 500 nodes × 1 Set lookup each = 500 operations
## Why Accept This PR
1. **Zero risk**: Same semantics, just faster data structure
2. **Standard pattern**: Set is the idiomatic choice for visited
tracking in graph algorithms
3. **Measurable impact**: Graph filtering with `--focus` flag will be
significantly faster on large monorepos
## Related Issue(s)
Contributes to #32265
## Merge Dependencies
This PR has no dependencies and can be merged independently.
---
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Correcting docs to mention that resource collection on Nx Cloud will be
availabe from 22.2 onwards.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When using `nx release version --preid=alpha`, the version determination
now correctly considers both prerelease tags AND stable release tags to
determine the "latest" version. Previously, it would only look at
prerelease tags matching the preid, ignoring stable releases that should
have become the new baseline.
For example, with tags: 1.1.0, 1.1.0-alpha.0, 1.1.0-alpha.1, 1.1.1
- Before: Would return 1.1.0-alpha.1 → bump to 1.1.0-alpha.2
- After: Returns 1.1.1 (stable >= preid base) → bump to 1.1.2-alpha.0
Fixes#33343
## Current Behavior
The Maven plugin version is currently at 0.0.10 across all pom.xml files
in the repository.
## Expected Behavior
With this PR, the Maven plugin version will be updated to 0.0.11. This
includes:
- Updating the version in the root pom.xml
- Updating the version in packages/maven/maven-plugin/pom.xml
- Updating the mavenPluginVersion constant in
packages/maven/src/utils/versions.ts
- Adding a migration script to automatically update user pom.xml files
from 0.0.10 to 0.0.11
## Related Issue(s)
N/A - Version bump for the Maven plugin
Webpack e2e tests occasionally hang in CI without clear indication of
where the test gets stuck.
Debug logs will help identify which step the test hangs at, making it
easier to diagnose and fix the root cause.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Current gradle plugin version is at 0.1.9
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Take gradle plugin to 0.1.10
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Pressing Cmd+K (or Ctrl+K) on non-docs pages does nothing. The Pagefind
search is only accessible when already on the documentation pages.
Pressing Cmd+K on any non-docs page redirects to the docs and
automatically opens the search modal with focus on the input field.
https://www.loom.com/share/72fcee74620640cab28639e9ad33d962
Closes DOC-314
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The `tools/update-repos/config/repos.json` configuration has the ocean
repository set to use `npm` as its package manager.
## Expected Behavior
The ocean repository should be configured to use `pnpm` as its package
manager, reflecting the actual package manager used by the repository.
## Related Issue(s)
N/A - Configuration update to reflect actual repository state.
This PR adds `SIGINT` handling when user kills the process via `Ctrl+C`
during CNW. This only prints when the workspace setup is complete, and
we also print the Cloud onboarding URL if it has been set up.
Also fixes an issue where `selectedRepositoryName` is never sent during
CNW.
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
you can mark some targets generated by gradle by specifying options.
## Expected Behavior
you can apply a prefix to all targets generated by gradle. This is
useful for targetDefaults, for example.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds a Gradle option to prefix all generated Nx target names
(including dependencies and CI targets) with tests to avoid
double-prefixing.
>
> - **Gradle project graph**:
> - Apply optional `targetNamePrefix` to all target names and dependency
rewrites in `createNodeForProject`, `processTargetsForProject`, and
`getDependsOnForTask`.
> - Wire prefix through plugin/task: read in
`NxProjectGraphReportPlugin`, expose on `NxProjectReportTask`, and pass
to processing functions.
> - Ensure CI targets (`ciTestTargetName`, `check-ci`, `build-ci`) are
correctly prefixed and not double-prefixed; update dependency
replacement logic accordingly.
> - Add logging for prefix usage.
> - **Plugin options (TS)**:
> - Extend `GradlePluginOptions` with `targetNamePrefix` in
`packages/gradle/src/plugin/utils/gradle-plugin-options.ts`.
> - **E2E tests**:
> - Add tests validating prefixed targets exist and run, and that CI
test targets are not double-prefixed in `e2e/gradle/src/gradle.test.ts`.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
9a5160b8855a32d6c13c33c97379e7aa143a0737. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Key optimisations:
1. Pre-computed PackageIndex - Built once during lockfile parsing:
- byName: Map from package name → array of versions (O(1) lookup)
- workspaceNames: Set of workspace package names (O(1) lookup)
- workspacePaths: Set of workspace paths (O(1) lookup)
- packagesWithWorkspaceVariants: Set of packages with workspace-specific
variants (O(1) lookup)
- patchedPackages: Set of patched package names (O(1) lookup)
2. findResolvedVersion: Changed from O(n) scan through all packages to
O(1) map lookup + O(k) where k = number of versions for that package
(typically 1-3)
3. isWorkspacePackage: Changed from O(n) scan to O(1) set lookup
4. hasWorkspaceSpecificVariant: Changed from O(n) scan to O(1) set
lookup
5. isNestedPackageKey: Now uses pre-computed workspace paths/names sets
instead of computing them each call
On my 40 project typescript monorepo my time goes from about 30 seconds
to 4.5s, a speed-up of 6-7x.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
This PR simplifies the CNW process so we only prompt for a starter (TS,
NPM Packages, React, Angular) and we clone a full example to showcase Nx
monorepo for the given starter. This speeds up CNW drastically and
allows users to get the workspace in 5-10 seconds vs 1-3 minutes.
Users can choose `Custom` to fall back to the previous prompts, which
will ask framework, unit test runner, e2e runner, etc.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Gradle multi-module projects have project names with colons (e.g.,
`:common:iam-client`)
which are invalid in git tag names. This adds a
`sanitizeProjectNameForGitTag()` function
that replaces colons with slashes and other invalid git ref characters
with hyphens.
The sanitization is applied when:
- Creating git tags in `createGitTagValues()`
- Creating the `ReleaseVersion` class gitTag property
- Matching existing tags in `getLatestGitTagForPattern()`
Fixes#33262
## Current Behavior
We only support Expo 53
## Expected Behavior
Add support for Expo 54
Allow existing workspaces wishing to remain on Expo 53 to continue to be
supported
Add migrations allowing LLMs to handle migrating from Expo 53 to Expo 54
## Related Issue(s)
Closes NXC-3526
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Rebuild logs during serve of Angular Rspack applications are logged an
exponential number of times with each change.
## Expected Behavior
Log only once
## Current Behavior
We currently install an outdated version of `@emotion/styled` that
causes Typecheck issues.
## Expected Behavior
Use latest version of Emotion
## Related Issue(s)
Fixes#31252
## Current Behavior
Angular Rspack outputs ESM for build and serve. However, with serve, it
causes issue for HMR.
## Expected Behavior
Use CJS for serve to allow HMR to work correctly
## Related Issue(s)
Fixes#33106
## Expected Behavior
Generate only `vitest.config.mts` file when not bundling with Vite
Use `vite.config` file if it exists already
Add `testMode` option to the `@nx/vitest` Inference Plugin to allow
easier switching between `vitest` and `vitest run`.
## Related Issue(s)
Fixes NXC-3334
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Removes legacy additions of `.cursor/rules/nx-rules.mdc` and
`.github/instructions/nx.instructions.md` to `.gitignore` across code,
templates, and migrations.
>
> - **.gitignore behavior**:
> - Remove logic in
`packages/nx/src/command-line/init/implementation/utils.ts` that
appended `.cursor/rules/nx-rules.mdc` and
`.github/instructions/nx.instructions.md`.
> - Clean up root `.gitignore` to exclude those entries.
> - Update new workspace templates
(`packages/workspace/.../__dot__gitignore`) to omit those entries.
> - **Migrations**:
> - Remove migration `21-1-0-add-ignore-entries-for-nx-rule-files` from
`packages/nx/migrations.json` and delete its implementation and spec.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
7863fa5beee127777f819a5155ae17239c5b16cd. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## Current Behavior
Trying to create a new workspace is failing on npm peer dep conflicts
when trying to use Vitest with Angular.
The version of `@analogjs/vitest-angular` only supports Vitest <4.
## Expected Behavior
Update to latest version of `@analogjs/vitest-angular` to support Vitest
4
## Related Issue(s)
Fixes#33602
## Current Behavior
`buildLibsFromSource` defaults to true only in the `@nx/rollup:rollup`
executor.
In the normalize options helper for the executor, it is not handled at
all. Programmatic usage would therefore result in `undefined`.
For pure Inference Plugin usage, `buildLibsFromSource` is also not
handled in normalize options.
Therefore, it always defaults to `undefined`.
## Expected Behavior
To reduce breaking changes, force `buildLibsFromSource` to be false for
Inference Plugin usage.
Explicitly set it in executor's normalize options helper to true to
match the schema default.
## Related Issue(s)
Fixes NXC-3537
# Fix: Pass releaseGroupName to getLatestGitTagForPattern for proper tag
resolution
## Problem
When using `releaseTag.pattern: "{releaseGroupName}@{version}"`, Nx
fails to resolve versions from git tags because the `{releaseGroupName}`
placeholder is not interpolated.
For example, with git tag `my-group@2.9.0`:
- **Expected**: Extract version `2.9.0`
- **Actual**: Extracts `"my-group"` → Error: `Invalid semver version
'my-group' provided`
## Root Cause
In `release-graph.ts:627-631`, only `projectName` is passed to
`getLatestGitTagForPattern()`, missing `releaseGroupName` needed for
interpolation.
## Solution
Pass `releaseGroupName` to the interpolation data (1-line change at
`release-graph.ts:631`):
```typescript
latestMatchingGitTag = await getLatestGitTagForPattern(
releaseTagPattern,
{
projectName: projectGraphNode.name,
releaseGroupName: releaseGroupNode.group.name, // ✅ Added
},
{ ... }
);
```
## Backward Compatibility
✅ Fully backward compatible:
- `releaseGroupNode.group.name` is always defined (user-defined or
`"__default__"`)
- Unused interpolation data is safely ignored
- Existing patterns (`v{version}`, `{projectName}@{version}`) continue
to work
## Tests
Added test case in `git.spec.ts` for `{releaseGroupName}@{version}`
pattern that verifies correct tag matching and version extraction.
## Files Changed
- `packages/nx/src/command-line/release/utils/release-graph.ts` (1 line)
- `packages/nx/src/command-line/release/utils/git.spec.ts` (1 test case)
Co-authored-by: James Henry <james@henry.sc>
## Current Behavior
The arboard crate is used without the `wayland-data-control` feature,
which means clipboard operations may not work properly on Wayland-based
Linux systems.
## Expected Behavior
With the `wayland-data-control` feature enabled, arboard can interact
with the clipboard on Wayland systems using the wlr-data-control
protocol.
## Related Issue(s)
N/A - Enhancement for better Wayland support
## Current Behavior
The Maven plugin incorrectly maps Maven's `isThreadSafe` mojo property
to Nx's `parallelism` target property. Maven's `isThreadSafe` indicates
whether a mojo can safely run in parallel with other mojos of the same
type within the same Maven build (multi-threaded Maven builds).
## Expected Behavior
Nx's `parallelism` controls whether the target can run in parallel
alongside anything else - a fundamentally different concept. All Maven
targets now default to `parallelism: true`, letting Nx handle
parallelism based on its own task graph analysis rather than using
Maven's unrelated thread-safety concept.
## Related Issue(s)
N/A - Internal cleanup based on code review feedback.
## Current Behavior
On Node.js v24+, the `@nx/jest/plugin` sets
`--no-experimental-strip-types` in NODE_OPTIONS which causes an error:
"node: --no-experimental-strip-types is not allowed in NODE_OPTIONS".
Additionally, `jest.config.ts` files using ESM syntax (`export default`,
`import`) fail to load correctly under Node.js type-stripping when the
project is configured for CommonJS.
## Expected Behavior
- Remove the NODE_OPTIONS manipulation that adds
`--no-experimental-strip-types`
- Add a migration (22.2.0-beta.2) that converts `jest.config.ts` files
from ESM to CJS syntax for projects using `@nx/jest/plugin`
- The migration only runs when `@nx/jest/plugin` is registered in
`nx.json`
- Projects with `type: module` are warned as they're incompatible with
the plugin
- Files using ESM-only features (import.meta, top-level await) are
skipped with a warning for manual conversion
## Demo
https://www.loom.com/share/8a157a0b01d144ae8d6ae48b9b0cd0e4
## Related Issue(s)
Closes NXC-3541
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
We don't have a migration to migrate users to use the new @nx/vitest
package if they're currently using @nx/vite
Given that we have Vitest-related operations marked as deprecated when
used via @nx/vite, we should have a migration.
## Expected Behavior
Add a migration that:
1. Installs @nx/vitest
2. Switches @nx/vite:test executor usage to use @nx/vitest:test executor
usage
3. Splits `@nx/vite/plugin` in nx.json that sets up vitest test targets
to use `@nx/vitest` instead
## Current Behavior
The `@nx/vite:test` executor is not returning the async iterable. This
causes a destructuring issue.
## Expected Behavior
Ensure the `@nx/vite:test` executor returns the async iterable.
## Related Issue(s)
Fixes#33588
This PR updates the `workspace-rule` generator so use ESLint v9 by
default. It currently forces the unsupported ESLint v8.
In theory this is only useful if not using workspaces and you need
tsconfig paths to be mapped and resolved correctly. For workspaces, you
can easily just generate any library to be used to contain custom rules.
Closes NXC-3500
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Blog posts contain broken links pointing to old `/powerpack` and
`/docs/enterprise/powerpack/*` paths that no longer exist.
## Expected Behavior
Links should point to the new enterprise documentation paths:
- `/powerpack` → `/enterprise`
- `/docs/enterprise/powerpack/*` → `/docs/enterprise/*`
- `/docs/reference/powerpack/*` → `/docs/reference/*`
## Related Issue(s)
Closes DOC-354
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When running `NX_PERF_LOGGING=true nx graph --file graph.json`, many
performance logs are missing (e.g., `create-project-graph-async`,
`retrieve-project-configurations`).
Only plugin-specific logs like `createDependencies` appear.
## Expected Behavior
All performance timing logs should appear, matching the output of
`NX_PERF_LOGGING=true nx show projects`.
## Related Issue(s)
N/A - Internal improvement for debugging/profiling.
## Solution
The `graph.ts` file had `process.exit(0)` calls that terminated the
process immediately, not giving the async `PerformanceObserver` callback
time to fire.
Added `await new Promise((res) => setImmediate(res))` before
`process.exit(0)` to give the event loop one tick to process pending
callbacks. This follows the existing
pattern in `show/projects.ts` and `show/project.ts`.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The Nx Console installation prompt blocks commands when run in
non-interactive contexts such as:
- CI environments
- AI agents
- Piped commands
The prompt only checked `process.stdout.isTTY` but not
`process.stdin.isTTY`, causing it to wait indefinitely for input that
would never arrive.
## Expected Behavior
Commands should complete without prompting when run in non-interactive
environments.
## Related Issue(s)
Fixes#33552
## Solution
Updated the check to verify:
1. Both `stdin` and `stdout` are TTY (truly interactive terminal)
2. Not running in a CI environment (using existing `isCI()` utility)
This ensures the prompt only appears when the user can actually provide
input.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Since Nx 21.6.1, running `nx graph` or other commands that calculate
affected projects prints git errors to stderr when the default branch is
not fetched:
```
fatal: ambiguous argument 'main': unknown revision or path not in the working tree.
```
This causes CI pipelines with strict stderr checking to fail, even
though the nx commands succeed.
## Expected Behavior
Git error messages should not be printed to stderr. The errors are
already caught and handled gracefully - they just shouldn't be visible
to the user.
## Related Issue(s)
Fixes#33330
## Solution
Added `stdio: 'pipe'` to the `execSync` call in `parseGitOutput()`. This
suppresses stderr output while still allowing the command to throw on
failure (which is already caught by the try-catch in `graph.ts`).
This matches the pattern used in `getMergeBase()` which already uses
`stdio: 'pipe'`.
## Current Behavior
When running `nx migrate latest`, the `create-nx-workspace` package is
not updated along with other Nx packages, even though it's a core part
of the Nx ecosystem that users may have as a dependency (especially when
extending the install package pattern).
## Expected Behavior
The `create-nx-workspace` package should be updated to the same version
as `nx` and other `@nx/*` packages when running migrations.
## Related Issue(s)
Fixes#33585
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The nuxt preset test was checking for `apps/${name}/src/app.vue`, but
since the generator now defaults to Nuxt v4 which uses the app directory
structure, this file is no longer created at that path.
## Expected Behavior
Tests should pass on master.
## Solution
Updated the test to check for `apps/${name}/app/app.vue` which is the
correct path for Nuxt v4's app directory structure.
## Current Behavior
When Nx commands finish or receive termination signals (SIGINT, SIGTERM,
SIGHUP), child processes spawned by continuous tasks (such as `nx
serve`) can remain orphaned in certain scenarios. This happens because
only the direct child process is killed using `childProcess.kill()`,
leaving grandchild processes running.
## Expected Behavior
When Nx terminates, all processes in the spawned process tree should be
properly terminated and no orphaned processes should remain.
## Related Issue(s)
Fixes#32438Fixes#33460
## Changes
- Updated signal handlers in `RunningNodeProcess` to use `this.kill()`
instead of `this.childProcess.kill()`, leveraging the existing
`tree-kill` implementation
- Added `tree-kill` to `NodeChildProcessWithNonDirectOutput` and
`NodeChildProcessWithDirectOutput` kill methods to ensure entire process
trees are terminated
We missed a peer dep error in the Nuxt 4 PR since CI allowed install to
go through, but in a real repo it would have failed.
We _may_ need to still have the `prefer-frozen-lockfile=false` option,
but let's let CI run with this first.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
We currently do not support Nuxt 4. We still generate Nuxt 3.
## Expected Behavior
Support Nuxt 4.
New workspaces will get Nuxt 4.
Existing Workspaces that use Nuxt 3 intentionally will continue to use
Nuxt 3.
Add a migration to update users to Nuxt 4
Handle ESLint flat config
## Related Issue(s)
Closes NXC-3525
Closes NXC-3497
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
The base `eslint` config will ignore `**/dist` but not `**/out-tsc`.
This can cause issues if lint is run after a `typecheck` which has
placed `.d.ts` files into an `out-tsc` directory.
## Expected Behavior
Base eslint config should ignore `**/out-tsc`
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
Storybook support is not explicitly set to 10.1 which has just been
released.
## Expected Behavior
Explicitly set storybook version to 10.1 to ensure support for Angular
21
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
- E2E nightly tests only run on Node 20 and 22.
- E2E nightly tests now also run on Node 24, 22, and 20 for linux. For
Windows and Mac run only 24.
Did a test run from this branch, and Node 24 passes where other versions
pass, and fails where other versions fail. It shouldn't make any golden
tests fail just due to Node 24, but it's possible that things will flake
more since the matrix has expanded. We just have to make them more
robust.
<img width="920" height="1089" alt="image"
src="https://github.com/user-attachments/assets/90ee4d04-68d5-4d0d-9729-60cacfbc99db"
/>
Close NXC-3491
## Current Behavior
The Next 16 AI Migration Instructions are always created, regardless of
existing Next version
## Expected Behavior
Make the Next 16 Migration optional
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
There is no documentation on how to create and use custom ESLint rules
in Nx workspaces.
Users can follow a guide to create custom ESLint rules using either:
1. Package Manager Workspaces (npm/yarn/pnpm/bun) - create a dedicated
ESLint plugin package that's symlinked via the package manager
2. `loadWorkspaceRules` utility from `@nx/eslint-plugin` - load rules
from any directory with automatic TypeScript transpilation
The guide includes:
- Comparison table for choosing the right approach
- Step-by-step instructions for both approaches
- TypeScript execution options (build first, Node.js native support,
tsx)
- Rule testing with `@typescript-eslint/rule-tester`
- Best practices and troubleshooting tips
Page:
https://deploy-preview-33618--nx-docs.netlify.app/docs/technologies/eslint/guides/custom-workspace-rules
Closes DOC-339
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Despite @nx/vite depending on @nx/vitest it only does so in the same
version that introduces the migration for Vitest 4.
This means the user does not get any migrations for Vitest 4
## Expected Behavior
Add the Vitest 4 migrations to the @nx/vite package to allow users to
migrate.
There's a problem when `@nx/rollup` is installed with yarn@1.22, and
typechecks.
This is caused by the transitive dependency chain:
```
rollup-plugin-copy@3.5.0 -> globby@10.0.1 -> @types/glob@7.2.0 -> @types/minimatch
```
When users run tsc without explicit `types` configuration, TypeScript
auto-discovers `@types/minimatch` from `node_modules` but can't properly
resolve it.
Note: This doesn't happen with NPM and PNPM, nor newer yarn versions.
Verified fix with this repro: https://github.com/jaysoo/rollup-251124Fixes#32398
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
## Current Behavior
- Storybook generator docs banner says "Nx uses Storybook 7"
- Separate storybook-9-setup.mdoc page exists
- No documentation for migrate-10 generator
## Expected Behavior
- Update banner to "Nx uses Storybook 10"
- Consolidate storybook-9-setup into upgrading-storybook guide
- Add migrate-10-generator-examples.md with AI-assisted migration docs
- Update all references to point to new consolidated guide
---
Main content is here:
https://deploy-preview-33619--nx-docs.netlify.app/docs/technologies/test-tools/storybook/guides/upgrading-storybook
Need to follow-up on the sidebar ordering as it doesn't seem to take it
into account for technologies section.
Fixes DOC-347
## Current Behavior
When a continuous task depends on another continuous task and the
dependent task exits with an error, the parent task continues running
indefinitely. The task execution never terminates, leaving processes
running in the background.
For example, if task `a` (continuous) depends on task `b` (continuous),
and task `b` exits with error code 1, task `a` will continue running
even though its dependency failed.
## Expected Behavior
When a continuous task exits (with any exit code), the failure should be
propagated to dependent tasks:
1. The failed continuous task should be marked as failed
2. Dependent continuous tasks should be marked as skipped
3. All affected continuous tasks should be killed
4. Task execution should terminate with an error
---
## Changes Made
### 1. Restore Error Handling in Continuous Task Exit Handlers
- Re-added the `cleaningUp` flag that was removed in a previous
TUI-related commit
- Modified `onExit` handlers for both regular and shared continuous
tasks to:
- Check if the task exited during normal cleanup vs. unexpectedly
- Call `complete()` with 'failure' status for unexpected exits
- Log error messages for debugging
### 2. Fix `cleanUpUnneededContinuousTasks()` Logic
The previous implementation always added `initializingTaskIds` to the
needed set, even when those tasks were already completed. This prevented
dependency tasks from being killed when the top-level task exited.
Fixed by:
- Only adding tasks from `initializingTaskIds` if they are still
incomplete
- Keeping dependencies of incomplete tasks alive
- This ensures continuous tasks are killed when no longer needed,
whether a dependency fails or a top-level task exits
### 3. Prevent Status Overwrites
Added a check in `onExit` handlers to only set status to `Stopped` if
the task hasn't already been completed. This prevents the async `onExit`
callback from overwriting the correct status (like 'skipped' or
'failure') with 'Stopped'.
### 4. Fix Signal Handling in `PseudoTtyProcess.kill()`
The Rust pseudo-terminal defaults to SIGINT when no signal is provided,
which does not reliably terminate child processes in PTY sessions.
Fixed by:
- Defaulting to SIGTERM in the JavaScript wrapper (rather than changing
the Rust default)
- The JS wrapper is the API boundary that should match Node.js
semantics, where `childProcess.kill(undefined)` defaults to SIGTERM
- The Rust default of SIGINT is appropriate for interactive use
(Ctrl-C), while programmatic cleanup needs SIGTERM
- This ensures child processes are properly killed when
`runningTask.kill()` is called
**File:** `packages/nx/src/tasks-runner/pseudo-terminal.ts`
## Technical Details
The fix leverages the existing task failure propagation mechanism in
`complete()` instead of using `process.exit(1)`, which:
- Allows proper cleanup through normal execution flow
- Respects the `--bail` flag configuration
- Works correctly with both TUI and non-TUI modes
- Maintains consistency with how other task failures are handled
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Older versions don't support the `nx mcp` command yet - but they CAN use
the `nx-mcp` package via npx
## Expected Behavior
We generatee the proper command into their MCP config by matching on
their version
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When multiple versions of the `nx` package are installed in a workspace
(e.g., due to a third-party package incorrectly depending on nx), users
have no visibility into
this issue through `nx report`.
## Expected Behavior
The `nx report` command now detects when other packages depend on a
different version of nx than the workspace version and reports this
clearly:
⚠️ Multiple Nx versions detected
Your workspace uses nx@20.0.0, but other packages depend on a different
version:
- some-package → @scope/tool → nx@19.0.0
These packages should not have nx as a dependency. Please report this
issue to the package maintainers.
Run pnpm why nx@19.0.0 for more details.
This helps users identify and report problematic packages that bundle
their own version of nx.
## Related Issue(s)
N/A - This is a proactive improvement to help users diagnose workspace
issues.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
nightly tests fail on gradle because of gradle parsing
## Expected Behavior
nightly tests should pass
## Current Behavior
We do not generate AI Instructions to aid with upgrading from Next 15 to
Next 16
## Expected Behavior
Add a migration generator to create a file containing instructions for
an LLM to upgrade Next 15 to Next 16
## Related Issue(s)
Closes NXC-3418
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
In TS Solution setups, we generate webpack config with
`generatePackageJson: true`. This is confusing and unneeded.
It should be set to false in TS Solution repos.
## Expected Behavior
Set `generatePackageJson: false` in webpack config for TS Solution
Setups
Closes NXC-3521
When generating NestJS applications in Angular workspaces, the base
tsconfig sets moduleResolution to 'bundler' which causes TS5095 errors
because 'bundler' requires module to be 'preserve' or 'es2015+'.
NestJS applications should use Node.js module resolution instead. This
fix sets moduleResolution to 'node' for NestJS applications (except when
using TS solution setup, which uses 'nodenext').
Fixes#33589
## Current Behavior
The ⚠️ emoji at the beginning of bc commits is duplicated in the bc
section of the changelog.
This is unneeded.
## Expected Behavior
Ensure the ⚠️ is not repeated in the bc section of the changelog
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
Close NXC-3516
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
1. **Socket Race Condition**: All daemon servers listen on the same
socket path, causing a race condition where shutting down daemons remove
sockets that newly started
daemons are listening on.
2. **Daemon Console Check Blocks**: The daemon availability check runs
synchronously and blocks the main thread.
3. **Version Mismatch Issues**: Packages using a different nx version
than what's installed in the workspace could still use the daemon,
leading to potential issues.
## Expected Behavior
1. Each daemon server creates a unique socket path based on its process
ID, preventing race conditions.
2. The daemon console check runs in the background without blocking.
3. The daemon is disabled when there's a version mismatch between the
running nx and the workspace's installed version.
## Changes
### 1. Unique Daemon Socket Paths
- Include `process.pid` in the socket directory hash to make each
daemon's path unique
- Store the socket path in `server-process.json` so clients know where
to connect
- Clients read the socket path from the file instead of calculating it
### 2. Backgroundable Daemon Check
- Reapplied #33491 which makes the Nx Console install check run on the
daemon in the background
- This was previously reverted due to the socket race condition (now
fixed by change 1.)
- Running in background also allows pulling the latest check logic from
npm
### 3. Version Mismatch Check
- Added `isNxVersionMismatch()` check in `DaemonClient.enabled()`
- Created shared utility `is-nx-version-mismatch.ts` for version
comparison
- Refactored server.ts to use the shared utility
- Uses `require.resolve('nx/package.json', { paths: [workspaceRoot] })`
to properly resolve the workspace's installed nx version
## Related Issue(s)
Fixes daemon socket path race condition and improves daemon reliability.
## Current Behavior
`copy-workspace-modules` executor only copies workspace dependencies 1
level deep.
If that workspace library depends on another workspace library, it is
not copied correctly.
## Expected Behavior
Copy transitive workspace modules
## Related Issue(s)
Fixes NXC-3466
When adding Cypress to a library, the generated commands.ts causes
TS2669 error because declare global requires the file to be a module.
Changed to use declare namespace Cypress directly.
Fixes#32930
## Current Behavior
PR #33491 introduced a daemon call into every command and caused
unexpected issues...
## Expected Behavior
the change is reverted while we investigate a proper fix
## Changes
This reverts commit 9471207767 from PR
#33491.
## Related Issue(s)
Fixes#33472
## Current Behavior
The manual DTE workflow explicitly sets the `ref` parameter to `${{
github.event.pull_request.head.sha }}` to checkout the actual branch
HEAD instead of the merge commit.
## Expected Behavior
Use GitHub's default ref behavior instead of explicitly overriding it,
as the default behavior now handles this correctly.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When generating a React component with --style=tailwind, the component
template incorrectly includes `className={styles['container']}` and
attempts to import CSS modules.
## Expected Behavior
Components generated with --style=tailwind should not include CSS
modules imports or `styles['container']` references, since Tailwind
doesn't use CSS modules.
## Related Issue(s)
Closes NXC-3511
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Stats don't come along with versions which makes it hard to see if it
was specific changes that make a difference.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stats are tagged with the version so we can compare stats between
versions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR fixes an issue where migrations can hang due to out invocation
of `storybook automigrate`. We are passing both `--config-dir` and
`STORYBOOK_PROJECT_ROOT`, the latter causes hanging with Storybook v9.
https://www.loom.com/share/39bbb350595c4a13aef86ec29f4b748f
## Current Behavior
Hangs
## Expected Behavior
Does not hang
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32492
This PR cleans up the markdown files under `packages/`. We previously
had to support Next.js docs and translate it for astro docs with proper
markdown syntax. This applies to generators, executors, and migrations.
Also removes the function to do the translation in astro app since it's
no longer needed.
## Code block (migrations)
<img width="1086" height="800" alt="Screenshot 2025-11-20 at 1 23 53 PM"
src="https://github.com/user-attachments/assets/bd9acb9b-7960-4e41-9d26-22d29da6658e"
/>
## Aside (generators)
<img width="802" height="443" alt="Screenshot 2025-11-20 at 1 43 17 PM"
src="https://github.com/user-attachments/assets/e2999821-8783-46ed-a984-2193f6f8eafa"
/>
## Current Behavior
During createNodes, if a file is imported and a function in said file
invokes the Nx project graph creation process, there's an infinite loop
that results in all nx commands hanging with little feedback.
Theoretically this loop would terminate at around the 10 minute mark,
but throughout the loop we would be digging deeper and deeper into
recursive territory so its possible that the node process could become
overwhelmed and hang.
## Expected Behavior
If recursive graph creation is detected, Nx terminates and logs the call
stack so it can be investigated properly.
## Related Issue(s)
Fixes#29618
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
This PR adds the ability for users to import ESLint rules from arbitrary
location in the workspace rather than storing them in
`tools/eslint-rules`. This is useful for monorepo not using
npm/yarn/pnpm workspaces and need a mechanism to load from any custom
rules location without them being installed/symlinked.
It also handles TS files automatically.
Demo: https://www.loom.com/share/3c32af4555614eeab4f81fce8db0c955
Example:
```js
import baseConfig from "../../eslint.config.mjs";
import { loadWorkspaceRules } from "@nx/eslint-plugin";
const customRules = await loadWorkspaceRules("foo/bar/eslint-rules");
export default [
...baseConfig,
{
ignores: ["**/out-tsc"],
},
{
files: ["**/*.ts", "**/*.tsx", "**/*.js", "**/*.jsx"],
plugins: {
custom: { rules: customRules },
},
rules: {
"custom/valid-command-object": "error",
},
},
];
```
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
Daemon command hangs at end instead of exiting
## Expected Behavior
Daemon command exits
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There's some issues with the jest configs in the repo, CJS files having
`import` in them, etc.
## Expected Behavior
CJS files don't have `import`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`cache: true` is overridden if task name is dev
## Expected Behavior
`cache: true` has priority
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32610
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Using .mts extension forces files to always be treated as ESM modules,
ensuring consistent behavior regardless of package.json or tsconfig
settings.
This matters for Node 24 because by default Node will strip types from
`.ts` files and then they are resolved through normal Node resolution.
In the past we can control CJS/ESM through tsconfig options, but now
only extension or `type` in `package.json` matters.
Changes:
- Updated all createOrEditViteConfig calls to pass useEsmExtension: true
- Updated normalizeViteConfigFilePathWithTree to check for .mts files
first
- Updated test files to expect .mts config files
- Updated snapshots to reflect new .mts extension
Closes NXC-3446
Flat config overrides util may fail when it isn't a plain JS object.
This PR makes the `hasOverrides` function more robust against these
cases.
Fixes#31796
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
the JSON parsing is broken because in verbose mode, the gradle plugin
returns more than just JSON.
## Expected Behavior
JSON parsing in the test should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We naively mark WholeFileChange for commits when getting the relevant
commits for projects.
There is already logic to perform better diff checking for lock files,
especially in the case of pnpm catalog usage
## Expected Behavior
Reuse existing logic to determine file changes more accurately
## Related Issue(s)
Fixes#33413
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
If no inputs or named inputs are defined, this area of code was hit:
```
const DEFAULT_INPUTS: ReadonlyArray<InputDefinition> = [
{
fileset: '{projectRoot}/**/*',
},
{
dependencies: true,
input: 'default',
},
];
export function getNamedInputs(
nxJson: NxJsonConfiguration,
project: ProjectGraphProjectNode
) {
return {
default: [{ fileset: '{projectRoot}/**/*' }],
...nxJson.namedInputs,
...project.data.namedInputs,
};
}
```
This resulted in weird behavior when the user would define `default` in
named inputs, but it would seemingly only be applied to the project's
deps and not the project itself
## Expected Behavior
The `default` input is the default for both
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #https://github.com/nrwl/nx/issues/32924
## Current Behavior
Every time a daemon connection is opened, we create a new interval and
unref it. This results in the daemon checking its process termination at
an ever increasing rate, which presents as increased memory usage and
practically means the daemon is just doing a lot more work than it needs
to in this area.
## Expected Behavior
The interval is registered only on initial server startup.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29836
This PR updates the guide here to also include type entries (which we
generate by default):
https://nx.dev/docs/technologies/typescript/guides/compile-multiple-formats
Update the content to account for the new inferred `@nx/rollup/plugin`
setup, but still mentions the executor. And also link to a tool that can
be used to check for types correctness.
Closes#33258
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: jaysoo <jaysoo@users.noreply.github.com>
if there is an error parsing a schema file for generators/executors then
we should fully error out to prevent caching a "bad" build even if the
site techincally works with missing plugin info.
## Current Behavior
Metrics collection is currently disabled in the CI workflow via the
`NX_CLOUD_ENABLE_METRICS_COLLECTION` environment variable set to
'false'.
## Expected Behavior
Metrics collection should be enabled to gather build and performance
data from CI runs.
## Related Issue(s)
Reverts the change from #33497
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The `@nx/js:typescript-sync` generator never syncs external project
references to `tsconfig.json` files if a runtime tsconfig file exists.
## Expected Behavior
The `@nx/js:typescript-sync` generator should sync external project
references to `tsconfig.json` files if it includes any files or a
runtime tsconfig file doesn't exist.
## Summary
This PR fixes a critical deadlock issue in the metrics collector that
occurred due to inconsistent lock acquisition order between the
collection thread and registration threads. The fix involved
restructuring lock scopes across multiple functions to maintain a
consistent lock hierarchy.
## Changes
- Fixed lock acquisition order in 4 registration functions
(register_main_cli_process, register_main_cli_subprocess,
register_task_process, register_batch)
- Restructured collect_metrics() to minimize system lock scope and
release it before acquiring other locks
- Fixed collection helper methods to read PIDs in scoped blocks without
holding system lock
- Added comprehensive trace logging for debugging lock contentions
- Added concurrent test case to verify no deadlocks occur under stress
## Testing
- All 12 metrics tests pass
- Comprehensive concurrent stress test added:
test_concurrent_group_creation_with_subprocess_updates
- Lock ordering consistency test added:
test_lock_order_consistency_across_registration_threads
## Lock Ordering Rule
Established and enforced this hierarchy across all threads:
1. Acquire system lock first
2. Release system lock
3. Then acquire registration/PID locks
This prevents circular wait conditions (A→B / B→A) that cause deadlocks.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
When Storybook is installed with a version range like `^10.0.0` or
`~8.5.3`, the configuration generator fails with error:
```
NX Invalid Version: ^10.0.0
TypeError: Invalid Version: ^10.0.0
```
This occurs because `gte()` from semver doesn't accept version ranges on
the left-hand side - only valid semver versions are allowed there.
The Storybook configuration generator should work with version ranges by
extracting the actual version number before comparison.
Fixes#33514
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Env variables from the parent target are not propagated to the atomized
target e.g.
`.test-ci.env` will be only applied to **no-op** `test-ci` but not to
`test-ci--path/to/test/file`.
## Expected Behavior
Running an atomized target will load from the parent's env files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Gradle projects in Nx workspaces can only configure metadata through
Gradle's built-in mechanisms. There's no way to specify Nx-specific
project metadata (like tags) or customize task target configurations
other than overriding with `project.json`
## Expected Behavior
Developers can now configure Nx-specific metadata for both projects and
tasks using a type-safe Kotlin/Groovy DSL:
### Project-level metadata (in build.gradle.kts):
```
nx {
set("name", "my-service")
array("tags", "scope:backend", "type:api")
set("description", "Payment processing service")
}
```
### Task-level metadata (in build.gradle.kts):
```
tasks.named("integrationTest") {
nx {
set("cache", false)
array("tags", "integration", "slow")
}
}
```
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
## Current Behavior
In certain scenarios, Nx commands would hang between command completion
and process exit. This was caused by inefficient message end detection
in the
daemon socket communication, where the check for `MESSAGE_END_SEQ` could
fail when TCP packets were fragmented.
## Expected Behavior
With this PR, the message end detection is more robust and handles TCP
packet fragmentation correctly, preventing the hanging issue. The
changes also
add better performance tracking and logging to help diagnose similar
issues in the future.
## Changes Made
- **Improved message end detection**
(`consume-messages-from-socket.ts`): Added a preliminary check of the
last character's code point before checking
the full MESSAGE_END_SEQ, which prevents false negatives when TCP
packets are fragmented
- **Enhanced performance tracking** (`daemon/client/client.ts`,
`daemon-socket-messenger.ts`): Added message-type-specific performance
marks and
measures for better debugging
- **Added server-side logging** (`daemon/server/server.ts`): Added
logging for message receipt, serialization, and response to help
diagnose
communication issues
## Related Issue(s)
This fix addresses hanging issues observed in daemon communication when
commands complete but the process doesn't exit.
Add a skipDefaultTag option to the DockerTargetOptions interface that
allows users to opt out of the automatic default tag that is prepended
to build targets.
This is useful for multi-platform builds that need to push during build
(e.g., using --platform linux/amd64,linux/arm64 --push), where the
default tag causes build failures because it attempts to push a tag that
was not configured.
- Add skipDefaultTag?: boolean to DockerTargetOptions interface
- Modify buildTargetOptions to conditionally skip default tag when
skipDefaultTag is true
- Inherit skipDefaultTag from parent target in configurations
- Add comprehensive unit tests for skipDefaultTag functionality
- Add e2e test to verify skipDefaultTag works end-to-end
- Maintains backward compatibility (default behavior unchanged when
option not specified)
Fixes#33477
## Current Behavior
Loading local plugins that are relative paths from workspace root, that
point to a JS file, still require preliminary data from default plugins
despite being resolvable. This is because we aren't passing `paths` to
`require.resolve`, so it is trying to resolve relative to the nx package
instead of the workspace.
## Expected Behavior
The straight JS path resolves
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The metrics collector has several inefficiencies and architectural
issues:
- Complex hierarchical data structure (`ProcessTreeMetrics`) that
doesn't align with how the data is consumed
- Separate `MetadataStore` struct with unnecessary indirection
- Full metadata resent to all subscribers on every collection cycle
- Mutable parameters passed through collection functions instead of
functional return values
- Repeated allocations and clones across collection cycles
- `CollectionRunner` tightly coupled to NAPI, making it untestable in
pure Rust
## Expected Behavior
This PR restructures the metrics collector for better performance,
testability, and maintainability:
### Architectural Changes
1. **Flat Process Model**: Replaced hierarchical `ProcessTreeMetrics`
with a flat `Vec<ProcessMetrics>`, simplifying data flow
2. **Group-Based Organization**: Introduced `GroupInfo` and `GroupType`
to logically organize processes:
- `MainCLI` - Nx CLI process and its subprocesses
- `Daemon` - Nx daemon and its children
- `Task` - Individual task execution processes
- `Batch` - Batch execution with multiple tasks
3. **Incremental Metadata Updates**:
- Track which groups and processes have been sent using
`Arc<DashMap<String, GroupInfo>>` and `Arc<DashMap<String,
ProcessMetadata>>`
- Only send new metadata to subscribers instead of full state every
cycle
- New subscribers receive full metadata on first update via
`needs_full_metadata` flag
- Automatic cleanup of dead process/group metadata
4. **Shared State with Arc**:
- Metadata maps shared between `ProcessMetricsCollector` and
`CollectionRunner` using `Arc<DashMap>`
- Eliminated duplicate metadata storage
- Single source of truth for all metadata
5. **Functional Programming Pattern**:
- Collection functions now return `Result<MetricsCollectionResult>`
instead of mutating parameters
- Cleaner error handling with `inspect_err` and `map`
- Easier to reason about data flow
- Removed ~100 lines of code by consolidating logic
6. **Channel-Based Communication**:
- Decoupled `CollectionRunner` from NAPI using `crossbeam_channel`
- Collection thread sends metrics via channel to listener thread
- Listener thread receives metrics and notifies NAPI subscribers
- `CollectionRunner` is now NAPI-free and fully testable in pure Rust
- Non-blocking collection (subscriber callbacks don't block metrics
collection)
### Performance Optimizations
- Pre-allocated `Vec` capacity when combining metrics from different
sources
- Eliminated unnecessary `HashMap` clones during metadata updates
- Single-pass insertion into `DashMap` during string key conversion
- Reduced memory allocations in hot paths
- Collection thread never blocks on JavaScript callbacks
### Code Quality Improvements
- **Testability**: Added 7 pure Rust unit tests for `CollectionRunner`:
- Group creation with different registration types
- Incremental metadata updates
- Dead group cleanup
- All tests pass without requiring NAPI/Node.js runtime
- Clearer separation of concerns between collection and notification
- Better comments explaining incremental update strategy
- More idiomatic Rust patterns throughout
- Updated TypeScript type exports to match new structure
### Threading Model
**Before:**
```
CollectionRunner (mixed collection + NAPI notification)
```
**After:**
```
CollectionRunner (pure Rust, testable)
└─> Channel
└─> Listener Thread
└─> NAPI ThreadsafeFunction
└─> Subscribers
```
## Testing
- ✅ 241 Rust tests passing (including 7 new `CollectionRunner` tests)
- ✅ Native module builds successfully
- ✅ TypeScript types updated and exports verified
## Related Issue(s)
Part of ongoing metrics collector optimization work.
## Current Behavior
The Nx Console install check for the prompt happens in the main process,
adding some overhead to each invocation of nx.
## Expected Behavior
We want this check to happen on the daemon so that it's running in the
background. If it's still running when nx is invoked, we can just skip
the prompt since it's non-critical.
Running it in the background also allows us to pull the latest version
of the logic from npm when executing - that way we can keep the logic
older versions up-to-date even when ppl don't migrate to latest.
## Current Behavior
The Maven plugin is currently at version 0.0.9.
## Expected Behavior
This PR bumps the Maven plugin to version 0.0.10 and creates the
necessary migration for users to automatically update their pom.xml
files.
## Related Issue(s)
N/A - Routine version bump
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
https://www.loom.com/share/560ceccdad45462e9fd3e3f185fc9fa5
Node 24 has stricter readline behavior, and enquirer is not checking for
closed state when invoking operations, resulting in an
ERR_USE_AFTER_CLOSE error when users press Ctrl+C during interactive
prompts.
This commit fixes the issue by adding uncaughtException handler to
ignore ERR_USE_AFTER_CLOSE errors.
When users press Ctrl+C, the process now exits cleanly without showing
an ugly error stack trace.
Fixes NXC-3412
Co-authored-by: Claude <noreply@anthropic.com>
Updates the Nx Powerpack docs and marketing page to make it clear that
Powerpack packages are included with Nx Enterprise, and cannot be
purchased separately, and remove references to the Nx Powerpack trial.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
The recipe for switching to TS project references states "If you
reference a local library project with its own `build` task" which
caused confusion. Users thought only buildable libraries should be
included in devDependencies, leading them to create unnecessary path
aliases for non-buildable libraries.
Closes DOC-149
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Currently, telemetry stats are only recorded when `create-nx-workspace`
completes successfully. This doesn't capture how many times the command
is invoked vs completed.
## Expected Behavior
Record a stat when `create-nx-workspace` is first invoked (before any
prompts), enabling analysis of drop-off between initial invocation and
workspace completion.
## Changes Made
### Telemetry
- Added `recordStat()` call in `normalizeArgsMiddleware()` immediately
after welcome message and before any user prompts
- Records with command name `create-nx-workspace` and metadata
`['start']` to distinguish from completion stat
- Allows correlation of invocation and completion events for drop-off
analysis
### AI Agents Prompt
- This is being temporarily disabled because we noticed a dip in
create-nx-workspace completions that lines up when this was released.
Disabling it temporarily to see if the dip is recovered by disabling the
prompt.
### React Framework Selection
- Added early returns in `determineReactFramework()` for cases where
framework is already provided or interactive mode is disabled
- Improves performance by avoiding unnecessary prompt interactions
### Code Quality
- Reorganized imports in alphabetical order for better maintainability
- Removed unused import (`printSocialInformation`)
## Related Issue(s)
WIP - Draft for discussion
## Current Behavior
When `nx add @nx/s3-cache` fails due to incompatible peer dependencies
or other installation errors, users see only a generic error message
without the actual error details from the package manager.
## Expected Behavior
The command should display complete error messages from the package
manager (both stdout and stderr), including peer dependency conflicts
and other important diagnostic information.
## Changes
Fixed the exec callback in the `installPackage` function to:
1. Capture the `stderr` parameter (was previously ignored)
2. Log both stdout and stderr with a newline separator for clarity
3. Ensure users see all error information from package managers
## Why It Matters
Package managers write installation errors and peer dependency warnings
to stderr. By ignoring stderr, users had no visibility into what
actually failed, making it difficult to diagnose and fix issues.
Fixes issue with `nx add` not showing proper error messages.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `remove-redundant-ts-project-references` migration fails with an
error when run on workspaces that don't have a root `tsconfig.json`
file, such as nx-examples.
## Expected Behavior
The migration should skip workspaces that are not using TypeScript
solution setup instead of throwing an error.
## Related Issue(s)
Fixes the issue encountered when running the migration on
nrwl/nx-examples repo.
## Changes
- Added check to skip migration if workspace is not using TS solution
setup
- Updated test setup to properly configure TS solution for existing
tests
- Added new test cases to verify skip behavior
The migration now uses `isUsingTsSolutionSetup()` to detect if:
- `tsconfig.base.json` exists
- `tsconfig.json` exists and extends the base
- Package manager workspaces are configured
- Proper TS solution structure is in place
Workspaces missing any of these requirements will have the migration
skip silently.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The migration for removing redundant TypeScript project references is
set to version `22.1.0-beta.8`.
## Expected Behavior
The migration should be updated to version `22.1.0-rc.1` to align with
the release candidate version.
## Related Issue(s)
N/A - Version update as requested.
## Current Behavior
The `@nx/js:typescript-sync` generator adds project dependencies as
TypeScript project references to each project's `tsconfig.json` and
runtime tsconfig file (e.g., `tsconfig.app.json`, `tsconfig.lib.json`,
etc.). This is redundant since projects' `tsconfig.json` files already
reference the runtime tsconfig file, which would reference the
dependencies.
## Expected Behavior
The `@nx/js:typescript-sync` generator should add project dependencies
as TypeScript project references to each project's runtime tsconfig file
(e.g., `tsconfig.app.json`, `tsconfig.lib.json`, etc.). If the project
only has a `tsconfig.json` file, it should add them to it.
We've observed some performance improvement with this change while
running the `typecheck` tasks.
## Summary
This PR combines two critical performance optimizations for batch task
scheduling and task hashing:
### 1. Batch Scheduling Fix
Fixed a correctness bug in the batch scheduling optimization where the
`visitedInBatch` tracking happened too early. Now tasks are only marked
as visited AFTER all scheduling checks pass, ensuring tasks can be added
to the batch from any valid dependency path.
**Files Modified:**
- `packages/nx/src/tasks-runner/tasks-schedule.ts`
**Impact:**
- Prevents task splitting across unnecessary batch boundaries
- Maintains correctness while optimizing performance
- All batch scheduling tests pass
### 2. Task Output Hashing Optimization
Added a DashMap-based cache to the Rust TaskHasher to prevent redundant
hashing when multiple tasks depend on the same outputs.
**Files Modified:**
- `packages/nx/src/native/tasks/task_hasher.rs` - Added
task_output_cache field
- `packages/nx/src/native/tasks/hashers/hash_task_output.rs` - Implement
cache logic
## Root Cause of Issue #33366
Large project graphs with high dependency fanout exhibit slow
`hashMultipleTasks` because:
- 100+ tasks may depend on the same 10 build tasks' outputs
- This generates 1,000+ separate `TaskOutput` hash instructions
- Each instruction independently:
- Lists output files from disk (filesystem I/O)
- Builds glob patterns
- Hashes the same files
- Result: Same files hashed 100× redundantly
## Solution: Task Output Cache
The cache key combines glob pattern and sorted output paths. When
identical outputs are hashed with the same pattern:
- First task: computes hash (~milliseconds) and stores in cache
- Remaining 99 tasks: cache hits (~nanoseconds each)
### Cache Lifetime
- `TaskHasher` instantiated once per `hashMultipleTasks` call
- Cache persists for entire hashing session
- Discarded when `hashMultipleTasks` completes
- Optimal scope for cache hit maximization
## Performance Impact
**Expected Improvements:**
- Best case (100 tasks, 10 shared deps): 100× speedup
- Typical monorepo: 10-20× speedup
- No shared deps: No regression (cache lookup negligible)
**Issue #33366 Analysis:**
- Current: `Time for 'hashMultipleTasks' 49351.488518` (49 seconds)
- Expected with optimization: ~5-10 seconds (depending on actual
dependency structure)
## Testing
- ✅ All task scheduling tests pass (2262 passed, 0 new failures)
- ✅ Batch mode tests pass (6/6)
- ✅ Native build completed successfully
- ✅ No regressions in existing functionality
## Design Notes
- Task output cache follows same pattern as `workspace_files_cache`,
`external_cache`, `runtime_cache`
- Thread-safe using DashMap with Arc for Rayon parallel processing
- Instrumented with trace-level logging for cache hits/misses
- Cache automatically cleaned up when TaskHasher is dropped
Updates the `ng-packagr` executors to support a breaking change in v21.
This needs to be done in advance because we use the published
`@nx/angular` executors to build the `@nx/angular` source code. To
update to Angular v21, we need this change to be merged, released, and
installed in the Nx repository so that we can build the `@nx/angular`
package containing the support for Angular v21.
Users cannot import TypeScript schema definitions or schema.json files
from Nx packages due to strict package exports introduced in Nx 21.0.0.
Users can now import both TypeScript definitions and JSON schemas from
generator/executor/builder paths using wildcard export patterns. Both
first-level (`*`) and second-level (`*/*`) patterns are supported to
handle different import depths.
Note: For old plugins that had `src/...` deep imports we keep those in
`exports`, but for newer plugins that always used `exports` we skip
`src/` in the export path. So `@nx/nuxt/generators` instead of
`@nx/nuxt/src/generators`.
Fixes#33336
## Current Behavior
nx init is executed with whatever version is installed globally by npm
(might be outdated)
## Expected Behavior
we pull down the latest version from npm (if it has provenance) and run
that when executing.
Also introduced a new `NX_USE_LOCAL` env var that will be respected by
all commands that have this pulling-from-latest behaviour.
Update CI to Node 24. Note that the e2e-release changes are pulled from
the original PR.
Note: There are changes to NPM 11 (Node 24) to make it run slower than
NPM 10 (Node 20/22) for publish. (https://github.com/nrwl/nx/pull/31934)
e.g. https://github.com/npm/cli/releases/tag/v11.0.0-pre.1 (`Upon
publishing, in order to apply a default "latest" dist tag, the command
now retrieves all prior versions of the package.` which incurs more
network cost)
## Current Behavior
The typecheck target in graph/client/project.json only depends on
^typecheck targets from other projects.
## Expected Behavior
The typecheck target now includes nx:build-native as a dependency to
ensure native dependencies are built before type checking.
## Related Issue(s)
This fix resolves typecheck failures caused by missing native
dependencies.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
## Current Behavior
there is no way to generally influence how maven goals/phases are
represented as targets in nx. This could be useful though for organizing
targets in nx, for example through nx.json `targetDefaults`
## Expected Behavior
There's a `targetNamePrefix` plugin option that can be passed.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: MaxKless <MaxKless@users.noreply.github.com>
After PR #33256 split lockfile parsing into separate node and dependency
caches, a regression occurred where dependencies could be regenerated
without nodes, leaving a shared module-level variable (`keyMap`) empty
and causing incorrect dependency resolution.
Changes:
- Serialize `keyMap` with nodes cache to maintain state between phases
- Remove module-level shared state from pnpm, npm, and yarn parsers
- Move `keyMap` creation inside `getNodes` functions for better
encapsulation
- Update `readCachedExternalNodes` to deserialize `keyMap` internally
Update from the macos-13 is in brownout and will be gone soon.
- macos-15-intel for x86_64-apple-darwin (Intel) builds
- macos-latest for aarch64-apple-darwin (ARM64) builds
Closes NXC-3444
## Current Behavior
We currently only generate vitest projects using Vitest 3
## Expected Behavior
Use Vitest 4 when generating new projects
## Related Issue(s)
Closes NXC-3343
Closes NXC-3379
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Clarifies some details of the Nx Cloud GitHub integration, such as which
features are available when you use the base integration vs a GitHub
powered organization.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
We do not render the commit title in the BC section of generated
changelogs.
## Expected Behavior
We should render the commit title in the BC section of generated
changelogs along with the Remote Release Client reference to the commit.
## Related Issue(s)
Closes NXC-3290
## Current Behavior
There may be a scenario when `cleanedAngularVersion` is of type `object`
rather than `string` which proceeds to error when passed to
`semver.major()`.
## Expected Behavior
If `cleanedAngularVersion` is not `string`, assume the latest version
will be installed. Similar to how no found angular version is handled.
## Related Issue(s)
Fixes#33347
- Fix for a bug with the external project references cache
- Add more caching for repeated operations
- Skip tsconfig files processing based on which targets should be
inferred
Fixes#33076
## Current Behavior
The library generator has an unused import and incorrect import pattern
for the vitest generator.
## Expected Behavior
Clean imports with the correct way to access the configurationGenerator
from @nx/vitest.
## Changes
- Removed unused imports (logger, readJson)
- Updated vitest generator import to use direct require instead of
ensurePackage pattern for accessing the generator
Fixes #
## Current Behavior
The Storybook 10 migration was originally intended to be optional.
## Expected Behavior
Make Storybook 10 migration add the migration generator to
migrations.json always. Users can remove it from here if they do not
want it, or they can use the Migrate UI from Nx Console to choose not to
run it.
Split entry point of `@nx/vitest` into `index.ts` for the Inference
Plugin, `generators.ts` for Generators, `executors.ts` for the
Executors.
Ensure the `README.md` is copied to the correct output directory
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
Split `vitest` out of `@nx/vite` and create a new `@nx/vitest`.
This allows for each plugin to have a single responsibility. One for
bundling, one for testing.
It should allow for lighter setups where Vite for Bundling is not
required, but users still want to use vitest for testing.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Storybook was accidentally downgraded to 9.1.9
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Storybook is upgraded back to 10.0
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cypress v15 is not supported.
## Expected Behavior
Cypress v15 should be supported.
## Related Issue(s)
Fixes#33304
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: leosvelperez <leosvelperez@users.noreply.github.com>
CI and nightlies can flake out during expo test if cypress or playwright
times out waiting for webserver. This makes is to the `export` that
powers `static-serve` is run before running e2e.
This is not usually a problem in new workspaces with inference, but this
legacy test uses executors so continuous task dependency isn't set up.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Nx plugin for Gradle is at version 0.1.8
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx plugin for Gradle is at version 0.1.9
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Track relevant CPU and memory system metrics.
- Link plugins to workers when possible.
- Refactor collector code by splitting it into two separate structs.
## Current Behavior
Maven plugin is currently at version 0.0.8.
## Expected Behavior
Maven plugin should be bumped to version 0.0.9 with a corresponding
migration for users.
## Changes Made
- Updated parent POM version to 0.0.9
- Updated package.json version to 0.0.9
- Updated mavenPluginVersion constant to 0.0.9
- Added new migration (0-0-9) to update user pom.xml files from 0.0.8 to
0.0.9
- Scheduled migration for Nx v22.1.0-beta.6
## Testing
- ✅ Maven package tests pass
- ✅ Build succeeds
- ✅ Linting passes
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Because `./nx` is passing args with `$@`, args are being split by
spaces. Reference for this behaviour:
https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html#Special-Parameters-1
This results in this set of process args when running `./nx start-ci-run
--distribute-on="3 linux-medium-jvm"`
```
[
"<user path>/.nvm/versions/node/v22.19.0/bin/node",
"<user path>/Projects/OTW/mm-test/.nx/nxw.js",
"start-ci-run",
"--distribute-on=3",
"linux-medium-jvm",
]
```
## Expected Behavior
the arg with whitespace should not be split before being passed to nx:
```
[
"<user path>/.nvm/versions/node/v22.19.0/bin/node",
"<user path>/.nx/nxw.js",
"start-ci-run",
"--distribute-on=3 linux-medium-jvm",
]
```
This PR is just for the repo itself to use `.cts` to explicitly use CJS
for jest config. Node 24 strip types so having `.ts` files with ESM
syntax even though we're previously transpiling them to CJS is a
problem.
Make run-one task terminal outputs in the TUI non-interactive by
default. Most tasks don't need interactivity, and it causes TUI to
ignore all its key bindings because it forwards them to the underlying
program. If interactivity is needed, users can press `i` to enable it.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently we detect if inputs are found in the build directory to
determine if they are considered dependent task output files. We can use
a simpler heuristic instead.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If an input is gitignored (and therefore not hashed by Nx), then we
consider it a dependant task output file. This gitignore classifier will
be a mirror of the class used within the Maven plugin. There will be
another PR to move this classifier into a shared kotlin project that can
be used between both projects.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Maven target dependencies are defined as simple strings that reference
other targets. Currently, parameters are not forwarded through these
dependencies when Maven goals are executed.
## Expected Behavior
Target dependencies in Maven should forward parameters (args) to their
dependency targets, enabling better parameter propagation through the
build pipeline.
## Changes Made
Modified `NxTargetFactory.kt` to transform simple string dependency
references into structured dependency objects with explicit parameter
forwarding:
- Install dependencies now forward parameters
- Phase dependencies now forward parameters
- Test dependencies now forward parameters
- CI target dependencies now forward parameters
This ensures that when a Maven goal executes, any parameters passed to
it are properly forwarded to all transitive target dependencies.
## Related Issue(s)
This change enables parameter passing through Maven target dependencies
via the new dependency object format with `"params": "forward"`.
When using Jest 30 with SWC, users are seeing an error where `__dirname`
is not defined for ESM modules. This is because the `.ts` extension is
type-stripped by Node 22.17/24+ via checking for
[`process.features.typescript`](https://github.com/jestjs/jest/blob/fe7f28c9d1941f5c2726831cd9d9e479b401610e/packages/jest-config/src/readConfigFileAndSetRootDir.ts#L46).
This means that instead of using the `commonjs` we set for `ts-node`,
normal Node resolution kicks in, and is now treating `jest.config.ts` as
ESM.
This PR fixes this issue by using an explicit `.cts` extension, which
forces CommonJS that we assume for Jest configs.
Note: For Jest 29 or earlier we need to keep `jest.config.ts` since the
`.cts` extension is not supported prior to Jest 30.
There's also a fix for an existing issue where using `module.exports` of
anything else from `@types/node` will error out if `tsconfig.json` has a
`types` field but does not include `node`. See:
https://www.loom.com/share/7ebe3c90a70e4ec7bfa53cbcccaaea7dFixes#32236
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
`@nx/vite` has a peerDep range of only `1 | 2 | 3` for `vitest`.
This will cause peer dep conflicts for using wishing to use Vitest 4.
## Expected Behavior
Add Vitest 4 to the peerDep range of `@nx/vite` to prevent conflicts.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
when trying to format with prettier while outside of the workspace (for
example in a `tmp` nx installation like is created during
`configure-ai-agents`), resolving prettier could fail even though it's
present in the actual workspace.
## Expected Behavior
resolving prettier works if it's available in either the proper
workspace or the tmp one by specifying `paths` in `require.resolve`
## Current Behavior
We currently support Next 14 and 15.
## Expected Behavior
Add support for Next 16, bringing support to 14, 15, 16.
Existing workspaces will continue to use the version they are on.
New workspaces will use Next 16.
Refer to Next 16 Migration Guide for migrating from Next 15 to 16
## Related Issue(s)
Fixes#33207
---------
Co-authored-by: Eric Büttner <eric.buettner@tuffz.com>
This pull request makes a minor update to the CI workflow configuration.
The change simplifies the `Start CI Run` step by removing the
`--fix-tasks="!*check-commit*"` option from the `npx nx-cloud@next
start-ci-run` command.
Updates @module-federation packages from 0.18.0 to 0.21.2 and
@module-federation/node from 2.7.11 to 2.7.21 to address Koa Open
Redirect vulnerability (CVE: GHSA-g8mr-fgfg-5qpc).
The vulnerability was in transitive dependencies:
@nx/react → @nx/module-federation → @module-federation/enhanced →
@module-federation/dts-plugin → koa@3.0.1-3.0.2
Changes:
- Updated package.json dependencies in @nx/module-federation and
@nx/rspack
- Updated version constants in Angular and React utils/versions.ts
- Added 22.2.0 migrations to all affected packages
Fixes#33285
This PR clarifies that Nx 22 removed SVGR support from Next.js and React
(Webpack/Rspack).
<img width="942" height="1185" alt="image"
src="https://github.com/user-attachments/assets/6ea8393f-b037-489f-804b-eb06d8d07e4c"
/>
Previously we had this option `svgr: true` but was configurable and
didn't align with current best practices like `import Logo from
'./logo.svg?react'`. We removed it from Nx 22, provided a migration, but
users will be confused by the docs.
Fixes DOC-326
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`createVitest` is looking at the full workspace every time. It should
only look at the directory with the config file.
## Expected Behavior
Pass the root as the projectRoot of the config file found.
## Current Behavior
The Nx TUI doesn't provide any visual feedback about task progress
outside of the terminal window itself. Users need to keep the terminal
visible to see task completion status.
## Expected Behavior
With this PR, the TUI now displays real-time task completion progress in
the terminal window chrome (tabs, title bars, dock icons) using the OSC
9;4 escape sequence. This provides at-a-glance progress feedback even
when the terminal is minimized or in the background.
## Related Issue(s)
N/A - This is a new feature enhancement
## Implementation Details
### What is OSC 9;4?
OSC 9;4 is a terminal escape sequence for displaying progress
indicators, originally from ConEmu and now supported by multiple modern
terminals.
### Key Changes
- Added `update_ghostty_progress()` method to calculate and display task
completion percentage
- Added `clear_ghostty_progress()` method to hide progress when done
- Integrated progress updates into task lifecycle (start, status update,
exit)
- Uses ST terminator (`\x1b\\`) for maximum terminal compatibility
- Writes to stderr to avoid conflicts with TUI rendering on stdout
### Supported Terminals
- **Ghostty** - Full support
- **Windows Terminal** (v1.6+) - Full support
- **VTE-based terminals** (GNOME Terminal, Ptyxis) - Full support
- **Other terminals** - Gracefully ignore sequences (no errors)
### Terminal Compatibility Note
The implementation uses the ST (String Terminator) escape sequence
rather than BEL, as this is preferred by Ghostty and required by
VTE-based terminals, while remaining compatible with Windows Terminal.
## Testing
Tested with:
- Building the native module successfully
- Rust formatting and linting passes
- Running nx commands with the TUI active
The progress indicator updates in real-time as tasks complete and clears
automatically when the TUI exits.
## Current Behavior
When processing scheduled batches, tasks are hashed one at a time even
though the hasher has a `hashTasks` method for batch hashing.
Results from a batch with 109 tasks.
```
hash batch: 8.297s
```
## Expected Behavior
Tasks without custom hashers should be batch-hashed using the hasher's
`hashTasks` method for better performance.
Results from a batch with 109 tasks.
```
hash batch: 991.725ms
```
## Related Issue(s)
This is a performance optimization for task hashing.
---
**Changes:**
- Added a new `hashTasks` function that intelligently separates tasks
with custom hashers from those without
- Tasks with custom hashers are hashed individually using `Promise.all`
- Tasks without custom hashers are batch-hashed using the hasher's
`hashTasks` method
- The function automatically filters out tasks that already have a hash
- Updated `processScheduledBatch` in task-orchestrator to use this new
function
## Current Behavior
Vitest's `createVitest` can be over-eager and include other projects in
the workspace when finding relevant test specifications.
This leads atomizer to look at relative paths outside the project root.
## Expected Behavior
Ensure that the plugin does not look at projects outside the project
root.
## Current Behavior
The Maven migration version was incorrectly set to `0.0.8-beta.0` in the
migrations.json file.
## Expected Behavior
The migration version should be set to `22.1.0-beta.4` to align with the
Nx release version.
## Related Issue(s)
Fixes the migration version discrepancy in the Maven plugin.
Embeds videos about self-healing CI into the corresponding feature doc
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
The Maven plugin is at version 0.0.7 with no automated migration path
for users to upgrade their pom.xml files.
## Expected Behavior
Users can upgrade to Maven plugin 0.0.8 and have their pom.xml files
automatically updated via the Nx migration system.
## Changes Made
- Updated Maven plugin version from 0.0.7 to 0.0.8 in:
- `packages/maven/package.json`
- `packages/maven/src/utils/versions.ts`
- `packages/maven/maven-plugin/pom.xml`
- Created `updateNxMavenPluginVersion()` utility function with:
- Proper XML parsing using `@xmldom/xmldom` DOM API
- Targeted updates only for `dev.nx.maven:nx-maven-plugin` elements
- Safe handling of all other version elements (dependencies, parent,
project, etc.)
- Comprehensive error handling
- Added migration `0-0-8/update-pom-xml-version.ts` that:
- Automatically runs when users upgrade to 0.0.8
- Updates root pom.xml files via the utility function
- Logs status of migrations performed
- Registered migration in `migrations.json`
- Added comprehensive unit tests (9 test cases):
- Updates only the nx-maven-plugin version
- Does not update other plugin versions
- Handles missing files gracefully
- Preserves XML formatting and structure
- Handles multiple plugin references
- Handles whitespace correctly
- Only updates plugins, not parent/project versions
- All tests passing (27/27)
## Test Plan
- [x] Unit tests pass (27 passing tests)
- [x] XML parsing correctly identifies and updates only
`dev.nx.maven:nx-maven-plugin`
- [x] Other version elements remain untouched
- [x] Migration registration validated
## Current Behavior:
Tui is working, but only able to be enabled on windows via env vars or
explicit command line config
## Expected Behavior:
Tui is default on
## Current Behavior
Maven and .NET use a bespoke script to handle skipping an optional
native target in case a system is not setup on a dev's machine.
.NET isn't in codeowners
## Expected Behavior
This pull request introduces improvements to the build and formatting
workflows for the `.NET` and Maven plugins, streamlining the execution
of native targets and updating code ownership assignments. The changes
focus on refactoring build scripts to use a unified runner, adding new
formatting capabilities for .NET projects, and updating the CODEOWNERS
file for clearer team responsibilities.
**Build and Format Workflow Improvements**
* Refactored the `.NET` analyzer build command in
`packages/dotnet/project.json` to use the new `run-native-target.js`
script, replacing the previous direct script invocation.
[[1]](diffhunk://#diff-036c1a7f2e7d98f5a3207441f2ff1cb25b5b5a03343672ce473f4ff0189a5946L25-R25)
[[2]](diffhunk://#diff-42d990ddcbf8d3585553503097ee8b8d1fff8cb6e25e0cd545a87e11d64c03a8L1-L7)
* Added new `format-native` and `_format-native` targets to
`packages/dotnet/project.json`, enabling verification and fixing of code
formatting for the .NET analyzer using `dotnet format`.
**Unified Native Target Runner**
* Introduced the `scripts/run-native-target.js` script to standardize
running native build and install targets, controlled by environment
variables for skipping builds.
**Maven Plugin Build Refactor**
* Updated the Maven plugin's install workflow in
`packages/maven/maven-plugin/project.json` to use the new native target
runner, and removed the obsolete `scripts/build-maven-analyzer.js`
script.
[[1]](diffhunk://#diff-2763fe8a7c2989643f53370a14a08c06616e85c29340fd5bcfa1a67d0deaee7aL11-R11)
[[2]](diffhunk://#diff-972edab06956ad35145cbc20b8e250e7067fbb288b1f99c92661c24f64d3e69dL1-L7)
**Ownership Updates**
* Updated the `CODEOWNERS` file to assign `.NET`-related directories to
`@FrozenPandaz` and `@AgentEnder`, clarifying team responsibilities.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We support Storybook 8 and 9
## Expected Behavior
Add support for Storybook 10, bringing Storybook support to 8, 9 and 10
## Related Issue(s)
Fixes#33141
## Current Behavior
Maven dependencies were not being resolved correctly from project roots,
which affected the dependency analysis in monorepos with Maven projects.
## Expected Behavior
Maven dependencies should be properly resolved from each project's root,
allowing Nx to correctly understand the project graph for Maven-based
projects.
## Changes Made
- Updated Maven plugin Kotlin code to properly resolve dependencies from
project roots
- Fixed devkit internal utilities to properly handle Maven dependency
resolution
- Updated TypeScript dependencies plugin to align with the new
resolution logic
## Files Changed
-
`packages/maven/maven-plugin/src/main/kotlin/dev/nx/maven/NxProjectAnalyzer.kt`
-
`packages/maven/maven-plugin/src/main/kotlin/dev/nx/maven/NxProjectAnalyzerMojo.kt`
- `packages/maven/src/plugins/dependencies.ts`
- `packages/dotnet/src/plugins/create-dependencies.ts`
- `packages/devkit/internal.ts`
- `packages/nx/src/devkit-internals.ts`
Fixes #XXXXX
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
CodeQL is not enabled for C#, but C# is in the nx repo
## Expected Behavior
CodeQL is enabled on C#
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR primes the cache for `@vitejs/plugin-vue`, similar to how we
already do for `esbuild`. When `vite.config.ts` is compiled into CJS,
then doing `require('@vitejs/plugin-vue')` may error with a race
condition if an `import` of the same module is in progress.
Fixes #NXC-3289
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
there are recommendations for using the CIPE fixing tools but they are
being removed
## Expected Behavior
removed tools should not be mentioned anymore.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Completed Maven documentation updates:
- [x] Add `nx show projects` command to display Maven projects after
initialization
- [x] Change example from `nx build` to `nx verify`
- [x] Simplify configuration section to use `plugins: ["@nx/maven"]`
with defaults
- [x] Update configuration description to accurately explain how targets
are created
## Summary
Successfully updated the Maven plugin documentation:
1. **Added `nx show projects` command** - Shows users how to list
discovered Maven projects after running `nx init`
2. **Changed example to `nx verify`** - Uses a more appropriate Maven
lifecycle phase that includes tests and verification
3. **Simplified configuration** - Updated the configuration section to
show the simpler string array syntax `plugins: ["@nx/maven"]`
4. **Corrected target creation description** - Updated the text to
accurately explain that `@nx/maven` automatically retrieves information
about projects from Maven and creates targets for each phase, goal, and
some additional targets for CI
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Expand this section
https://nx.dev/docs/technologies/java/maven/introduction#add-nx-to-a-maven-workspace
>
> With instructions to run the following
>
> nx show projects
>
> To see a list of Maven projects
>
> And change nx build Maven project to nx verify Maven project
>
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: FrozenPandaz <8104246+FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
devcontainer wasn't working reliably
## Expected Behavior
devcontainer should work reliably and reuse the configuration setup we
have for all these different tools that are needed
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
in a `.nx` installation, `require.resolve` won't find the `extends`
preset nx.json file because there are no root `node_modules`
## Expected Behavior
in a `.nx` installation, the nested `.nx/installation/node_modules` are
also used to try and resolve the preset.
This PR builds on the previous fix that ensured `eslint-config-next` was
correctly installed when using Next.js 15. #30258
Now, the logic has been further refined to dynamically determine the
installed Next.js version and install the corresponding
`eslint-config-next` version accordingly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
### Current Behavior
- `next@~15.1.4` is installed
- `eslint-config-next@14.2.16` is installed (incorrect for Next.js 15)
### Expected Behavior
If Next.js 15 is detected -> eslint-config-next@15.1.4 is installed
If Next.js 14 is detected -> eslint-config-next@14.2.16 is installed
### GitHub Repo
https://github.com/tuffz/new-nx-with-preset-nextjs
### Steps to Reproduce
1. Run the following command from the official documentation:
`npx create-nx-workspace@latest --preset=next`
3. Open `package.json` and check the installed dependencies
- `next@~15.1.4` is installed
- `eslint-config-next@14.2.16` is installed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30257 (& #30258)
guides couldn't be merged into one page w/ tabs and keep consistent
headers. so we're back to splitting them out. but all under a
source-control-integration parent route. so we don't need to do any
redirects and such as the index route will contain the links to each one
Removed duplicate information about installing Nx globally.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Duplicate line.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Removed duplicate line.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
the implementation is brittle and will fail if `contextFileName` is not
a string
## Expected Behavior
we should just not handle other things that folks are putting in there.
but not fail
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Dogfoods the Pnpm Catalogs feature in the Nx repo. This is the first
step to move all dependencies to Pnpm Catalogs definitions. More work
will be done incrementally later as we consolidate package versions
across the repository.
The initial list of dependencies moved to Pnpm Catalogs is:
- Angular packages
- React packages
- TypeScript packages
- Jest packages
- Rspack packages
- Some common utilities
## Current Behavior
We have tried to enable v8 serialization again... but it still seems
problematic. We don't want to revert again... so we evaluated some
options:
1. Disable by default
2. Disable for the single client method we think may be problematic
3. Fall back to JSON if v8 fails
4. Disable by default and still fall back if JSON fails
## Expected Behavior
We decided to update Nx such that the default behavior will be a
combination of #4, and #2. So by default we use JSON, if that
serialization fails we'll try v8... but there's an exception so the
method we know to be an issue will never try v8.
If you opt in to v8 by default, the combo changes to #3 + #2. So, by
default we'd use v8... if it fails try json... never try v8 for
processInBackground
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Docker plugin assumed `commitSha` was always non-null; when `null`,
`shortCommitSha.slice` caused a runtime error during target
interpolation.
## Expected Behavior
Plugin should succeed even if latest commit SHA cannot be resolved,
simply omitting shortCommitSha-based substitutions.
## Changes
- Added null guard: `shortCommitSha` now set to `commitSha ?
commitSha.slice(0,7) : null`.
- Added test "should not throw when commitSha is null" verifying node /
target creation succeeds.
- No breaking changes; only broadens safe input surface.
## Additional notes
Logic only executes when `commitSha` was previously null (error case);
normal paths unchanged. If consumers interpolate `{shortCommitSha}`,
they should handle possible null (unchanged if interpolation is already
optional).
This PR removes the need to check links during deploy and instead
enforces it in CI. This removes the need to build astro-docs when
building next.js app.
Reduces Vercel build from 10-11 mins to 6.5 mins.
<img width="1231" height="94" alt="image"
src="https://github.com/user-attachments/assets/ad5d4459-f917-4609-8c00-151f61dc29d6"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Update release notes entry tor 2025.07.3 - short link support for DTE
summary
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
You can see the issue here:
https://staging.nx.app/cipes/68fba96042d3126ee8ec0d19/analysis?runGroup=18785923031-1-linux
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes BAC-1387
This PR wraps one of the exports of `@nx/webpack` within a dynamic
function that ultimately requires `tsquery`. This causes an issue in
yarn v1 where `typescript` cannot be resolved thus causing an error when
`@nx/webpack` is imported.
The errors happens on every new workspace that starts from empty:
```
npx create-nx-workspace --preset=ts --pm=yarn
nx add @nx/web
nx g @nx/web:app apps/demo --bundler=webpack
```
Results in:
```
NX Cannot find module 'typescript'
Require stack:
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@phenomnomnominal/tsquery/dist/src/ast.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@phenomnomnominal/tsquery/dist/src/index.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/src/generators/convert-config-to-webpack-plugin/lib/extract-webpack-options.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/src/generators/convert-config-to-webpack-plugin/convert-config-to-webpack-plugin.js
- /private/var/folders/p4/6tvkdn_11xlc_2j999ybhbkr0000gn/T/tmp-59809-4kedkj5a1XsO/node_modules/@nx/webpack/index.js
- /private/tmp/web4/node_modules/@nx/devkit/src/utils/package-json.js
- /private/tmp/web4/node_modules/@nx/devkit/src/generators/to-js.js
- /private/tmp/web4/node_modules/@nx/devkit/public-api.js
- /private/tmp/web4/node_modules/@nx/devkit/index.js
- /private/tmp/web4/node_modules/@nx/web/src/generators/application/application.js
- /private/tmp/web4/node_modules/nx/src/config/schema-utils.js
- /private/tmp/web4/node_modules/nx/src/command-line/run/executor-utils.js
- /private/tmp/web4/node_modules/nx/src/project-graph/utils/project-configuration-utils.js
- /private/tmp/web4/node_modules/nx/src/utils/package-json.js
- /private/tmp/web4/node_modules/nx/bin/nx.js
Pass --verbose to see the stacktrace.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
Note: Other generators like React/Vue are fine since they have
dependency on tsquery, which installs typescript.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Summary
This PR includes three performance and correctness improvements:
1. **Split lockfile cache into separate node and dependency caches** -
Previously, both createNodes and createDependencies would read/write the
entire cache. Now each manages its own cache independently:
- `parsed-lock-file.nodes.json` for external nodes
- `parsed-lock-file.dependencies.json` for dependencies
2. **Prevent duplicate plugin resolution calls with promise cache** -
Added a promise cache to prevent concurrent duplicate calls to
`retrieveProjectConfigurationsWithoutPluginInference` when multiple
plugins fail to resolve simultaneously
3. **Normalize targets in separate loop after validation** - Moved
target normalization out of the validation loop to ensure proper
sequencing
## Test plan
- [ ] Tests pass (currently failing in CI - needs investigation)
- [ ] Build succeeds
- [ ] Lint passes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
When stringifying a pnpm v9 lockfile with workspace packages, Nx crashes
with: "Cannot destructure property 'specifiers' of 'projectSnapshot' as
it is undefined."
This occurs when:
- The lockfile has a root importer with `link:` references to workspace
packages
- But the lockfile is missing the workspace package importer entries
- The code tries to access `importers[importerPath]` which returns
undefined
- This undefined value gets added to the output lockfile
- During serialization, it crashes when trying to destructure undefined
Workspace packages with missing importers are now silently skipped
during lockfile serialization. This prevents the crash and allows Nx to
continue operating with out-of-sync lockfiles.
The fix adds a null check before adding workspace dependency importers
to the output lockfile.
Closes NXC-3244
This reverts commit 54db861b72.
## Current Behavior
Daemon messaging is all done over JSON messages
## Expected Behavior
Daemon messages use v8 serialization to avoid string length issues
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
With the Accept header in place during the retrieval of cache, the
client always expects an octet-stream from the server.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When the `Accept` header is missing, you might not get the correct data
depending on the underlying implementation of a self hosted cache
solution. We use AWS API Gateway which has a hard requirement for
`Accept` to determine how it should convert the data.
Fixes#33092
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We search for the gradle wrapper of a project by first looking at the
project root, then traversing upwards to the workspace root. If a
workspace has a separate gradle project defined that does not contain a
wrapper, then Nx will error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add a field to the gradle plugin that will allow users to specify a
custom gradle installation within their workspace. Nx will check for a
gradle wrapper that the specified location when executing gradle tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes NXC-3147
## Current Behavior
When the Nx daemon returns a cached project graph from memory (without
recomputing), it does not write the graph to disk. This creates a
cache/daemon mismatch scenario:
1. Daemon has valid project graph in memory
2. A non-daemon process (fallback when daemon fails) encounters errors
and writes cache to disk with those errors
3. Parent process gets clean graph from daemon
4. Forked executor processes read from disk cache which contains errors
5. The errors cause `readProjectGraphCache()` to return `null` (when no
`minimumComputedAt` is provided)
6. This triggers a misleading "No cached ProjectGraph is available"
error instead of surfacing the actual errors
This issue manifests intermittently in CI environments, especially when:
- Daemon connection timeouts occur
- Multiple concurrent processes are running (DTE scenarios)
- File system latency is high
## Expected Behavior
The daemon should always write its current project graph to disk
whenever it returns it, ensuring the disk cache stays synchronized with
the daemon's in-memory cache. This prevents stale or errored caches from
persisting when the daemon has a valid graph.
## Related Issue(s)
Fixes NXC-3030
## Implementation Details
Modified `getCachedSerializedProjectGraphPromise()` in
`packages/nx/src/daemon/server/project-graph-incremental-recomputation.ts`
to write the project graph cache to disk after retrieving the result,
even when reusing the in-memory cached graph.
The fix ensures that:
- Any errored cache written by a non-daemon process gets overwritten by
the daemon's valid graph
- Forked executor processes always read a consistent cache that matches
what the daemon served to the parent process
- Real errors are properly surfaced instead of being hidden by a generic
"no cache available" message
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Local `tsconfig.app.json` is never picked up due to wrong resolved path.
## Expected Behavior
Local `tsconfig.app.json` is picked up and the path aliases are added to
Vite.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#33231
Removed "Explain with AI" feature documentation and redirected all URLs
to Self-Healing CI. Added sunset notice to blog posts, updated
configuration files, and preserved historical content for reference.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When `Dockerfile` is at project root, we attempt to append `--tag .`
which is invalid for docker.
## Expected Behavior
Ensure that if `Dockerfile` is at project root, we use `workspaceRoot`
to determine the `--tag`.
Note, this tag is primarily used as a deterministic method for Nx to
find the correct docker image when calling `docker run` and `nx release`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When using `--output-style=stream-without-prefixes` nx incorrectly shows
the TUI instead of streaming
## Expected Behavior
When using `--output-style=stream-without-prefixes`, nx should stream
with no prefixes just like it does with `--output-style=stream`
## Related Issue(s)
Fixes#32535
Co-authored-by: Hugo Burton <hugo.burton@westpac.com.au>
## Current Behavior
`node_modules` are being copied during copy-local-native
## Expected Behavior
`node_modules` are not being copied during `copy-local-native`
## Current Behavior
Maven is installed as a global dependency for all e2e targets
(`e2e-local`, `e2e-ci--**/**`, and `e2e-macos-ci--**/*`), even when only
the Maven e2e tests need it.
## Expected Behavior
Maven should only be installed as a dependency for the Maven e2e tests
that actually use it, avoiding unnecessary installations for other e2e
test projects.
## Changes Made
- Removed `nx-maven-plugin:install` from the global e2e target defaults
in `nx.json`
- Added `nx-maven-plugin:install` as a specific dependency to the Maven
e2e project targets in `e2e/maven/project.json`
This optimization ensures Maven is only installed when needed, reducing
unnecessary build overhead for other e2e tests.
## Current Behavior
`nx init` does not search for `Dockerfile` patterns to suggest adding
the `@nx/docker` plugin.
## Expected Behavior
`nx init` finds and suggests `@nx/docker` plugin
Fixes NXC-3319
Fixes the order of the arguments in invocations to
`resolveCatalogReference` when resolving catalog references from the
filesystem (not using a `Tree`).
## Current Behavior
In some scenarios, when some processes terminate unexpectedly (e.g.
crashed due to OOM), the task runner will incorrectly determine their
exit code to be 0. This results in Nx storing the task results as a
success, which can cause cache hits with false positive successes.
## Expected Behavior
When processes terminate unexpectedly (e.g. crashed due to OOM), the
task runner should correctly determine their exit code from the signal,
and it should never be 0. The stored task result should not be marked as
successful.
## Related Issue(s)
Fixes#29204
## Current Behavior
When `@nx/docker` is registered via string only (`nxJson.plugins:
["@nx/docker"]`, project graph creation fails because we try to access
`options.buildTarget`.
## Expected Behavior
Handle undefined `options` gracefully, and still create the default
target.
## Related Issue(s)
Fixes NXC-3320
## Current Behavior
Dependencies are outdated and Rust tooling needs to be updated.
## Expected Behavior
Rust dependencies are updated to their latest compatible versions.
## Changes
- Updated Rust dependencies
- Rebased with latest `origin/master`
- Updated pnpm lock file
## Related Issue(s)
None
## Current Behavior
No docs describing migration path
## Expected Behavior
Docs describing migration path
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
.NET sometimes bails on a failed mutex in e2e
## Expected Behavior
it runs only 1 at a time
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
It was removed when the scripts were cleaned up during next.js->astro
migration. Adding this back since blog posts need to be synced first
before serving.
## Current Behavior
When project configuration errors occur due to invalid token usage
(e.g., `{workspaceRoot}` in the middle of a path), error messages don't
provide sufficient context about where the error occurred.
## Expected Behavior
Error messages should include:
- For project-level errors: the project and target context (e.g.,
"libs/my-app:build")
- For nx.json targetDefaults errors: the nx.json context (e.g.,
"nx.json[targetDefaults]:test")
This makes it much easier for users to locate and fix the configuration
issue.
## Changes
This PR adds comprehensive integration tests to verify the improved
error messaging:
- Test for project-level invalid token usage showing project:target
context
- Test for nx.json targetDefaults invalid token usage showing nx.json
context
Tests use mock plugins to simulate realistic scenarios where invalid
`{workspaceRoot}` token usage would occur, ensuring the error messages
contain the expected context information.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
by default code blocks will get text as the lang if not set or the lang
is not supported
but we should be so I don't have to look at the warnings in the terminal
output 😅
also remove the frame=none since the team preferred to have the terminal
frame
Example of invalid codeblock messages
Also added conformance rule for validating image pages for public and
src/assets/ directory
examples of incorrect absolute path ref from "public" folder and
incorrect absolute path:
fixes DOC-242
fixes DOC-259
## Current Behavior
Currently, when configuring the `@nx/docker` plugin, we only set the
target name and a basic command.
The intention was that targetDefaults might be able to be used to
configure additional args, but this falls short in some places.
## Expected Behavior
Allow setting additional args when configuring the `@nx/docker` plugin
that supports interpolated values, similar to `versionSchemes`.
This will allow additional flexibility when setting up the docker build
command such as:
```json
{
"plugin": "@nx/docker",
"options": {
"buildTarget": {
"name": "docker:build",
"args": ["-t {projectName}"]
}
}
}
```
This means that we can use `nx run-many -t docker:build` and it will
successfully add the name of the projects into the tag.
This is one example, other examples include being able to set individual
Docker Layer Caching where each registry needs a unique name.
## Current Behavior
The Maven plugin currently checks if a path is absolute by using
`outputFile.startsWith("/")`. This only works on Unix-like systems and
fails on Windows where absolute paths start with a drive letter (e.g.,
`C:\`).
## Expected Behavior
The Maven plugin should correctly identify absolute paths on all
platforms (Windows, macOS, Linux) using the platform-agnostic
`File.isAbsolute()` method.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A - This is a proactive bug fix for cross-platform compatibility.
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When Nx Cloud is used, but the Nx Cloud client is unavailable, an error
is thrown and commands are not run.
## Expected Behavior
When Nx Cloud is used, but the client is unavailable, continue execution
without Nx Cloud.
## Related Issue(s)
Fixes NXC-3175
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Tests either cause agents to run out of memory:
<img width="956" height="358" alt="image"
src="https://github.com/user-attachments/assets/e55bae05-7757-46e7-88ed-158f72411195"
/>
<img width="1278" height="336" alt="image"
src="https://github.com/user-attachments/assets/40dc8dd6-4409-461e-b75a-5c1c36551da5"
/>
Or setup tasks fail due to network flakiness:
https://staging.nx.app/runs/J1qWVZA7K5
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A fully affected, cache busted task graph should run without any
failures.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request updates the documentation for configuring .NET target
types in the `nx.json` file to provide clearer instructions and
examples. The changes make it easier to understand how to customize
target names and configurations for the `@nx/dotnet` plugin.
Improvements to configuration documentation:
* Added a section describing how each target type can be configured,
including renaming targets, customizing options, disabling targets, and
specifying additional properties.
* Updated the example configuration to show how to rename targets (e.g.,
"build" to "compile"), add configurations (e.g., production
optimization), set dependencies between targets, and disable targets
(e.g., disabling "pack").
* Clarified that targets are created with the configuration specified in
the `nx.json` `plugins` array, rather than just with custom names.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The first-class programmatic API of nx release is only documented within
the manage releases introduction and is incomplete (`ReleaseClient` is
not covered at all).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The programmatic API has its own in depth guide, which is then
cross-referenced from the manage releases guide. `ReleaseClient` is now
documented including its new Nx 22 features.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`run`/`watch` are not mentioned in docs
## Expected Behavior
`run`/`watch` docs are accurate
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Maven plugin targets are only created for goals explicitly bound to
executions in the POM. Goals defined in a plugin but not bound to any
execution are not available as Nx targets.
## Expected Behavior
All available Maven goals should be accessible as Nx targets, including:
- Goals bound to executions (existing behavior)
- Unbound goals defined in the plugin (new behavior)
## Changes Made
1. **Added unbound goal support**: The `NxTargetFactory` now creates
targets for goals defined in a plugin but not bound to any execution.
These targets are created with the format `goalPrefix:goalName` without
an execution ID.
2. **Added continuous build tracking**:
- Added `continuous` property to `NxTarget` data class to track whether
a goal supports continuous builds
- Updated `MojoAnalyzer` to detect continuous goals from the cache
configuration
- All targets now properly propagate continuous mode information
3. **Code improvements**:
- Improved formatting and indentation for consistency
- Made `execution` parameter optional in `createSimpleGoalTarget` to
support both bound and unbound goals
- Updated command generation to work with or without execution IDs
## Related Issue(s)
This change enables better Maven goal discovery and execution in Nx
monorepos.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When an invalid output exists we report:
```
NX The following outputs are invalid:
- foo.txt
Run `nx repair` to fix this.
```
Without specifying the reason, we tell to run `nx repair`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
More feedback provided to the user as to the error with their output:
```
NX The following outputs are invalid:
- foo.txt
** Reason: Outputs must start with either "{workspaceRoot}/" or "{projectRoot}/".
Run `nx repair` to fix this.
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes some pages that don't use the proper markdoc syntax for
line lighting in code blocks. The `{% meta %}` tag is needed and it is
missing in some places.
Closes DOC-2790
## Current Behavior
When the daemon is disabled due to an error, the reason isn't captured,
making it harder to debug why the daemon was disabled.
## Expected Behavior
The error message/reason is now stored when marking the daemon as
disabled, allowing better visibility into what caused the daemon to be
disabled.
## Related Issue(s)
Node tool executions (non-watch) were exiting before completing. This
change ensures they complete before exit.
closes#32385
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Node tool executions are not completing since #32356
## Expected Behavior
Node tool executions complete before exit
## Related Issue(s)
#32385Fixes#32385
## Current Behavior
When errors happen in earlier stages of compilation process, such as
processing global styles, these errors are not printed and the rspack
build process hangs at the Sealing phase.
## Expected Behavior
Ensure that errors that have occurred that would cause the process to
hang are printed and process exits correctly.
Part of this happens because the usual printing of errors happens in the
`afterDone` hook, which is never reached when the above occurs.
## Related Issue(s)
Fixes NXC-3268
## Current Behavior
Readme template files are being published to npm with inconsistent
naming conventions.
## Expected Behavior
Readme template files should be excluded from npm publication and
consistently named as `readme-template.md`.
## Changes
- Renamed all readme template files to `readme-template.md` across
angular-rspack-compiler, angular-rspack, dotnet, and maven packages
- Updated .npmignore files to exclude readme-template.md from npm
publication
- Updated package.json build commands to reference the new
readme-template.md paths
- Removed `!README.md__tpl__` exceptions from package.json files array
entries
add new page for the createNodes api compat
add callouts to extending project graph and tooling plugin page
fixes DOC-255
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Fixes the pnpm caching setup for the `main-macos` job. It can currently
fail when the pnpm cache directory doesn't exist. We need to handle the
pnpm cache conditionally and separately from the node setup.
…as testing projects<!-- Please make sure you have read the submission
guidelines before posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
- Microsoft.Testing.Platform projects are not detected as having a test
target
- `serve` does not have an equivalent
## Expected Behavior
- Test projects are properly detected
- `serve` has been split into 2 targets:
- `watch`
- `run`
The split of `serve` mirrors the`dotnet` cli in the same way that we
mirrored `vite` when adding `preview` and `dev` targets when we moved
with project crystal. `watch` can be used for a variety of cases, but
provides hot reload + run a 'la `dev` / `serve`. `run` is more of a fire
and forget target that starts up the app. Both targets would only really
be used in local dev.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…as testing projects
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
<img width="784" height="196" alt="image"
src="https://github.com/user-attachments/assets/45702b02-a97f-4d75-a67b-76eacdfb56ff"
/>
## Current Behavior
The dependency management documentation does not mention PNPM catalogs
as an option for maintaining single version policy.
## Expected Behavior
Documentation includes information about PNPM catalogs, explaining how
they can be used to maintain a single version policy when using PNPM as
the package manager. This helps if user searches for PNPM catalogs.
## Related Issue(s)
Fixes DOC-302
Co-authored-by: Claude <noreply@anthropic.com>
This PR adds a bit more content to the Java intro page so users can see
how to install Nx, add the plugins, etc. Links to the Gradle and Maven
intro pages, and also the Gradle tutorial.
Fixes DOC-301
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
- add docker to sidebar
- sidebar only shows when there are non-hidden
executor/generator/migration impls to prevent linking to 404 pages
fixes DOC-299
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR fixes a bad redirect where Java intro page went to Angular
Rspack. Also update original Gradle API redirect to go to the Gradle
page rather than the generic Java one.
Closes DOC-298
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
The nxViteTsPaths plugin currently always copys the package.json file at
the end of the build and does not check if the file was generated from
the build process. This adds logic to check if the package.json file
already exists in the dist path before copying to prevent overwriting
generated files.
Closes#30312
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
nxViteTsPaths always copies package.json at end of build.
## Expected Behavior
nxViteTsPaths only copies package.json at end of build if package.json
not generated during build.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30312
This reverts commit d37d8252e4.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Java landing page at nx.dev/java only mentions Gradle support and
indicates that Maven support is coming soon.
## Expected Behavior
The Java landing page should reflect that Maven is now available
alongside Gradle.
https://nx-dev-git-mvn-follow-nrwl.vercel.app/java
## Related Issue(s)
Updates the documentation to reflect the Maven plugin introduced in
#32947
---
**Changes:**
- Updated hero section to state "Nx supports both Gradle and Maven"
- Modified getting started instructions to mention both `@nx/gradle` and
`@nx/maven`
- Updated features description to include Maven builds
- Combined Gradle and Maven documentation links into a single "Learn
More" section with buttons for both
- Updated call-to-action links to point to
`/docs/technologies/java/{gradle,maven}/introduction`
## Summary
Update Maven plugin version from 0.0.6-SNAPSHOT to 0.0.6 for release.
## Changes
- Root pom.xml (nx-parent)
- packages/maven/maven-plugin/pom.xml
- packages/maven/src/utils/versions.ts
## Test plan
- Maven plugin builds correctly with the new version
- No breaking changes to Maven integration
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `main-macos` in the CI verification workflow runs some setup only
needed by the e2e tests unconditionally. This means that even when the
tests are not run, up to ~9 minutes can be spent setting up things that
will not be used.
## Expected Behavior
The `main-macos` in the CI verification workflow should only run the
minimal steps needed to verify whether the tests will be run. If the
tests are to be run, the job should proceed with the remaining required
setup steps; otherwise, it should skip them.
The job will now check whether tests will be run as early as possible
and gate the rest of the steps based on the result.
## Example similar runs
Before: 10m 48s
(https://github.com/nrwl/nx/actions/runs/18625394891/job/53102778452)
After: 1m 3s
(https://github.com/nrwl/nx/actions/runs/18654449747/job/53189013526)
## Current Behavior
When independent versioning with conventional commits, and only one
project in a release group needs bumped, but it depends on another
project via local dependency protocols such as `file://` or `workspace:`
protocol, the local protocol dependency is not replaced.
## Expected Behavior
local protocol is replaced with the current version of the dependency.
## Related Issue(s)
Fixes#30995
## Current Behavior
When there are flaky tasks in a local run for a workspace that has Nx
Cloud enabled, a help message is displayed, advising users to use Nx
Cloud and pointing them to documentation on how to do so. Given that the
workspace is already using Nx Cloud, the message is redundant.
## Expected Behavior
When there are flaky tasks in a local run for a workspace that has Nx
Cloud enabled, no help message should be shown advising users to use Nx
Cloud and pointing them to documentation on how to do so. If the
workspace doesn't have Nx Cloud set up, the message should still be
shown.
- **fix(angular): prevent outputting inline source maps when building an
Angular package**
- **fix(angular): set ng-packagr tsconfig options based on ng-packagr
version**
## Current Behavior
TsConfig options are being set based on older versions of ng-packagr.
These values changed in Angular 20.
## Expected Behavior
Ensure TsConfig options are set based on the version of `ng-packagr`
installed.
## Related Issue(s)
Fixes#33081
Kudos to @daiscog for the initial work on this 🚀
---------
Co-authored-by: David Scourfield <daiscog@users.noreply.github.com>
## Current Behavior
The `@nx/angular` plugin doesn't support generating any project or
artifact when the workspace is using TypeScript project references
because the Angular framework doesn't support it. The message logged to
the users is very generic and slightly misleading. It's not clear enough
and doesn't provide relevant information to allow users to understand
the exact limitation.
## Expected Behavior
The generators from the `@nx/angular` plugin should log a clear error
message with information pointing to the specific issue in the Angular
framework preventing the setup from working for Angular projects.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The AI config is out of date.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The AI config is up to date
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There is no first-party Maven support for Nx
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Maven Support is ready for usage.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When configuring `resolve` config for the `rspack` config with Angular
Rspack, we only consider `node_modules` local to the application.
## Expected Behavior
Ensure workspace root node_modules are also considered and added to the
`resolve` config.
## Related Issue(s)
Closes NXC-3267
Fixes#33026
This PR creates a global spinner handler and adds the runtime
information to the `convert-to-inferred` migration process.
The global spinner ensures a single instance of the `ora` spinner. The
ora cannot run several instances in parallel, so running multiple
instances causes flickering due to message deletion.
The `covert-to-inferred` plugin migration will now show the loading
spinner and progress indicator specifying how many projects have been
converted.
Additional changes:
- DelayedSpinner will not show if there is another (parent) spinner
already running.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Developers may have to install several languages manually to work in the
Nx repo.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Developers can use https://mise.jdx.dev/ to automatically install the
versions of languages necessary to work in the nx repo
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Fix a few failing e2e nightly tests due to npm peer dep conflicts.
Reduced nightly run with the fixed test suites:
https://github.com/nrwl/nx/actions/runs/18651446735. Most of them still
fail, but with existing failures unrelated to npm peer deps issues.
These are not part of the Golden nightly tests yet.
## Current Behavior
Angular Rspack outputs to CJS for Module Federation. It also has
potential issues to cause infinite live reload loops.
## Expected Behavior
Angular Rspack with Module Federation should work as expected
This PR also adds:
- example of Module Federation with Angular Rspack in
`examples/angular-rspack/module-federation`
## Current Behavior
@nx-dotnet/core is recommended plugin for .NET
## Expected Behavior
@nx/dotnet is new .NET plugin
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Vijay Ramakrishnan <vramak@microsoft.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When adding a `project.json` file to configure certain aspects of an
existing Nx project, that project's name will be changed. We had to fix
this for package-json based projects a while back, and as we expand
polyglot its coming up again.
## Expected Behavior
The "default name" behavior stamped into the project.json plugin doesn't
trample existing names. To do this, it had to be moved out of the
project.json plugin and into the validate + normalize flow
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Some migrations used by `nx repair` are missing
## Expected Behavior
Migrations used by `nx repair` are only removed when deemed applicable.
This reverts a portion of commit
a637f9eef9.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes an issue where due to the removal or `--legacy-peer-deps`
for NPM, you can no longer install prerelease versions of Nx. This also
means `npx create-nx-workspace@next` cannot be used with NPM.
For example, if you have this `package.json`:
```json
{
"dependencies": {
"nx": "22.0.0-beta.4",
"@nx/devkit": "22.0.0-beta.4"
},
"license": "MIT"
}
```
And tried `npm install`, it will error out with:
```
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: undefined@undefined
npm error Found: nx@22.0.0-beta.1
npm error node_modules/nx
npm error nx@"22.0.0-beta.1" from the root project
npm error
npm error Could not resolve dependency:
npm error peer nx@">= 21 <= 23" from @nx/devkit@22.0.0-beta.1
npm error node_modules/@nx/devkit
npm error @nx/devkit@"22.0.0-beta.1" from the root project
```
By allowing prereleases via `^22.0.0-0` NPM can work again.
Note: pnpm and yarn are fine.
Formats the `pnpm-workspace.yaml` when catalog definitions are updated
after running `nx migrate`. Like the rest of the Catalog feature, it's
agnostic to the package manager, allowing for an easier addition of
support for future package managers.
The TypeScript packages tutorial shows how to import shared local
libraries but doesn't mention that users need to add dependencies to
package.json and run npm install.
This PR instructs users to link packages properly. Also fixes line
highlighting.
<img width="787" height="718" alt="image"
src="https://github.com/user-attachments/assets/03ec8cca-eab0-4514-8c07-c7d4d316a606"
/>
Installs the correct dependencies after converting to the ESLint Flat
configuration. This was highlighted after removing the npm
`--legacy-peer-deps` flag from default usage in Nx.
Additionally, it fixes nightly e2e failures:
- `e2e-esbuild`
- `e2e-eslint`
- `e2e-gradle`
- `e2e-js`
- `e2e-web`
- `e2e-webpack`
Nightly run where all pass:
https://github.com/nrwl/nx/actions/runs/18592750415
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Terminal output is all logged in one chunk, resulting in a somewhat
jarring experience for lots of output that can cause issues in the
extreme cases.
Task cache status is missing from the run-many outputs
Outputs are sometimes missing
## Expected Behavior
The above are fixed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
- We currently install `@vitejs/plugin-vue` verion `^5` which only
supports `Vite 5 | 6`. This causes peerDep conflicts with `Vite 7`.
- Vue and Nuxt always install v7 version of TypeScript ESLint packages.
This causes peer dep conflicts when ESLint v9 is installed.
## Expected Behavior
- Migrate to `@vitejs/plugin-vue` version `^6` which supports `Vite 5 |
6 | 7`.
- Vue and Nuxt should install a version of the TypeScript ESLint
packages that works for the installed ESLint version.
Nightly run where the previously failing `e2e-vue` tests pass with these
changes:
https://github.com/nrwl/nx/actions/runs/18591984947/job/53009089023
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
This PR removes `nx documentation` and old docs pages from the next.js
app. This improves CI times since we no longer need to check `nx
documentation`, and the next.js app is faster to build.
## Changes
- `.github/workflows/ci.yml` no longer runs `nx documentation`
- Remove `documentation` target from root `project.json` and
corresponding scripts in `scripts/documentation/generators`
- Remove old docs pages from next.js app (e.g.
`nx-dev/nx-dev/pages/[...segments].tsx`)
- Remove manifest JSON files for old docs
- Remove old `og:image` generator for docs (blog, and other pages handle
it differently, this was just for old docs).
- Update bad links in `docs/blog` and `docs/changelog` since we no
longer match them to their manifest JSON files -- the redirects were
already working so just pointed to the new Astro URL
## Notes
- There were some missing dependencies like `ai` for `nx-dev/nx-dev`
that worked previously due to hoisting, but was failing build in this PR
I fixed those.
---------
Co-authored-by: Claude <noreply@anthropic.com>
- **docs(nx-dev): show all blogs in the list below highlighted**
- **docs(nx-dev): adjust ai label on blog posts**
- **docs(nx-dev): adjust how labels are rendered on blog list**
- **docs(nx-dev): swap podcasts tag to ai tag**
Preview:
https://nx-dev-git-nxdev-update-blog-list-page-nrwl.vercel.app/blog
## Current Behavior
When a task is selected and its outputs are displayed in the terminal
pane, the TUI always tracks a task by name regardless of its status.
## Expected Behavior
- When a task is selected, its outputs are displayed in the terminal
pane, and the terminal pane is focused, we track the selected task by
name.
- When a task is in progress, the TUI should track it by name while in
progress.
- When it finishes, it should switch to track another in-progress task
at the same index or in a close index if there is none in progress at
the same index.
- If it's the last task that finished, keep tracking it by name.
- When a task is pending or finished:
- When it's selected and its outputs are displayed in the terminal pane,
the TUI should track it by name.
- When it's selected and its outputs are not displayed in the terminal
pane, the TUI should track the index.
This allows the relevant in-progress section to be visible in more
scenarios than before. The TUI wouldn't blindly follow all tasks by
name.
Additionally, this PR updates the sorting of in-progress tasks to
prioritize start time first, followed by alphabetical order. This
stabilizes the section more (reduces extra movement due to alphabetical
sorting) and aligns with a similar sorting done for finished tasks
(based on the end time).
## Summary
Improved database initialization with better error handling, automatic
recovery from stale files, and cache preservation during error recovery.
## Changes Made
### 1. Iterative Retry Logic with Explicit State
Converted initialization from recursive calls to an iterative loop with
a state flag (`cleaned_up_stale_files`) that limits retries to 2
attempts. This makes retry conditions explicit and self-documenting
while preventing potential stack overflow.
### 2. Complete Auxiliary File Cleanup
Now removes all SQLite database files during cleanup (`.db`, `.db-wal`,
`.db-shm`) instead of just the main `.db` file. This prevents stale
Write-Ahead Logging auxiliary files from causing initialization failures
after version upgrades.
### 3. Smart Compatible Database Handling
Compatible databases (matching version) are now reconfigured based on
their current journal mode:
- **DELETE mode**: Attempts opportunistic upgrade to WAL for better
performance, cleans up any orphaned WAL files from previous runs
- **WAL mode**: Verifies WAL still works; if it fails, removes only
auxiliary files (preserving cache), retries, and falls back to DELETE
mode if still failing
- **Unknown/query failed**: Full reconfiguration with complete cleanup
on failure
This preserves cached build outputs when possible while recovering from
stale file issues automatically.
### 4. WSL1 Proactive Detection
Detects WSL1 environments by reading `/proc/version` and automatically
uses DELETE journal mode instead of attempting WAL (which WSL1 doesn't
support), preventing initialization failures.
### 5. Enhanced Error Messages
Replaced generic error messages with context-specific, platform-agnostic
guidance:
- Permission errors: Explains how to check file/directory permissions
and ownership without platform-specific commands
- Disk full: Suggests freeing space or moving workspace
- Missing directories: Explains unexpected condition with
troubleshooting steps
- All errors: Include debug instructions (`NX_NATIVE_LOGGING=trace`) and
reporting link
Error messages work consistently across Windows, macOS, and Linux
without suggesting commands that may not be available on the user's
platform.
### 6. Code Quality Improvements
Extracted helper functions to reduce duplication:
- `query_journal_mode()` - Query database's current journal mode
- `set_busy_handler()` - Configure connection-level busy handler
- `remove_wal_files()` - Remove only WAL auxiliary files
- `remove_all_database_files()` - Complete database cleanup
- `create_io_error()` / `create_db_error()` - Generate helpful error
messages
## Problems Solved
### Stale WAL Files After Version Upgrades
Leftover `.db-wal` and `.db-shm` files from previous versions no longer
cause initialization to fail. These files are now cleaned up
automatically during initialization.
### Cache Loss on Recoverable Errors
When WAL mode issues occur on otherwise healthy databases, only
auxiliary files are removed, preserving the main database and all cached
build outputs. Full wipes only happen for genuine corruption or version
mismatches.
### WSL1 Compatibility
WSL1 environments now work without initialization failures by
proactively detecting the environment and using DELETE mode instead of
attempting WAL.
### Performance Optimization
Databases in DELETE mode automatically attempt upgrading to WAL when the
environment supports it (e.g., after moving workspace from network drive
to local disk), providing better performance without manual
intervention.
### Poor Debugging Experience
Error messages now provide specific, actionable guidance based on the
error type, helping users resolve issues without needing to ask for
help.
## Impact
- ✅ Users no longer need manual `nx reset` for stale file issues
- ✅ Cache and build outputs preserved during error recovery
- ✅ WSL1 works out of the box
- ✅ Automatic performance improvements when environment changes
- ✅ Better error messages reduce support burden
## Related Issue(s)
Fixes#28640Fixes#30856Fixes#32894
## Current Behavior
`@nx/remix` depends on `@nx/react` which depends on `@nx/vite`.
`@nx/vite` has a `peerDependency` on `vite: 5 || 6 || 7`
This direct dependency chain causes an issue wherein vite 7 is installed
and causes a conflicting peer dependency between `@remix-run: 2`
## Expected Behavior
Remix should use `Vite 5 | 6`. Break the chain between `@nx/react` and
`@nx/vite` causing `Vite 7` to be installed.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Replaced legacy custom `PlayButton` with the `VideoPlayer` component for
a consistent video playback experience. Applied changes across multiple
components and integrations.
This PR adds 404 and header custom events back for docs. These were
previously in the Next.js docs pages, but were missing when we migrated
to Astro.
The `sendCustomEvent` and `sendPageEvent` functions did not account for
the way that Astro is configured via `window.__CONFIG` object, so this
PR fixes those too.
## Screenshots
I ran these in preview mode with the site built with
`COOKIEBOT_DISABlED=true`.
Custom page view on 404:
<img width="2672" height="1527" alt="Screenshot 2025-10-15 at 3 10
05 PM"
src="https://github.com/user-attachments/assets/5bbe30fc-56cb-4427-b138-56edcf3bbc71"
/>
Header docs CTA event:
<img width="2672" height="1527" alt="Screenshot 2025-10-15 at 3 13
02 PM"
src="https://github.com/user-attachments/assets/246cb99d-0a30-4d94-a4a3-8f8659062f23"
/>
Header `Try Cloud` CTA event:
<img width="2672" height="1527" alt="Screenshot 2025-10-15 at 3 10
10 PM"
src="https://github.com/user-attachments/assets/addd2645-cf3e-4c83-ae39-9f00a434a21d"
/>
## Current Behavior
Using TS Soln Workspaces and/or Packaage Manager Workspaces, handling of
certain workflows and scenarios is not correct.
Detecting and Sharing Workspace Libraries relies entirely on TS Path
Aliases existing in the base TSConfig file.
All guidance also points towards adding Workspace Libraries as
dependencies or devDependencies within the consuming application's
package.json file.
This also does not allow correct configuration of sharing.
Meanwhile, TS Path Aliases are added for remote applications such that
TS can find them in consuming applications, while also being able to
provide Typing Support.
However, this has an increased build-time cost for TS compilation as it
will follow the path in source.
## Expected Behavior
Allow attaching Workspace Libraries as deps in the package.json of host
and remote applications.
Configure packages added in such a manner correctly for share scope in
Module Federation.
Attach Remote applications to Host applications via devDependencies in
package.json.
Configure the `exports` and `main, types` properties in the remote
application's package.json to point to the `src/remote-entry.ts` file
such that node resolution can correctly follow the paths.
Bundler will continue to strip this out of compilation and replace with
Module Federation Module Loading code.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When rendering changelogs for releases, breaking changes with multi-line
explanations
are not formatted correctly:
1. Only the first line of a breaking change explanation is captured and
rendered
2. PR references (like `#33014`) are missing from breaking change
entries, making it
difficult to trace back to the original PR
3. Multi-paragraph breaking changes lose their formatting and structure
For example, a breaking change with this format:
BREAKING CHANGE: The --legacy-peer-deps behavior is no longer forced.
If you need it, configure your package manager to enforce it.
Would only render the first line, and without the PR reference.
## Expected Behavior
The changelog renderer should:
1. Capture and render all lines of a breaking change explanation, not
just the first
line
2. Include PR/commit references in the breaking change section (e.g.,
`([#33014](url))`)
3. Properly indent multi-line and multi-paragraph breaking changes for
better
readability
4. Maintain consistent formatting between the feature/fix entry and its
corresponding
breaking change entry
Example of correct output:
```markdown
### ⚠️ Breaking Changes
- **misc:** The `--legacy-peer-deps` behavior is no longer forced.
([#33014](url))
If you need it, configure your package manager to enforce it.
```
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`NX_VERBOSE_LOGGING` turns on/off the debug logs for the gradle plugin
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`NX_GRADLE_VERBOSE_LOGGING` turns on/off the debug logs for the gradle
plugin
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Running `nx run nx:test --help` and `nx test nx --help` behave
differently
## Expected Behavior
They are equivalent
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The tui is enabled even for a single task, and it currently doesn't
bring a lot of value for those single-task use cases
## Expected Behavior
The tui is disabled for single task runs.
## Current Behavior
The bottom corner indicator of the in-progress section in the TUI is not
displayed when there are more tasks in progress than the maximum
parallel capacity (this can occur when there are continuous tasks).
## Expected Behavior
The bottom corner indicator of the in-progress section in the TUI should
always be displayed at the end of the running tasks.
## Current Behavior
The `--legacy-peer-deps` behavior is forced by Nx to try to account for
potential incompatible peer deps users might have.
## Expected Behavior
Nx shouldn't force the `--legacy-peer-deps` behavior. Users can easily
set this up by configuring the package manager they use.
## Related Issue(s)
Fixes#22066Fixes#29537
BREAKING CHANGE: The `--legacy-peer-deps` behavior is no longer forced.
If you need it, configure your package manager to enforce it.
technically the fix to plugin stats now showing up was expired GH token.
But refactored the plugin stats fetching to skip locally unless
NX_DOCS_PLUGIN_STATS env var is set to help speed up local serves/builds
since 99% of the time we're not concerned with the plugin-registry page.
along with trying to centralized the logic between 1st/3rd party plugins
since it was a little confusing from my initial impl.
## Current Behavior
The `remoteUrlDefinitions` variable in
`packages/react/mf/dynamic-federation.ts` is
initialized as an empty object (`{}`), which causes:
1. The `resolveRemoteUrl` callback is never called because
`remoteUrlDefinitions` is
always truthy
2. When `loadRemoteModule` is called before `setRemoteDefinitions`,
users get a cryptic
error "Cannot read properties of undefined (reading 'endsWith')" instead
of the
helpful error message
## Expected Behavior
- `resolveRemoteUrl` should be called when provided and
`remoteUrlDefinitions` hasn't
been set
- The helpful error message should be shown when `loadRemoteModule` is
called before
setup
## Changes Made
Applied the same fix from PR #27927 (for Angular) to the React
implementation:
- Changed `remoteUrlDefinitions` initialization to be `undefined` by
default
- Added nullish coalescing operator (`??=`) in `setRemoteDefinition` to
initialize only
when needed
## Related Issue(s)
Fixes#33055
This follows the same pattern as PR #27927 which fixed#27793 and #27842
for Angular.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
blog and marketing pages will still link to astro docs, so depend on the
astro sitemap to check all links available to be used.
NOTE: the specific header links (url fragments) are skipped for pages
that come from astro docs (prefixed with /docs) due to not having a
simple way to create these lists without parsing all the build html
files out and that's not the part we really care about
confirmed working https://github.com/nrwl/nx/pull/33042 and
https://github.com/nrwl/nx/pull/33036 which are blocked until this
change merges
Fixes DOC-264
## Current Behavior
The Nx release configuration currently uses 5 separate flat properties
for release tag
configuration:
- `releaseTagPattern`
- `releaseTagPatternCheckAllBranchesWhen`
- `releaseTagPatternRequireSemver`
- `releaseTagPatternPreferDockerVersion`
- `releaseTagPatternStrictPreid`
This flat structure makes the configuration verbose and harder to
organize, especially
as more release tag options are added.
Example of current configuration:
```json
{
"release": {
"releaseTagPattern": "{projectName}@{version}",
"releaseTagPatternRequireSemver": true,
"releaseTagPatternStrictPreid": false
}
}
```
## Expected Behavior
After this PR, all release tag-related configuration is consolidated into a single
nested releaseTag object with the following structure:
- releaseTag.pattern (was releaseTagPattern)
- releaseTag.checkAllBranchesWhen (was releaseTagPatternCheckAllBranchesWhen)
- releaseTag.requireSemver (was releaseTagPatternRequireSemver)
- releaseTag.preferDockerVersion (was releaseTagPatternPreferDockerVersion)
- releaseTag.strictPreid (was releaseTagPatternStrictPreid)
Example of new configuration:
```
{
"release": {
"releaseTag": {
"pattern": "{projectName}@{version}",
"requireSemver": true,
"strictPreid": false
}
}
}
```
Migration & Backward Compatibility:
- An automatic migration transforms old configurations to the new structure
- Old flat properties are deprecated but still supported during the migration period
- The deprecated properties will be removed in Nx 23
- All internal code has been updated to use the new nested structure
BREAKING CHANGE: This is a breaking change in the preferred configuration structure. Existing configurations will continue to work through the migration period, but users should update to the new nested format.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When versioning independent projects in Nx release, the updateDependents
configuration
defaults to 'auto'. This means that dependents are updated (with a patch
version bump)
when a dependency is versioned, as long as a group or projects filter is
not applied
that does not include them.
With 'auto', if you apply a filter that excludes dependents, they won't
be updated even
though their dependencies have been versioned.
## Expected Behavior
The updateDependents configuration now defaults to 'always'. This means
that dependents
will always be updated (with a patch version bump) when a dependency is
versioned,
even if they are not included in the group or projects filter.
This provides more predictable behavior and ensures that versioned
dependencies don't
cause version mismatches with their dependents, which could lead to
broken builds or
runtime issues.
BREAKING CHANGE: Users who relied on the previous 'auto' behavior can
explicitly set `updateDependents: 'auto'` in their nx.json:
```json
{
"release": {
"version": {
"updateDependents": "auto"
}
}
}
```
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The current `stop-agents-on-failure` description is confusing customers
as they are expecting agents to be shut down after the first failure
## Expected Behavior
The `stop-agents-on-failure` description clearly distincts between task
and command failure.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Show the same options for flat config as we do for legacy config.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR adds support for generating embeddings using docs in the
`astro-docs` folder. The embeddings are used for `docs_search` MCP tool,
and we currently do not populate new content into it.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
This PR skips check for the required env var during graph creation.
Although it only happens when `NODE_ENV === 'production'` it is possible
that this is set as such, which would cause an error.
The blob outputs could be missing because CI or user ran `affected -t
e2e-ci` and the changeset did not affect e2e tests, thus no reports
generated. In this case, intead of erroring we should just log out a
warning so users know what happened.
<img width="1252" height="212" alt="image"
src="https://github.com/user-attachments/assets/a90f1f93-0d49-4976-8fa6-a40d2a46161a"
/>
The generator `setup-tailwind` is outdated and not necessary. You can
easily set up Tailwind yourself in 1 minute. Keep the pages around
because people do search for tailwind in our docs.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The PR to add the .NET plugin is failing because it uses the scope
`dotnet`, and that has to be present in master since the pr-title-checks
workflow validates against scopes in master.
## Expected Behavior
The scope is in master
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
In the vite nxTsConfigPaths plugin, when using `buildLibsFromSource:
false`, it has no effect when running vitest.
This is an issue especially in large nx projects when running vitest
browser mode because it has a potential to load all the files from the
entire project using the vite dev server (if no modules mocking is being
used).
This increases the amount of time vitest runs substantially.
Plus, there is no way for vite plugin authors to reuse the same
generated tsconfig file (the one generated by nx that points to the
`dist/` folder path) and reuse this information to configure TypeScript
for example.
One example that comes to mind is analog's angular-vite-plugin, meaning
even if nx supported it, that plugin wouldn't be able to know where is
the generated tsconfig is.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
I expect to be able to use `buildLibsFromSource: false` in my vitest
browser mode tests and reduce the amount of time it takes to run those
tests in large scale projects.
In one of my benchmarks I managed to reduce tests from over 1 minute to
9 seconds (!) with this option enabled.
In order to share the generated tsconfig path I've added another
environment variable called `process.env.NX_GENERATED_TSCONFIG_PATH`
Please let me know if this should be added to the documentation
somewhere and if so where, and I'll add it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
When release groups changed to become more flexible and powerful, with
`updateDependents` tracing across any number of transitive release
groups, the logic for filtering (e.g. `--projects` and `--groups` on the
CLI) was never updated to reflect this new dynamism and complexity.
Now in this PR, release graph construction has been fully separated out
from the release-group-processor. It now lives in the new
`ReleaseGraph`. This is also now where filtering takes place so that the
filters can be fully graph aware.
There is additionally a new `always` option available for
`updateDependents` in addition to `auto` and `never` which are
unchanged. `always` means that a project's dependents will be updated
wherever they may live in the graph, regardless of whether or not they
were directly included within a project or graph filter. We feel that
this is what people want most of the time so this is also going to
become the default in a follow up breaking change PR. In order to be
easier to review, and to increase confidence in this refactor, this PR
does not yet make that change to leave as many tests as possible
untouched (other than utilities changing).
BREAKING CHANGE: The signature of `init()` on `VersionActions` has
changed, it no longer accepts a second argument. Validation of the
manifest files, if any, now takes place via a separate method
(`validate()`) call after construction of the new `ReleaseGraph`. For
the most part, users do not need custom `VersionActions` so only a small
percentage of consumers should be impacted.
Fixes https://github.com/nrwl/nx/issues/31273
## Current Behavior
Currently the `nx-schema.json` is enforcing a `groups: properites` type
when it should be `groups: Record<string, properties>`
## Expected Behavior
Update `nx-schema.json` to have `release.groups: Record<string,
propeties>`
## Current Behavior
NestJS dependencies are not added to the project's package.json leading
to issues when pruning lockfile for dockerfiles.
## Expected Behavior
Ensure NestJS dependencies are added to the project's package.json.
## Related Issue(s)
Fixes#32548
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`nx preview <app>` does not enable watch mode on the build.
This used to be the case until (I think)
https://github.com/nrwl/nx/pull/20367
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx preview <app>` should also enable watch mode and rebuild on files
change.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
FYI: I also had to apply [this config
change](https://github.com/vitejs/vite/issues/19410#issuecomment-2655507784)
for Vite 6 to unstuck from "Rebuilding project...". Maybe it's just my
project, not sure but in any case those are 2 separate issues.
Fixes#31604
The codebase contains conditional logic based on `NEXT_PUBLIC_ASTRO_URL`
environment variable to support both old Next.js docs and new Astro docs
paths.
Since the migration to Astro is complete, the checks aren't needed.
Also add support for different `NX_DEV_URL` avalues for the Astro docs
so canary docs don't point to prod website, for example. (`footer.tsx`
and `Header.astro`).
Note: The changes are largely just removing the var check. Some files of
interest are:
- astro-docs/src/components/layout/Header.astro
- nx-dev/ui-common/src/lib/footer.tsx
- nx-dev/nx-dev/next.config.js
- nx-dev/nx-dev/redirect-rules.js
Also note that plugin registry and doc viewer should no longer be used.
Once we don't need the Next.js app anymore, we can just delete the
project rather than removing it right now. For now, just set `noindex`.
Closes DOC-161, DOC-230
---------
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Fixed the description of the commands to not have raw markdown when
running `npx nx login help`. Also updated the description such that we
don't specifically mention `cloud.nx.app` as not all users will be using
this environment by default.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The TUI title displays `Running Running ...` in its title.
## Expected Behavior
The TUI title should not display `Running` duplicated in its title.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
PR releases are being released with a range of `-1 - 1` which is
incorrect
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
PR releases have a peer dependency on just that PR release.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Remove the old CreateNodes v1 signature and related types from the
public API.
This standardizes on CreateNodesV2 as the primary interface.
Related to Nx 22 createNodes v2 compatibility work.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com><!-- Please make sure you
have read the submission guidelines before posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
<!-- This is the behavior we have today -->
Workspaces that did not use package manager workspaces lost some
dependencies with the other fix.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Workspaces that do not use package manager workspaces will still get the
correct dependencies.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When resolving the tsconfig file, project root is always used,
regardless of cwd.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Prepend workspaceRoot to force absolute path resolution
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31987
- **chore(repo): split remaining long e2e tests (#32948)**
- **chore(repo): run hanging tests serially**
- **chore(repo): bust cache to test changes**
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
https://linear.app/nxdev/issue/CLOUD-3753/hanging-tests
Fixes CLOUD-3753
Clarify which name should be used when calling a local plugin
Fixes DOC-232
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
This PR adds an option to allow users to include certain third-party
deps in the bundle by specifying the `excludeFromExternal` option. There
is an existing `thirdParty: true` option that Nx Console uses to bundle
_all_ third-party deps in the bundle, but the new option is more
granular.
## Current Behavior
Nx automatically detects certain dependencies (like optional peer
dependencies) and marks them as external. Users have no way to override
this behavior when they want to bundle these packages instead.
## Expected Behavior
Users can specify an `excludeFromExternal` option to exclude specific
packages from the external list, allowing them to be bundled even if Nx
automatically detected them as external.
## Related Issue(s)
Closes #NXC-2532
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When creating a buildable library for Next w/ Vite, we do not configure
an additional entry point for server components.
## Expected Behavior
Ensure additional server entry point is configured.
## Related Issue(s)
Fixes#31457
Behaviour changes introduced:
- `preserveMatchingDependencyRanges` set to `true` by default
- `releaseTagPatternStrictPreid` set to `true` by default
- `releaseTagPattern` for fixed release groups set to
`{releaseGroupName}-v{version}`
BREAKING CHANGE
## Current Behavior
JSON files are not being filtered from transform with the
JavascriptTransformer.
## Expected Behavior
Only handle JS/TS files with the JavascriptTransformer.
## Related Issue(s)
Fixes#32690
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Nx is currently using a vulnerable version of axios (<1.12.0) which has
a reported high-level vulnerability
[CVE-2025-58754](https://www.cve.org/CVERecord?id=CVE-2025-58754). This
is being flagged by GitHub Advanced Security on a Nx-powered monorepo:
<img width="1260" height="712" alt="Screenshot 2025-09-12 at 09 42 56"
src="https://github.com/user-attachments/assets/251b47c7-07d1-4c21-aafb-0811554d8861"
/>
## Expected Behavior
Nx should be using a patched version of axios (≥1.12.0) that addresses
said vulnerability.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
Error on install in node_modules folder.
[ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in
/Volumes/ssd/user/Dev/project/node_modules/@nx/remix/package.json
at exportsNotFound (node:internal/modules/esm/resolve:313:10)
## Expected Behavior
Can install without error.
## Related Issue(s)
* [@nx/remix package.json is broken due to export
misspelling](https://github.com/nrwl/nx/issues/32810)
Fixes#32810
We show legacy eslintrc format that's been deprecated and shouldn't be
used anymore. We still want to document the legacy format in case users
haven't switched yet.
---------
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
This PR removes redundant `typecheck` targets from projects already
building with `tsc`.
- Add `addTypecheckTarget: false` to projects using `tsc` as
`build-base`.
- Exclude `e2e` and `nx-dev` projects from having `tsc` build inferred
but leave the `typecheck` target
Note: angular-rspack and angular-rspack-compiler has an issue where
`@nx/vite/plugin` is inferring the typecheck target. We may want to
check `addTypecheckTarget` for that plugin as well.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
Closes NXC-3208
## Current Behavior
Nx Release currently only checks for commits with affected files changed
under the root of projects configured for release.
However, changes to other files may affect and invalidate these projects
also.
## Expected Behavior
Reuse Nx's affected logic to determine when commits contain changes that
affect the projects configured for release.
BREAKING CHANGE: More files are now being used to determine relevant
commits, meaning there is higher chance for projects to receive version
bumps
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Fix docs so it aligns with remote cache implementation.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32870
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The inputs for nx:build did not have transitive true for it's node
inputs
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The inputs for nx:build did not have transitive true for it's node
inputs
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
The install command will fail on Linux machines due to `apt` command
only allowing one invocation at a time. This PR solves this by writing
lock and status files to coordinate between potentially many tests on
the same machine.
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Set up search analytics for docs.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes DOC-220
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Relative deploy URL is not being handled correctly in the
postcss-cli-resources Plugins for Webpack and Rspack after switching to
use WHATWG URL in favour of the url.resolve() method.
## Expected Behavior
Ensure the relative deploy URL is properly resolved when using relative
paths
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#32714
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `nx` package is being published with the native package dependencies
using an invalid version range `"*"`.
## Expected Behavior
The `nx` package should be published with the native package
dependencies pointing to the same version as the `nx` package.
A recent change to `nx release` requires workspace packages to be
identified as such when deciding to replace the version.
## Related Issue(s)
Fixes#32898
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
These fields were not being used and it takes time to calculate.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The fields are removed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates our module boundary feature/rule pages such that:
- It is clear that the feature is for both JS/TS projects (ESLint) and
any language (conformance)
- Update links to the ESLint rule from feature page to the actual ESLint
rule page (since feature covers both ESLint and Conformance now)
- Add a "Why" section to the conformance overview page
The conformance page (`docs/enterprise/powerpack/conformance`) is meant
to be the main landing page that we send to users. Also updates the
Enterprise page so link to the overview page.
<img width="1024" height="459" alt="image"
src="https://github.com/user-attachments/assets/c24f110d-cc44-41c8-b448-56d4a246a7b6"
/>
## Updated Pages
- /docs/features/enforce-module-boundaries
- /docs/enterprise/powerpack/conformance
-
/docs/technologies/eslint/eslint-plugin/guides/enforce-module-boundaries
- /docs/reference/powerpack/conformance/overview
- /docs/enterprise/polygraph#conformance
- /enterprise
## Notes
The `/docs/enterprise/powerpack/conformance` and
`/docs/reference/powerpack/conformance/overview` have some overlaps,
where the latter documents all the API options. We should look at
cleaning both the conformance and owners reference pages such that they
are just API docs.
## Related Issue(s)
Closes DOC-206
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Devkit creates the ignore object using the `ignore` package. Nx also
creates the ignore object.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Only `nx` creates the ignore object using the `ignore` package. Devkit
utilizes a util from nx.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
Optimizes `get_dep_output` by replacing recursive traversal with BFS +
parallel processing.
**Key optimization**: The old recursive implementation processed the
same task multiple times when it appeared in multiple dependency paths
(diamond dependencies). The new implementation:
- Uses BFS with a visited HashSet to process each task exactly once
- Collects all tasks first, then processes them in parallel with Rayon
- Returns task references directly, eliminating redundant HashMap
lookups
This deduplicates work and leverages parallelism, significantly
improving performance on large task graphs.
**Note**: Only processes regular dependencies, not
continuous_dependencies, since continuous tasks (like watch/serve) don't
produce outputs that need to be hashed.
The same test on my machine without these changes takes many minutes
before crashing my editor. Now it takes <3ms.
## Test plan
- ✅ All Rust tests passing
- ✅ Native module builds successfully
- ✅ Added 4 unit tests covering direct dependencies, transitive
dependencies, diamond deduplication, and task output filtering
- ✅ Added performance test verifying large graphs (depth 30 = 90 tasks)
complete in <10ms
## Current Behavior
TypeScript build info files (*.tsbuildinfo) are currently committed to
git in several e2e test directories:
- e2e/release/tsconfig.tsbuildinfo
- e2e/remix/tsconfig.tsbuildinfo
- e2e/rollup/tsconfig.tsbuildinfo
- e2e/storybook/tsconfig.tsbuildinfo
These are generated build artifacts that should not be tracked in
version control.
## Expected Behavior
Build info files should be ignored by git and not committed to the
repository.
## Related Issue(s)
N/A - General housekeeping to clean up committed build artifacts
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The provenance error pops up frequently for custom registries and it can
be confusing.
## Expected Behavior
With an updated error message, it's clearer what's going on and how to
fix it. This is what it looks like for a custom registry:
```
NX The migrate command failed.
NX An error occurred while checking the provenance of nx@21.10.5-provenance.
This might be due to a custom registry configuration (http://localhost:4874/). Please check whether provenance is correctly configured for your registry.
To disable this check at your own risk, you can set the NX_SKIP_PROVENANCE_CHECK environment variable to true.
```
## Current Behavior
Tasks inferred by the `@nx/js/typescript` plugin can result in a cache
hit when the public API (`.d.ts` files) of external deps changes. This
is incorrect.
Those tasks correctly have an input `dependentTasksOutputFiles:
'**/*.d.ts'`, but that only covers local workspace dependencies, not
external dependencies.
## Expected Behavior
Tasks inferred by the `@nx/js/typescript` plugin should result in a
cache miss when the public API (`.d.ts` files) of external deps changes.
The `tsc -b` command would invalidate its own cache when any dependency
(local or external) `.d.ts` files change, and the Nx cache should do the
same.
This is a temporary workaround that will more aggressively invalidate
the cache, but it's safer than having false positives. We'll work on a
proper solution that will only hash `.d.ts` files from external
dependencies. Once we have it, we'll revert this change so that the
inputs are as surgical as possible while still being safe.
markdoc graph components were not updating the theme if the user changed
their theme preference causing contrast issues with graph content.
now the graph components will update the selected them when the system
theme or pages theme changes
also do not render title bar if no title is provided
fixes: DOC-237
Since Nx only keeps the last 2 majors listed in a plugins
migration.json, it's possible migrations can be defined and a valid
link, but a new nx version will removed those migrations now causing the
page to 404 a link that previously worked.
instead of 404-ing when plugin migrations delete old versions of
migrations we provide a message stating that there are no migrations,
but you can check the previous versions of the docs to check if the
migration you need is listed here.
We still will not include the migrations link in the sidebar when the
migration.json does not contain any migrations.
Example:
<img width="780" height="425" alt="image"
src="https://github.com/user-attachments/assets/de27c4f7-1442-44e6-9005-970450cabe1e"
/>
Fixes DOC-251
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
- remove side_by_side and the usage of cards grid for graph views
- re-center project/task graphs on render to better fit into view
- also updating the height of a few usages of the graph for when there
was a tall stack of nodes to better fit
- NOTE: we can still apply custom node styles if we want, but since the
complaint was just the default render size bc zoom level, I decided to
just resize the view for the elements.
before:
after:
fixes: DOC-248
This reverts commit 5f4a0fe852.
The previous PR was erroneously merged into `master` for 21.6.x, so we
had to revert it. This PR brings it back for 22.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There are migrations for v19.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Migrations prior to v20 (v19 and below) are cleaned up. Users migrating
from Nx 19 will have to do it piece meal by going to Nx 20 first, then
they will be able to go straight to Nx 22.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Remove the deprecated `decorate-cli` script.
- Stop sorting TypeScript path mappings by default in `nx format` and
generators.
BREAKING CHANGE: The long-deprecated `decorate-cli` script has been
removed.
BREAKING CHANGE: The `nx format` command and generators no longer
default to sorting TypeScript path mappings. To keep the previous
behavior, pass the `--sort-root-tsconfig-paths` flag to the command or
set `NX_FORMAT_SORT_TSCONFIG_PATHS=true`.
## Current Behavior
The experimental inlining feature in the `@nx/js:tsc` and `@nx/js:swc`
executors is deprecated.
## Expected Behavior
The experimental inlining feature in the `@nx/js:tsc` and `@nx/js:swc`
executors should be removed.
BREAKING CHANGE: The experimental inlining feature in the `@nx/js:tsc`
and `@nx/js:swc` executors was removed. A migration will remove the
related options (`external` and `externalBuildTargets`). Still, if you
use or rely on the feature, you need to make your dependencies buildable
or use a different build tool with bundling capabilities.
## Current Behavior
The configuration of the `@rollup/typescript-plugin` is incorrect and
overrides options provided by tsconfig.
It also doesn't respect options from the tsconfig file.
## Expected Behavior
Ensure tsconfig options are respected and not implicitly overriden.
The webpack package contains deprecated options that were marked with
TODO(v22) comments for removal:
- deleteOutputPath option
- sassImplementation option
These deprecated options were still being referenced in the codebase and
schema files, potentially causing confusion for users.
Remove the deprecated options from the webpack package to clean up the
API for v22:
- Remove deleteOutputPath option from the webpack executor and related
configurations (use Webpack's output.clean option instead)
- Remove sassImplementation option from the webpack executor and related
configurations (sass-embedded is now the default)
- Add a migration to automatically update existing workspaces that use
these deprecated options
Closes NXC-3108
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The rspack package contains deprecated options that were marked with
TODO(v22) comments for
removal:
- deleteOutputPath option in the rspack executor schema (Line 79 in
models.ts)
- sassImplementation option in the rspack executor schema (Line 164 in
models.ts)
These deprecated options were still being referenced in the codebase and
schema files,
potentially causing confusion for users.
## Expected Behavior
Remove the deprecated options from the rspack package to clean up the
API for v22:
- Remove deleteOutputPath option from the rspack executor and related
configurations
- Remove sassImplementation option from the rspack executor and related
configurations
- Add a migration to automatically update existing workspaces that use
these deprecated options
## Related Issue(s)
Resolves NXC-3112
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
There isn't a replacement for `bundle-rollup` since the rollup executor
does not support isolated configs. This module ensures that existing
projects will continue to work.
This PR removes an unnecessary logic for React component testing via
Cypress. We've made it not possible to have optional webpack configs a
while back (i.e. non-isolated config support). This means that even
legacy users _must_ have a webpack config using `composePlugin(...)`.
Thus, pass the options to that plugin function and things will continue
to work as usual for those users.
Remove the Rspack Application Generator in favour of generators from
`@nx/react`, `@nx/angular` and other plugins with app generators.
Resolves NXC-3109
The default TypeScript plugin for Rollup has changed from
rollup-plugin-typescript2 to @rollup/plugin-typescript. To continue
using the legacy plugin, explicitly set useLegacyTypescriptPlugin: true
in your configuration.
Resolves NXC-3094
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
The deprecated simpleName option has been removed from the library
generators for Angular, React, Nest, and JS packages. Use the --name
option to provide the exact name for the library.
BREAKING CHANGE: simpleName option is no longer supported in library
generators
Closes NXC-3107, NXC-3098, NXC-3093, NXC-3111
This PR fixes an issue with new docs where graph or PDV tag with inner
JSON content will cause formatting issues with other code blocks on the
page.
Rather than using `<slot/>` to render the inner code fence, which seems
to not play well with the rest of the page, we instead skip rendering
the inner content altogether, and pass the data as `astroRawData` to the
underlying React component. This removes the need to handle
HTML/attribute parsing, so it is much cleaner in addition to resolving
conflicts.
Note: Also fixed some of the previous JSON content as they were invalid.
BREAKING CHANGE: The svgr option has been removed from withReact,
NxReactWebpackPlugin, and withNx (for Next.js). Projects that need SVGR
support should now use the new withSvgr composable function from
@nx/react.
For React webpack projects:
- Import withSvgr from '@nx/react'
- Add withSvgr() to your composePlugins chain after withReact()
For Next.js projects:
- Add SVGR webpack configuration directly to your next.config.js
Migrations have been provided to automatically update existing
configurations.
Closes NXC-3106
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The spinners shown during project graph creation display incorrect
plugin counts. They show the total number of registered plugins instead
of the actual number of plugins being processed for each specific phase.
For example, if there are 10 total plugins but only 3 have
`createDependencies`, the spinner would incorrectly show "Creating
project graph dependencies with 10 plugins" instead of "Creating project
graph dependencies with 3 plugins".
## Expected Behavior
Spinners should show accurate counts reflecting the actual number of
plugins being executed for each phase of project graph creation.
## Related Issue(s)
This fixes a misleading user experience where users see progress
indicators that don't match the actual work being performed.
## Changes Made
### 1. Dependencies Phase
- Use `createDependencyPlugins.length` instead of `plugins.length` for
spinner count
### 2. Metadata Phase
- Filter plugins once for `createMetadata` capability
- Use filtered count for spinner
- Eliminate double filtering by using filtered array directly in
processing
### 3. Create Nodes Phase
- Filter plugins once for `createNodes[0]` pattern existence
- Use filtered count for spinner
- Eliminate redundant pattern check in loop
## Benefits
- **Accurate Progress**: Users see correct plugin counts during each
phase
- **Better Performance**: Eliminated redundant filtering operations
- **Consistent Code**: All three phases now follow the same pattern of
filter-once-use-everywhere
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The messaging can be confusing if vscode/cursor are installed but not
added to PATH.
## Expected Behavior
The messaging is clearer.
## Current Behavior
`svgr` support has been deprecated in `webpack` for some time, but it
was never marked as deprecated for `rspack`.
## Expected Behavior
Mark `svgr` support as deprecated with aim for removal in v23
## Current Behavior
The publish workflow has a duplicate `permissions` block incorrectly
nested under a GitHub script action step, which causes a syntax error in
the GitHub Actions workflow.
## Expected Behavior
The workflow should run without syntax errors. The `permissions` block
should only be defined at the job level, not within individual steps.
## Related Issue(s)
This fixes a GitHub Actions workflow syntax issue where permissions were
incorrectly nested under a step action.
The `pull-requests: write` permission is already correctly defined at
the job level (lines 510-513), so the duplicated permissions block under
the step was unnecessary and causing errors.
🤖 Generated with [Claude Code](https://claude.ai/code)
## Current Behavior
The project graph build process incorrectly handles dependencies when
workspace projects have
different versions or are referenced via specific version ranges. This
causes several issues:
1. NPM lockfile parser crashes when encountering symlinked nested
dependencies in workspaces
(which don't have versions)
2. Package.json dependencies that reference workspace projects with
specific versions (e.g.,
"proj4": "1.0.0" when workspace has "version": "2.0.0") incorrectly
resolve to the workspace
project instead of the installed npm package
3. Version ranges and file references to workspace projects are not
properly validated
## Expected Behavior
The dependency resolution should:
- Handle symlinked workspace packages in npm lockfiles without crashing
- Correctly differentiate between workspace projects and npm packages
when specific versions are
referenced
- Properly validate version ranges against workspace package versions
using semver
- Support file references (e.g., "file:../proj6") for workspace
dependencies
- Only resolve to workspace projects when the version constraint is
satisfied or when using
wildcards
## Notes
This has inadvertently caused issues when calculating which manifest
files need to be updated in the JSVersionActions / Nx Release for Npm
Packages
## Related Issues
Fixes#31454
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
## Current Behavior
NestJS libraries using decorators in constructor, or otherwise, are
causing TS errors due to missing configuration for decorators.
## Expected Behavior
Ensure decorator config settings are set in `tsconfig.lib.json`.
## Related Issue(s)
Fixes#30749
This PR brings back PR releases.
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
This pull request introduces support for configuring specific AI agents
in Nx workspaces, allowing users to select which agents to set up and
generating only the relevant configuration files for those agents. It
also updates documentation, schemas, and tests to reflect this new, more
flexible approach.
The most important changes are:
**Agent Selection and Configuration:**
* Added the ability to specify which AI agents to configure via an
`agents` array, both in the setup schema (`schema.json`) and the
`CreateWorkspaceOptions` type. The supported agents are: `claude`,
`gemini`, `codex`, `cursor`, and `copilot`. The generator only creates
configuration files for the selected agents, rather than all by default.
[[1]](diffhunk://#diff-f4d0a6778d70986b54028fb1a5a9338ad4db252edd6db4066e7ee87e8d7f28a5R22-R30)
[[2]](diffhunk://#diff-8141dbb37440f99a460b1e23d0c7229cd16338984832faf528d0ff23de179766R40-R50)
[[3]](diffhunk://#diff-ed4e3e85dbc5d3358491bcef52a8f403a9607df8c874ec9dadef7cd2a1eba6c7R89-R121)
* Implemented prompt logic for selecting AI agents interactively during
workspace creation, and exposed available agent types for use in prompts
and configuration.
[[1]](diffhunk://#diff-672af9097acda13d133130b660df34e6ddf6a61a74f9a6d66832255123e8f9b9R16)
[[2]](diffhunk://#diff-672af9097acda13d133130b660df34e6ddf6a61a74f9a6d66832255123e8f9b9R75-R119)
**File Generation Logic:**
* Refactored the `setupAiAgentsGenerator` implementation to generate
only the files relevant to the specified agents (e.g., `CLAUDE.md`,
`.mcp.json` for Claude; `.gemini/settings.json` for Gemini; `AGENTS.md`
for others), and to append to existing files rather than overwrite them.
[[1]](diffhunk://#diff-ed4e3e85dbc5d3358491bcef52a8f403a9607df8c874ec9dadef7cd2a1eba6c7R1-R45)
[[2]](diffhunk://#diff-ed4e3e85dbc5d3358491bcef52a8f403a9607df8c874ec9dadef7cd2a1eba6c7R89-R121)
* Added new utility functions for determining config file paths and
reading agent-specific configuration, improving maintainability and
clarity of file handling logic.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Pre and post hooks lack corellation Id which might make it difficult to
culculate stats for task using pre and post hooks.
Additionally, post hook does not expose the duration or time span for
the task. Using pre/post hook might not be precise enough.
## Expected Behavior
Hooks expose the unique taskId so we can corellate pre hook of a task to
the post hook of the same task. Post hook should expose start and end
time of the task run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Resolves discussion
[31076](https://github.com/nrwl/nx/discussions/31076)
Refactored multiple components to integrate `motion` animations for a
smoother UI experience. Implemented `AnimateValue` for animated
statistic values across various sections and improved readability by
replacing `JSX.Element` with `ReactElement` where applicable.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `README.md` file for `@nx/web` is currently not copied into the
publish directory for release.
## Expected Behavior
Ensure the `README.md` file is copied into the publish directory.
## Related Issue(s)
Fixes NXC-3055
Add a new `NX_MIGRATE_SKIP_REGISTRY_FETCH` environment variable to opt
out of fetching package versions and migrations metadata from the
registry and instead, use package installation to get the information.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running `nx format:check`, if there is an error, it is considered
as files not formatted correctly
But if Prettier is throwing a real error, it is not diplayed. We just
see an empty result without information
For example:
Format check failing with empty result
```
nx format:check
```
But when running the command, we can see the error:
```
node "/node_modules/prettier/bin/prettier.cjs" --list-different "packages/lib/.spec.swcrc"
packages/lib/.spec.swcrc
[error] No parser could be inferred for file "/packages/lib/.spec.swcrc".
```
## Expected Behavior
I should see the prettier error to understand why it is failing
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Building on Netlify fails.
```
3:03:48 PM: FAILURE: Build failed with an exception.
3:03:48 PM: * What went wrong:
3:03:48 PM: A problem occurred configuring root project 'nx'.
3:03:48 PM: > Could not resolve all artifacts for configuration 'classpath'.
3:03:48 PM: > Could not resolve dev.nx.gradle:project-graph:0.1.7.
3:03:48 PM: Required by:
3:03:48 PM: root project : > dev.nx.gradle.project-graph:dev.nx.gradle.project-graph.gradle.plugin:0.1.7
3:03:48 PM: > Dependency requires at least JVM runtime version 17. This build uses a Java 8 JVM.
3:03:48 PM: > Could not resolve com.ncorti.ktfmt.gradle:plugin:0.24.0.
3:03:48 PM: Required by:
3:03:48 PM: root project : > com.ncorti.ktfmt.gradle:com.ncorti.ktfmt.gradle.gradle.plugin:0.24.0
3:03:48 PM: > Dependency requires at least JVM runtime version 17. This build uses a Java 8 JVM.
3:03:48 PM: * Try:
3:03:48 PM: > Run this build using a Java 17 or newer JVM.
3:03:48 PM: > Run with --stacktrace option to get the stack trace.
3:03:48 PM: > Run with --debug option to get more log output.
3:03:48 PM: > Run with --scan to get full insights.
3:03:48 PM: > Get more help at https://help.gradle.org.
3:03:48 PM: BUILD FAILED in 30s
```
## Current Behavior
Gradle plugin needs Java 17, but Netlify uses 8.
## Expected Behavior
Skip targets on Netlify just like on Vercel.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-3175
- add prettier overrides for mdoc files to be treaded as markdown (along
with running format)
- update links to nx-commands refs to use correct header links
- fix link on quickstart page to point to CI feature overview
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- Bump version of gradle plugin to V2
- Add java to publish pipelines so that we can build the gradle plugin.
- Removed files from freeBSD VM to prevent disk storage limit issues
- Bumped up the kotlin version of gradle projects such that kotlin can
build on freeBSD
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The TUI had two distinct scrolling issues:
1. **Tasks List Events Scrolling**: Any tasks list event (scrolling,
arrow keys, task status changes) would cause the terminal pane to scroll
down exactly 8 lines in two batches of 4 - one immediately and another
after ~200ms delay.
2. **New Task Initial Positioning**: When navigating to a task for the
first time, the task output would render 4 lines above the bottom
position, then automatically scroll to the correct bottom position after
a short delay.
## Expected Behavior
1. Tasks list navigation and events should not cause any scrolling in
the terminal pane
2. Task output should appear correctly positioned at the bottom from the
first render without any delayed scroll adjustments
---
## Technical Details
### Root Cause
**Issue 1 - Tasks List Events Scrolling (8 lines)**
- Task list events triggered `debounce_pty_resize()` calls
- This caused immediate resize + 200ms delayed resize
- Each resize applied 4-line scroll adjustments due to dimension
recalculations
- Result: 8 lines total scroll (4 immediate + 4 delayed)
**Issue 2 - New Task Initial Positioning (4 lines)**
- New PTY instances created with default dimensions (24×80)
- Terminal panes had different calculated dimensions (e.g., 22×137)
- Viewport height mismatch caused content to appear 4 lines up from
bottom
- Delayed resize would correct positioning, causing visible
scroll-to-bottom
### Solution
**Architectural Improvement**: Migrated from individual dimension fields
to shared dimensions using `Arc<RwLock<(u16, u16)>>` to ensure
consistency across all PTY references.
**Issue 1 Fix**: Removed redundant `debounce_pty_resize()` calls during
task navigation events, eliminating the double-resize pattern.
**Issue 2 Fix**: Added immediate dimension correction in
`render_terminal_pane_internal()` to ensure correct positioning from
first render.
### Changes Made
- **pty.rs**: Replaced individual `rows`/`cols` fields with shared
`dimensions: Arc<RwLock<(u16, u16)>>`
- **app.rs**: Added immediate resize in
`render_terminal_pane_internal()` for correct initial positioning
- **app.rs**: Removed redundant `debounce_pty_resize()` calls during
task navigation events
- Improved error handling and eliminated potential deadlock risks in
resize operations
### Performance Impact
- Eliminated double-resize pattern during navigation (~67% reduction in
resize operations)
- No more visible scrolling delays or positioning issues
- Maintained all layout change functionality while removing unnecessary
operations
## Current Behavior
The `cache_outputs` table is always created with a foreign key to the
`task_details` table. When `NX_DISABLE_DB=true` is set, the
`task_details` table is not created, and this results in an error when
trying to insert any records in the `cache_outputs` table.
## Expected Behavior
When `NX_DISABLE_DB=true` is set, the `cache_outputs` table should not
have a foreign key to the non-existent `task_details` table.
## Related Issue(s)
Fixes#32208
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
provenance checks fail on latest on windows because `npm.cmd` is only
executable with a shell. That removes the entire security aspect of
using `execFile` so we just go back to `exec`.
## Expected Behavior
provenance checks shouldn't fail on windows.
## Related Issue(s)
Fixes#32713
Increased the maximum number of active contributors mentioned in the
pricing description from 30 to 50 in the `Pricing` component
(`nx-dev/ui-cloud/src/lib/pricing.tsx`).
## Current Behavior
The React init generator unconditionally adds the
@nx/react/router-plugin to the nx.json plugins
array whenever addPlugin is true. This causes the React Router plugin to
be added even for
React applications that don't use React Router, which is unnecessary and
can lead to unwanted
behavior.
## Expected Behavior
The React Router plugin should only be added to nx.json when:
1. The React application is actually using React Router (specifically
for SSR/RSC scenarios)
2. The addPlugin option is true
This ensures that:
- Applications without React Router don't get the plugin unnecessarily
- Applications with React Router for SSR/RSC get the plugin
automatically when created with the
--useReactRouter flag
- Libraries never get the React Router plugin as they don't need it
## Related Issue(s)
Fixes#32525
update pagefind config to improve search hits
add weight and filter properties for docs to control individual pages
filter` allows selecting "type" of docs being searched
where weight can set the given pages search weight
unfortunately this will set the weight of the whole page content instead
which can make performance worse so important to use it sparingly.
current set values are trial and error based. and subject to change over
time really just depends on feedback over time of the search
performance.
fixes DOC-159
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
only claude has dedicated setup in the nx repo.
## Expected Behavior
Claude, Gemini and things that use AGENTS.md have dedicated setup in the
nx repo.
## Current Behavior
The `tsx` package is missing causing TUI to hang in interactive mode.
## Expected Behavior
The `tsx` package is installed so commands running `npx tsx` don't need
to ask for a permission to install it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Reverting gradle v2 plugin from Nx due to issues with publish pipelines
not being able to handle the new changes. Will re-apply once the kinks
in publish are ironed out.
The AI chat on nx.dev shows an error 'Failed to parse stream string. No
separator found.' after successfully receiving a response from the API.
The AI chat should work without showing streaming parse errors after
successful responses.
Also fixed tailwind pruning by including `feature-ai` in the globs to
check.
https://github.com/user-attachments/assets/2517d856-7a45-48f4-b71b-885f3714fb44
Fixes DOC-216
When NEXT_PUBLIC_ASTRO_URL is set, the blog index now includes a
dedicated search box that filters results to only blog posts. This
ensures blog search functionality is maintained when the main docs
search is moved to the Astro site.
Blog index page has no search functionality when Astro docs are enabled,
making it difficult to find specific blog posts.
Blog index page displays a search box that searches only within blog
posts (using Algolia facet filter for 'Nx | Blog') when Astro docs are
enabled, preserving the ability to search blog content.
Without astro docs:
<img width="1162" height="733" alt="Screenshot 2025-09-19 at 2 26 34 PM"
src="https://github.com/user-attachments/assets/a499fb03-ecc6-4a4f-9303-2198e32f9a77"
/>
With astro docs:
<img width="1143" height="784" alt="Screenshot 2025-09-19 at 2 27 42 PM"
src="https://github.com/user-attachments/assets/4d0bfa7e-0ca6-4694-bba0-fc5e63d1b140"
/>
https://github.com/user-attachments/assets/fe96bc49-dafe-4bc6-9b89-578f29f93cf7
Fixes DOC-221
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We were managing disparate versions across all gradle projects.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Centralize all plugins and dependencies into one location for easier
maintenance.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Algolia search appears on all nx-dev pages, including non-documentation
pages like AI chat and changelog, even when the new Astro documentation
site is enabled. This creates confusion as search should only be
available on documentation pages.
- When NEXT_PUBLIC_ASTRO_URL is set (indicating new docs are enabled),
Algolia search is disabled on all nx-dev pages
- Non-documentation pages (AI chat, changelog) use the non-documentation
header without search
- Documentation header only shows search when Astro docs are not enabled
- Clean up existing styling issues and ensure consistent header usage
across the site
- Updated documentation-header.tsx to conditionally hide search when
NEXT_PUBLIC_ASTRO_URL is set
- Updated header.tsx to pass showSearch prop based on
NEXT_PUBLIC_ASTRO_URL
- Modified AI chat page to use non-documentation header and fixed
styling issues
- Modified changelog page to use non-documentation header-
- Fixed astro header such that `Office Hours` and `Live Streams` are
replaced with `Nx Live` (already done on Next.js side)
- Fixed astro sidebar reference updater middleware formatting
## Examples
Non-docs headers (for homepage, blog, cloud, enterprise, etc.):
<img width="1349" height="103" alt="Screenshot 2025-09-19 at 11 49
06 AM"
src="https://github.com/user-attachments/assets/5a9e6355-43b9-4142-9c76-b30ccc4982b1"
/>
Changelog (with astro docs):
<img width="1467" height="1401" alt="Screenshot 2025-09-19 at 11 48
36 AM"
src="https://github.com/user-attachments/assets/8e135ca7-fe36-4b44-b181-633d3dc5890d"
/>
AI Chat (with astro docs):
<img width="1246" height="952" alt="Screenshot 2025-09-19 at 11 48
24 AM"
src="https://github.com/user-attachments/assets/866c7e4d-8eac-40ab-9c77-5d125135d4e9"
/>
Changelog (without astro docs);
<img width="1180" height="1132" alt="image"
src="https://github.com/user-attachments/assets/eccdeb17-08fc-4f90-949d-5c7879abe3d3"
/>
AI Chat (without astro docs):
<img width="1172" height="1407" alt="image"
src="https://github.com/user-attachments/assets/2ad6b797-32bc-498b-93cb-29cc368030f1"
/>
Astro docs header with updated `Nx Live` link:
<img width="685" height="434" alt="Screenshot 2025-09-19 at 11 48 51 AM"
src="https://github.com/user-attachments/assets/48facc87-2c90-4195-97c7-024b11112001"
/>
Fixes DOC-219
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Fixed the `parseAstroHtmlWrappedJson` function used by PDV and graph tag
components to render code fence properly.
The problem was that inner HTML with code fence caused escaped
double-quotes (`\"`) to be improperly handled. By the time we read the
HTML via React props, the escape character is already done (`\`). Thus,
use code fence to let Starlight render the full block, and then parse
out the JSON object from the `[data-code]` attribute on the div.
For example, previously this would fail:
```
{% project_details %}
{ "foo": "\"bar\"" }
{% /project_details %}
```
That doesn't work because the HTML is just ""bar"", which is invalid.
But changing the above to this works:
````
{% project_details %}
```json
{ "foo": "\"bar\"" }
```
{% /project_details %}
````
This works because you get something like `data-code=""foo":
"\"bar\"""` set on the `div`. So we can use regexp
to match everything within that attribute and parse it out as JSON once
we convert some entities.
Check the
[`nx-dev/ui-markdoc/src/lib/utils/parse-astro-html-wrapped-json.ts`](https://github.com/nrwl/nx/pull/32778/files#diff-c3d8e90b624e30217beaa44c46a16b9053533cf9a8542a4f7301ccaf3dbdab58)
file for the full logic.
Also added JSON code fences to all graph tags in mdoc files to ensure
proper parsing.
<img width="709" height="866" alt="Screenshot 2025-09-18 at 3 41 26 PM"
src="https://github.com/user-attachments/assets/fdae86a6-929a-4a1f-82fe-7d4052de5db5"
/>
Closes #DOC-217
This PR migrates to the unified `@nx/graph` with UI and persisted url
graph state.
- new UI components
- remove obsolete state machines code
- remove obsolete URL query parameters handling
## Current Behavior
When generating workspaces or projects with ESLint and using the TS
solution setup, the generated `out-tsc` directory for TS output is not
ignored in the ESLint configuration. This results in the lint task
processing and potentially reporting errors from that directory.
## Expected Behavior
When generating workspaces or projects with ESLint and using the TS
solution setup, the generated `out-tsc` directory for TS output should
be ignored in the ESLint configuration.
## Current Behavior
Options configured in the `e2e-ci` tasks are not forwarded to their
atomized tasks.
## Expected Behavior
Options configured in the `e2e-ci` tasks can be forwarded to their
atomized tasks.
The `@nx/cypress/plugin` and `@nx/playwright/plugin` plugins will infer
their `e2e-ci` dependencies to atomized tasks with `"options":
"forward"`.
This resolves multiple database-related race conditions that cause
"database is locked" errors and `BorrowMutError` panics during task
cleanup and service initialization.
## Issues Fixed
1. **Task cleanup race condition**: Exit handlers and cleanup methods in
the task orchestrator simultaneously attempted to remove the same task
record, causing SQLite lock contention
2. **Missing database retry logic**: Native operations bypassed the
existing retry mechanism, making them vulnerable to concurrent access
failures
3. **SQLite connection borrowing conflicts**: Direct connection access
in `NxTaskHistory::setup()` violated Rust's borrowing rules when other
services held concurrent borrows
## Solution
### Application-level coordination
- Added atomic check-and-remove pattern using `Map.delete()` return
value
- Only the process that successfully removes from the task map performs
the database operation
- Eliminates duplicate database calls entirely
### Database-level robustness
- Fixed `RunningTasksService` methods to use retry-enabled database
operations
- Replaced `prepare() + stmt.execute()` pattern with direct
`db.execute()` calls
- Ensures all operations benefit from exponential backoff retry logic
(up to 20 attempts)
### Connection access safety
- Moved `array::load_module` from service setup to centralized database
connection opening
- Removed direct `.conn` access that bypassed safe wrapper patterns
- Load array module once per connection instead of per service
instantiation
## Files Changed
- `packages/nx/src/tasks-runner/task-orchestrator.ts` - Race condition
prevention
- `packages/nx/src/native/tasks/running_tasks_service.rs` - Retry logic
fixes
- `packages/nx/src/native/db/initialize.rs` - Centralized array module
loading
- `packages/nx/src/native/tasks/task_history.rs` - Removed unsafe
connection access
Provides comprehensive concurrency safety through defense-in-depth:
prevents race conditions at the application level while ensuring
database operations are resilient to concurrent access.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently we do not support overwriting the default test target since
with custom tests from Gradle. This means you cannot use a test suite
other than the default `test`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- We can now detect custom test suites via the Gradle API, which
receives the test tasks via the task type rather than the test name.
- We can atomize against test targets without having to set these
targets in the gradle plugin configuration
- Setting a custom test target that conflicts with a defined test suite
in Gradle now throws an error
- Check-ci correctly depends on all atomized targets of test targets
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-2962
## Current Behavior
When Angular components reference assets in their stylesheets using
`url()` (e.g., `background-image: url('../assets/test-pattern.svg')`),
the Nx Angular Rspack plugin processes the CSS but fails to extract and
copy the referenced asset files to the output directory. This results
in:
- CSS is processed and URLs may be rewritten to reference output paths
(e.g., `url('./media/test-pattern.svg')`)
- The actual asset files are never copied to the output directory
- Browser shows 404 errors for missing asset files when the application
runs
- No `media` directory is created in the build output
## Expected Behavior
With this fix, assets referenced in component stylesheets are now
properly extracted and emitted to the output directory:
- Asset files referenced in component stylesheets are extracted and
copied to the output directory
- CSS URLs are correctly rewritten to point to the copied assets
- No 404 errors occur for asset files
- A `media` directory is created in the output with the extracted assets
- Both inline and external component styles properly handle asset
extraction
## Related Issue(s)
Fixes#32487
## Changes Made
### Core Fix
- Modified the Angular Rspack plugin to properly collect and emit
stylesheet assets during the compilation process
- Added asset collection during both bundle file and inline style
processing in `setup-compilation.ts` and
`setup-with-angular-compilation.ts`
- Implemented asset emission in the `processAssets` hook of the Angular
Rspack plugin
### Test Coverage
- Added comprehensive example application
(`examples/angular-rspack/csr-css-assets`) that demonstrates:
- External component stylesheets with asset references
- Inline component styles with asset references
- Various asset types (SVG, images)
- Proper asset extraction and URL rewriting
### Technical Details
The fix addresses the gap between Angular's `ComponentStylesheetBundler`
which correctly processes assets and generates `outputFiles`, and the Nx
Angular Rspack plugin which now properly emits these files using
`compilation.emitAsset()` during the build process.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
All errors.. even Project Graph errors cause the daemon to shutdown.
This meant that showing partial graphs in the graph application no
longer worked.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Shutting down the daemon won't help for project graph errors. In this
case, we should not shutdown the daemon. And showing partial project
graphs will work again.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When running `pnpm nx test-native nx`, OSC (Operating System Command)
escape sequences appear after the test completes, displaying as random
characters like `10;rgb:f8f8/f8f8/f2f2` and `11;rgb:0000/2b2b/3636`.
## Expected Behavior
Test execution should complete cleanly without any escape sequences
appearing in the terminal.
## Root Cause
The issue occurs because:
1. Tests in `tasks_list.rs` create `TasksList` components for testing UI
functionality
2. `TasksList` accesses the `THEME` static for styling (e.g.,
`THEME.secondary_fg`)
3. `THEME` is a `LazyLock` that initializes by calling `is_dark_mode()`
4. `is_dark_mode()` uses `terminal_colorsaurus::color_scheme()` which
sends OSC queries to detect terminal colors
5. The test process often exits before the terminal responds, leaving
orphaned responses that appear as escape sequences
## Solution
Added compile-time conditional compilation to skip terminal color
detection during tests:
- `#[cfg(test)]`: Returns `true` (dark mode) without sending OSC
queries. Tests run in virtual buffers and don't need the terminal theme.
It's also less deterministic to have tests relying on the terminal
theme.
- `#[cfg(not(test))]`: Performs normal terminal detection for production
use
This approach:
- ✅ Eliminates OSC sequences during test execution
- ✅ Preserves normal color detection in production
- ✅ Provides deterministic test behavior regardless of terminal theme
- ✅ Improves test performance by avoiding I/O operations
When i18n localization is enabled, rspack generates assets with locale
prefixes
(e.g., 'fr/main.abc123.js'), but chunk.files array is empty. This caused
the
stats reporting to show 0 bytes for all files.
Updated the asset filtering logic in stats.ts to:
- Try exact match first (preserves existing behavior for non-i18n
builds)
- Match assets by chunk names when chunk.files is empty (i18n builds)
- Handle assets with locale prefixes and hash values in filenames
Fixes#32277
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump version of gradle plugin to 0.1.8
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…me cache inputs (#31428)"
This reverts commit 5679b3ea
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This commit caused a major perf regression.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This commit is reverted for now.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Gradle plugin is at version 0.1.7
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bump version to 0.1.8
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
We already have `NEXT_PUBLIC_NO_INDEX` supported in pages router, so
canary.nx.dev does not get indexed. However, we missed this in the app
router, so `/blog` is not setting `noindex` in preview environments.
## Current Behavior
When running an npm script through nx and not using the PseudoTerminal,
child processes might not be killed when the `nx:run-script` executor is
killed.
## Expected Behavior
When running an npm script through nx and not using the PseudoTerminal,
child processes should be killed when the `nx:run-script` executor is
killed.
## Current Behavior
Generating Angular projects with Jest results in Jest v30 being used,
which is not supported by Angular and causes peer dependency errors.
## Expected Behavior
Generating Angular projects with Jest should install a compatible
version of Jest (Angular currently supports `^29.5.0`).
Add missing Nx Cloud documentation pages.
Files added:
- astro-docs/src/content/docs/reference/Nx Cloud/config.mdoc
- astro-docs/src/content/docs/reference/Nx Cloud/release-notes.mdoc
- astro-docs/src/content/docs/guides/Nx Cloud/optimize-your-ttg.mdoc
Redirects fixed:
- 8 CI/concepts pages now point to correct locations
Closes DOC-204
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There's no way to distribute Cypress Component Tests.
## Expected Behavior
Cypress Component Tests can be distributed.
Users can choose to infer individual tasks per Cypress Component Test
files that can be distributed across Nx Agents using DTE, by setting the
`ciComponentTestingTargetName` option for the `@nx/cypress/plugin`:
```json
// nx.json
{
...
"plugins": [
{
"plugin": "@nx/cypress/plugin",
"options": {
...
"componentTestingTargetName": "component-test",
"ciComponentTestingTargetName": "component-test-ci"
}
},
...
]
}
```
## Current Behavior
gradle dependencies are hardcoded to included builds & subprojects
## Expected Behavior
we use project configurations to determine dependencies like the tooling
api does
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: lourw <56288712+lourw@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
remove remix and react-native guides and redirect to their intro pages
since they functionally covered the same content already
remove the Module federation concepts since those were already
removed/redirected in the main nx.dev and didn't need to be copied over
to astro site.
fixes: DOC-183
Tabs were not aligning properly on mobile, causing visual
inconsistencies. Added align-items: end to tablist elements to ensure
proper vertical alignment.
<img width="528" height="614" alt="image"
src="https://github.com/user-attachments/assets/b9a1d9b3-c051-43ac-9454-21b16c7f21b5"
/>
Fixes DOC-168
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When updating manifests, Nx Release will replace explicit peerDependency
ranges with the new version that is being created.
i.e.
```json
"peerDependencies": {
"nx": ">= 20 <= 22"
}
```
`nx release version 21.6.0`
```json
"peerDependencies": {
"nx": "21.6.0"
}
```
## Expected Behavior
When processing dependency updates, check for
`preserveMatchingDependencyRanges`.
If this is set to `true` or an array with explicit `dependencyTypes`
check if a valid range is set.
If so, do not update the range.
i.e.
`preserveMatchingDependencyRanges: true`
```json
"peerDependencies": {
"nx": ">= 20 <= 22"
}
```
`nx release version 21.6.0`
```json
"peerDependencies": {
"nx": ">= 20 <= 22"
}
```
If the new version breaks the range, throw an error asking user to
update the range.
i.e.
```json
"optionalDependencies": {
"nx": ">= 20 <= 22"
}
```
`nx release version 23.2.0`
```
The version "23.2.0" is not a valid range for optionalDependencies "nx" in manifest "dist/packages/devkit/package.json". Please update to a valid range.
```
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Update all documentation links in nx-dev UI components to conditionally
use the new /docs
structure when NEXT_PUBLIC_ASTRO_URL is set. This prevents landing on
the old docs page due to the lack of redirect support in Next.js'
`<Link>` when used with pages router.
Note: Blog pages are not updated in `docs/blog` because blog is using
app router which supports redirects. For example, on
https://canary.nx.dev/blog/nx-self-healing-ci the link at the end for
`Nx AI Docs` point to https://canary.nx.dev/features/enhance-AI and is
correctly redirected to https://canary.nx.dev/docs/features/enhance-ai.
## Logic
- When NEXT_PUBLIC_ASTRO_URL is set: links point to /docs/* URLs
- When NEXT_PUBLIC_ASTRO_URL is not set: links use legacy URLs (current
production behavior)
## Pages and components updated
### Pages router pages and components
These are critical since pages router does not support redirects in next
config.
- Homepage (/) components
- AI Page (/ai) components
- Enterprise Page (/enterprise) components
- NX Cloud (/nx-cloud) components
- Pricing (/pricing) components
- Community (/community) components
- Contact (/contact) components
- Powerpack (/powerpack) components
- Gradle pages components
- Common UI components (footer, headers, sidebar)
- Solution pages (engineering, leadership, management)
- Changelog (/changelog)
### App router pages
These pages would have worked regardless since app router supports
redirects in next config.
- React Page (/react):
- ui-react/src/lib/hero.tsx - 1 link
- ui-react/src/lib/features.tsx - 4 links
- ui-react/src/lib/feature-sections.tsx - 3 links
- Powerpack Page (/powerpack):
- ui-powerpack/src/lib/powerpack-features.tsx - 2 links
- Remote Cache Page (/remote-cache):
- ui-remote-cache/src/lib/remote-cache-solutions.tsx - 2 links
- ui-remote-cache/src/lib/faq.tsx - 1 link
---
Verified with NEXT_PUBLIC_ASTRO_URL=https://canary.nx.dev:
- All links now point to /docs URLs (no 308 redirects)
- Old URLs still redirect for backward compatibility
- Pages load successfully with updated links
Fixes DOC-184
## Current Behavior
The Module Federation docs had out of date code snippets
## Expected Behavior
Bring the Module Federation docs in line with recent developments
## Current Behavior
The inferred `docker:build` target does not depend on the build target.
Given that most `docker build` commands rely on the initial application
itself to be built first, it makes sense to depend on the build target.
## Expected Behavior
`docker:build` dependsOn `build`
switch to making typedoc to the rendering and then pull in the generated
file contents instead of manually parsing the reflection metadata.
Fixes: DOC-63
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Add SVG icons to the Technologies section sidebar items to improve
visual hierarchy and navigation. Icons are displayed next to technology
labels like TypeScript, Angular, React, Vue, Node.js, Java, etc.
`Sidebar` is now using a custom `SidebarSublist` that uses `data-icon`
(if it exists) to render the SVG images. A middleware is used since
`attrs` cannot be set on sidebar items with children. Alternatively, we
could cast the sidebar config to avoid type errors.
<img width="746" height="410" alt="image"
src="https://github.com/user-attachments/assets/4da0385b-e38b-4a58-b83f-19c517c79bac"
/>
<img width="529" height="509" alt="image"
src="https://github.com/user-attachments/assets/f9c00af7-5ed6-40dc-b99c-6ef78ebdd5ba"
/>
Closes #DOC-197
The astro-docs header lacks the CTA buttons (Contact and Login) that are
present in the Next.js version, missing important navigation elements
for user engagement.
Added Contact and Login buttons to the astro-docs header with responsive
design:
- Desktop (≥1280px): CTA buttons visible in header
- Mobile (<1280px): CTA buttons appear in mobile menu at bottom
- Proper element priority to prevent overflow: Theme switcher (always
visible) > CTAs > Social icons
- Visual ordering: CTA buttons, social icons, divider, theme switcher
https://www.loom.com/share/34feb737d11342b19f3ef2df0174a5dc?fromJoinRequest=true
Closes DOC-142
## Current Behavior
We are using the default codeql setup, which refuses to run on PRs from
forks
## Expected Behavior
We use the yml based codeql setup, which should run correctly
> [!IMPORTANT]
> This is only the first half of this effort. After this is merged, PRs
will need to be rebased and the repo will need a settings update from
@FrozenPandaz
Fixes orphaned `fork.js` processes that occur when the parent Rust
PseudoTerminal process terminates faster than the fork process can
complete its cleanup, causing the fork to hang during Node.js socket
cleanup.
- Add deleteOutputPath option to rspack executor schema
- Modify rspack executor to only clean output directory when
deleteOutputPath is not explicitly set to false
- This aligns rspack executor behavior with webpack executor and allows
users to control output cleaning
- Fixes issue where rspack.output.clean configuration was being bypassed
Fixes#32015
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
There is no method for overriding the repo config for Container Registry
and Repository Name per environment.
## Expected Behavior
Allow an environment variable `NX_DOCKER_IMAGE_REF` to be set to modify
the full image reference
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Summary
- Moved git utilities that depend on `ignore-files` crate from
`utils/git.rs` to `watch/git_utils.rs`
- Made `find_git_root` and `collect_workspace_gitignores` functions
private since they're only used internally
- Fixed WASM build failure caused by `ignore-files` dependency not being
available for WASM targets
## Test plan
- [x] Verified `pnpm build:wasm` now succeeds
- [x] Verified regular `nx build nx` still works
- [x] Confirmed watch functionality remains intact
The `ignore-files` crate is conditionally excluded from WASM builds in
Cargo.toml, but the git utilities were trying to import it
unconditionally. Moving these utilities to the watch module (which is
already excluded from WASM) provides a cleaner solution than conditional
compilation.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Import is unused
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Import is removed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request makes minor updates to the GitHub Actions workflow
configuration for Rust toolchain installation. The main change is the
addition of an explicit (empty) `rustflags` parameter to the
`actions-rust-lang/setup-rust-toolchain` steps in both the CI and
publish workflows, and a correction of the `targets` parameter to
`target` in the publish workflow.
* CI workflow updates:
* Added `rustflags: ''` to the Rust toolchain setup steps in
`.github/workflows/ci.yml` to ensure no custom Rust flags are set during
installation.
[[1]](diffhunk://#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR72-R73)
[[2]](diffhunk://#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR277-R278)
* Publish workflow updates:
* Changed `targets` to `target` and added `rustflags: ''` for the Rust
toolchain setup in `.github/workflows/publish.yml` to fix parameter
usage and clarify Rust flags.
## Current Behavior
Task duration estimation includes all task runs regardless of their
status (success, failure, cancelled), which can lead to inaccurate
timing predictions.
## Expected Behavior
Task duration estimation should only consider successful task runs to
provide more accurate timing estimates for future task execution
planning.
## Related Issue(s)
Fixes inaccurate task duration estimation by filtering out
failed/cancelled tasks from the calculation.
## Changes Made
- Modified SQL query in `get_estimated_task_timings` to filter by
`status = 'success'`
- Added database index on `status` column to improve query performance
- Updated both the WHERE clause condition and table schema
initialization
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The import is unused
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The import is removed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request updates the workflow configuration for PR title
validation to simplify the setup and improve caching behavior.
Workflow configuration updates:
* Removed the explicit installation step for `pnpm` using
`pnpm/action-setup`, as this workflow doesn't install packages
* Updated the Node.js setup step to disable package manager caching by
setting `package-manager-cache: false`, which replaces the previous
`cache: 'pnpm'` option.…. as this workflow doesn't install packages
## Current Behavior
When using Atomizer with Playwright, test reports are generated per
atomized tasks, and Nx doesn't offer a way to merge them into a single
report. This requires the user to handle multiple reports for a single
test file or run a manual/custom aggregation.
## Expected Behavior
When using Atomizer with Playwright, Nx offers an extra target that can
be run separately to merge/aggregate the Atomized task reports.
The "blob" reporter must be configured in the Playwright configuration
so that it can be generated and used to merge and generate a unified
report. For that purpose, the Nx Playwright preset includes the blob
reporter by default when in CI. An option called `generateBlobReports`
can be used to opt out.
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvelperez@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
The TUI tasks list uses pagination when it has many tasks that don't fit
in the viewport.
## Expected Behavior
The TUI tasks list should be scrollable and not use pagination.
Additionally, this PR includes a fix so that when a task is selected in
the task list, it's always ensured that the task is visible if resizing
the terminal or when the task is moved due to a different status.
> [!NOTE]
> CI is failing on this PR right now, its expected. We don't currently
adhere to this advice, and its causing issues. This PR should represent
a sync of this, and future protection
## Current Behavior
Previously, we had no automated check to detect when files tracked by
Git were inadvertently listed in `.gitignore`. This could lead to
inconsistent behavior in Nx's caching system.
## Expected Behavior
With this PR, the CI pipeline now includes a check
(`check-git-ignored-tracked-files`) that identifies tracked files that
would be ignored by Git if they weren't already being tracked. This
ensures consistency in Nx's cache hash calculation.
## Why This Matters for Nx
This check is critical for Nx's caching system because:
**Hash Calculation Consistency**: Nx calculates cache hashes based on
the files that Git tracks. When a file is both tracked by Git and listed
in `.gitignore`, it creates an inconsistency where:
- Git includes the file in operations (and Nx hash calculations)
- `.gitignore` indicates the file should be ignored
- This can lead to different hash calculations depending on timing and
environment
**Impact on Cache Performance**:
- **Cache Misses**: Valid cache entries may be missed due to hash
discrepancies
- **Unreliable Builds**: Tasks may not re-run when they should, or may
re-run unnecessarily
- **Cross-Environment Issues**: Different developers or CI environments
may calculate different hashes for identical code
**The Solution**: The new script identifies these problematic files and
provides clear remediation steps:
- For files that shouldn't be tracked: `git rm --cached <file>`
- For files that should be tracked: Update `.gitignore` to be more
specific
This ensures that Nx's intelligent caching system works as designed,
providing fast, reliable builds across the entire development workflow.
## Related Issue(s)
Fixes the inconsistency between Git tracking and ignore patterns that
can affect Nx cache hash calculations.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
Terminal panes in the TUI show focus state through color changes only -
focused panes display the task name in primary foreground color while
unfocused panes use secondary foreground color.
## Expected Behavior
Terminal panes should provide stronger visual feedback when focused by
making the title bold in addition to the existing color change,
consistent with other TUI components like the dependency view.
## Related Issue(s)
This enhancement improves the visual hierarchy and makes it easier for
users to identify which terminal pane currently has focus, especially in
multi-pane layouts.
## Changes Made
- Modified the title styling logic in `TerminalPane::render()` to
conditionally apply `Modifier::BOLD` when the pane is focused
- Added a test to verify the focus state behavior is correctly
implemented
- The change follows the existing pattern used in other components and
maintains backward compatibility
The implementation uses a conditional modifier that applies bold styling
only when `state.is_focused` is true, leaving unfocused panes unchanged.
This provides consistent visual feedback across the TUI while preserving
existing functionality.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: AgentEnder <6933928+AgentEnder@users.noreply.github.com>
This PR updates the the plugin registry links to point to intro since
the API docs aren't useful as a discovery page.
Since we use the API path to build generator, executor, etc. links I
added a new `introPath` property instead.
This PR pins our publish actions to specific SHAs, and removes unused
logic tied to the previous PR release support.
Note: `dtolnay/rust-toolchain` cannot be pinned since will treat the SHA
as the Rust version. e.g. `@abc` will try to install Rust version `abc`,
which is invalid.
ReleaseGroupProcessor already iterates through all release groups, and
sometimes change is anyways not propagated.
## Current Behavior
All release groups are iterated in a way that, if group A depends on
group B:
- A will
[propagate](https://github.com/nrwl/nx/blob/53bb276a39a2de09938ed1161fadbbe92a96e596/packages/nx/src/command-line/release/version/release-group-processor.ts#L832)
changes to B
- B will
[check](https://github.com/nrwl/nx/blob/53bb276a39a2de09938ed1161fadbbe92a96e596/packages/nx/src/command-line/release/version/release-group-processor.ts#L894)
if it should be bumped by its dependencies
This means there is redundant double-checking in the code.
However, propagation doesn't always work. The linked
[snippet](https://github.com/nrwl/nx/blob/53bb276a39a2de09938ed1161fadbbe92a96e596/packages/nx/src/command-line/release/version/release-group-processor.ts#L1626-L1661)
selects a random project of group *A*, and if that project doesn't have
dependencies to projects in group *B*, it doesn't consider *B* as
bumped.
## Expected Behavior
### Ideally
There would be no double loops.
### Otherwise
If there are, they should consider all projects when deciding what to
bump. For instance, with something like:
```typescript
const hasDependencyInChangedGroupV2 = Array.from(releaseGroupFilteredProjects).some(
(project) => {
const dependencies = this.projectGraph.dependencies[project] || [];
return dependencies.some(
(dep) =>
this.getReleaseGroupNameForProject(dep.target) ===
changedDependencyGroup
)
})
```
## Notes
- I know it's a bold move to simply delete code. I wanted to highlight
that, if tests pass, we are either missing tests or we are doing
unnecessary work. I would like to replicate locally with a bit more
confidence, but `jest` tests seem to be flaky
- I would need to pick @JamesHenry 's brain about what's the intention
with this "double" propagation in order to have the full context here
## Current Behavior
If the daemon shuts down, and the user tries to run `nx reset`, an ESRCH
error is thrown since the pid in server-process.json doesn't match up to
a process
## Expected Behavior
We check if the process is alive before terminating it
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Relative urls are not being handled correctly in the
`postcss-cli-resources` Plugins for Webpack and Rspack after switching
to use WHATWG URL in favour of the deprecated `url.parse()` method.
## Expected Behavior
Ensure relatives are handled appropriately by resolving them based on
the context of the current resource being loaded.
## Related Issue(s)
Fixes#32582
## Current Behavior
When external nodes change, the project graph cache is not invalidated.
This can sometimes lead to missing dependencies due to reusing cached
dependencies for nodes that no longer exist.
## Expected Behavior
When external nodes change, the project graph cache should be
invalidated.
## Current Behavior
The README.md file contains a broken link to the CI documentation that
points to `/ci/intro`, which no longer exists.
## Expected Behavior
The README.md file should contain the correct link to the CI
documentation pointing to `/ci/getting-started/intro`.
## Related Issue(s)
Fixes#32549
Credits to @MeAkib for originally identifying and addressing this issue.
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 Share your feedback on Copilot coding agent for the chance to win a
$200 gift card! Click
[here](https://survey3.medallia.com/?EAHeSx-AP01bZqG0Ld9QLQ) to start
the survey.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: FrozenPandaz <8104246+FrozenPandaz@users.noreply.github.com>
## Current Behavior
If an invalid bundler is provided to `create-nx-workspace` for the
`angular-monorepo` preset, it defaults to `webpack`.
## Expected Behavior
Invalid bundler option should default to the default provided within in
the angular app generator
## Current Behavior
The `Vite`'s `resolveConfig` always adds default server settings to the
config:
```
server: {
preTransformRequests: true,
sourcemapIgnoreList: [Function: isInNodeModules$1],
middlewareMode: false,
fs: {
strict: true,
allow: [Array],
deny: [Array],
cachedChecks: undefined
}
},
```
This leads to `libs` always ending up with serve targets even if we
don't define `serve` configuration
## Expected Behavior
The serve targets should only exist if we explicitly set port or host.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Migrate gradle project graph plugin to 0.1.7
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Reverts nrwl/nx#32416
Picking up tests via test name is fragile and breaks workspaces where
nx-expected task names do not have exact named counterparts.
…#32435)"
This reverts commit 2c678a1d51.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This causes a regression in Nx Cloud
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is no regression in Nx Cloud.. gotta find a different way.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes#32526
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`--help` behaviour is defined in the Nx alias entrypoints, and doesn't
show the correct output:
```
npx nx start-ci-run --help
nx start-ci-run [options]
Starts a new CI run for distributed task execution. This command is an alias for [`nx-cloud start-ci-run`](/ci/reference/nx-cloud-cli#npx-nxcloud-start-ci-run).
Options:
--help Show help [boolean]
--version Show version number [boolean]
--verbose Prints additional information about the commands (e.g., stack traces).
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When running `npx nx start-ci-run --help` the help from the file in the
NxCloud repo should be displayed:
```
npx nx start-ci-run --help
Usage: npx nx-cloud start-ci-run [options]
Starts an Nx Cloud CI Pipeline Execution and configures distribution.
Options:
--distribute-on <config> Configure how to distribute with Nx Agents. Accepts:
- "<count> <launchTemplate>" (e.g., "8 linux-medium-js")
- path to a .yaml/.yml file for dynamic changesets
- "manual" to disable the warning for legacy DTE setups
--stop-agents-after <targets> Comma-separated targets that signal agents can stop.
Include configuration when needed, e.g., "build:locale-en".
--require-explicit-completion Require explicitly completing the CI run with
"npx nx-cloud complete-ci-run".
--stop-agents-on-failure Stop all agents when a command fails (default: true).
--with-env-vars <CSV> Extra env vars to forward to agents in addition to NX_* (e.g., "VAR1,VAR2").
--use-dte-by-default Use this to disable auto-distribution of Nx tasks (default: true)
--no-distribution Disable distribution for this run
--assignment-rules <file> YAML file with assignment rules (for manual DTE only, see docs)
--fix-tasks <csv> Task names to auto fix
--force Force start a CIPE even when a CI environment is not detected.
--help, -h Show this help and exit.
Notes:
- Do not run this command locally. If run accidentally, clean up with "npx nx-cloud cleanup".
- For legacy manual DTE setups, you can pass "--distribute-on=manual".
Examples:
npx nx-cloud start-ci-run --distribute-on="8 linux-medium-js" --stop-agents-after=lint,test,build
npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yaml" --stop-agents-after=e2e
npx nx-cloud start-ci-run --distribute-on="manual" --stop-agents-after=e2e
npx nx affected -t lint,test,build
Docs:
https://nx.dev/ci/reference/nx-cloud-cli#npx-nxcloud-startcirunhttps://nx.dev/ci/reference/assignment-rules
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #CLOUD-3580
## Current Behavior
The daemon process check in `startServer()` was running continuously
without any interval, causing excessive CPU usage. The `setInterval()`
call was missing the timing parameter, making it run as fast as
possible.
## Expected Behavior
With this change, the daemon process check runs every 20ms,
significantly reducing CPU overhead while maintaining responsive daemon
process monitoring.
## Related Issue(s)
This change optimizes CPU usage in the Nx daemon server by preventing a
continuous polling loop.
## Changes Made
- Added `20` as the interval parameter to the `setInterval()` call in
`packages/nx/src/daemon/server/server.ts:572`
- The daemon process ID check now runs every 20ms instead of
continuously
- Maintains the same functionality while dramatically reducing CPU
consumption
## Current Behavior
The `@nx/devkit` package has `nx` as a direct dependency.
## Expected Behavior
The `@nx/devkit` package should not have `nx` as a direct dependency.
Update `postinstall` script to only be needed for Angular versions lower
than v20.2.0, for which the relevant entry points are patched to expose
needed functionality.
This reverts commit f3bc2b207a.
# Testing
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Many CI runs are running out of memory causing Agents to get OOM killed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This change is reverted and CI runs.. only sometimes run out memory
😅
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cargo deps get fetched on first usage, which is when graph computes +
cargo metadata runs under @monodon/rust
## Expected Behavior
Cargo deps are fetched separately.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, the flaky task detection considers ALL tasks that have mixed
success/failure results as "flaky", including non-cacheable tasks like
development servers (`nx serve`) which are expected to have inconsistent
behavior.
## Expected Behavior
With this PR, only explicitly cacheable tasks (`cache: true`) are
considered for flaky detection. Non-cacheable tasks with mixed results
will no longer trigger flaky warnings.
## Related Issue(s)
This addresses the issue where non-cacheable tasks like development
servers were incorrectly being flagged as flaky, creating noise in the
flaky task detection system.
## Implementation Details
### Changes Made
1. **Database Schema Updates**
- Added `cache` column to `task_details` table
- Updated `HashedTask` struct to include `cache: Option<bool>` field
2. **Query Logic Enhancement**
- Modified flaky task detection query to JOIN with `task_details` table
- Added filter condition `AND task_details.cache = 1` to exclude
non-cacheable tasks
- Added clear comments explaining the query logic
3. **Data Flow Updates**
- Updated TypeScript code in `hash-task.ts` to pass `cache` information
from Task objects to native layer
- Both batch and individual task detail recording now include cache
property
4. **Comprehensive Testing**
- Updated existing tests to include cache information
- Added new test "should not consider non-cacheable tasks as flaky" that
verifies:
- Tasks with `cache: false` are NOT marked as flaky
- Tasks with `cache: undefined` are NOT marked as flaky
- Only explicitly cacheable tasks with mixed results are marked as flaky
### Test Results
- **Rust tests**: 202 passed ✅
- **TypeScript tests**: 4 passed ✅ (all NxTaskHistory tests)
## Benefits
- **Improved Accuracy**: Flaky detection now focuses only on tasks where
consistency is expected
- **Reduced Noise**: Development servers and other non-cacheable tasks
no longer create false positives
- **Better Developer Experience**: More relevant and actionable flaky
task warnings
---------
Co-authored-by: Claude <noreply@anthropic.com>
When NEXT_PUBLIC_ASTRO_URL is set and nx-dev serves docs through Astro,
certain URLs cause infinite redirect loops due to self-referencing
redirect rules. Specifically:
- /docs/guides/nx-cloud/setup-ci redirected to itself
- /docs/reference/devkit redirected to itself
There is also a missing redirect from `/docs` to
`/docs/getting-started/intro` in the Next.js app, leading to a
client-side redirect from Astro website. Plus, `/getting-started/:path*`
was being redirected to the intro page instead of the the more specific
pages.
URLs should either redirect to their proper destinations or serve
content without infinite loops. Removed the two self-referencing
redirect rules that were causing the problem.
`/docs` redirects on server-side not client-side, and `/getting-started`
URLs are redirected to specific pages e.g.
/getting-started/start-new-project ->
/docs/getting-started/start-new-project
Fixes DOC-196
## Current Behavior
CodeQL analysis fails for Java projects in Gradle workspaces because the
required build tasks (clean and testClasses) are not available for
included builds.
## Expected Behavior
CodeQL can successfully analyze Java code by having access to the
necessary Gradle build tasks for all included builds in the workspace.
## Related Issue(s)
This change ensures CodeQL compatibility for Java projects by
dynamically adding clean and testClasses tasks to all included builds.
Fixes #
## Current Behavior
Scrolling via trackpad is way too fast in comparison with scrolling via
arrow keys / mouse wheel
## Expected Behavior
Scrolling via trackpad is analogous to mouse / arrow keys. Additionally,
home + end can jump to the beginning / end of terminal outputs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Themes are not picked up correctly from Nx Console
<img width="1128" height="637" alt="image"
src="https://github.com/user-attachments/assets/8dad4935-6d98-49f3-95a9-34f4880e2551"
/>
## Expected Behavior
Theme is applied
<img width="856" height="543" alt="image"
src="https://github.com/user-attachments/assets/aa7e21ae-a243-4399-b351-a85be339fd4b"
/>
### Changes
- Fix builtin module test to avoid duplicate `node:` prefixes
### Testing
- Update ci pipeline to use node v24
- Update agents to use node v24
### MISC
Requires: https://github.com/nrwl/nx/pull/32223
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
`neverConnectToCloud` can be confusing due to 2 aspects
1. the setup of nx cloud is named via the command `nx connect`
2. network connectsion to external services i.e. nx cloud
`neverConnectToCloud` is meant to control 1 and not 2
this means if you have previously connected to nx cloud and have an
access token configures. nx cloud will still be used since you're not
trying to "setup up nx cloud" aka `nx connect` but are instead using nx
cloud (i.e. making network requests to nx cloud)
Instead using `--no-cloud` or `NX_NO_CLOUD=true` would be how you
prevent network access to nx cloud
Fixes: DOC-194
## Current Behavior
The `@nx/js:typescript-sync` wrongly identifies stale project
references.
## Expected Behavior
The `@nx/js:typescript-sync` should correctly identify stale project
references.
## Current Behavior
The Claude Code workflow is currently enabled and responds to @claude
mentions in issues and PRs.
## Expected Behavior
The Claude Code workflow should be disabled by removing the workflow
file.
## Related Issue(s)
This change disables the automated Claude responses on the repository.
## Current Behavior
If another plugin, or project/package.json exists in the repo that has a
`serve-static` target, running `nx add @nx/rpsack` will fail.
The `@nx/rspack:init` generator does not have any alternative names for
`serve-static` causing conflicts.
## Expected Behavior
The `init` generator should provide more options for the `serve-static`
target such that the plugin can be added without error.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- fix some remnants on old navigation pattern for task graph in PDV
- fix an issue where UI only has `target` and `project` but backend
returns TaskGraph with default configuration
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
In a devcontainer environment, the tmp file we write to when the user
doesn't want to install nx console isn't saved. This means that every
time they start
## Expected Behavior
Devcontainers are a special case, we can skip asking the user if we
detect we are in one.
## Description
With `@module-federation/enhanced@0.18`, dynamic federation changed. The
`init` method is now deprecated and setup is different dependent on
whether the MFP Build Plugin is used. For us, it is, requiring a change
to how we initialise MF.
This also requires an update to Rspack also to `1.5.0`.
`NxModuleFederationDevServerPlugin` currently ignores static dynamic
remotes and does not start them automatically locally.
## Changes
- Replace usage of `init` with `registerRemotes`
- Support Rspack 1.5
- Fix issue with `NxModuleFederationDevServerPlugin` ignoring static
dynamic remotes during dev locally
- Remove restriction on shape of the `module-federation.manifest.json`
## Related Issues
Fixes#32542
## Current Behavior
- Sidebar active link uses default text color instead of accent color
(DOC-143)
- Breadcrumb current page text is barely visible with opacity 0.2
(DOC-141)
- TOC lacks proper spacing between items and has no background styling
(DOC-174)
- TOC hard to parse (DOC-138)
## Expected Behavior
- Sidebar active link uses accent color for better visibility
- Breadcrumb current page has proper text color and visibility
- Deepdive callout paragraphs have compact 12px spacing
- TOC has proper spacing and background styling with dark mode support
<img width="1450" height="1357" alt="Screenshot 2025-08-28 at 1 58
10 PM"
src="https://github.com/user-attachments/assets/b0414e22-ed6c-46ac-b66f-79e80fb868a5"
/>
<img width="1331" height="1030" alt="image"
src="https://github.com/user-attachments/assets/d0a7341e-f389-4357-9028-9def94a23b4f"
/>
<img width="716" height="1187" alt="image"
src="https://github.com/user-attachments/assets/fe4617fa-4c45-4748-aced-a0e513f50965"
/>
## Related Issue(s)
Fixes DOC-143
Fixes DOC-141
Fixes DOC-138
Fixes DOC-174
also fixed issue where links contained 'CI Features' instead of
'ci-features' in URL breaking the markdown to html link rendering
Fixes: DOC-181
Fixes: DOC-186
## Current Behavior
Nx for Gradle plugin is at version 0.1.6
## Expected Behavior
Bumped up the version for the Nx for Gradle plugin, and added necessary
migrations to `nx migrate` the plugin to the newest version.
The Next.js documentation site has no redirect rules to guide users to
the new Astro documentation structure, resulting in broken links and 404
errors when users try to access the old URLs.
All legacy documentation URLs from the Next.js site should redirect to
their appropriate locations in the new Astro documentation site,
following a consistent mapping strategy.
This commit implements the following redirect mapping strategy:
1. **API References Consolidation**: Individual generator and executor
pages are redirected to their parent listing pages since the new docs
don't have individual pages:
- `/api/generators/<specific>` → `/generators`
- `/api/executors/<specific>` → `/executors`
- `/api/migrations` → `/migrations`
2. **CI Content Reorganization**: CI-related content has been
restructured into three main areas:
- Platform-specific CI setup guides consolidated into
`/docs/guides/nx-cloud/setup-ci`
- DTE setup for all platforms consolidated into
`/docs/guides/nx-cloud/manual-dte`
- Security topics moved to `/docs/concepts/ci-concepts/cache-security`
3. **URL Convention Normalization**:
- All redirect targets are prefixed with `/docs`
- Spaces in paths converted to hyphens (e.g., "Nx Cloud" → "nx-cloud")
- Special cases like `convert-to-inferred` redirect to
`/docs/guides/tasks-caching/convert-to-inferred`
4. **Content Consolidation**:
- Technologies without dedicated executor/generator pages (Java, Vue,
Node) redirect to their main/intro technology page
- Deprecated content marked with TODO comments for future migration
decisions
All redirect targets have been verified to exist on canary.nx.dev.
There are some TODOs for missing content that we need to follow-up on,
or check if they are addressed in other PRs.
Fixes DOC-154
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
There is currently no way to pass `templateParameters` to the
`HtmlRspackPlugin`.
## Expected Behavior
Add `templateParameters` to the NxAppRspackPluginOptions and pass
through to `HtmlRspackPlugin`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
We use a regular npm publish flow using access tokens and provenance.
## Expected Behavior
We use https://docs.npmjs.com/trusted-publishers which is more secure
and has provenance configured automatically.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
add link verification script that
- gets all links in the build html files
- compares all links to sitemap links
- fails if there is a link not in the sitemap to prevent creating broken
links
NOTE:
some generated api docs still ref the old URLS (i.e. non /docs prefixed)
which we'll need to change either in this PR or in a quick follow up PR
before releasing as to not break any doc changes that have to be shipped
before full astro port
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
The logo in the documentation header links to the docs intro page
(/docs/getting-started/intro) instead of the main Nx homepage.
The logo should link to https://nx.dev to allow users to easily navigate
back to the main Nx homepage from the documentation.
Fixes DOC-167
Demo: https://www.loom.com/share/71fb2b78d40b4730a073fdfe4a3b66c2
The breadcrumbs component was showing 'Docs' as a clickable segment
which led to a 404 since there's no page at /docs. This filters out the
'docs' segment from the UI while keeping all href links with the /docs/
prefix.
Fixes DOC-165
Demo: https://www.loom.com/share/33aa13e515cf4213a64ecbf29200f3e1
## Current Behavior
When merging project config its easy to return `''` for the root
project's root, but we expect `'.'`.
## Expected Behavior
We normalize this to prevent plugin author's from making an easy mistake
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The React Native e2e tests contain variable naming conflicts and
inconsistent error handling in the process cleanup sections:
- Variables named `process` shadow the global Node.js `process` object
- Inconsistent error handling patterns in process cleanup logic
- Some cleanup operations attempt to kill processes that may not exist
## Expected Behavior
The React Native e2e tests should have:
- Clear variable names that don't shadow global objects
- Consistent error handling patterns throughout all test cleanup
sections
- Robust process cleanup that handles cases where processes may not be
running
### Changes Made
1. **Variable Naming**: Renamed `process` variables to `childProcess` to
avoid shadowing the global Node.js `process` object
2. **Error Handling**: Added consistent try-catch blocks around all
process cleanup operations
3. **Process Cleanup**: Simplified cleanup logic by passing `undefined`
for process ID when the process reference is not available, allowing
`killProcessAndPorts` to handle port cleanup appropriately
This fixes issues that could occur in nightly builds where process
cleanup wasn't being handled consistently, potentially leading to
hanging processes or ports.
Add docs explaining docker version schemes and the default option
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we attempt to create a new cloud-connected workspace with
`create-nx-workspace`, we read `package.json` from the incorrect
location. This means we are not able to retrieve the workspace name
correctly and results in the newly created cloud workspace having the
fallback name `my-workspace`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When we try to read `package.json` we pass in in the correct directory
in which we expect to find the file. This allows us to correctly parse
the json file and retrieve the correct workspace name.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
There was a recent change to `TaskGraphClientResponse` where we drop the
multiple `taskGraphs` and replace with single `taskGraph`. Goal was to
improve the performance for `nx graph` task graph in general and support
multiple targets. Docs pages that render task graph were not updated to
adhere to the new single task graph model. This PR fixes it.
This PR also adjusts the project graph to handle missing props more
gracefully.
## Current Behavior
We retry NX_VERSION_CHANGED errors
## Expected Behavior
We retry NX_VERSION_CHANGED and LOCK_FILES_CHANGED errors
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
- Adds support for `incompatibleWith` field in `packageJsonUpdates` to
prevent updates from running when specified packages are present
- Provides the opposite functionality of the existing `requires` field
- Implements logic to skip packageJsonUpdates when any incompatible
packages are found
## Changes Made
### Core Implementation
- Added `incompatibleWith?: Record<string, string>` to
`PackageJsonUpdates` type
- Implemented `areIncompatiblePackagesPresent()` method with semver
checking
- Updated migration logic to check for both requirements and
incompatibilities
- Added comprehensive tests for both positive and negative scenarios
### Vite 7 Compatibility Fix
- Added `incompatibleWith: { "@remix-run/dev": "*" }` to vite 7
packageJsonUpdate
- Prevents vite 7 update from running when @remix-run/dev is present
## Usage Example
```json
{
"packageJsonUpdates": {
"17.0.0": {
"version": "17.0.0",
"packages": {
"new-package": { "version": "^17.0.0" }
},
"incompatibleWith": {
"old-package": "*",
"conflicting-package": "<2.0.0"
}
}
}
}
```
The update will be skipped if either `old-package` (any version) or
`conflicting-package` (version < 2.0.0) is present in the workspace.
## Test Plan
- [x] Added unit tests covering both positive and negative scenarios
- [x] Verified existing tests still pass
- [x] Applied to real-world case (vite 7 + Remix incompatibility)
- [ ] Test on workspace with @remix-run/dev to verify vite 7 is skipped
- [ ] Test on workspace without @remix-run/dev to verify vite 7 is
applied
## Type of Change
- [x] New feature (non-breaking change which adds functionality)
- [x] Bug fix (non-breaking change which fixes an issue)
## Notes
This feature enables better control over migration paths and prevents
package conflicts during nx migrate operations. The vite 7 + Remix case
is a concrete example where this prevents incompatible package
combinations.
## Current Behavior
Angular v20.2 is not supported.
## Expected Behavior
Angular v20.2 is supported.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
… (#32458)"
This reverts commit c916349179.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This workflow may have a vulnerability.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We'll investigate it before re-introducing it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The `ProjectMetadata` type does not allow for additional properties,
despite the schema having `"additionalProperties": true`. This prevents
folks who are extending Nx and adding details there from doing so in a
way that does not result it type errors.
## Expected Behavior
Userland code extending Nx should be able to add to ProjectMetadata
without running into type errors.
This PR fixes issues with connecting new Astro docs with the `/docs`
rewrite rule on Next.js side.
https://www.loom.com/share/150deedd25a24259b0aa8cb141cec1d3
The redirects now go through Netlify since it's a lot more flexible, and
we need to do that later when porting Next.js to Netlify, etc.
## Not done / follow-up:
Other pages and UI components that use `<Link>` to a doc page need to
check against `NEXT_PUBLIC_ASTRO_URL` and make sure to use the updated
`/docs` path for that. I only handled the homepage for now just to show
it working.
update robots.txt to point to the sitemap-index.xml so crawlers
shouldn't actually look at sitemap.xml directly anyway
but also included sitemap.xml to match that of the sitemap-index.xml
content for historical reasons in case anything still references that
older sitemap
## Current Behavior
There is currently no overview page for the Docker plugin, just
documentation on the using it with Nx Release.
## Expected Behavior
Add an overview page for the Docker plugin
## Current Behavior
The `@nx/js:typescript-sync` generator does not detect duplicate project
references.
## Expected Behavior
The `@nx/js:typescript-sync` generator should detect duplicate project
references.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
We had hardcoded test target names which meant that users who specify
custom test suites would not get their atomized tests correctly picked
up.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Allow users to configure the `testTargetName` field in their `nx.json`
and correctly identify which tasks to atomize.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`expo export` expects the `--output-dir` to be within the project
directory.
When using Nx w/o Inference Plugins, we generate an export target that
attempts to place the output directory outside the project directory.
## Expected Behavior
Ensure that the output directory is within the project directory.
- **docs(nx-dev): rename directory to match existing routes**
- **docs(nx-dev): use route middleware to populate sidebar w/ auto
generate command docs**
Unlike the technology section w/convention based file structure driving
the content that is auto generated. the devkit/nx-cli/cnw pages do not
have a reference file structure to generate from. so we leverage the
astro content collections to pull the desired pages. only issues is this
has to be at "run time" and not at setup time. which means we have to
inject these routes via the route middleware.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we migrate version catalogs to use new versions of the gradle
project graph plugin, we lose the original formatting of the version
catalogue file.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We use AST parsing on the version catalogue so that we can make version
edits on the specific portion of the file.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When detecting whether a workspace is set up with pnpm workspaces, we
only check for the existence of the `pnpm-workspace.yaml` file. While
most of the time that's enough, it's not entirely correct because that
file can exist without a `packages` entry and solely contain other
settings.
## Expected Behavior
When detecting whether a workspace is set up with pnpm workspaces, we
should check for the existence of the `pnpm-workspace.yaml` file and the
`packages` entry.
This pull request updates the `mcp.ts` command handler to improve
compatibility with multiple package managers and enhance argument
handling for command execution. The changes ensure that the correct
flags are used for each package manager and that commands with spaces
are executed properly.
* Adjusted arguments passed to the `dlx` command for `npm`, `yarn`, and
`bun` to use their respective flags (`-y`, `--quiet`, `--silent`),
ensuring consistent behavior across different package managers.
* Improved handling of `dlx` commands that may contain spaces (e.g.,
`pnpm dlx`) by splitting the command and passing arguments appropriately
to `spawnSync`.
* Updated both `mcpHandler` and `showHelp` functions to use the new
argument handling logic for executing commands and displaying help
output.
Remove unnecessary file.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #DOC-157
## Current Behavior
When creating a workspace, some pnpm-specific settings are written to an
`.npmrc` file in the workspace root. Npm warns about those unknown
config properties.
## Expected Behavior
The pnpm-specific settings should be written to the
`pnpm-worskpace.yaml` file for pnpm versions that support it (10.6.0+).
## Current Behavior
The e2e tests in the repo can sometimes fail due to Cypress and/or
Playwright version mismatches between the version in the repo lockfile
and the version that gets installed in workspaces generated when running
the e2e tests.
The e2e tests rely on the browsers installed by the agent, but the agent
installs the browser for the version the repo lockfile has, while the
e2e tests need the version that gets generated in the workspaces.
## Expected Behavior
The e2e tests in the repo should not fail due to Cypress and/or
Playwright version mismatches. It's unreliable to rely on the browsers
installed by the agent due to potential version mismatches.
## Current Behavior
When daemon is not running, its pid is null... We don't handle this in
`stop`
## Expected Behavior
We handle this in stop.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, there is no automated check to ensure that PR titles follow
our conventional commit format. This can lead to inconsistent PR titles
that don't match our commit conventions.
## Expected Behavior
With this change, all PR titles will be automatically validated against
our git commit rules when a PR is:
- Opened
- Edited
- Synchronized
- Reopened
The check uses the existing `scripts/commit-lint.js` script to validate
PR titles, ensuring they follow the same format as our commit messages
(e.g., `feat(scope): description`, `fix(scope): description`, etc.).
## Related Issue(s)
This was requested to improve PR quality and consistency across the
repository.
## Implementation Details
- Added a new GitHub Actions workflow:
`.github/workflows/pr-title-validation.yml`
- The workflow writes the PR title and body to a temporary file in the
format specified
- Runs `node ./scripts/commit-lint.js` on the file to validate the PR
title
- The check will fail if the PR title doesn't match our conventional
commit format
- The workflow only runs for the `nrwl` repository owner (consistent
with other workflows)
## Test Plan
- [x] Tested locally with valid PR titles (e.g., `feat(core): add new
feature`)
- [x] Tested locally with invalid PR titles (confirmed validation
failure)
- [x] Tested with breaking change notation (`fix(core)!: breaking
change`)
- [ ] Test on actual PR once merged
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
This PR updates the base href for the new astro docs to match how we
plan to launch it.
The assets including `_astro/` and `.netlify/` are rewritten correctly
now, as well as stripping trailing slash to match what we have in
Next.js.
## Current Behavior
getProjects(Tree) from project-configuration.ts does not return projects
created in generators when called from generator callbacks. This happens
because findCreatedProjectFiles only looks for changes with type ===
'CREATE', but during callbacks, the tree has already been flushed to
disk, so newly created project files are marked as 'UPDATE' instead of
'CREATE'.
## Expected Behavior
getProjects(Tree) should return all projects, including those created
during the current generator run, even when called from generator
callbacks.
## Changes Made
- Modified findCreatedProjectFiles() to include both CREATE and UPDATE
changes
- Added deduplication using Set to prevent duplicate project files
- Added comprehensive test coverage for the callback scenario
## Related Issue(s)
Fixes#29852🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
## Current Behavior
Angular with Esbuild does not error when server bundles violate the
budgets.
Currently, Angular Rspack will error when server bundles violate the
budgets.
## Expected Behavior
Match the behaviour with Angular with Esbuild in Angular Rspack.
Do not error when server bundles violate the budgets.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Summary
Fixed bug where `alwaysAddToPackageJson: "devDependencies"` was ignored
and always defaulted to "dependencies".
- Updated ternary logic in migrate.ts to properly handle string values
- Added comprehensive test case for string values
- Maintains backward compatibility with boolean values
## Test Plan
- [x] Added test case covering both "dependencies" and "devDependencies"
string values
- [x] Verified existing tests still pass
- [x] Confirmed backward compatibility with boolean values
Fixes#30586
Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Craigory Coppola <AgentEnder@users.noreply.github.com>
Fixes path handling issue in @nx/plugin generators where the last folder
name in the path was being ignored.
The executor and generator generators were not creating subdirectories
as expected when provided with directory paths. This fix detects when
the path looks like a directory path and adjusts the directory to
include the artifact name as a subdirectory.
**Changes:**
- Modified normalizeOptions in both executor and generator generators to
detect directory paths
- Added logic to create subdirectories when the path segment matches the
artifact name
- Added comprehensive tests to verify the fix works correctly
- Ensures backward compatibility with existing file path usage
Fixes#31803Fixes#31776
Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Craigory Coppola <AgentEnder@users.noreply.github.com>
## Current Behavior
When running commands in parallel with `nx:run-commands`, if a command
fails, others are not stopped, and the task continues until all commands
finish. This means that if a long-running command is running, it won't
be stopped when other commands have already failed.
## Expected Behavior
`nx:run-commands` should fail fast. In a parallel execution, the rest of
the running commands should be terminated if a command fails.
## Related Issue(s)
Fixes#28477
## Current Behavior
Previously, we needed to rely on `virtualRuntimeEntry` to allow builds
between caching to operate successfully.
## Expected Behavior
In more recent version of `@module-federation/enhanced` this is no
longer the case.
By setting this option, it is now inflating the size of the bundles
produced by Webpack and Rspack
As it is no longer a strict requirement, remove it.
Users can still set it manually if they run into issues
## Related Issue(s)
Fixes#31831Fixes#32404
## Current Behavior
We use dark gray for a secondary fg color, but when dimmed and in
certain terminals its not easy to read for light mode
## Expected Behavior
We've struggled with getting this pallet right for a while, while we
continue working on it we'll just set it to all black
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When the Nx daemon detects a version mismatch and returns
`NX_VERSION_CHANGED`, the client shuts down the connection but doesn't
retry the current message that triggered the error. This causes the
current operation to fail silently.
## Expected Behavior
When `NX_VERSION_CHANGED` is received, the client should:
1. Shut down the current connection
2. Automatically retry the message that triggered the version change
error
3. Continue with the operation transparently
## Related Issue(s)
This improves daemon resilience when Nx versions change during
development.
Fixes#29446
## Changes Made
- Modified `packages/nx/src/daemon/client/client.ts` to track the last
sent message and retry it when `NX_VERSION_CHANGED` is received
- Added `retryLastMessage()` method to `PromisedBasedQueue` to support
message retry
- Added proper logging for version change detection in
`shutdown-utils.ts`
The fix ensures that operations don't fail when the daemon detects a
version change, improving the developer experience.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
The Claude GitHub Actions workflow includes xiongemi, ndcunningham,
isaacplmann, and mandarini in the allowed users list.
## Expected Behavior
These users should be removed from the allowed users list for Claude
GitHub Actions workflow permissions.
## Related Issue(s)
<!-- No specific issue number -->
Fixes configuration by removing users from allowed list.
## Current Behavior
We error if a non-parallel task has a continuous dependency, but when
running a command that contains a task that depends on a continuous task
which itself is marked as non-parallel we do not error. This results in
the command hanging on the continuous non-parallel task, instead of
running the parent task as well.
## Expected Behavior
We error in both situations.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Signed-off-by: AgentEnder <craigorycoppola@gmail.com>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Currently, the NX Console installation prompt can appear in
non-interactive environments like CI/CD pipelines, causing processes to
hang indefinitely waiting for user input.
## Expected Behavior
The NX Console installation prompt should only appear in TTY
(interactive terminal) environments where users can actually respond to
the prompt.
## Related Issue(s)
This change adds a TTY check (`process.stdout.isTTY`) before showing the
NX Console installation prompt, preventing hanging in automated
environments while preserving the interactive experience for developers
working in terminals.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Certificates in the local trust store are ignored, because reqwest
(rustls) is using webpki-roots.
## Expected Behavior
Certificates from the local trust store are trusted.
This PR solves this the same way as turborepo - by turning on the
`rustls-tls-native-roots` feature in reqwest.
This PR re-enables the escaped markdoc tags. Note that graph and PDV
tags that pointed to an external JSON file is changed to inline the JSON
instead so we don't need that extra file loading logic.
## Current Behavior
Multiple pages in the Astro documentation site display broken components
due to:
- Escaped template blocks (\{% ... %\}) that prevent proper rendering
- Component name mismatches using hyphens instead of underscores
- Missing side-by-side component causing "Undefined tag" errors
- Graph components showing "Could not parse JSON" due to markdown code
blocks
- External JSON file references not being inlined properly
## Expected Behavior
All documentation pages render correctly with:
- Proper template block syntax without backslash escaping
- Component names matching markdoc.config.mjs registrations
- All required components available and properly configured
- Graph and project_details components displaying JSON data inline
- All Markdoc components functioning as intended
<img width="824" height="849" alt="Screenshot 2025-08-20 at 10 55 53 AM"
src="https://github.com/user-attachments/assets/3d94e2a8-c971-49a6-a7aa-95ac40a8c86b"
/>
<img width="797" height="627" alt="Screenshot 2025-08-20 at 12 33 19 PM"
src="https://github.com/user-attachments/assets/1352e8bd-f5df-4db0-8679-a1627b2b6911"
/>
Also add back the `side_by_side` tag for now since it's used in a couple
of places:
<img width="797" height="627" alt="Screenshot 2025-08-20 at 12 33 19 PM"
src="https://github.com/user-attachments/assets/4ecaf12b-592f-4885-88d8-bc25e4c7d087"
/>
<img width="775" height="1059" alt="Screenshot 2025-08-20 at 12 55
23 PM"
src="https://github.com/user-attachments/assets/0cc32bd4-e2f0-41b9-b2a6-29edabccae0e"
/>
## Related Issue(s)
Fixes DOC-148
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Code snippets use custom Nx attributes (fileName and highlightLines)
that don't display properly in Astro Starlight
## Expected Behavior
Code snippets use Starlight's native format with filenames shown as
comments and highlights using curly brace syntax
<img width="980" height="710" alt="Screenshot 2025-08-20 at 10 58 07 AM"
src="https://github.com/user-attachments/assets/38c6629f-8be3-4934-b839-ae5ece980f36"
/>
## Related Issue(s)
Fixes DOC-137
This PR prepares for the canary environment where we can use `/docs/*`
for the new astro docs while keeping the same domain.
## Current Behavior
The nx-dev Next.js app doesn't have any rewrite rules for the `/docs`
path, making it unable to proxy requests to the Astro documentation
site.
## Expected Behavior
When the `NEXT_PUBLIC_ASTRO_URL` environment variable is set, the
Next.js app configures rewrites for `/docs` and `/docs/*` paths to proxy
to the Astro documentation site. If the environment variable is not set,
no rewrites are configured, maintaining backward compatibility.
## Related Issue(s)
Fixes DOC-134
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The Astro/Starlight documentation pages display duplicate titles because
both the frontmatter title and an h1 heading in the content are being
rendered. This creates a poor user experience with the same title
appearing twice at the top of each page.
## Expected Behavior
Each documentation page should display its title only once. Starlight
automatically renders the frontmatter title as the page's h1, so there
should be no h1 headings in the content body. The frontmatter title
should be the single source of truth for the page title, with optional
sidebar labels for customization.
## Related Issue(s)
Fixes DOC-125
## Current Behavior
Some test expectations fail in macOS due to some paths not being
normalized in the assertions.
## Expected Behavior
Tests should pass.
## Current Behavior
The `@nx/js/typescript` plugin incorrectly infers that all projects are
libraries. This is not correct, because apps also have tsconfig files
which would be processed and targets will be inferred for them (e.g.
`typecheck`). Depending on the order of the plugin execution, it can
result in projects having the wrong type.
## Expected Behavior
The `@nx/js/typescript` plugin should not infer the project type. The
project type will be correctly derived later, when the project graph
nodes are normalized.
## Current Behavior
Nx release now updates peer dependency versions, which is great... but
it broke the peer dep range in the published version of @nx/devkit.
## Expected Behavior
@nx/devkit maintains a version range of +/- 1 major version of nx. We
will fix release soon.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31801 (already fixed, but comments on this highlighted the
problem)
## Summary
Fixes an issue where dummy tasks (created when dependency projects don't
have required targets) would generate non-deterministic dependency
structures based on target processing order.
## Current Behavior
When creating task graphs with targets in different orders, dummy tasks
would inherit different configurations from different source tasks,
leading to inconsistent task graphs.
For example:
- Processing `[test, lint]` vs `[lint, test]` would create the same
dummy task IDs
- But the dummy tasks would have different dependency structures
depending on which task created them first
## Expected Behavior
Task graphs should be deterministic regardless of target processing
order. The same dummy task should always have the same dependencies.
## Related Issue(s)
This addresses the issue described where task graph generation was
non-deterministic due to dummy task dependency variations.
## Test Plan
- [x] Added unit test: "should create deterministic task graphs
regardless of target order"
- [x] Verified existing tests continue to pass
- [x] Test validates task graphs are identical when targets are
processed in different orders
🤖 Generated with [Claude Code](https://claude.ai/code)
## Current Behavior
The sidebar in the Astro docs has two issues:
1. Introduction pages are not appearing first in technology sections -
they appear after Generators, Executors, and Migrations
2. Nested groups (like Guides folders and sub-technology sections) are
expanded by default, making the sidebar difficult to navigate
## Expected Behavior
With this PR:
1. Technology sections now display items in the correct order:
- Introduction (if exists)
- Guides (if exists)
- Generators (if exists)
- Executors (if exists)
- Migrations (if exists)
- Everything else (other static files and nested sections)
2. All nested groups are collapsed by default for better navigation:
- Guides folders are collapsed
- Sub-technology sections (Next, Remix, Express, Nest, etc.) are
collapsed
- Any auto-generated folder groups are collapsed
<img width="789" height="484" alt="Screenshot 2025-08-19 at 2 30 36 PM"
src="https://github.com/user-attachments/assets/0562693c-b17a-4562-8f58-a0fba50fc6fe"
/>
## Related Issue(s)
DOC-122 (Linear)
- Expanded inputs with placeholder to prevent content shifting
- Bump `@nx/graph` to fix task graph missing transitive deps issue
- Disabling cache will throw runtime errors for expanded inputs
operation so putting in a couple of safe fallbacks when things are
undefined
## Current Behavior
The PostCSS CLI resources plugins in webpack, rspack, and angular-rspack
packages currently use the deprecated `url.parse()` and `url.format()`
methods, which generate security warnings:
```
(node:xxx) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead.
```
## Expected Behavior
The code should use the modern WHATWG URL API to eliminate deprecation
warnings and improve security.
## Related Issue(s)
This change addresses the Node.js deprecation of `url.parse()` due to
security implications and lack of standardization.
## Changes Made
- **URL Parsing**: Replace `url.parse(inputUrl)` with `new
URL(normalizedUrl, 'file:///')`
- **URL Reconstruction**: Replace `url.format({ pathname, hash, search
})` with simple string concatenation
- **URL Resolution**: Replace `url.resolve(deployUrl, outputUrl)` with
`new URL(outputUrl, deployUrl).href`
## Files Modified
- `packages/webpack/src/utils/webpack/plugins/postcss-cli-resources.ts`
- `packages/rspack/src/plugins/utils/plugins/postcss-cli-resources.ts`
- `packages/angular-rspack/src/lib/utils/postcss-cli-resources.ts`
## Implementation Details
- Uses WHATWG URL API with a `file:///` base for parsing relative URLs
consistently
- Maintains backward compatibility - all existing functionality works
the same
- Simple string concatenation for URL reconstruction is cleaner and more
readable
- Clear variable names (`normalizedUrl`, `parsedUrl`) improve code
maintainability
## Testing
- All existing tests pass
- Build and lint validation successful
- No functional changes to URL handling behavior
This migration eliminates security warnings while modernizing the
codebase to use standardized URL APIs.
## Summary
- Add CURSOR_TRACE_ID environment variable detection for Cursor
- Simplify get_env_var to be purely map-based for better testability
- Add Cursor support to extension installation logic
- Add test case for CURSOR_TRACE_ID detection
## Test plan
- [x] All existing tests pass
- [x] New test case for CURSOR_TRACE_ID detection passes
- [x] Rust code compiles and passes clippy checks
- [x] Prepush validation passes
This ensures Nx Console extension can be properly installed in Cursor
when the CURSOR_TRACE_ID environment variable is present, providing
better support for Cursor users.
Fixes #[ISSUE_NUMBER]
## Current Behavior
Running Angular migrations (particularly Angular Material migrations)
normally results in many warnings stating that projects were skipped.
This happens because Angular migrations make some assumptions that are
not guaranteed in Nx monorepos:
- build and test tasks are literally called `build` and `test` (it they
have a different name, the Angular migrations don't handle them)
- those tasks must have a `tsConfig` option set in the task `options`
object
While Nx can't change the first assumption, it can ensure that
`tsConfig` is set in some tasks that allow it.
## Expected Behavior
Tasks using the `@nx/angular:package`, `@nx/angular:ng-packagr-lite`,
and `@nx/jest:jest` executors should have the `tsConfig` option set to
aid the Angular migrations to run.
Note: This PR restores the `tsConfig` option for the `@nx/jest:jest`
executor that was recently removed. The option description states that
it is only metadata for Angular migrations and is not used by the
executor. The option will only be set by Nx generators for Angular
projects.
## Related Issue(s)
Fixes#32138
## Current Behavior
The `@nx/js/typescript` plugin exhibits the following wrong behaviors
when it comes to determining whether a project is buildable:
- Having a custom conditional export other than `development` pointing
to a source file means the project is not buildable
- Having any conditional export pointing to source files means the
project is not buildable
- It falls back to check against included files when `outDir` is defined
The above creates issues where some buildable libraries are not
identified.
## Expected Behavior
The `@nx/js/typescript` plugin should behave as follows (simplified)
when it comes to determining whether a project is buildable:
- If `outFile` is defined:
- If the `.` entry point is defined and it's pointing to the `outFile`
or any of its conditional exports are pointing to the `outFile`, it's
buildable
- If `exports` is not defined and `main` or `module` are defined and
pointing to the `outFile`, it's buildable
- Otherwise, it's not buildable
- Otherwise, if `outDir` is defined:
- If the `.` entry point is defined and it's pointing to a path
contained in the `outDir` or any of its conditional exports are pointing
to a path contained in the `outDir`, it's buildable
- If `exports` is not defined and `main` or `module` are defined and
pointing to a path contained in the `outDir`, it's buildable
- Otherwise, it's not buildable
- Otherwise (no `outFile` and no `outDir`):
- If the `.` entry point is defined and it's pointing to a path not
matched by the `files` or `include` patterns or any of its conditional
exports are pointing to a path not matched by the `files` or `include`
patterns, it's buildable
- If `exports` is not defined and `main` or `module` are defined and
pointing to a path not matched by the `files` or `include` patterns,
it's buildable
- Otherwise, it's not buildable
The above also ensures that custom conditional exports are not a factor,
given that all that is needed is that at least one conditional export is
deemed non-buildable.
## Related Issue(s)
Fixes#32116Fixes#32290
…URL API"
This reverts commit f768886ae7.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Accidentally pushed this without review
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Reverting it so it can be reviewed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Replace the deprecated url.parse() and url.format() methods with the modern WHATWG URL API in PostCSS CLI resources plugins to resolve security and maintainability concerns.
- Replace url.parse(inputUrl) with new URL(normalizedUrl, 'file:///')
- Replace url.format({ pathname, hash, search }) with simple string concatenation
- Replace url.resolve(deployUrl, outputUrl) with new URL(outputUrl, deployUrl).href
- Apply changes consistently across webpack, rspack, and angular-rspack packages
The deprecated url.parse() method is prone to security vulnerabilities and is not standardized. WHATWG URL API provides a modern, secure, and standardized way to parse URLs while maintaining all existing functionality.
Resolves deprecation warnings about url.parse() security implications.
This PR improves our error message whenever our GitHub API token expires
so we're not confused about what's broken. It expires each year as
required by Octokit.
Current error:
```
Error occurred prerendering page "/changelog". Read more: https://nextjs.org/docs/messages/prerender-error
HttpError: Bad credentials
```
New error:
```
Error occurred prerendering page "/changelog". Read more: https://nextjs.org/docs/messages/prerender-error
Error: The GitHub token is invalid or has expired. Please provide a new Personal Access Token (PAT) via the GITHUB_TOKEN environment variable.
```
## Current Behavior
Nx currently installs an outdated `@types/node` version (18.16.9) which
lacks TypeScript definitions for the native `fetch` API introduced in
Node.js 18. This causes "fetch is undefined" TypeScript errors in NestJS
projects and other Node.js applications when using webpack transformers
or other build tools.
## Expected Behavior
The `fetch` API should be properly typed in TypeScript without requiring
additional type packages or workarounds. Users should be able to use the
native fetch API in Node.js applications without TypeScript compilation
errors.
## Related Issue(s)
Fixes#31637
Fixes https://github.com/nrwl/nx/issues/29714
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <cferry09@gmail.com>
add new redirects file
redirect root to the intro page
redirect legacy showcase projects to quickstart until those projects get
updated
closes: DOC-94
closes: DOC-114
## Current Behavior
ESM Loader for Windows is not working because it is encountering an
absolute path that is not using the `file://` protocol.
## Expected Behavior
Ensure that when loading the `esm-loader`, it uses the file protocol
## Related Issue(s)
Fixes#32376
## Current Behavior
We currently do not support converting webpack configs using
`NxAppWebpackPlugin` to `NxAppRspackPlugin`.
## Expected Behavior
Add support for converting webpack configs using the
`NxAppWebpackPlugin`.
## Related Issue(s)
Fixes#30292
## Current Behavior
The Jest plugin does not use `NX_CACHE_PROJECT_GRAPH` in its
implementation. Unlike other plugins (e.g., ESLint, TypeScript), it does
not provide a way to control or disable its internal caching behavior.
## Expected Behavior
The Jest plugin should leverage `NX_CACHE_PROJECT_GRAPH`, ensuring
consistent caching behavior across Nx plugins. This would make it easier
to manage or override caching strategies when building higher-order
plugins that extend Nx core functionality.
## Related Issue(s)
Fixes #
---
### Additional Context
* When creating higher-order plugins that extend Nx core plugins, it’s
often useful to manage cache differently. Without this, concurrency
issues can occur if `createNodesV2` is invoked multiple times in
parallel.
* This highlights a broader need for improved plugin extensibility:
* Instead of re-invoking `createNodesV2` (which handles multiple files,
cache, etc.), it would be helpful to expose lower-level functions
responsible only for generating configuration.
* This would give plugin authors more granular control while reducing
unintended side effects.
## Current Behavior
The Astro docs site doesn't display breadcrumbs at the top of the page
content, making navigation context unclear.
## Expected Behavior
Breadcrumbs should appear at the top of each page content (after the
page title) showing the navigation hierarchy, matching the behavior from
the original Next.js app.
<img width="1343" height="361" alt="Screenshot 2025-08-15 at 2 47 19 PM"
src="https://github.com/user-attachments/assets/8f2c983a-710f-4d0b-aa6e-b2303884596a"
/>
## Current Behavior
The @nx/js:node executor had several process management issues:
- Multiple concurrent builds could cause overlapping/corrupted console
output,
especially in NestJS projects
- Process stdout streams weren't properly coordinated between different
tasks
- Rapid file changes could trigger multiple simultaneous rebuilds
without
proper debouncing
- Console output formatting could break with mixed output from
overlapping
processes
## Expected Behavior
The node executor should:
- Handle process output streams cleanly with no overlapping/corrupted
output
- Properly debounce rebuild triggers to prevent resource conflicts
- Maintain clean console formatting even with rapid file changes
- Coordinate output between concurrent processes using a global stream
manager
## Related Issue(s)
Fixes#30247Fixes#22999Fixes#22945
## Current Behavior
When using version plans, after running the release command, version
plans were deleted.
This happened even if a `project` or `group` filter was supplied and not
all version plans were used.
## Expected Behavior
Ensure that:
- Only Version Plans for projects in filter are deleted
- If filtered projects exist in version plans that contain unfiltered
projects, hard error
## Related Issue(s)
Fixes#31327
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
If a host does not have any remotes, it fails to serve as the
`staticRemotesPort` returns as `-Infinity`.
## Expected Behavior
When a host has no remotes, set `staticRemotesPort` to `undefined` and
use this to determine whether we should wait for it.
Add a new option `skipBuildCheck` to the `@nx/js/typescript` plugin
build options to allow skipping the check for a buildable setup and
always infer a build task.
## Current Behavior
Running `nx migrate` in a non-js repo (no `package.json` in the
workspace root) hangs.
## Expected Behavior
Running `nx migrate` in a non-js repo should work correctly.
Open Graph images on nx.dev are returning 404 errors for several pages:
- `/ai-chat` and `/changelog` reference non-existent
`/images/nx-media.jpg`
- `/extending-nx` references non-existent
`/images/open-graph/extending-nx.jpg`
- Pages with anchors have broken og:image URLs
All pages should have working Open Graph images for proper social media
sharing.
Fixes DOC-98
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When resolving token data for creating the GitHubReleaseClient, The GH
CLI supports `https` option for `git_protocol` and it is not being
handled.
This results in no token data being resolved.
Further API requests that require a `Bearer` token in the headers fail.
## Expected Behavior
Ensure `https` protocol is also handled.
`gh auth token` still operates and produces a token that can be used.
## Related Issue(s)
Fixes#31828
## Current Behavior
When `nx g @nx/react:host` is used and 0 `--remotes` are passed, we
still add the `loadRemote` helper from
`@module-federation/enhanced/runtime`.
This causes a typecheck error as it is unused.
## Expected Behavior
Only add the helper when it is needed (i.e. >0 remotes).
## Current Behavior
The astro-docs structure lacks index pages for directory navigation,
making it difficult for users to discover and navigate between related
content sections. Additionally, some index pages were missing the proper
sidebar configuration to hide them from the navigation.
## Expected Behavior
With these changes, all directories in astro-docs now have proper
index.mdoc files that:
- Display auto-generated cards for subdirectory navigation using the `{%
indexpagecards %}` component
- Are hidden from the sidebar navigation with `sidebar: hidden: true`
- Provide clear entry points for discovering related content
The changes include:
- Added index.mdoc files for all technology, concept, guide, and
reference directories
- Implemented proper case handling for directory names (e.g., "Guides" →
"guides")
- Enhanced the IndexPageCards component to work with .mdoc files
- Ensured consistent sidebar configuration across all index pages
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
The Astro docs site header had a different structure and styling
compared to the production nx.dev header. It was missing key navigation
elements like the version switcher, Resources dropdown with icons, and
proper navigation ordering.
The Astro docs header now matches the production nx.dev header structure
with:
- Version switcher (v21, v20, v19) positioned correctly
- Resources dropdown with organized sections (Learn, Events, Company)
and icons
- Proper navigation order: Blog, Resources, | AI, Nx Cloud | Enterprise
- Consistent styling using Tailwind CSS classes
- Maintained social icons and theme switcher functionality
- All links without underlines and proper hover states
Fixes DOC-111
This removes the need to ignore `@nx/cypress` in
`packages/cypress/.eslintrc.json`. This was never really a ciruclar dep,
as
`packages/cypress/src/generators/configuration/files/v9/__directory__/plugins/index.js`
is a template for `generateFiles`, thus appending `__tmpl__` fixes it.
Other packages have valid reasons so a comment is added to clarify for
the future.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Our project graph gradle migrations currently only bump up the gradle
plugin if its versions are set in `build.gradle.kts` files. This means
that migrations will not work with workspaces that use version catalogs
and aliases.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Given a workspace using the project graph gradle plugin on a legacy
version, migrations should bump up the version of the Nx gradle plugin
if its specified in `libs.versions.toml` instead of `build.gradle.kts`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #NXC-2952
- Added "worker" to exclusion pattern in add-snippet.ts to prevent
worker creation code from being added to the generated worker file
itself
- Fixed double slash in tsconfig.worker.json template by removing extra
"/" since offsetFromRoot() already returns paths ending with "/"
- Added comprehensive tests to prevent regression including edge cases
with complex worker names
Fixes#31977
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The Nest.js webpack build target configuration was generating
webpack-cli arguments without the required cwd in build.options.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Nest.js webpack build target should generate proper webpack-cli
arguments with the cwd as part of the build.options
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31863
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
When we switched to the TS solution setup with inferred `tsc` builds, we
didn't update the dependencies for `@nx/vite` to use `tslib` instead of
`@swc/helpers`. It was previously using `@nx/js:swc` executor, but now
`build-base` target is inferred as `tsc -b`.
It did not cause issues since other packages including `nx` always
install tslib, but technically it is incorrect, and we were ignoring the
errors by adding `tslib` and `@swc/helpers` to be ignored in
`.eslintrc.json`.
This PR also cleans up the eslint config for all other packages since we
do not need to ignore `tslib` for `@nx/dependency-checks` to pass.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`@nx/vite` is missing `tslib` dependency even though the built JS file
uses it.
## Expected Behavior
Should have `tslib` as a dependency and not `@swc/helpers`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When using TypeScript solution setup with rspack, conditionally enable
build mode for TsCheckerRspackPlugin to generate declaration files.
This prevents TS6305 errors in module federation scenarios where
declaration files are expected but missing.
Fixes#31929
The additionalEntryPoints option was failing on Windows because
tinyglobby
expects POSIX-style paths but was receiving Windows-style paths with
backslashes.
This fix applies normalizePath to ensure cross-platform compatibility.
Fixes#29690
## Current Behavior
Rspack + React + Module Federation applications are not able to work
properly due to the presence of splitChunks optimization on default web
configs.
## Expected Behavior
Optimizations like this should be overridden by the Module Federation
plugin in order for them to work.
## Related Issue(s)
https://github.com/nrwl/nx/issues/32329
Fixes #
Added override of splitChunks configs for Nx's Module Federation
plugins.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Upgrades both `@nx/expo` and `@nx/react-native` to use the latest
versions of Expo and React Native. Expo iOS and Android builds work
perfectly.
> [!WARNING]
> This PR explicitly does not modify `@nx/detox`; see comment
[here](https://github.com/nrwl/nx/discussions/19473#discussioncomment-13414668)
on a discussion about why Nx should consider using Maestro instead.
## Tasks
- [x] Fix `@nx/expo` E2E tests
- [x] Verify Android and iOS builds
- [x] Fix `@nx/expo` legacy tests (see comment
[here](https://github.com/nrwl/nx/pull/31497#issuecomment-2961048831))
- [x] Fix Android builds with `@nx/expo`
- [x] Remove `react-test-renderer` from `@nx/expo`
- [x] Add migration to remove dependencies from `@nx/expo`
- [x] `@testing-library/jest-native`
- [x] `react-test-renderer`
- [x] Fix `@nx/react-native` E2E tests (see comment
[here](https://github.com/nrwl/nx/pull/31497#issuecomment-2964720118))
- [x] Verify Android and iOS builds (see comment
[here](https://github.com/nrwl/nx/pull/31497#issuecomment-2960921558))
- [x] Add migrations to update deps for `@nx/react-native`
- [x] Add migration to remove dependencies from `@nx/react-native`
- [x] `@testing-library/jest-native`
- [x] `jest-react-native`
- [x] `react-test-renderer`
- [x] Remove `react-test-renderer` from `@nx/react-native`
## Changes
- Upgrade Expo to v53 and update project templates
- Upgrade React Native to v0.79 and update project templates
- Upgrade React to v19.0
- Upgrade `metro-config` and `metro-resolver` to v0.82.4 (fixes#30557)
- Remove `react-test-renderer`
- Remove `jest-react-native`
- Remove `@testing-library/jest-native`
- Fix bug in `@nx/expo` and `@nx/react-native` application generators
where the generated `package.json` was being overwritten (fixes#31416)
## Links
-
https://github.com/facebook/react/tree/main/packages/react-test-renderer#react-native-testing
-
https://callstack.github.io/react-native-testing-library/docs/migration/jest-matchers
-
https://react.dev/blog/2024/04/25/react-19-upgrade-guide#deprecated-react-test-renderer
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Nx generates an Expo project using SDK v52, and React Native projects
using RN 0.76
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx should generate an Expo project using SDK v53, and React Native
projects using RN 0.79
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31498, #30557, #31416
---------
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- use regex to get test class name
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- remove the filter on the test file name
- use junit first to get test class name
- then if junit does not work, use regex as fallback
- fix warnings of unit tests
- upgrade dev.nx.gradle.project-graph to 0.1.3
in ci, in order to testClassDirs to exist, might need to run
compileTestKotilin or compileTestJava first.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes https://github.com/nrwl/nx/pull/31693
---------
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Caleb Ukle <caleb@nrwl.io>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Running `npx create-nx-workspace` always results in `error.log` in the
new workspace.
## Expected Behavior
No `error.log`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When using build targets with nested library dependencies (App -> lib1
-> lib2),
dependencies from the deepest libraries were not being included in the
generated
package.json due to restrictive target input patterns.
This fix adds an isTransitiveDependency parameter to findAllNpmDeps
function that
uses broader file patterns ({projectRoot}/**/*) when processing
transitive
project dependencies instead of the restrictive build target patterns.
Fixes#30895
## Current Behavior
`joinPathFragments` in nest app generator for the target dir of the
template files is incorrect because it makes the path unix-style which
does not work for Windows.
## Expected Behavior
Use `path.join`
## Related Issue(s)
Fixes#31992
## Current Behavior
Using `joinPathFragments` with `generateFiles` is incorrect as we do not
take into OS-specific paths with `joinPathFragments`.
This is problematic when trying to read files on the system for Windows
users for example.
## Expected Behavior
Use `path.join` to ensure the correct file path is used and passed to
`readdirSync`
## Current Behavior
The `name` property is not set for vitest configs. Vitest will therefore
infer the name for the test suite based off the directory name.
In a monorepo this can cause issues as the directory name may be
repeated but for different contexts.
## Expected Behavior
Set the project name as the name in the test config
## Related Issue(s)
Fixes#32163
# Description
Move Angular Rspack into the Nx repo.
The relevant packages are:
- angular-rspack
- angular-rspack-compiler
## Examples
Adds `Angular Rspack` examples to `examples/angular-rspack` which allow
for demonstration of various configs to use various features within
angular, such as:
- proxy
- ssr
- ssg
- i18n
These examples use `@nx/angular-rspack` with `workspace:*` protocol
allowing for immediate feedback on changes to `angular-rspack` and
`angular-rspack-compiler` to be reflected in these examples.
* fix: errors from ComponentStylesheetResult are hidden
if componentStylesheetBundler.bundleFile/bundleInline doesn't throw an error
but the results still contain errors, the errors will not be reported and
the resulting style sheet will be empty.
* fix: sass/includePaths are not passed to setup function
* feat(angular-rspack,angular-rspack-compiler): reuse existing compilation if exists
* feat(angular-rspack,angular-rspack-compiler): ensure only affected file is rebuilt
* test(angular-rspack): add unit tests for angular-transform-loader
* test(angular-rspack): add unit tests for angular-transform-loader
* fix: format
* fix: wip
* fix: test change
* fix: test change 2
* feat(angular-rspack): add withConfigurations
* test(angular-rspack): add unit tests for withConfigurations
---------
Co-authored-by: Michael <michael.hladky@push-based.io>
* fix: errors from ComponentStylesheetResult are hidden
if componentStylesheetBundler.bundleFile/bundleInline doesn't throw an error
but the results still contain errors, the errors will not be reported and
the resulting style sheet will be empty.
* fix: sass/includePaths are not passed to setup function
* feat(angular-rspack,angular-rspack-compiler): reuse existing compilation if exists
* feat(angular-rspack,angular-rspack-compiler): ensure only affected file is rebuilt
- Added serveStaticTargetName options array with 5 alternative names
- Fixes conflicts when Angular module federation projects create
serve-static targets
- Allows webpack plugin to work with existing Angular setups without
manual nx.json editing
Fixes#32267Fixes#31384
### Summary
Fixes a TypeError in the Nx release-publish executor that occurs when
`npm dist-tag add` fails, preventing users from seeing the actual npm
error message.
### Problem
When `npm dist-tag add` fails during `nx release publish`, users see a
JavaScript TypeError instead of the actual npm error:
```
npm dist-tag add error:
Something unexpected went wrong when processing the npm dist-tag add output
TypeError: Cannot read properties of undefined (reading 'summary')
at runExecutor (/node_modules/@nx/js/src/executors/release-publish/release-publish.impl.js:207:50)
```
### Root Cause
The error handler attempts to access `stdoutData.error.summary` without
checking if `error` exists. Since npm dist-tag outputs errors to stderr
(not stdout), the parsed stdout is typically an empty object `{}`,
causing `stdoutData.error` to be `undefined`. Accessing `.summary` on
`undefined` throws a TypeError.
### Solution
Added optional chaining (`?.`) when accessing error properties to
prevent TypeErrors:
```javascript
// Before (throws TypeError):
if (stdoutData.error.summary) { ... }
// After (safe):
if (stdoutData.error?.summary) { ... }
```
### Example
**Before this fix:**
```bash
$ nx release publish
npm dist-tag add error:
Something unexpected went wrong when processing the npm dist-tag add output
TypeError: Cannot read properties of undefined (reading 'summary')
```
**After this fix:**
```bash
$ nx release publish
npm dist-tag add error:
# (The actual npm error from stderr is shown, or if no JSON error, the code continues gracefully)
```
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
Jest module resolution requires manual maintenance of workspace package
mappings in moduleNameMapper with brittle relative paths that break
across different directory structures.
## Expected Behavior
Dynamic workspace package resolution without manual maintenance, using
absolute paths that work from any test directory.
## Changes
- Remove all workspace package mappings from `jest.preset.js`
`moduleNameMapper`
- Add `@nx/*` and `nx/src/*` resolution to `patched-jest-resolver.js`
- Use absolute paths and efficient workspace root detection for PNPM
- Add file vs directory checks to prevent `EISDIR` errors
### References:
`ts-jest` project references issue:
https://github.com/kulshekhar/ts-jest/issues/1648
## Current Behavior
The TUI dependency view experiences buffer overflow panics when
rendering scrollbars on small or constrained terminal sizes. Users
encounter crashes with messages like "index outside of buffer" at
various coordinates such as (134, 37), (86, 0), (107, 0), etc.
## Expected Behavior
The TUI should handle all terminal sizes gracefully without crashing,
maintaining proper visual rendering of scrollbars and padding elements
while staying within buffer boundaries.
## Key Code Changes
The fix adds **clean, reusable helper functions** for bounds checking to
prevent buffer overflows:
### 1. **New Helper Functions** (lines 216-239):
```rust
/// Check if a rectangle fits within buffer boundaries
fn fits_in_buffer(area: &Rect, buf: &Buffer) -> bool {
area.x + area.width <= buf.area().width && area.y < buf.area().height
}
/// Create a safe rectangle clamped to buffer boundaries
fn clamp_to_buffer(area: Rect, buf: &Buffer) -> Option<Rect> {
if area.width == 0 || area.height == 0 {
return None;
}
let safe_area = Rect {
x: area.x,
y: area.y,
width: area.width.min(buf.area().width.saturating_sub(area.x)),
height: area.height.min(buf.area().height.saturating_sub(area.y)),
};
if safe_area.width > 0 && safe_area.height > 0 { Some(safe_area) } else { None }
}
```
### 2. **Simplified Scrollbar Bounds Check** (lines 478-481):
```rust
// Render scrollbar with bounds checking
if let Some(safe_scrollbar_area) = Self::clamp_to_buffer(outer_area, buf) {
scrollbar.render(safe_scrollbar_area, buf, &mut state.scrollbar_state);
}
```
### 3. **Cleaner Padding Validation** (lines 241-286):
```rust
fn render_scrollbar_padding(outer_area: Rect, buf: &mut Buffer, style: Style) {
const PADDING_WIDTH: u16 = 2;
const RIGHT_MARGIN: u16 = 3;
const WIDTH_PADDING: u16 = 2;
const TOTAL_WIDTH: u16 = PADDING_WIDTH + RIGHT_MARGIN + WIDTH_PADDING;
// Early exit if area is too small or has no height
if outer_area.width < TOTAL_WIDTH || outer_area.height == 0 {
return;
}
// Use helper function for bounds checking
if Self::fits_in_buffer(&top_area, buf) {
// render top padding
}
if Self::fits_in_buffer(&bottom_area, buf) {
// render bottom padding
}
}
```
**Key improvements:**
- **Reduced complexity**: Scrollbar bounds checking went from 11 lines
to 3 lines
- **Reusable helpers**: `fits_in_buffer()` and `clamp_to_buffer()` can
be used throughout the codebase
- **Named constants**: Replaced magic numbers with descriptive constants
- **Clear intent**: Function names clearly express what the code does
## Related Issue(s)
This fixes buffer overflow panics that occur when the terminal user
interface attempts to render scrollbar widgets and padding outside the
available buffer boundaries, particularly on smaller terminal sizes or
when the terminal is resized.
The fix adds minimal bounds checking to:
1. **Scrollbar rendering**: Validates the scrollbar area fits within
buffer boundaries before rendering
2. **Padding rendering**: Ensures top/bottom padding areas don't extend
beyond buffer limits
**Comprehensive test coverage added**: 10 unit tests covering all edge
cases including the specific problematic buffer dimensions that
previously caused panics (45×30, 76×30, 104×30, 135×37, etc.).
Tested across multiple terminal buffer sizes and confirmed no more
buffer overflow panics while maintaining correct scrollbar
functionality.
Previously, the documentation indicated that the nx-cloud fix-ci command was only needed when not using Nx Agents. This has been updated to clarify that the fix-ci command is always required for self-healing CI functionality, regardless of whether Nx Agents are being used or not.
- Updated docs/shared/features/self-healing-ci.md to remove Nx Agents distinction
- Updated blog post to show fix-ci is always required
- Simplified CI configuration examples to show proper placement after nx commands
use resolved module as base path for the file replacement, making sure
the path will be absolute
## Current Behavior
file are replaced using the relative path written on the "with" key.
Using AnalogJs I have problems on using the fileReplacement feature
using vite dev server.
```ts
mode === 'development' &&
replaceFiles([
{
replace: './src/environments/environment.ts',
with: './src/environments/environment.development.ts',
},
]),
```
this is not working because modules are resolved with their absolute
path, so this piece of code:
```ts
const foundReplace = replacements.find((replacement) =>
resolved?.id?.endsWith(replacement.replace)
);
```
is not finding anything with the leading './' (no log on console for
replacement).
Changing to this:
```ts
mode === 'development' &&
replaceFiles([
{
replace: 'src/environments/environment.ts',
with: 'src/environments/environment.development.ts',
},
]),
```
logs `replace "src/environments/environment.ts" with
"src/environments/environment.development.ts"` but vite throws an error
cause it doesn't find the module.
My solution ensures that files are replaced using the base path from the
existing module, replacing only the involved substring.
## Expected Behavior
correct file replacement
## Current Behavior
The heading unit test for the @nx/expo:application generator uses
toHaveTextContent with a strict string comparison. This causes the test
to fail when the heading output includes minor formatting differences or
additional content.
## Expected Behavior
The test should use a regular expression with toHaveTextContent to allow
partial matches.
### Summary
- Enhanced VS Code debugging: All Node applications now automatically
get VS Code
debugging configuration
- Improved webpack source maps: Added `devtoolModuleFilenameTemplate`
for better
debugging experience
- Smart port allocation: Automatically assigns unique debug ports to
prevent conflicts
- Comprehensive file support: Debug configuration supports `.js`,
`.mjs`, and `.cjs` output files
This improvement makes debugging Node applications in Nx workspaces
seamless and consistent across all frameworks and bundlers.
closes: https://github.com/nrwl/nx/issues/14708
This PR enables the Node.js executor to run ESM-only packages (like
`node-fetch`@3) alongside CommonJS modules.
### Changes:
- ESM loader: Implemented custom ESM resolver to handle Nx workspace
library mappings in ESM contexts
- Dynamic execution: Node executor now switches between CommonJS and ESM
loaders based on the detected module format
- esbuild updates: Enhanced esbuild executor to properly handle ESM
output formats and creating a proper `package.json`
closes: #10296
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Enhanced TUI Experience: Intelligent Pane Management and Dependency
Analysis
This PR significantly improves the TUI experience by implementing smart
pane switching and enhanced dependency visualization when tasks fail.
### 🚀 Key Features
#### Automatic Pane Switching for Failed Dependencies
- **Smart Detection**: When a task becomes skipped due to dependency
failures, the TUI automatically identifies the root cause
- **Intelligent Switching**: Panes showing skipped tasks automatically
switch to display the failed dependency's terminal output
- **Duplicate Prevention**: If both panes would show the same failed
task, the layout automatically consolidates to a single pane to avoid
redundancy
#### Enhanced Dependency View for Skipped Tasks
- **Root Cause Analysis**: Skipped tasks now show clear messaging about
which dependency caused the failure
- **Visual Indicators**: Skipped tasks use warning colors (orange
borders, scrollbars) to distinguish them from pending tasks
- **Interactive Navigation**: Users can scroll through dependencies of
skipped tasks to understand the failure chain
#### Centralized Status Icon System
- **Consistent Styling**: Created a centralized `status_icons` module
for consistent task status representation across all components
- **Unified Theming**: All status indicators (checkmarks, spinners,
warning symbols) now use consistent colors and styling
### 🔧 Technical Improvements
#### Code Optimization
- **Simplified Logic**: Replaced complex `matches\!` patterns with
direct equality checks where appropriate (e.g., `status_map.get(dep) ==
Some(&TaskStatus::Failure)`)
- **Cleaner Conditionals**: Converted nested match statements to more
readable if-else patterns using `matches\!` macro
- **Functional Programming**: Used iterator chains with `filter` and
`map` for cleaner collection processing
#### Enhanced State Management
- **Layout Consolidation**: When duplicate panes are detected, the
system automatically switches from double to single pane layout
- **State Consistency**: Proper cleanup of terminal pane data,
dependency view states, and layout areas when consolidating panes
- **Key Event Handling**: Extended keyboard navigation to work with both
pending and skipped tasks in dependency view
### 🎯 User Experience Improvements
#### Better Failure Visibility
- **Immediate Focus**: Failed dependencies are immediately brought to
the user's attention without manual navigation
- **Context Preservation**: When switching panes, the system maintains
proper focus and scroll states
- **Clear Messaging**: Skipped tasks display specific information about
which dependency failed rather than generic messages
#### Responsive Layout
- **Dynamic Adaptation**: Layout automatically adjusts from double to
single pane when appropriate
- **Consistent Theming**: Skipped tasks use warning colors throughout
the interface for immediate recognition
- **Improved Scrolling**: Enhanced scrollbar styling that adapts to task
status (warning colors for skipped tasks)
### 🛠 Files Changed
- **`app.rs`**: Core pane switching logic, layout management, and
automatic failure detection
- **`dependency_view.rs`**: Enhanced skipped task support, root cause
analysis, and improved styling
- **`tasks_list.rs`**: Integration with centralized status icon system
- **`graph_utils.rs`**: New dependency analysis functions for failure
chain detection
This enhancement transforms the TUI from a passive monitoring tool into
an intelligent assistant that proactively helps users understand and
navigate build failures.
## Current Behavior
When generating a new Angular component it imports `CommonModule` by
default.
## Expected Behavior
The `CommonModule` is not needed as often in modern angular because of
the new control flow syntax and the move away from `[ngClass]` and
`[ngStyle]` in favour of `[class]` and `[style]`. It is also not
included by the official angular component generator.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
This PR upgrades both `@module-federation/enhanced` and
`@module-federation/sdk` to
[0.18.0](https://github.com/module-federation/core/releases/tag/v0.18.0),
which uses the transitive dependency koa@3 that contains a patch for the
reported vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2025-8129
## Current Behavior
The `@module-federation/enhanced` and `@module-federation/sdk`
dependencies are on version 0.17.0, which contains a reported
vulnerability related to the use of koa@2.
This causes any consumers of the latest nx version to receive a security
vulnerability warning due to the transitive dependency koa@2 being
installed, e.g. via GitHub security overview:
<img width="938" height="375" alt="Screenshot 2025-08-07 at 23 26 26"
src="https://github.com/user-attachments/assets/d4653940-3a23-45c6-881f-639e4732fdce"
/>
## Expected Behavior
Having nx installed should not raise a security vulnerability warning.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
_n.a._
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Bump `@nx/graph` version with the fix for `nx-dev`. This only happens
for pages with multiple project graphs because the internal
`ProjectGraphClient` assumes a singleton.
## Summary
Implements lazy loading for task graphs to significantly improve initial
load times in the graph visualization UI. Instead of loading all task
graphs upfront, graphs are now fetched on-demand based on user
interaction.
### Key Changes
- On-demand loading: Task graphs are loaded only when needed (when
selecting a target or specific projects)
- Server-side optimization: Efficient task graph generation for specific
targets and projects
- Client-side caching: Intelligent cache management to avoid refetching
already loaded graphs
- Multiple query patterns support:
- `/tasks/:selectedTarget` - Load all projects with that target
- `/tasks/:selectedTarget?projects=app1 app2` - Load specific projects
only
- `CLI: nx <target> <project> --graph`
### Server-side
`packages/nx/src/command-line/graph/graph.ts`
- Added `createTaskGraphsForTargetAndProjects` function for flexible
task graph generation
- Modified `/task-graph.json` endpoint to support query parameters
(projects, target)
- Implemented proper handling for both UI (projects param) and CLI
requests
- Added server-side caching for task graphs (Map-based cache)
### Client-Side
Routes and Loaders (graph/client/src/app/routes.tsx)
- Added selectedTargetLoader with cache-aware fetching
- Integrated task graph cache for optimal data fetching
- Simplified route structure by removing unnecessary metadata loader
Cache Management (graph/client/src/app/task-graph-cache.ts)
- Created sophisticated TaskGraphCache class
- Tracks individual project graphs and fetch status
- Supports partial fetching (only missing projects)
- Handles different query patterns intelligently
Components (graph/client/src/app/feature-tasks/tasks-sidebar.tsx)
- Updated to use selectedTarget loader data
- Graceful handling when no data is available
Service Layer (graph/shared/src/lib/project-graph-data-service/)
- Updated all service implementations to support getSpecificTaskGraph()
- Modified method signature to accept projects: string | string[] | null
- Services updated: Fetch, Local, Mock, NxConsole
Type Definitions (graph/shared/src/lib/)
- Updated ProjectGraphService interface
- Cleaned up type imports and definitions
Build Configuration
- scripts/generate-graph.ts - Simplified generation logic
- scripts/generate-graph-environment.ts - Updated workspace
configuration
- graph/client/webpack.config.js - Updated asset paths
- .gitignore - Updated ignored directories
### Bug Fixes (Latest Update)
### Performance Impact
**Before:**
- Generates ALL task graphs upfront (hundreds/thousands in large repos)
- Blocks main thread during generation
- Large network payloads regardless of usage
- No caching, regenerates on every request
**After:**
- Only generates task graphs when actually needed
- Lightweight metadata response for fast initial load
- Progressive loading as users explore
- Intelligent caching with cache invalidation
- **Stable and error-free**: No console crashes or race conditions
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Chau <25516557+nartc@users.noreply.github.com>
## Current Behavior
There is no method for specifying an exact version for docker version
during `nx release`
## Expected Behavior
Add `--dockerVersion` to provide the user with a manner of providing an
exact docker version
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <Coly010@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The new Pre/Post Tasks Execution API was missing command information
that was available in the old `StoreRunInformationLifeCycle` system.
This made it impossible to track the original command that initiated
task execution, particularly problematic for complex commands like `nx
affected` and `nx run-many`.
## Expected Behavior
With this change, both `PreTasksExecutionContext` and
`PostTasksExecutionContext` now include an `argv: string[]` field
containing the complete raw command line arguments from `process.argv`.
## Related Issue(s)
Addresses the missing command information discussed in
https://github.com/nrwl/nx/discussions/29637
## Changes Made
- **Add `argv: string[]` field** to `PreTasksExecutionContext` interface
- **Add `argv: string[]` field** to `PostTasksExecutionContext`
interface
- **Pass `process.argv` directly** to both execution contexts
- **Remove command parsing functions** (no longer needed)
## Benefits
- **Complete Raw Data**: Provides full `process.argv` including node
executable path, script path, and all arguments
- **No Information Loss**: Every argument preserved exactly as passed to
the process
- **Better Analysis**: Consumers can parse/analyze arguments however
needed
- **Simpler Implementation**: No parsing required - just pass
`process.argv` directly
## Example
Instead of missing command information, plugins now receive:
```typescript
{
workspaceRoot: '/path/to/workspace',
nxJsonConfiguration: { ... },
argv: [
"/usr/bin/node",
"/usr/local/bin/nx",
"affected",
"--target=build",
"--head=HEAD~1"
]
// ... other fields
}
```
This is especially valuable for tracking complex commands like `nx
affected` and `nx run-many` where the original command context was
previously lost.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Commit message validation only happens during the pre-push hook, which
means developers don't get feedback about incorrect commit message
format until they try to push their changes to the remote repository.
## Expected Behavior
Commit messages should be validated immediately when creating a commit,
providing instant feedback and preventing incorrectly formatted commits
from being created in the first place.
## Changes Made
- **Add `.husky/commit-msg` hook** - Validates commit messages before
commit creation
- **Enhance `scripts/commit-lint.js`** - Support both commit-msg hook
and existing pre-push validation
- **Add WIP support** - Allow "wip" messages to bypass format validation
for work-in-progress commits
- **Maintain backward compatibility** - Existing pre-push validation
continues to work
## Benefits
- Immediate feedback on commit message format
- Prevents bad commits from being created
- Supports WIP commits for development workflow
- No disruption to existing validation process
## Related Issue(s)
This improves the developer experience by catching commit message format
issues earlier in the workflow.
## Current Behavior
We currently do not have a method for interpolating Environment
Variables into the `versionSchemes` for Docker Release.
## Expected Behavior
We allow the usage of `{env.VAR_NAME}` to interpolate Environment
Variables
## Current Behavior
The esbuild e2e test `it should generate an app that cosumes a
non-buildable ts library` is failing and causing CI issues.
## Expected Behavior
The test should be temporarily disabled until the underlying issue is
resolved.
## Related Issue(s)
The test failure is due to https://github.com/pinojs/pino/issues/2253.
This test should be re-enabled once that pino issue is resolved.
## Changes
- Added `.skip` to the failing test
- Added a TODO comment referencing the pino issue for when to re-enable
the test
## Current Behavior
- Some resizing (e.g., splitting the terminal) when the TUI shows the
Dependency View causes the TUI to crash with an out-of-bounds issue
while rendering.
- The Dependency View shows the scrollbar as an inner scrollbar instead
of being located in place of the right border (like the Terminal Pane
does).
<img width="828" height="361" alt="image"
src="https://github.com/user-attachments/assets/b9f8de5f-6fb3-401c-9da3-4867cd71ca73"
/>
## Expected Behavior
- The TUI shouldn't crash when showing the Dependency View and a big
resize occurs.
- The Dependency View should show the scrollbar in place of the right
border (like the Terminal Pane does).
<img width="827" height="362" alt="image"
src="https://github.com/user-attachments/assets/a04bf7c0-00ca-485c-9f5f-5a316557bd3b"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When generating a Next.js application with Jest as the unit test runner,
Jest configuration fails because it defaults to looking for
`tsconfig.app.json` which doesn't exist in Next.js projects. Next.js
apps use `tsconfig.json` as their main TypeScript configuration file.
## Expected Behavior
Jest should be configured to use `tsconfig.json` as the runtime
TypeScript configuration for Next.js applications, allowing Jest to
properly resolve TypeScript configurations.
## Related Issue(s)
Fixes#31555
## Summary
Fixes#31602 by adding validation to `create-nx-workspace` to reject
workspace names that start with numbers, preventing confusing errors
later in the workspace generation process.
## Changes Made
- **Added `validateWorkspaceName()` function** - Validates that
workspace names start with letters
- **Integrated validation into workspace creation flow** - Validates
both command-line arguments and interactive input
- **Clear error messaging** - Provides helpful error message with
examples of valid names
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
The repository currently uses outdated versions of the `tmp` and
`@types/tmp` dependencies:
- `tmp` version ~0.2.1
- `@types/tmp` version ^0.2.0
## Expected Behavior
Update to the latest compatible versions of these dependencies:
- `tmp` version ~0.2.4
- `@types/tmp` version ^0.2.6
This will ensure we have the latest bug fixes and improvements from
these packages.
## Related Issue(s)
This is a general dependency update to keep the project up to date.
## Related Issue(s)
[tmp allows arbitrary temporary file / directory write via symbolic link
`dir` parameter](https://github.com/advisories/GHSA-52f5-9888-hmc6)
Fixes Github advisory https://github.com/advisories/GHSA-52f5-9888-hmc6
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when running gradle command with args, it requires to use
--args="--continutous"
for bootRun, which is continuous, i got an error
```
Execution failed for task ':bootRun'.
> Failed to query the value of task ':bootRun' property 'mainClass'.
> Querying the mapped value of task ':resolveMainClassName' property 'outputFile' before task ':resolveMainClassName' has completed is not supported
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
change it when just running `nx run demo:bootRun --continuous`, it will pass --continuous directly to ./gradlew.
any args not in the list
```
new Set([
'taskName',
'testClassName',
'args',
'excludeDependsOn',
'__unparsed__',
]);
```
will passed as arga to the ./gradlew
i try to add `__unparsed__`, but it is always empty.
for bootRun, i add excludeDependsOn as false in nx.json and that error
goes away.
```
"bootRun": {
"options": {
"excludeDependsOn": false
}
}
```
so for all continuous task, i changed excludeDependsOn as false in the
option
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When Nx Cloud is enabled, task details are not stored in the task
history. This results in features like local flaky task detection or
displaying estimated task durations in the TUI not working.
## Expected Behavior
Task details should always be stored in the task history regardless of
Nx Cloud being enabled.
## Current Behavior
The Gradle plugin does not normalize project root paths when creating
project nodes, which can lead to inconsistent path handling across
different operating systems and file systems.
## Expected Behavior
Project root paths should be normalized using `normalizePath` from
`@nx/devkit` to ensure consistent path handling regardless of the
operating system or file system.
## Related Issue(s)
This is a general improvement to prevent potential path-related issues
in Gradle project detection and configuration.
add basic registry page at /plugin-registry
Note: most of this work was aimed at getting the content to the page, we
can come back to making the plugin registry page prettier and have more
functionality in future PRs
resolves: DOC-71
This is to ensure that the NX_CLOUD_AUTH_TOKEN is treated the same as
ACCESS_TOKEN.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
If there isn't any Nx Cloud properties in the `nx.json`, the CLI doesn't
recognize `NX_CLOUD_AUTH_TOKEN` as a environment variable to communicate
with Nx Cloud. If I provide just `NX_CLOUD_ACCESS_TOKEN`, the CLI does.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Since `AUTH_TOKEN` is suppose to be an alias for `ACCESS_TOKEN`, the
behavior should be the same.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
This plugin is listed first, despite being last maintained 3 years ago.
## Expected Behavior
We should not show unmaintained projects when there are others covering
the same technology that are maintained
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
E2E tests are distributed to agents but run sequentially (1 per agent),
underutilizing agent capacity.
## Expected Behavior
E2E tests run in parallel (2-3 per agent) with proper port allocation to
prevent conflicts.
## Changes Made
- Add port allocation utilities to prevent port conflicts in parallel
tests
- Configure CI agents to run 2-3 e2e tests in parallel per agent
- Keep `e2e-release` sequential due to shared git state requirements
### MISC
- On CI browsers (cypress/playwright) are already pre-installed, we
improve this by short-circuiting the installation.
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
The website should still function when Brave shield is up.
`window.Cookiebot` defaults to `<script id="Cookiebot">` when the script
is blocked... so the original check is not fully correct.
## Current Behavior
React Router requires using a Vite plugin. This means that during the
CNW flow, if a user selects `Yes` to the prompt for `React Router for
SSR`, we do not prompt them for `bundler`.
This can be confusing for users that expect to be able to select
bundler.
## Expected Behavior
Clarify during the prompt for React Router for SSR that Vite will be
selected as the bundler.
intro docs for nx-cloud aren't needed as it's duplicate information and
should instead be covered by the regular intro flows, which now mention
nx cloud.
Moved over some content into applicable pages, such as `nx g
ci-workflow` command and calling out `nx connect` command in places.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
- The logic to detect whether the workspace uses the TS solution setup
restricts the top-level properties in the `tsconfig.base.json` file and
only allows `compilerOptions`. This prevents extending from other
tsconfig files in the `tsconfig.base.json` file.
- Generating projects in a workspace without any known root tsconfig
files (`tsconfig.json`, `tsconfig.base.json`) results in the old setup
being generated. Workspaces without root TS configuration should be able
to use the TS solution setup.
## Expected Behavior
- The logic to detect whether the workspace uses the TS solution should
not restrict the top-level properties in the `tsconfig.base.json` file.
The only things required for the TS solution setup are to have
`composite: true` and `declarations` enabled.
- The TS solution setup should be used when generating projects in a
workspace without any known root tsconfig files (`tsconfig.json`,
`tsconfig.base.json`).
## Related Issue(s)
Fixes#32134
Add cookie consent for website using
[Cookiebot](https://www.cookiebot.com).
Moves all tracking logic into
`window.addEventListener('CookiebotOnAccept', ...)` callback.
when using worktrees I'm getting an error like
```
❯ git worktree add ../test-feat-a feat-a
Preparing worktree (checking out 'feat-a')
Updating files: 100% (9887/9887), done.
HEAD is now at c14325d3d3 feat(nx-dev): update nx.dev homepage (#32132)
fatal: bad object 0000000000000000000000000000000000000000
husky - post-checkout script failed (code 128)
```
this is due to our post-checkout husky hook. This PR fixes it
## Current Behavior
Running the `@nx/react:remote` generator as a standalone generator in a
TS Proj Workspace will result in the generator throwing an error that
`@org/remoteName` is invalid.
## Expected Behavior
Ensure we normalize the project name early to disregard the scope that
is added.
This matches the behaviour of the host generator.
## Related Issue(s)
Fixes#30807
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, the project name is just last part to full gradle path, for
example:
- gradle path for :parent-path:project-name, it currently takes only
project-name
this might create duplicates in a large project
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- change the name to match gradle path exactly, then the project name
would just be the gradle path
- for example, the gradle command would be `./gradlew
:parent-path:project-name:build`, nx command would be `nx run
:parent-path:project-name:build`
https://linear.app/nxdev/issue/NXC-2917/fix-terminal-ui-compatibility-with-gradle-naming
need to be fixed before this pr
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behaviour
E2e tests fail with Node 24 because npm 11 writes deprecation warnings
to stderr even on successful commands, causing registry version
resolution to fail.
## Expected Behaviour
Registry version resolution should work with npm 11 warnings in stderr.
## References
```
NX Unable to resolve the current version from the registry: "registry=http://localhost:4873" tag=latest. Please ensure that the package exists in the registry in order to use the "registry" currentVersionResolver. Alternatively, you can use the --first-release option or set "release.version.fallbackCurrentVersionResolver" to "disk" in order to fallback to the version on disk when the registry lookup fails.
```
https://staging.nx.app/runs/l9kRV3E6ST
- use lfs for imgs
- copy over concepts to astro site.
- note: some of the markdoc impl hasn't been done yet, so those are left
as plain text. things like the project view, graph, side-by-side still
need to be moved.
closed: DOC-67
The federationRuntime option not longer exists in experiments, use
asyncStartup to enable asynchronous container startup.
## Current Behavior
When creating a new project with module federation (`nx g
@nx/angular:host host --remotes=remote1,remote2 --ssr`) and then try to
to run the `serve-ssr` target (`nx serve-ssr host`) you get this error:
<img width="1615" height="511" alt="image"
src="https://github.com/user-attachments/assets/19819020-821b-4422-83ae-88203018b981"
/>
## Expected Behavior
It should serve the application using SSR.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
As it currently stands, there is no (easy) way to get HMR support
working with Rspack + Nest by using the `@nx/rspack:rspack` build
executor and `@nx/js:node` serve executor because we need to turn
`watch: false` in the serve executor (as we don't want it to watch and
call the build again) but that in turn makes the rspack build executor
not use `compiler.watch` this only building once.
Due to the way options are passed through to the executor (via
`runExecutor`) even if we do:
```
"options": {
"buildTarget": "myapp:build",
"buildTargetOptions": {
"watch": true
},
"watch": false
}
```
The `watch: false` overwrites it.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We should be able to have the Rspack executor abide by whatever the
`watch` configuration is that is returned from our `rspack.config.ts`
file for the application.
There is precedent for abiding by the tools configuration file vs the
executor option, the Webpack executor already does it.
The Webpack compiler is started in watch mode if the `watch` flag is
true in the webpack config itself vs. strictly abiding by the executors
options. Based on
https://github.com/nrwl/nx/issues/1992#issuecomment-2826664777 I could
do what I want, but I am using Rspack not Webpack.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
https://github.com/nrwl/nx/issues/1992
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
At some point in time, we had support for Module Federation aliases, and
I noticed some of our examples broke in the latest versions of Nx.
This is an attempt to regain that support with some normalization of
Module Federation project names.
## Expected Behavior
We need to have the mapping back of aliases in the format:
```typescript
const mfConfig = {
// ...
"@nx-mf/remote": "_nx_mf_remote@http://localhost:3001",
// ...
}
```
## Related Issue(s)
https://github.com/nrwl/nx/issues/31346
Fixes #
Add a function specific to parse Federated names into resolvable
JavaScript vars.
Use this function in every place a `str.replace(/-/, '_')` is being
used.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
We currently generate a Dockerfile for node applications that only takes
into account npm.
This means that if the workspace is using yarn or pnpm then when we
prune the lockfile, we have an incorrect lockfile in the output folder
for the docker build.
## Expected Behavior
Ensure the generated Dockerfile is compliant for the package manager
used in the workspace
## Current Behavior
Framework deps such as `express` are not added to the app's package.json
## Expected Behavior
Ensure framework deps are added to app's package.json
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`graph-client` application uses `@nx/graph/legacy`
## Expected Behavior
The entire repo should be free of `@nx/graph/legacy` imports. Existing
behaviors of the graph should be maintained.
## Current Behavior
When multiple commands use the same option, we follow a pattern of using
`withX` helpers.
The `dockerVersionScheme` option does not follow this pattern.
## Expected Behavior
Create `withDockerVersionSchemeOptions` to follow the pattern
## Current Behavior
Running tasks for Angular projects that use Angular CLI builders can
result in validation errors when the project or workspace configurations
contain Nx-specific properties.
## Expected Behavior
Running tasks for Angular projects that use Angular CLI builders
shouldn't result in validation errors when the project or workspace
configurations contain Nx-specific properties.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running `nx prune api` it fails with:
```
NX The following outputs are invalid:
- apps/api/dist/package.json
- apps/api/dist/package-lock.json
```
## Expected Behavior
Prune should work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Jest fails to parse TypeScript config files with ES module syntax on
Node.js 24 with error:
```
Error: Jest: Failed to parse the TypeScript config file
SyntaxError: Unexpected token 'export'
```
## Expected Behavior
Jest should successfully parse TypeScript config files on Node.js 24.
## Related Issue(s)
This occurs because Jest 30 + Node.js 24 can't parse TS configs with
imports without the `--no-experimental-strip-types` flag.
Related to: https://github.com/jestjs/jest/issues/15682
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Running `nx release changelog [version]` fails for docker images
## Expected Behavior
it should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
If user sets `registryUrl` to `docker.io` then release fails.
## Expected Behavior
We should support setting it to `docker.io` even though it's not
necessary.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`nx release` supports `--dockerVersionScheme`
`nx release version` does not.
## Expected Behavior
`nx release version --dockerVersionScheme` should work
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, in the repo, the version is 0.1.0
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
since i modify the new code, i need to publish a version of
https://plugins.gradle.org/plugin/dev.nx.gradle.project-graph
change the version to 0.1.4
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
See:
https://nx-dev-git-docs-node-docker-nrwl.vercel.app/features/manage-releases
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
Generating a node application does not set the outputs for the prune and
copy workspace modules tasks.
## Expected Behavior
Ensure the outputs are set so that cache can be restored correctly
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Storybook docgen assume `flow` types when encountering `import type`
syntax.
## Expected Behavior
Ensure `reactDocgen` is set to typescript
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when run bootJar and bootRun, i got this error:
```
> Querying the mapped value of task ':application:resolveMainClassName' property 'outputFile' before task ':application:resolveMainClassName' has completed is not supported
```
both bootJar and bootRun dependsOn resolveMainClassName. however, when
it runs with excludeDependsOn, the gradlew command will be `./gradlew
:app:bootRun --exclude-task :app:resolveMainClassName`. when running the
command like that, it will cause an issue
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
for bootJar and bootRun, hardcode excludeDependsOn to false
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There is a runtime issue in project graph pruning where we attempt to
eagerly traverse workspace nodes when they may not exist.
## Expected Behavior
Ensure the workspace node exists before traversing it.
## Current Behavior
The `@nx/node:setup-docker` generator does not initialize the docker
plugin.
## Expected Behavior
The `@nx/node:setup-docker` generator sets up the docker plugin
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
When using `nx release` with Docker projects, the
`release.releaseTagPattern` defined at the root level is not inherited
by release groups. Users must explicitly specify the `releaseTagPattern`
at both the root level AND within
`release.groups.<group>.releaseTagPattern` for it to work correctly when
using 'independent' releases.
Example configuration that doesn't work as expected:
```json
{
"release": {
"releaseTagPattern": "release/{projectName}/{version}",
"groups": {
"apps": {
"projectsRelationship": "independent",
// releaseTagPattern is not inherited here
}
}
}
}
```
## Expected Behavior
The `release.releaseTagPattern` should be automatically inherited by
group configurations, following the same inheritance pattern as other
release configuration properties. Users should only need to specify the
pattern once at the root level unless they want to override it for
specific groups.
With this fix, the above configuration will work correctly, and the
docker releases will use the `release/{projectName}/{version}` pattern
for git tags.
## Related Issue(s)
Fixes #
We should match the version which we install of `@rspack/core` to be the
same as `@nx/rspack` as the mismatch can cause errors:
https://staging.nx.app/runs/McxmSeecWa/task/e2e-rspack%3Ae2e-local
```
> rspack build --node-env=production
● ━━━━━━━━━━━━━━━━━━━━━━━━━ (10%) building builtin:swc-loader??ruleSet[1].rules[2].use[0]!/../my-rspack-react/apps/my-rspack-react/src/../repos/my-rspack-react/node_modules/@nx/rspack/node_modules/@rspack/core/dist/cssExtractLoader.js:141
}) : result, dependencies.length > 0 && this.__internal__setParseMeta(PLUGIN_NAME, JSON.stringify(dependencies)), callback(null, resultSource, void 0, data);
^
TypeError: this.__internal__setParseMeta is not a function
at /../my-rspack-react/node_modules/@nx/rspack/node_modules/@rspack/core/dist/cssExtractLoader.js:141:58
at ../my-rspack-react/node_modules/@nx/rspack/node_modules/@rspack/core/dist/cssExtractLoader.js:142:11
at /../my-rspack-react/node_modules/@rspack/core/dist/index.js:3435:255
at /../my-rspack-react/node_modules/@rspack/core/dist/index.js:3431:120
Node.js v22.16.0
```
This version is also the same as in our migrations for `@nx/rspack`.
References:
https://github.com/nrwl/nx/blob/master/packages/rspack/package.json#L32https://github.com/nrwl/nx/blob/master/packages/rspack/migrations.json#L81
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
before:
gradle tutorial didn't match with other tutorials format
after:
gradle tutorial fits format of other tutorials
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
Currently users running `nx release` without a correct setup will see an
unhelpful message:
```
NX Release group "__default__" matches no projects. Please ensure all release groups match at least one project:
The relevant config is defined here: nx.json
```
This change provides a link to https://nx.dev/features/manage-releases
so users can find the correct information to fix their setup.
This is particular useful when users are curious or checking out `nx
release` for the first time, and may not realize that there are set up
steps.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Error message is not helpful
## Expected Behavior
Provide a link for users to find the info they need
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
In certain cases, `execSync` was not returning data correctly based on
`stdio` settings.
## Expected Behavior
Use `exec` and handle stdout manually to ensure information is retrieved
and processed correctly
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Task ordering for running `prune` was not correct as the
`prune-lockfile` and `copy-workspace-modules` targets need the build to
have succeeded first.
## Expected Behavior
Ensure `prune-lockfile` and `copy-workspace-modules` depends on `build`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/node:app` generator does not set up `prune` as a target to
prune the lockfile for TS Solution based repos. Nor does it handle
workspace modules that may be used by the application.
## Expected Behavior
Create the following targets when generating a node application
- `copy-workspace-modules`
- `prune-lockfile`
- `prune`
The latter should act as a noop, depending on the other two targets to
ensure a fully pruned output
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Docker Version Utils will interpolate `{currentDate|YY.MM.DD}` with the
local timezone.
## Expected Behavior
Force the formatting to be UTC
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Bun's text-based lockfile is not parsed correctly when collecting nodes
and dependencies for the project graph.
## Expected Behavior
Bun's text-based lockfile should be parsed correctly when collecting
nodes and dependencies for the project graph.
## Related Issue(s)
Fixes#31862Fixes#31433Fixes#31338Fixes#30607Fixes#30603Fixes#30466Fixes#30460Fixes#30362Fixes#30302
## Current Behavior
The post install hook creates the project graph... which contains quite
a bit of work and appears to be hanging at times.
## Expected Behavior
The post install hook is slimmer, and has a hard timeout of 30s to avoid
hanging.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31694
## Current Behavior
We do not currently have a plugin for docker to infer targets such as
- build
- run
## Expected Behavior
The Docker Plugin should remain agnostic between tech stacks, but should
allow for the containerization of projects.
It should support initially the ability to build and run images by
inferring targets on projects that contain a Dockerfile.
`nx release` should be expanded to support releasing Docker images to
registries
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When you run `npx -y create-nx-workspace@latest nameofmyrepo-monorepo
--preset=apps --nxCloud=skip --skip-install --skip-prettier --verbose`
it fails because `--skip-install` is passed to the `new` generator (even
though it's not an CNW option), which means no `node_modules` to resolve
`nx/bin/nx`.
## Expected Behavior
Running CNW should not skip install ever.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31834
- Add a label to the TUI terminal pane with the live/actual task
execution duration and estimated duration based on available task
history
- Consolidate the `INTERACTIVE`/`NON-INTERACTIVE` information at the
bottom alongside the instructions to toggle
- Handle smaller available width and hide labels accordingly, with a
priority of Task Name, Duration, Tab to Focus help label when deciding
what to show
- Increase the tick rate to calculate live times every 100ms
## Current Behavior
The ESLint flat config generator crashes with "Debug Failure. False
expression: Negative numbers should be created in combination with
createPrefixUnaryExpression" when running `nx g
@nx/eslint:convert-to-flat-config`.
## Expected Behavior
The generator should handle negative numbers properly and complete
without errors.
## Related Issue(s)
Fixes#31955
Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvelperez@users.noreply.github.com>
## Current Behavior
The `pnpm-parser` does not handle when `importerSnapshot.dependencies`
is undefined and is trying to access indexes of the object.
## Expected Behavior
Add a check to make usre `importerSnapshot.dependencies` exists before
accessing values within it
Allow application names starting with @ symbol to support scoped
packages like @myorg/myapp.
Updated the validation pattern to match the library generator pattern
that already supports this.
Fixes#31229
Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Leosvel Pérez Espinosa <leosvelperez@users.noreply.github.com>
## Current Behavior
The `@nx/js:typescript-sync` generator does not provide details about
the out-of-sync files. It only returns a generic message.
<img width="1155" height="107" alt="image"
src="https://github.com/user-attachments/assets/6fc170cc-6aab-49cd-b17d-764da57b840a"
/>
## Expected Behavior
The `nx sync:check` command should display additional details about the
out-of-sync files if provided by the sync generators. The
`@nx/js:typescript-sync` generator should provide details about the
out-of-sync files.
<img width="1140" height="214" alt="image"
src="https://github.com/user-attachments/assets/3c74df6c-7dc3-4462-b0c9-75bce5bf81b4"
/>
Note: the `nx sync` command will still only display the generic message
to avoid cluttering the logs and the details can be seen in the changes
made to files.
## Current Behavior
When building the project graph nodes, the node `type` is always
inferred as `lib` when `projectType` is not set.
## Expected Behavior
When building the project graph nodes, the node `type` should be derived
correctly using the same logic used by generators when `projectType` is
not set.
## Related Issue(s)
Fixes#31983
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Caleb Ukle <caleb.ukle+github@pm.me>
## Current Behavior
The TUI (Terminal User Interface) is enabled for all environments,
including AI agents like Claude Code, which can cause issues with
AI-driven development workflows.
## Expected Behavior
When an AI agent is detected through environment variables, the TUI
should be automatically disabled to prevent interference with AI-driven
interactions.
## Related Issue(s)
This change improves the developer experience when using AI agents by
automatically detecting their presence and adjusting the interface
accordingly.
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
The native Rust code in nx_walker and logger components was creating
threads that weren't being properly cleaned up, leading to resource
leaks over time.
## Expected Behavior
With these changes, threads are properly managed and cleaned up to
prevent resource leaks, improving the overall stability and performance
of Nx operations.
## Related Issue(s)
This addresses native thread leak issues discovered during development.
Fixes thread leaks in native components
## Current Behavior
The TUI's arrow key handling uses only alternate screen mode detection
to determine whether to send arrow key sequences to programs or handle
scrolling locally. This works for programs like vim, less, and git log,
but fails for enquirer-style prompts that use cursor positioning without
alternate screen mode.
## Expected Behavior
Arrow key handling should properly detect when interactive programs like
enquirer are running and send arrow key sequences to them for
navigation, while maintaining TUI scrolling for regular command output.
## Related Issue(s)
This improves the TUI's interaction with enquirer prompts and similar
interactive programs that don't use alternate screen mode but still need
to receive arrow key input.
## Changes Made
- **Enhanced Detection Logic**: Added `handles_arrow_keys()` method that
detects interactive programs using:
- Alternate screen mode detection (vim, less, git log, htop)
- Cursor movement sequence detection (enquirer-style programs)
- **Refactored Arrow Key Handling**: Updated `handle_arrow_keys()` to
use improved detection
- **Consistent Mouse Event Handling**: Updated `send_mouse_event()` to
use same detection logic
- **Comprehensive Tests**: Added tests for interactive program detection
patterns
## Technical Details
The new `handles_arrow_keys()` method checks for:
1. **Alternate screen mode** - Strong indicator for programs like vim,
less
2. **Cursor control sequences** - Detects enquirer-style programs that
use:
- `\x1b[?25l` / `\x1b[?25h` (hide/show cursor)
- `\x1b[H` (cursor positioning)
- `\x1b[A/B/C/D` (cursor movement)
This ensures enquirer prompts receive proper arrow key navigation while
maintaining backward compatibility with existing TUI scrolling behavior.
Fixes arrow key navigation in enquirer prompts and similar interactive
programs.
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When resolving "./" imports from a nested project, the target project
locator incorrectly resolves to the parent project instead of the
current project.
For example, given:
- `parent-project` at `libs/parent-path`
- `child-project` at `libs/parent-path/child-path` (nested 1 level under
parent)
When importing "./" from `libs/parent-path/child-path/module.ts`, it
incorrectly resolves to `parent-project` instead of `child-project`.
## Expected Behavior
"./" imports from within a nested project should resolve to that
project, not its parent.
## Related Issue(s)
Fixes#31980
### Changes
- add `tsBuildInfoFile` option all packages `tsconfig.lib.json`
- fix `legacy-post-build` executor via `copy-asset-handler` to ignore
dirs that we won't be copying from to improve glob search efficiency.
## Current Behavior
- When the minimal view in the TUI is shown, some borders are initially
shown for a fraction of a second.
- When rendering terminal panes, the scrollbar can be wrongly shown for
a fraction of a second when the PTY dimensions are stale. This looks
like the scrollbar flashes.
## Expected Behavior
- When the minimal view in the TUI is shown, no borders should ever be
shown.
- The scrollbar should only be shown when rendering terminal panes when
needed.
## Current Behavior
Angular tests run with other tests in parallel causing memory issues.
## Expected Behavior
Angular tests are isolated to run on their own agent to prevent memory
issues.
## Related Issue(s)
This is a maintenance improvement to prevent CI memory issues.
Fixes nrwl/nx internal issue
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Security package is removed. This resolution fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remove the resolution.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Angular projects use `jest-preset-angular` v14, which doesn't support
Jest v30.
Note: When support for Jest v30 was added, `jest-preset-angular` didn't
have a version explicitly supporting it.
## Expected Behavior
Angular projects should use `jest-preset-angular` v15, which supports
Jest v30.
## Related Issue(s)
Fixes#32024
BREAKING CHANGE: Stylus (.styl) files are no longer supported.
Stylus has been deprecated and was slated to be removed in Nx 20.
Now we are removing it.
- Remove `stylus` and `stylus-loader` dependencies
- Remove `deprecated-stylus-loader` file
- Remove `stylus` configuration from `webpack` and `rspack` plugins
- Remove `'styl'` option from `rspack` generator schemas and TypeScript
definitions
- Remove `.styl`/`.stylus` extensions from executor schema file
completion globs
MISC
Even though we removed stylus from our repo as a dependency other
projects in the workspace still have stylus as an optional dependency:
- Vite
- Astro
So we add a placeholder for it since on npm registry there is a
_security_ placeholder.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
`npm-parser` for lockfile pruning is trying to run `Object.entries` on a
potentially null or undefined object (packageJson.dependencies).
## Expected Behavior
Ensure `?? {}` is used when evaluating `Object.entries`
### Changes
The stylus npm registry has been compromised.
So can resolve `stylus` with `npm:ignore@*` it tells the package manager
to replace the dependency with the ignore package from npm registry.
Until we can merge: https://github.com/nrwl/nx/pull/32035
## Current Behavior
In the TUI, opening the Terminal Pane for a task with the space bar,
navigating to another task, and pressing "1" to pin it, results in the
terminal pane displaying the output of the task for which the space bar
was pressed initially instead of the pinned task.
## Expected Behavior
Pinning tasks in the TUI should work correctly and always display the
output of the pinned task.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
improve doc page where people land after running `nx init`
- clarify how to use nx after setup
- make sure to update CI configs
- how to finish nx cloud setup if opted-in for cloud
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
add documentation for build-ci target for gradle
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
currently there is no build-ci target documented
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
tutorial intro language is subpar
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
improve tutorial intro language
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The migration for Jest v30 is missing package updates for `ts-jest` and
`jest-util`.
## Expected Behavior
The migration for Jest v30 should have package updates for `ts-jest` and
`jest-util`.
## Current Behavior
When running the Jest `replace-removed-matcher-aliases` migration on
Windows, it resolves the spec files incorrectly and fails.
## Expected Behavior
Running the Jest `replace-removed-matcher-aliases` migration should work
correctly regardless the OS.
## Related Issue(s)
Fixes#31991
## Current Behavior
When using the TS solution setup, tasks inferred by the
`@nx/next/plugin` do not have the `@nx/js:typescript-sync` generator
set.
## Expected Behavior
When using the TS solution setup, tasks inferred by the
`@nx/next/plugin` should have the `@nx/js:typescript-sync` generator
set.
## Related Issue(s)
Fixes#31983
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When running ESLint using the `@nx/eslint:lint` executor with `--quiet`
and `--fix`, and there are errors, no fix is made, and the task
incorrectly succeeds.
This is a regression introduced by
https://github.com/nrwl/nx/commit/9406d2bfdb15e33ad85345533f96f6136130e817,
which updated the executor to not fix warnings when `--quiet` is used,
but the solution was incorrect.
## Expected Behavior
When running ESLint using the `@nx/eslint:lint` executor with `--quiet`
and `--fix`, and there are errors, fixes should be applied, and the task
should succeed if there are no remaining errors. It should not fix
warnings.
## Related Issue(s)
Fixes#31868
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Jest is currently pinned to version 29 due to compatibility issues with
synckit@0.11.10 that caused TypeErrors in Jest tests.
## Expected Behavior
With the synckit compatibility issue resolved in v0.11.11, Jest can be
safely upgraded back to version 30, providing users with the latest Jest
features and improvements.
## Related Issue(s)
The underlying synckit compatibility issue has been fixed:
https://github.com/un-ts/synckit/issues/252
This reverts the temporary downgrade that was applied in #31981.
Fixes the Jest version regression by restoring Jest 30 support.
Updating Nx from 21.3.0-beta.7 to 21.3.0-rc.0
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
## Current Behavior
When running nx-cloud commands like `nx start-ci-run` in environments
without local Nx installation, users get this error:
```
NX Could not find Nx modules at "/path/to/workspace".
Have you run npm/yarn install?
```
This prevents legitimate use of nx-cloud commands in CI environments
that don't have local Nx modules installed.
## Expected Behavior
nx-cloud commands should be able to run using the global Nx installation
without requiring local Nx modules, since they're designed to work
independently of the local workspace setup.
## Related Issue(s)
This fixes scenarios where users run `nx start-ci-run` in CI
environments without local Nx installation.
## Changes Made
- Added `isNxCloudCommand()` function to identify nx-cloud commands:
`start-ci-run`, `login`, `logout`, `connect`, `view-logs`, `fix-ci`,
`record`
- Modified the missing local installation check to exclude nx-cloud
commands
- Added execution path for nx-cloud commands when no local Nx is
available - they now run via the global nx-commands module
- Preserves the error check for regular Nx commands that require local
installation
## Testing
- Verified that nx-cloud commands are properly identified
- Confirmed that regular Nx commands still show the error when local Nx
is missing
- Ensured nx-cloud commands can run without local Nx installation
## Current Behavior
The `create-nx-workspace` command only creates local git repositories
and does not provide any integration with GitHub for pushing the newly
created workspace to a remote repository.
## Expected Behavior
The `create-nx-workspace` command should offer users the option to
automatically create a GitHub repository and push their new workspace to
it using the GitHub CLI (`gh`), streamlining the workflow from workspace
creation to remote repository setup.
## Changes Made
- **New Options**: Added `skipGitHubPush` and `verbose` command-line
options
- **GitHub Integration**: Integrated GitHub repository creation and push
workflow into the main create-workspace process
- **Interactive Prompts**: Added user-friendly prompts for GitHub
repository creation with validation
- **Async Refactor**: Converted git utilities from sync to async/await
pattern for better error handling
- **Bug Fix**: Fixed `gh repo create` command to include `--source` flag
for proper directory specification
- **Error Handling**: Added comprehensive error handling with optional
verbose logging
## Implementation Details
### New CLI Options
- `--skipGitHubPush`: Skip pushing to GitHub via gh CLI (default: false)
- `--verbose` (`-v`): Enable verbose logging for detailed error messages
### Workflow Integration
- After successful git initialization and commit, prompts user if they
want to push to GitHub
- Uses `gh` CLI to authenticate and create repository
- Provides default repository name format (`username/workspace-name`)
- Validates repository name format
- Handles errors gracefully with helpful fallback instructions
### Technical Changes
- Refactored `git.ts` utilities to use `execAndWait` and `spawnAndWait`
for better async handling
- Added `pushToGitHub` function with comprehensive error handling
- Updated `CreateWorkspaceOptions` interface with new optional
properties
- Enhanced command-line argument parsing in `yargs-options.ts`
## Testing
The changes maintain backward compatibility - existing workflows
continue to work unchanged. The new GitHub integration is opt-in and
gracefully handles cases where:
- GitHub CLI is not installed
- User is not authenticated with GitHub
- Network issues prevent repository creation
- User chooses not to push to GitHub
## Related Issue(s)
This PR enhances the user experience by providing seamless integration
between workspace creation and GitHub repository setup.
## Current Behavior
The static build for a React Module Federation application can suffer
from issues where react is not initialised on load.
This is caused by Module Federation trying to lazily instantiate the
library.
## Expected Behavior
Ensure that React deps are marked as eager in the module federation
config to allow them to be instantiated on load
## Related Issue(s)
Fixes#31612
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <Coly010@users.noreply.github.com>
## Current Behavior
The workspace packages logic for pruning lockfile assumes the
jsPackageName is the same as the node name.
This is not always the case.
## Expected Behavior
Ensure the actual node name is used to reference the node in the project
graph
## Summary
- support configuring max cache size via NX_MAX_CACHE_SIZE env var
- show max cache size from env var in `nx report`
- document the new `NX_MAX_CACHE_SIZE` option
- test NX_MAX_CACHE_SIZE in e2e cache tests
## Testing
- `pnpm nx run-many -t lint,test,build` *(failed: NX Lexer error)*
- `pnpm test:e2e` *(failed: Command "test:e2e" not found)*
- `pnpm e2e` *(failed: Failed to process project graph)*
------
https://chatgpt.com/codex/tasks/task_e_68503bff022c832c8c014c61432aa2ed
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running Nx tasks without the daemon, tui, and using run-commands w/
serially running tasks, its possible that Nx will not properly terminate
on receiving SIGTERM.
## Expected Behavior
Nx properly shuts down child tasks on receiving SIGTERM
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When an Nx workspace exists inside a subdirectory of another git
repository or when parent directories contain `.gitignore` files, those
ignore patterns can affect file traversal within the Nx workspace,
making project resolution non-deterministic.
For example, if a workspace is inside a directory with `*` in its
`.gitignore`, Nx fails to properly traverse workspace files.
## Expected Behavior
Nx should respect `.gitignore` files in a smart way:
- **Workspace is git root**: Ignores all parent gitignore files
- **Workspace nested in git repo**: Respects gitignore files within the
git repository but ignores any gitignore files above the git root
- **No git repo found**: Respects all parent gitignore files (backwards
compatibility)
This ensures deterministic project resolution regardless of where the
workspace is located.
## Related Issue(s)
Fixes#27368, #28000, #27295, #28123, #29413
Supersedes #29245 (incorporates feedback from @Cammisuli and @adamalton)
## Implementation Details
The fix implements smart gitignore boundary detection that:
1. **Finds the nearest git repository root** by walking up the directory
tree
2. **Uses built-in git ignore handling** for maximum compatibility
3. **Disables automatic parent discovery** and manually adds only
relevant `.gitignore` files
4. **Stops at git repository boundaries** to prevent external gitignore
files from affecting the workspace
This approach addresses the feedback from the original PR #29245 to
handle both:
- Standalone workspaces (where workspace root = git root)
- Workspaces nested within larger git repositories
The solution leverages the `ignore` crate's existing functionality while
providing precise control over which ignore files are considered.
## Test Plan
- [x] Unit tests covering all three scenarios
- [x] Workspace is git root: ignores parent gitignores
- [x] Workspace nested in git repo: respects repo gitignores, ignores
external ones
- [x] No git repo: uses all parent gitignores (backwards compatibility)
- [x] All existing walker tests continue to pass
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Adam Biggs <adam.biggs@lmpm.com>
## Current Behavior
The `nx watch` command currently requires a file change before executing
the specified command for the first time.
## Expected Behavior
Add support for running the watch command once before watching for
changes. This is useful when you want to see results immediately without
having to make a file change first.
## Related Issue(s)
N/A - Feature addition
## Implementation Details
- Added a new `--initialRun` flag (alias `-i`) to the `nx watch` command
- When the flag is set to `true`, the command executes once before
setting up the file watcher
- Works with both `--all` mode and specific project selections
- Default value is `false` to maintain backward compatibility
- Documentation has been updated to reflect this new option
## Usage Examples
```bash
# Run the command initially, then watch for changes
nx watch --all --initialRun -- echo "Running command"
# Or with the alias
nx watch --projects=myapp -i -- npm run test
```
## Test Plan
- [ ] Manual testing with `--all` flag
- [ ] Manual testing with specific projects
- [ ] Verify command runs initially when flag is set
- [ ] Verify command does not run initially when flag is not set
(default behavior)
- [ ] Documentation generated correctly
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The daemon doesn't log several things which would be helpful when
troubleshooting issues
## Expected Behavior
There are several more logs
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/webpack` and `@nx/rspack` packages depend on a pinned version
of `less` and `less-loader`.
This causes an issue with dependency resolution for packages that
require a different version of these packages.
## Expected Behavior
Use a range for `less` and `less-loader` to aid package managers in
resolution and hoisting.
## Related Issue(s)
Fixes#31953
## Current Behavior
Nx switched to use sass-loader with `modern-compiler` api. However, it
did not update to use `loadPaths` instead of `includePaths`.
## Expected Behavior
Use `loadPaths`.
## Related Issue(s)
Fixes#30340
## Current Behavior
<!-- This is the behavior we have today -->
Scroll position gets reset when unrelated tasks finish. Additionally,
scrolling is just really slow.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This pull request introduces momentum-based scrolling and improves
scroll position preservation across terminal panes and pseudo-terminal
instances (`PtyInstance`). It also adds a new `ScrollMomentum` module to
manage scrolling behavior dynamically based on user input patterns. The
changes enhance user experience by making scrolling smoother and more
intuitive, especially during rapid or sustained scrolling.
### Scroll Momentum Enhancements:
* Added the `ScrollMomentum` module to calculate dynamic scrolling
behavior based on time intervals and direction changes, allowing for
accelerated scrolling during sustained input.
(`packages/nx/src/native/tui/scroll_momentum.rs`,
[packages/nx/src/native/tui/scroll_momentum.rsR1-R101](diffhunk://#diff-60e4cfcd0a48b7d32e565a9254f89f142587e07a37536ca103b1ae76a760135eR1-R101))
* Integrated momentum-based scrolling into `TerminalPaneData` and
`PtyInstance`, replacing static scroll methods with dynamic ones
(`scroll_up` and `scroll_down`) that use calculated momentum values.
(`packages/nx/src/native/tui/components/terminal_pane.rs`,
[[1]](diffhunk://#diff-494d587e52e864f34496326a7453461a9a15e5c136d504a54db36a59cae7c446L45-R66);
`packages/nx/src/native/tui/pty.rs`,
[[2]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L122-R158)
[[3]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L148-R192)
[[4]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L175-R231)
### Scroll Position Preservation:
* Enhanced `PtyInstance` to preserve scroll position during terminal
resize operations, ensuring better continuity when dimensions change.
(`packages/nx/src/native/tui/pty.rs`,
[[1]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L76-R91)
[[2]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14L91-R120)
### Code Improvements:
* Added momentum reset logic when switching interactive modes or
changing scroll direction to avoid abrupt changes in scrolling behavior.
(`packages/nx/src/native/tui/components/terminal_pane.rs`,
[[1]](diffhunk://#diff-494d587e52e864f34496326a7453461a9a15e5c136d504a54db36a59cae7c446R150-R169);
`packages/nx/src/native/tui/scroll_momentum.rs`,
[[2]](diffhunk://#diff-60e4cfcd0a48b7d32e565a9254f89f142587e07a37536ca103b1ae76a760135eR1-R101)
* Updated `TerminalPaneData` and `PtyInstance` constructors to
initialize `ScrollMomentum` instances for consistent scrolling state
management. (`packages/nx/src/native/tui/components/terminal_pane.rs`,
[[1]](diffhunk://#diff-494d587e52e864f34496326a7453461a9a15e5c136d504a54db36a59cae7c446R38);
`packages/nx/src/native/tui/pty.rs`,
[[2]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14R53)
[[3]](diffhunk://#diff-1e180729578f1157895b8cd0df25b87ba902ac7804e3a944601d28d3cf437b14R67)
These changes collectively improve the usability of terminal panes and
pseudo-terminal instances by making scrolling more responsive and
preserving user context during resize events.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we generate a router-router app the e2e test generated expects the
server to be ran on port `4300`.
Which fails because react-router serves from only one port and it's the
dev port which is defaults to `4200`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This should work out of the box
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When generating stories, the generation can fail due to a bad path
normalization with:
```bash
NX Failed to read src/src/app/app.tsx
Pass --verbose to see the stacktrace.
```
## Expected Behavior
Generating stories should work correctly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This line was added by accident.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This line is removed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, the CI workflow templates and setup messages contain
potentially confusing or outdated information:
1. CI workflow templates include a comment about "Nx Affected runs only
tasks affected by the changes in this PR/commit. Learn more:
https://nx.dev/ci/features/affected." which may be redundant or
confusing
2. The setup messages for CI and remote cache simply say "Finish it by
visiting: {url}" which doesn't provide clear next steps
## Expected Behavior
With these changes:
1. The redundant affected comment is removed from CI workflow templates
to reduce noise
2. The setup messages are improved to say "Push your repository and
finish the setup: {url}" which provides clearer guidance on what the
user needs to do next
3. Jest snapshot test references are updated to use the current Jest
documentation URL
## Related Issue(s)
This is a minor cleanup improvement to reduce confusion and provide
better user guidance in the CI setup flow.
Improve the generation of Storybook stories:
- Import relevant types from the appropriate packages
- Use TypeScript `satisfies` operator
- Simplify the selector in the generated interaction test example
- Fix an issue when source root is not set in the project configuration
When we generate a random port in our node e2e tests we should ensure
that the random generation port generation range starts from 1024.
Also, move the `getRandomPort` function to `e2e-utils` so that other
tests benefit from this change.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
In some rare occurences we've observed our atomization plugins returning
an invalid list of test files. We've only seen this in the jest plugin
in our internal monorepo under a very specific yet hard to repro area.
## Expected Behavior
If this occurs, the plugin errors.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
## Current Behavior
Currently, there is no way for a target using `run-commands` to define
where in the command args are attached.
This is problematic in some tooling cases where args positional location
matters
## Expected Behavior
Placing `{args}` into the command should allow for interpolation of any
and all args provided.
Therefore commands can be written such as `docker run {args} imageRef`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, when options.install=true (need to do pod install), it only
syncs deps.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
make it sync deps regardless of options.install, so when developers
choose to run `pod-install` after, it will work right away.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when serve up the react-native app using web configuration, it defaults
tsconfig to
```
tsConfig: joinPathFragments(options.projectRoot, 'tsconfig.app.json'),
```
which is not right
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
not hard code ts config path, add a function determineTsConfig for that
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
NX has a dependency to a [vulnerable version of
esbuild](https://github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99)
## Expected Behavior
Updating several `@module-federation` dependencies to update esbuild to
v0.25.5 and fix the vulnerability
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31923
## Current Behavior
When a task with no PTY (e.g. a task using the `nx:noop` executor) has
its output pane open and it finishes successfully, no output is shown,
and there's a blank space to the right of the task list where the output
pane is meant to be.
<img width="1366" height="413" alt="image"
src="https://github.com/user-attachments/assets/fc34cc18-1bed-4d73-9b94-5a25069e8a3d"
/>
## Expected Behavior
When a task with no PTY (e.g. a task using the `nx:noop` executor) has
its output pane open and it finishes successfully, the output pane
should be correctly rendered in a successful status.
<img width="1365" height="411" alt="image"
src="https://github.com/user-attachments/assets/cb8862d5-f1c2-4aa6-a098-f710020e64f4"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
This PR adds support for the `proxyConfig` option in the
@rspack/dev-server executor, similarly to the existing option in the
matching Webpack executor. This new options is another step for allowing
simpler migration to Rspack when coming from Webpack, adding to the
feature parity of the Rspack executor.
## Current Behavior
The `@nx/rspack:dev-server` executor does not allow for passing a
`proxyConfig` as an option, opposed to the matching Webpack executor,
that does.
## Expected Behavior
The `@nx/rspack:dev-server` executor allows for passing a `proxyConfig`
option, same as the `@nx/webpack:dev-server` executor.
## Related Issue(s)
None.
## Current Behaviour
We are having a lot of cache misses due to using `compilerOptions` the
key for registering the `ts-node` service.
This can cause out-of-memory errors due to several registrations of the
`ts-node` service consecutively.
https://github.com/nrwl/nx/actions/runs/16233768215/job/45840886378
## Expected Behaviour
The `ts-node` service _should_ have cache hits so that the knock-on
effect of multiple registration (out-of-memory) does not happen via
plugins.
## MISC
If we set `NX_PREFER_TS_NODE` env variable we should not show the
warning fallback message.
## Current Behavior
Gray for secondary light foreground has low contrast in light themes
## Expected Behavior
This pull request includes a small change to the `Theme` implementation
in the `packages/nx/src/native/tui/theme.rs` file. The change updates
the `secondary_fg` color from `Color::Gray` to `Color::DarkGray` to
improve visual contrast.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo is using Nx `21.3.0-beta.5`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo is using Nx `21.3.0-beta.6`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When the available space in the TUI task list is small, task names can
be cropped while still displaying the Duration column.
## Expected Behavior
When the available space is insufficient, task names should be
prioritized over duration. Additionally, update the overall column
display decision logic to better use the available space.
### Before
<img width="622" height="368" alt="image"
src="https://github.com/user-attachments/assets/bd486408-abef-4601-9339-b2bf3c589287"
/>
### After
<img width="618" height="369" alt="image"
src="https://github.com/user-attachments/assets/5331172a-23b8-4924-8f3f-b2b107d011d8"
/>
## Current Behavior
Jest v30 is not supported.
**Note**: this is currently awaiting for `jest-preset-angular` to
support Jest v30:
https://github.com/thymikee/jest-preset-angular/pull/3175.
## Expected Behavior
Jest v30 should be supported.
## Related Issue(s)
Fixes#31778
## Current Behavior
When tasks are pending (not started yet), the TUI shows an empty
terminal pane with no information about why the task is waiting. Users
have no visibility into task dependencies or their status.
## Expected Behavior
When a task is pending, the TUI now displays a comprehensive dependency
view showing:
- Progress header indicating how many dependencies are complete vs total
- Scrollable list of all dependencies (direct and transitive) with
real-time status updates
- Support for continuous tasks where InProgress/Stopped are considered
complete
- Keyboard navigation (arrow keys, j/k vim keys, page up/down)
- Dependencies sorted by complexity (most dependencies first), then
alphabetically
### Dependencies Pending
### Dependencies Ready but waiting for thread
### Scrollable
## Related Issue(s)
This enhancement improves the TUI experience by providing clear
visibility into task dependencies, making it easier to understand build
pipelines and debug issues.
---------
Co-authored-by: Claude <noreply@anthropic.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
excludeDependsOn is true by default, but got this error when running `nx
run nx-api:compileTestKotlin`:
```
* What went wrong:
Execution failed for task ':nx-api:compileTestKotlin'.
> Error while evaluating property 'friendPathsSet$kotlin_gradle_plugin_common' of task ':nx-api:compileTestKotlin'.
> Querying the mapped value of provider(java.util.Set) before task ':nx-api:compileJava' has completed is not supported
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
have a way to turn off excludeDependsOn
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
Fixes #
## Summary
- support `--tui` flag alongside `--output-style`
- expose tui option in NxArgs
- respect `tui` CLI option in TUI detection
- warn when environment can't display TUI even if flag is set
- test tui CLI flag parsing
## Testing
- `pnpm nx run-many -t lint,test,build` *(fails: Failed to process
project graph)*
- `pnpm test:e2e` *(fails: Command "test:e2e" not found)*
------
https://chatgpt.com/codex/tasks/task_e_68517adad738832c81ecdfba7f4a1feb
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Craigory Coppola <AgentEnder@users.noreply.github.com>
Introduced a new "Credit Pricing" reference page for Nx Cloud, detailing credit consumption and pricing metrics. Updated documentation structure, menus, sitemap, and headers to integrate the new page. Removed outdated FAQ entries and replaced the "Pricing" reference with the new "Credits Pricing" link in navigation. Adjusted related redirects and UI components for consistency.
## Current Behavior
The CI workflow generators for both @nx/workspace and @nx/gradle
currently reference the old documentation URL `https://nx.dev/ai` when
explaining the `nx fix-ci` command.
## Expected Behavior
The CI workflow generators should reference the correct self-healing CI
documentation URL `https://nx.dev/ci/features/self-healing-ci`.
## Related Issue(s)
<\!-- Please link the issue being fixed so it gets closed when this is
merged. -->
This is a follow-up to update the documentation links to point to the
correct self-healing CI feature page.
## Changes Made
- Updated @nx/workspace CI workflow generator to use the correct
documentation URL
- Updated @nx/gradle CI workflow generator to use the correct
documentation URL
- Updated all snapshot tests to reflect the new URLs
- Updated tutorial documentation that shows the CI workflow examples
**Files Updated:**
- `packages/workspace/src/generators/ci-workflow/ci-workflow.ts`
- `packages/gradle/src/generators/ci-workflow/generator.ts`
-
`packages/workspace/src/generators/ci-workflow/__snapshots__/ci-workflow.spec.ts.snap`
-
`packages/gradle/src/generators/ci-workflow/__snapshots__/generator.spec.ts.snap`
- `packages/workspace/src/generators/ci-workflow/ci-workflow.spec.ts`
- `docs/shared/tutorials/react-monorepo.md`
- `docs/shared/tutorials/typescript-packages.md`
- `docs/shared/tutorials/angular-monorepo.md`
- `docs/shared/tutorials/gradle.md`
All changes ensure users are directed to the correct self-healing CI
documentation when using the `nx fix-ci` command in their CI workflows.
## Current Behavior
Angular v20.1 is not supported.
## Expected Behavior
Angular v20.1 should be supported.
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
## Current Behavior
The `sourceRoot` project configuration property is optional. Several
places in the codebase do not properly handle this, which can result in
issues.
## Expected Behavior
A missing `sourceRoot` project configuration property should be handled
correctly throughout the codebase.
## Related Issue(s)
Fixes#30638
## Current Behavior
When generating a facade with the NgRx generators, the spec file imports
a non-existent `readFirst` from `@nx/angular/testing`. That helper was
deprecated for a long time and removed in Nx v21, but this usage was
missed, causing those tests to fail.
The e2e tests that cover this were disabled for the pnpm package
manager, so it was not caught in the PR/main CI pipeline. It was
correctly failing in the Nightly CI pipeline. The tests are now enabled
for all package managers.
Nightly failure:
https://staging.nx.app/runs/uRlR20Fzt9/task/e2e-angular%3Ae2e-local
## Expected Behavior
When generating a facade with the NgRx generators, the spec file for the
facade should be correct.
## Related Issue(s)
Fixes #
## Current Behavior
Currently, users can opt out of sorting the root tsconfig file path
mappings by providing `--sort-root-tsconfig-paths=false` to the `nx
format` commands, or by providing `{ sortRootTsconfigPaths: false }` to
the `formatFiles` function when invoked programmatically. Still, Nx
generators sort the root tsconfig file path mappings by default, and the
only way to bypass that is to run two different commands:
```bash
nx g component path/to/component --skip-format
nx format:write --sort-root-tsconfig-paths=false
```
## Expected Behavior
Users should be able to easily opt out of sorting the root tsconfig file
path mappings by setting the `NX_FORMAT_SORT_TSCONFIG_PATHS` environment
variable to `false`. With that set, all the relevant commands, including
`nx generate` will respect it.
## Related Issue(s)
Fixes#29043
## Current Behavior
Nx-cloud commands are scattered across different directories in the
command-line structure, making them harder to find and maintain.
Commands like `record`, `start-ci-run`, and `fix-ci` don't exist as
direct nx commands. The fix-ci command in CI workflows doesn't run when
previous steps fail.
## Expected Behavior
All nx-cloud related commands are organized in a dedicated directory
with consistent patterns and shared utilities. New commands provide
better CI/CD integration. The fix-ci command always runs to provide
AI-powered recommendations even when builds fail.
## Related Issue(s)
Improves code organization and adds missing CI workflow commands for
better developer experience.
## Changes Made
### 🏗️ **Reorganized nx-cloud commands**
- Created `/packages/nx/src/command-line/nx-cloud/` directory structure
- Moved existing commands (`login`, `logout`, `connect`) to new location
- Extracted shared utility function to eliminate code duplication
### 🆕 **Added new nx-cloud commands**
- `nx record` - Records command execution for distributed task execution
- `nx start-ci-run` - Starts new CI run for distributed execution
- `nx fix-ci` - Fixes CI configuration issues with AI-powered
suggestions
### 🔧 **Code quality improvements**
- Reduced code duplication by 80+ lines across command implementations
- All commands now follow consistent patterns using shared utilities
- Fixed import paths throughout codebase after reorganization
### 🚀 **Enhanced CI workflow support**
- **Gradle Generator**: Added `alwaysRun` property to Command type for
conditional execution
- **Template Updates**: GitHub Actions and CircleCI templates now handle
`alwaysRun` property
- **Fix-CI Integration**: The `fix-ci` command now always runs
regardless of previous step failures
### 📚 **Comprehensive documentation updates**
- Updated all CI provider documentation (GitHub Actions, Azure DevOps,
GitLab, Bitbucket, CircleCI, Jenkins)
- Updated Nx Cloud tutorial documentation (GitHub Actions, CircleCI)
- **Framework Tutorials**: Added `if: always()` condition to fix-ci
commands in:
- Gradle tutorial (`/docs/shared/tutorials/gradle.md`)
- Angular monorepo tutorial
(`/docs/shared/tutorials/angular-monorepo.md`)
- React monorepo tutorial (`/docs/shared/tutorials/react-monorepo.md`)
- TypeScript packages tutorial
(`/docs/shared/tutorials/typescript-packages.md`)
- Added proper documentation linking for all new commands
- All validation passes (TypeScript, formatting, documentation)
### 🎯 **Key Technical Improvements**
- **Always-Run Logic**: Fix-ci command uses platform-specific
conditional execution:
- GitHub Actions: `if: always()`
- CircleCI: `when: always`
- Azure DevOps: `condition: always()`
- **Consistent Patterns**: All nx-cloud commands follow unified
implementation approach
- **Backward Compatibility**: All existing functionality preserved
during reorganization
All nx-cloud commands now provide a more cohesive experience with better
CI integration, ensuring users get AI-powered recommendations even when
builds fail.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
For really large objects (particularly those containing large strings)
JSON.stringify can fail
## Expected Behavior
Daemon serialization doesn't fail for the same strings when setting
`NX_USE_V8_SERIALIZER=true`. This should become the default behavior.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
The existing parallelization example does not work correctly due to the
encapsulated run_command swallowing the status codes and passing the
runs with a failed command.
If users are interested in how to parallelize the tasks they can easily
find it today. We should provide minimal example like we do for other CI
providers.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This reverts commit
[a745ca5dd6fac1c91233976b9fe3713a7018cfe3](https://github.com/nrwl/nx/pull/31860/commits/a745ca5dd6fac1c91233976b9fe3713a7018cfe3).
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/31837
The main Nx Cloud page was completely rebuilt with a new component structure, replacing the old sections (`Hero`, `TrustedBy`, `FasterAndCheaper`, etc.) with new ones like `NxCloudHero`, `CiBottleneck`, `TimeToGreen`, `Features`, and others.
## Summary
This PR refactors the @nx/workspace CI workflow generator to adopt the
same centralized command generation pattern used by the Gradle
generator, making it more maintainable and consistent.
## Key Changes
### 1. Centralized Command Generation
- Added `getCiCommands()` function that generates command arrays for all
CI providers
- Replaced hardcoded commands in templates with dynamic command
substitution
- All CI providers now use identical commands with provider-specific
formatting
### 2. Performance Improvement
- Replaced `nx affected` with `nx run-many` for better performance
- Updated all CI workflow templates and snapshots accordingly
### 3. Better Code Organization
- Separated nx-cloud record comments from nx-affected comments
- Added helper functions `getCiPrefix()` and `getCiArgs()` for cleaner
code
- Improved comment clarity to guide users on when to switch to nx
affected
### 4. Bitbucket Prefix Fix
- Fixed inconsistent YAML formatting in Bitbucket pipelines
- Pull requests section: no prefix for comments
- Branches section: proper "- " prefix for comments
### 5. Template Consistency
- All CI providers (GitHub, Azure, GitLab, CircleCI, Bitbucket) now
generate identical commands
- Consistent comment structure across all templates
- Updated tutorial template to match new format
## Test Results
- ✅ All 114 tests passing
- ✅ All 95 snapshots updated and verified
- ✅ 100% backward compatibility maintained
## Benefits
1. **Maintainability**: Changes to commands only need to be made in one
place
2. **Consistency**: All CI providers use identical commands and comments
3. **Performance**: nx run-many provides better performance than nx
affected
4. **Extensibility**: Easy to add new CI providers or modify existing
ones
5. **Clean Architecture**: Follows the same pattern as other generators
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
for spring-framework
```
rootProject.children.each {project ->
project.buildFileName = "${project.name}.gradle"
}
```
it got custom build file name
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- change nxProjectGraph plugin, add buildFiles in the output json like:
```
{
"nodes": {},
...
"buildFiles": ["build.gradle"]
}
```
then, it get the build files from reports, combine build files from
build.gradle and custom build files from reports.
```
const allBuildFiles = Array.from(
new Set([...buildFilesFromSplitConfigFiles, ...buildFiles])
);
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Inserted an announcement callout highlighting the upcoming Nx Essentials Online Workshop (July 29-30) in the Getting Started and Quick Start documentation pages. Includes a link for registration and early bird details.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
for gradle, its inputs depends on outputs of its dependsOn task. (e.g.
jar task)
however, if the output file does not exist, (for example, running for
1st time in ci), it will not add to inputs.
when getting inputs, it would give a warning like
```
file or directory '/Users/emily/code/ocean/dist/libs/shared/db-schema-kotlin/classes/java/main', not found
file or directory '/Users/emily/code/ocean/dist/libs/shared/db-schema-kotlin/classes/kotlin/main', not found
file or directory '/Users/emily/code/ocean/dist/libs/shared/db-schema-kotlin/resources/main', not found
```
it is a warning, not an error, so can't be caught.
```
In Gradle's file resolution internals:
When you call task.inputs.files → Gradle resolves each file/directory.
If a declared file or dir does not exist AND it's allowed to be missing, Gradle does not throw an error — instead it logs:
file or directory '...' not found
This log is just an INFO or DEBUG message.
Gradle's normal file resolution is designed to be tolerant —
so missing files do NOT stop the build by default
```
## Expected Behavior
this solution basically take AL
<img width="1106" alt="Screenshot 2025-06-22 at 1 02 33 PM"
src="https://github.com/user-attachments/assets/7a6e8a50-44ec-4c83-bf3d-dc52346b331d"
/>
L of outputs of dependsOn tasks and add to inputs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The getPackageManagerCommand call in the new generator has a long line
that doesn't follow the codebase's formatting standards.
## Expected Behavior
The code should be properly formatted with line breaks for better
readability.
## Related Issue(s)
Code formatting improvement - no related issue.
This PR addresses the issue where the `eslint-plugin` rules fail to
`require()` modules during development when working with ts source
files. The problem occurs because `require.resolve()` finds .js paths in
package.json exports, but the actual .js files don't exist in
development mode - only .ts files are present.
So when you `require()` and the file is loaded NodeJS throws an error
because the `.js` imports cannot be resolved.
This can occur in a ts solution workspace environment where the failure
is not accommodating.
Instead, we can use `tsquery` to check if the file has a valid named
function export.
## Current Behavior
The native cache system has minimal logging, making it difficult to
debug issues or understand what's happening during cache operations.
When problems occur, there's insufficient visibility into:
- File copying operations and their progress
- Output expansion and glob pattern matching
- Cache PUT operation timing and success/failure details
- Directory creation and cleanup processes
## Expected Behavior
With these changes, the native cache system provides comprehensive
logging that:
- Tracks all file operations with sizes and timing
- Provides detailed visibility into glob pattern expansion
- Logs cache PUT operations with performance metrics
- Includes trace-level debugging for troubleshooting
- Makes it easier to diagnose cache-related issues
## Related Issue(s)
This enhancement improves the observability and debugging capabilities
of the native cache system without changing its core functionality.
## Changes Made
- **Enhanced cache PUT operations**: Added timing metrics and detailed
logging for each step
- **Improved file copying**: Added progress tracking, size reporting,
and detailed trace logs
- **Better output expansion**: Added comprehensive logging for glob
pattern analysis and path validation
- **Fixed borrow checker error**: Resolved compilation issue in file_ops
copy function
- **Comprehensive tracing**: Added trace and debug logging throughout
the cache operations
The logging follows a structured approach:
- `trace\!()` for detailed step-by-step operations
- `debug\!()` for summary information and timing metrics
- Proper error context for debugging issues
This makes the native cache system much more observable and easier to
debug when issues arise.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Updated tests to utilize the `customRegistryUrl` variable instead of hardcoded `http://localhost:7190` URLs, improving maintainability and flexibility.
## Current Behavior
When using third-party presets with `npx create-nx-workspace`, passing
framework values other than the predefined backend frameworks fails with
a schema validation error:
```
Error: Property 'framework' does not match the schema. 'angular' should be one of express,koa,fastify,nest,none.
```
For example:
```bash
npx create-nx-workspace --preset=@rig/cli@alpha --framework=angular --theme=pcb --name=hello-world
```
## Expected Behavior
Third-party presets should be able to pass any framework value without
schema validation errors, allowing for greater flexibility in the Nx
ecosystem.
## Related Issue(s)
This fixes the issue where third-party presets cannot pass framework
values like 'angular', 'react', 'vue', etc., due to overly restrictive
schema validation.
## Changes
- Removed the `enum` constraint from the `framework` property in the
workspace preset generator schema
- The property remains a string type but now accepts any value
- Maintains backward compatibility with existing functionality
The built-in Nx preset generators still only handle frameworks they know
about, but the schema validation no longer blocks third-party presets
from passing other framework values.
## Test plan
- [x] Workspace package builds successfully
- [x] Schema validation allows any string value for framework property
- [x] Backward compatibility maintained for existing presets
- [ ] Manual test: `npx create-nx-workspace --preset=@rig/cli@alpha
--framework=angular` should work without schema validation errors
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
Co-authored-by: Claude <claude@anthropic.com>
Running Nx in CI without a remote cache is a common misconfiguration that leads to slow, inefficient builds. This change introduces a proactive warning to prevent this "silent failure" and guide users toward a performant setup.
A new `NxCloudCIMessageLifeCycle` hook now checks for a remote cache configuration at the start of any command run within a CI environment.
The warning is only displayed if no remote caching is detected. It is intelligently suppressed if the workspace has:
* An Nx Cloud access token configured.
* A dependency on nx-cloud or @nrwl/nx-cloud.
* An on-premise cache provider (s3, gcs, azure, sharedFs) configured in nx.json.
* The NX_SELF_HOSTED_REMOTE_CACHE_SERVER environment variable set.
* `tasksRunnerOptions` is configured
This ensures we only notify users who are genuinely missing out on caching, improving the out-of-the-box developer experience.
When creating a node app If you want plugins to be added and
`applicationGeneratorInternal` is called instead of
`applicationGenerator` the option will be overwritten by the default
`false`.
This PR changes our Nightly GHA status reporting from a
per-project-per-environment basis to a per-project basis.
This consolidation will make the status reports easier to understand by
reducing the granularity of reporting.
Additionally, we now capture timed-out jobs as a failure instead of
being overlooked.
Sample:
```
Golden Test Failure
⭐ : Golden Projects
✅ : Passing: 15
❌ : Failing: 1
🚨 : Failed Golden Projects
| Failed project |
|--------------------------------|
| e2e-node |
```
This PR enhances the typescript plugin build detection. Notably the
changes include:
- Add absolute path handling for package.json entry points.
- Simplify the buildable verification
- Add glob pattern matching for `include` patterns.
MISC:
- Also fixes `e2e-rollup` test failing due to the typescript plugin
having the same build target as rollup so it created an unexpected
output.
closes: #29670
## Current Behavior
When installing Storybook dependencies with pnpm, the regex for
extracting base framework names from compound framework packages (e.g.,
@storybook/web-components-vite) was not properly handling hyphens in
framework names. This
caused it to extract incorrect base framework names like @storybook/web
instead of @storybook/web-components, leading to attempts to install
non-existent packages.
## Expected Behavior
The regex should properly extract base framework names that include
hyphens, correctly identifying @storybook/web-components as the base
framework for packages like @storybook/web-components-vite. This ensures
that only valid
Storybook packages are installed during dependency resolution.
## Related Issue(s)
Fixes#31292
This PR Improves the test cleanup logging for `killPorts`.
Instead of asserting that no error is thrown during cleanup, we now log
the error message when one occurs. This helps surface common but
non-critical errors (like `ECONNRESET`) without failing the test
unnecessarily.
So a test like this:
https://github.com/nrwl/nx/actions/runs/15918605455/job/44900857152
won't fail although the primary body of the test has passed
successfully.
The documentation for migrating to TypeScript project references only
shows examples for library projects, making it unclear whether the same
configuration requirements apply to application projects.
This PR clarifies that the steps apply to both libs and apps, with the
latter typically using `tsconfig.app.json` instead of
`tsconfig.lib.json`.
Fixes#31715🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When using bun as a package manager with Nx bundling operations
(webpack, vite,
etc.), lockfile creation was failing with various errors:
- "Unable to create bun lock files" warnings
- "argument 'value' must be either string or Buffer" errors
- External dependencies not being found (next, webpack-cli, etc.)
- Build failures when using generatePackageJson option
- Project graph issues with bun text-based lockfiles
This affected multiple bundlers and scenarios across the Nx ecosystem.
## Expected Behavior
Bun lockfile creation should work seamlessly across all Nx bundling
operations
without errors. Users should be able to use bun with any Nx bundler
(webpack,
vite, esbuild) and the generatePackageJson option without encountering
lockfile-related build failures.
## Related Issues
Fixes#30568Fixes#26640
## Current Behavior
When Vite projects use Vue, the typecheck target still uses the standard
TypeScript compiler (tsc) instead of vue-tsc, which is the recommended
TypeScript compiler for Vue projects. This can lead to incomplete type
checking as
tsc doesn't understand Vue's single-file components (.vue files) and
their specific syntax.
## Expected Behavior
When a Vite project uses the Vue plugin (vite:vue), the typecheck target
should automatically use vue-tsc instead of tsc for type checking. This
ensures proper type checking of Vue components and maintains
compatibility with
Vue's TypeScript integration. The external dependencies and help
metadata are also updated to reflect the use of vue-tsc when
appropriate.
## Related Issue(s)
Fixes#31647
## Current Behavior
When generating a JS library with the rollup bundler, the generator
would always create a .swcrc file regardless of the includeBabelRc flag
setting. This meant that even when users explicitly requested a Babel
configuration by
setting includeBabelRc: true, the generator would ignore this preference
and still use SWC configuration.
## Expected Behavior
When generating a JS library with any bundler (including rollup), the
generator should respect the includeBabelRc flag. If includeBabelRc is
set to true, it should create a .babelrc file and skip creating a .swcrc
file. Only
when includeBabelRc is false or not set should it fall back to creating
the appropriate transformer configuration file (.swcrc for swc/rollup
bundlers).
## Related Issue(s)
Fixes#31582
## Current Behavior
The Nest.js webpack build target configuration was generating
webpack-cli arguments without the required -- prefix, resulting in
node-env=production and node-env=development instead of proper CLI
arguments.
## Expected Behavior
The Nest.js webpack build target should generate proper webpack-cli
arguments with the -- prefix: --node-env=production and
--node-env=development for correct command line execution.
## Related Issue(s)
Fixes#31578
## Current Behavior
When the `@nx/eslint:lint` executor runs and an unexpected error occurs,
only the error message is displayed and not the stack trace. This
requires users to re-run with `--verbose` to see the stack trace.
## Expected Behavior
When the `@nx/eslint:lint` executor runs and an unexpected error occurs,
the error message and the stack trace should be logged.
## Related Issue(s)
Fixes#21630
## Current Behavior
Running Angular CLI schematic migrations that update project
configurations that contain Nx tokens (e.g. `{workspaceRoot}`,
`{projectRoot}`, `{projectName}`) does not work correctly. The schematic
migrations receive the project configuration option values with the
non-expanded tokens, which is not something handled.
## Expected Behavior
The Nx adapter for Angular should expand Nx tokens in project
configurations so schematic migrations can correctly process them. When
writing the project configuration back, the tokens should be restored on
a best-effort basis.
## Related Issue(s)
Fixes#29052
## Current Behavior
When generating Expo apps and libs with `--unit-test-runner=none` some
test-specific files and dependencies are generated.
## Expected Behavior
When generating Expo apps and libs with `--unit-test-runner=none` no
test-specific files and dependencies should be generated.
## Related Issue(s)
Fixes#30366
## Current Behavior
Projects generated with Vite that import from another project will
produce incorrect declaration files when built in an integrated
workspace (using TS path mappings).
## Expected Behavior
Projects generated with Vite that import from another project should
produce the correct declaration files when built in an integrated
workspace (using TS path mappings).
## Related Issue(s)
Fixes#30814
template examples use nx-cloud record feature which will fail if cloud
isn't enable making for bad user experience. We instead commend out the
usage and call attention to how to connect to cloud so the template will
work OOTB
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Currently the TUI is disabled on windows due to poor support for the
pseudoterminal and some lingering issues.
## Expected Behavior
This PR starts tackling this by making the TUI more usable without the
pty. The first step here is enabling processes created without the pty
to display live outputs in the TUI, which was currently not possible.
## Copilot Summary
This pull request introduces enhancements to task execution and output
handling in the Nx task runner. The changes focus on improving the
handling of progressive output for the TUI (Text User Interface), adding
support for pseudo-terminal processes, and refining the orchestration of
tasks. Below are the most important changes grouped by theme:
### Enhancements to Task Execution and Output Handling:
*
[`packages/nx/src/tasks-runner/running-tasks/node-child-process.ts`](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cR12):
Added a new `onOutput` method to allow streaming output to the TUI via
callbacks. Updated `stdout` and `stderr` handlers to invoke these
callbacks for progressive output. Introduced a
`canProvideProgressiveOutput` method to indicate whether a task can
stream output.
[[1]](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cR12)
[[2]](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cL55-R80)
[[3]](diffhunk://#diff-8c0c3712ab796458d8f6fc6cb685f68a45c01fb94f2210d9b60eaabb07610a7cL88-R112)
### Support for Pseudo-Terminal Processes:
*
[`packages/nx/src/tasks-runner/forked-process-task-runner.ts`](diffhunk://#diff-9e7468f39e004b5e6087ab9a309150efa755b4f9f8047514b63fc71f8034c930L143-R143):
Added comments to clarify when pseudo-terminal processes are used for
interactive tasks and when non-interactive processes with piped output
are used. These changes improve readability and understanding of the
trade-offs involved.
[[1]](diffhunk://#diff-9e7468f39e004b5e6087ab9a309150efa755b4f9f8047514b63fc71f8034c930L143-R143)
[[2]](diffhunk://#diff-9e7468f39e004b5e6087ab9a309150efa755b4f9f8047514b63fc71f8034c930R155-R165)
### Improvements to Task Orchestration:
*
[`packages/nx/src/tasks-runner/task-orchestrator.ts`](diffhunk://#diff-e9bae83332b3d6e57c023959ab2e5f191c97e0a154a8c1d36dd81f8f869e1bdfL637-R637):
Enhanced the registration of tasks in the TUI lifecycle. Added checks to
ensure tasks that support progressive output but are not interactive
(e.g., `NodeChildProcessWithNonDirectOutput`) are registered correctly.
Introduced a fallback for tasks that don't support progressive output.
[[1]](diffhunk://#diff-e9bae83332b3d6e57c023959ab2e5f191c97e0a154a8c1d36dd81f8f869e1bdfL637-R637)
[[2]](diffhunk://#diff-e9bae83332b3d6e57c023959ab2e5f191c97e0a154a8c1d36dd81f8f869e1bdfL649-R655)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Cypress `open-cypress` inferred task in a workspace with the
`customConditions` TypeScript compiler option set, fail with the error:
```bash
TSError: ⨯ Unable to compile TypeScript:
error TS5098: Option 'customConditions' can only be used when 'moduleResolution' is set to 'node16', 'nodenext', or 'bundler'.
```
This happens because Cypress forces `ts-node` to use `module: commonjs`
and `moduleResolution: node10`, which is incompatible with the
`customConditions` TypeScript compiler option.
## Expected Behavior
Cypress `open-cypress` inferred task in a workspace with the
`customConditions` TypeScript compiler option set should work as
expected.
## Related Issue(s)
Fixes#31616
## Current Behavior
The `@nx/jest/plugin` loads the Jest config file using the project's
`tsconfig.json` file.
## Expected Behavior
The `@nx/jest/plugin` should try to load the Jest config file using the
`tsconfig.spec.json` file (or other common filenames also handled by the
nx jest resolver). If those files don't exist, it should fall back to
the project's `tsconfig.json` file.
## Related Issue(s)
Fixes#31351
## Current Behavior
The `@nx/jest:configuration` generator always adds the
`firsttris.vscode-jest-runner` to the VSCode recommended extensions if
it's missing.
## Expected Behavior
The `@nx/jest:configuration` generator should only add the
`firsttris.vscode-jest-runner` to the VSCode recommended extensions when
configuring `@nx/jest` for the first time.
## Related Issue(s)
Fixes#29345
## Current Behavior
When a message handler in the Daemon server throws an error, the process
exits, and nothing is printed to the terminal.
## Expected Behavior
Errors thrown by message handlers in the Daemon server should be handled
appropriately and printed to the output.
## Related Issue(s)
Fixes#31407Fixes#31567
## Current Behavior
When using the Rollup executor with TypeScript, the build process uses
`rollup-plugin-typescript2` which can fail when importing types from
external dependencies.
This results in errors like "Invalid value for option 'files' - entry
does not exist" when
the TypeScript plugin tries to resolve type imports from node_modules.
## Expected Behavior
Users should be able to build TypeScript projects with Rollup without
encountering errors
when importing types from external packages. Additionally, users should
have the option to
migrate to the newer `@rollup/plugin-typescript` which handles external
dependencies more
gracefully.
## Related Issue(s)
Fixes#30488
This PR updates the description for `indexHtmlTransformer` for Angular
webpack browser executor to clarify what it accepts. Also adds an
example
<img width="1192" alt="Screenshot 2025-06-26 at 8 22 23 AM"
src="https://github.com/user-attachments/assets/883d9d91-21a9-4806-ae1d-336779b09061"
/>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30831
- Fixed documentation to clarify grep uses regex not glob patterns
- Updated examples to show proper regex usage
- Corrected both --grep and --grepInvert documentation
Fixes#30181
## Current Behavior
The Vite build executor uses naive string manipulation to calculate the
output directory path, which fails in nested monorepo structures where
the workspace root and project root have different relative paths.
## Expected Behavior
The Vite build executor properly resolves the output directory path
using Node.js path utilities, ensuring correct path calculation
regardless of monorepo nesting structure.
## Related Issue(s)
Fixes#31234
## Current Behavior
Module federation templates in React generators use subpath imports
without explicit file extensions (e.g., @nx/rspack/app-plugin,
@nx/module-federation/webpack). This causes compatibility issues with
Node.js 24's native TypeScript support, which requires explicit file
extensions for ESM package subpath imports.
## Expected Behavior
Module federation templates should include .js extensions on all subpath
imports to ensure compatibility with Node.js 24 while maintaining
backwards compatibility with earlier Node.js versions. The imports
should be in the format @nx/rspack/app-plugin.js,
@nx/module-federation/webpack.js, etc.
## Related Issue(s)
Fixes#31448
## Current Behavior
The Angular library generator ignores the `skipTsConfig` option and
always modifies the `tsconfig.base.json` file, even when users
explicitly set `skipTsConfig=true` to avoid TypeScript configuration
changes.
## Expected Behavior
When `skipTsConfig=true` is passed to the Angular library generator, the
`tsconfig.base.json` file should not be modified. Project-specific
tsconfig files should still be created as expected, but the
workspace-level TypeScript
configuration should remain untouched.
## Related Issue(s)
Fixes#31185
The command `nx g @nx/angular:service
libs/shared/data-access-user/src/lib/user` was missing the required
`--project` parameter. Added `--project=data-access-user` to fix the
error "Required property 'project' is missing".
Fixes#31410
Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
## Current Behavior
Module federation configurations with relative URLs are broken due to PR
#30615, which forced all remote URLs to be parsed as absolute URLs
using `new URL()`. This breaking change prevents developers from using
relative URLs in their module federation setups, causing runtime errors
when the application tries to load remote modules.
## Expected Behavior
Module federation should support both relative and absolute URLs
seamlessly:
- Relative URLs should work as they did before, maintaining backward
compatibility
- Absolute URLs should continue to work with enhanced query parameter
support
- The URL processing should be consistent across all module federation
helpers (Angular and React)
## Related Issue(s)
Fixes#31538
## Overview
This PR enhances the Migrate UI by adding a "Stop" button that allows
users to halt in-progress migrations at any point during execution.
It works in tandem with https://github.com/nrwl/nx-console/pull/2567
### Currently
When a migration is running and needs to be stopped for any reason:
- User accidentally triggered the migration
- Migration is taking longer than expected
- Changes are needed before completion
Users must wait for the migration to complete before using the available
"Undo" or "Skip" options.
### Expected
Users should be able to stop a currently running migration at any time
before it completes, providing immediate control over the migration
process.
### Key Features:
- Refactor guards to improve migration state checks and add conditions
for running and completing migrations.
- Update the state machine to handle new states for running, stopped,
and evaluating migrations.
- Implement logic to track running migrations and allow for stopping
them gracefully.
- Introduce a new process for running migrations in a separate child
process to support cancellation.
- Enhance metadata management to include stopped migrations and update
UI accordingly. (The UI is completely driven by the backend now aka Nx
Console)
- Add tests to cover new migration states and behaviours.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
This adds new partners `Angular Architects` and `This Dot Labs`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `nxViteTsPaths` plugin determines the buildable libraries by
checking the existence of the following target:
```ts
process.env.NX_TASK_TARGET_TARGET === 'serve'
? 'build'
: process.env.NX_TASK_TARGET_TARGET
```
But it later creates the command to build the dependencies to always run
the `process.env.NX_TASK_TARGET_TARGET` target. This is wrong and
results in trying to run the `serve` task for the dependencies when the
root task is `serve`.
## Expected Behavior
The `nxViteTsPaths` plugin should use the same task name to determine
the buildable libraries and run the command to build the dependencies.
## Related Issue(s)
Fixes#31333
## Current Behavior
When a user sets `target: node` in their Webpack or Rspack config,
`NxAppRspackPlugin` and `NxAppWebpackPlugin` do not respect additional
user config for `library.target`.
## Expected Behavior
The user config should be respected.
## Related Issue(s)
Fixes#30937
This PR fixes and issue with Next.js + Jest to remove warnings about
outdated transforms.
## Changes Made
- Updated Next.js application generator to use next/jest.js instead of
manual babel-jest configuration
- Updated Next.js library generator to use the same modern configuration
approach
- Added e2e tests to verify the new Jest configuration works correctly
- Kept same CJS vs ESM logic for JS vs TS config (existing behavior)
## Current Behavior
When using React 19 with Next.js applications in Nx, developers receive
a warning about outdated JSX transform because the Jest configuration
uses
manual babel-jest setup instead of Next.js's recommended approach.
## Expected Behavior
Next.js applications and libraries generated by Nx should use
next/jest.js configuration which automatically handles the modern JSX
transform
(runtime: 'automatic') and provides proper Jest setup for Next.js
projects without warnings.
## Related Issue(s)
Fixes#27900
## Current Behavior
Documentation examples show `tsconfig.lib.json` and
`tsconfig.spec.json` extending from `./tsconfig.json`.
## Expected Behavior
Examples should extend directly from `../../tsconfig.base.json` to
match Nx's recommended TypeScript configuration structure.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31704
- Modified create-ts-config.ts to make tsconfig.json extend
./.nuxt/tsconfig.json instead of root tsconfig
- Updated nuxt.config.ts template to make .nuxt/tsconfig.json extend the
root tsconfig with correct relative path
- Added relativePathToRootTsConfig parameter to template generation
- Updated test snapshots to reflect the new configuration chain
This ensures IDEs can properly recognize Nuxt components, composables,
and auto-imports by establishing the correct TypeScript configuration
inheritance chain: tsconfig.app.json → tsconfig.json →
.nuxt/tsconfig.json → tsconfig.base.json
## Related Issues
#30742
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
When users provide an absolute path for the Module Federation manifest
file
that already includes the workspace root, the plugin incorrectly
prepends the
workspace root again, resulting in an invalid path like
`/workspace/root/workspace/root/path/to/manifest.json`.
## Expected Behavior
The plugin should detect if the provided manifest file path already
starts with
the workspace root and avoid prepending it again. This allows users to
provide
either relative or absolute paths for the manifest file, and both will
work
correctly.
## Related Issue(s)
Fixes#31524
## Current Behavior
`@module-federation/enhanced` v0.9.0 has a dependency to
`@module-federation/dts-plugin` v0.9.0, which has a dependency to `koa`
v2.15.4, which has a [security vulnerability
](https://github.com/koajs/koa/security/advisories/GHSA-x2rg-q646-7m2v)
And because `@module-federation/enhanced` is pinned with `^0.9.0` it
won't automatically update it to a version greater than `0.9.x`
## Expected Behavior
Until `@module-federation/enhanced` releases a v1, it needs to be
manually updated when we want to benefit from a newer "minor" version.
Pinning `@module-federation/enhanced` to `^0.15.0` allows to benefit
from the latest release and security fix.
## Related Issue(s)
Fixes#30502Fixes#30748
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
In the new TS Soln Setup with Package Manager Workspaces, there is
currently no builtin method for creating a pruned lockfile that is
agnostic across bundlers and compilers.
This is problematic for apps that must be containerized.
## Expected Behavior
Add a new `@nx/js:prune-lockfile` executor that can be used to produce a
pruned lockfile in the build artifact output directory, ready for
containerization.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Colum Ferry <Coly010@users.noreply.github.com>
Created a new contact page for Nx Labs to highlight services and provide a form for inquiries. Updated the professional services section in the header menu to include a link to this page.
## Description
This PR fixes an issue where asset files copied during a build using the
`@nx/js:tsc` executor are placed in the wrong directory depending on the
current working directory from which the `nx` command is executed.
This behavior becomes particularly problematic in scenarios like release
workflows that rely on `preVersionCommand` to run E2E tests. For
instance, when using tools like Jest from the root of an E2E project,
scripts like `start-local-registry` may trigger a build and run the
`preVersionCommand`. However, instead of placing assets in the expected
`dist` folder of the project, they are incorrectly copied relative to
the E2E folder’s location.
## Reproduction Steps
1. Create a new Nx workspace:
```bash
npx --yes create-nx-workspace assets-issue --preset=ts --no-interactive
cd assets-issue
```
2. Add the Nx Plugin package:
```bash
nx add @nx/plugin
```
3. Generate a new plugin:
```bash
nx g @nx/plugin:plugin packages/my-plugin --linter eslint
--unitTestRunner jest
```
4. Add a generator to the plugin:
```bash
nx g @nx/plugin:generator packages/my-plugin/src/generators/my-generator
```
5. Build the plugin from the workspace root:
```bash
nx build my-plugin
```
✅ Assets are copied correctly:
```
dist/packages/my-plugin/generators/files/src/index.ts.template
dist/packages/my-plugin/generators/schema.json
dist/packages/my-plugin/generators/schema.d.ts
```
6. Now build the same project from a nested folder:
```bash
mkdir e2e && cd e2e
nx build my-plugin --skip-nx-cache
```
❌ Assets are copied relative to the current folder:
```
e2e/packages/my-plugin/dist/generators/files/src/index.ts.template
e2e/packages/my-plugin/dist/generators/schema.json
e2e/packages/my-plugin/dist/generators/schema.d.ts
```
## Expected Behavior
The build output—especially copied assets—should always respect the
project’s `outputPath` configuration regardless of where the `nx`
command is invoked from. The behavior should be consistent and **not
influenced by `process.cwd()`**.
The simpleName option is no longer useful as we've moved to using
options "as provided" without transformation. Users should provide the
exact name, directory, and import path they want to use.
## Changes
- Add x-deprecated to schema.json marking for removal in Nx 22
- Add runtime warning when simpleName is used
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Users are confused with `--simpleName` with using `--name` AND
`--directory`
## Expected Behavior
We should tell users that only `--name` should be used.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29508
---------
Co-authored-by: Claude <noreply@anthropic.com>
Update React monorepo tutorial:
- Fix reference to .eslintrc.base.json (now eslint.config.mjs)
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30199
Co-authored-by: Claude <noreply@anthropic.com>
## Changes
- Update build output path from {workspaceRoot}/dist/{projectRoot} to
.next folder
- Replace vite.config.ts example with next.config.js distDir
configuration
- Add note about legacy executor configuration vs inferred tasks
- Clarify that sourceRoot may not exist in all Next.js projects
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The docs for Next.js says output can be configured in `vite.config.ts`,
which is nonsense. It also mentions the output directory that is only
applicable in the legacy setup.
## Expected Behavior
Fix configuration example, and show different ways to configure output
(both new crystal setup, and legacy executor-based setup).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31037
Co-authored-by: Claude <noreply@anthropic.com>
Refined AI features including new capabilities (self-healing CI, AI data analysis), updated descriptions, and rearranged feature order. Adjusted section ID for CI security and added links to highlight AI integrations in pricing plans.
This PR fixes an issue when you use React with Webpack/Rspack, and
aren't using `@nx/webpack/plugin` or `@nx/rspack/plugin`.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Project configuration contains this for build options:
```
"styles": ["src/myapp/styles.tailwind"]
```
## Expected Behavior
It shoud be :
```
"styles": ["src/myapp/styles.css"]
```
Which is what we actually generate.
## Current Behavior
The deprecation warning for the old script to decorate the Angular CLI
doesn't state the version in which it will be removed. This was
intentional to allow sufficient time for users to migrate away from it.
## Expected Behavior
The deprecation warning for the old script to decorate the Angular CLI
should state that it will be removed in Nx v22. It has been a long time
since it was deprecated, and it should have provided more than enough
time for users to move away from it.
## Related Issue(s)
Fixes #
## Current Behavior
The `set-inject-document-domain` migration updates the component
configuration. This is incorrect since the `inject-document-domain` is
not a property supported by the component configuration.
## Expected Behavior
The `set-inject-document-domain` migration should not update the
component configuration.
## Related Issue(s)
Fixes#31610
## Current Behavior
When the user hasn't interacted with the TUI and has not disabled the
auto-exit functionality, it will always auto-exit regardless of the
number of failed tasks.
## Expected Behavior
When the user hasn't interacted with the TUI and has not disabled the
auto-exit functionality, it should not auto-exit if there are multiple
failed tasks. Additionally, as long as no terminal output panes are open
(e.g., the run one command will always display the initiating task
terminal pane), it should focus and open the first failed task.
If all tasks succeed or there's only one failure, it should continue to
auto-exit.
Adds comprehensive explanation that both files support executors and all
Nx features through the 'nx' property in package.json. Clarifies that
project.json is optional.
Preview:
https://nx-dev-git-issues-28715-nrwl.vercel.app/reference/project-configuration#project-level-configuration-files
## Current Behavior
The documentation for project configuration does not clearly explain
that both package.json and project.json support the same Nx features,
including executors.
## Expected Behavior
The documentation now clearly states that:
- Both package.json and project.json support targets through the "nx"
property in package.json
- The choice between the two is primarily a matter of preference
- Includes an updated example showing how to use `nx.targets` in
package.json
## Related Issue(s)
Fixes#28715
## Current Behavior
When Nx is invoked from a global install, both the global and local
versions register process exit handlers that flush captured logs. This
causes Nx Cloud logs to be displayed twice - once from the global
installation and once from the local installation.
## Expected Behavior
Only the local Nx installation should handle log flushing, preventing
duplicate log output. The process exit handler is moved from the global
entry point (nx.ts) to the local entry point (init-local.ts) so that log
flushing only occurs once.
## Related Issue(s)
This change requires users to update their globally installed Nx to
fully resolve the duplicate logging issue, as the fix is now in the
local version that gets invoked.
## Current Behavior
The string regex the script uses to validate commits is not correctly
escaped.
## Expected Behavior
The string regex the script uses to validate commits should be correctly
escaped.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Adds the path to the terminal output s.t. you can at least debug what's
going on
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When building applications that depend on workspace libraries for
deployment (particularly in containerized environments like Docker),
developers must manually handle copying workspace dependencies and
updating package.json references.
This creates friction when trying to deploy applications that consume
workspace libraries, as the build output doesn't contain the necessary
workspace dependencies and the package.json still references them with
`workspace:` protocol which doesn't work outside the workspace context.
## Expected Behavior
With the new `@nx/js:copy-workspace-modules` executor, developers can
automatically prepare their built applications for deployment by:
1. **Automatically copying workspace dependencies**: The executor scans
the application's package.json for workspace dependencies (those with
`workspace:` or `file:` version specifiers) and copies the source code
of these dependencies into a `workspace_modules` directory within the
build output
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Some Angular migrations collect the Angular projects from the project
graph using the dependencies information. When reading the project
configuration for those projects, it can throw an error if trying to do
it for a completely inferred project (it doesn't have a project
configuration file).
## Expected Behavior
The Angular migrations collecting Angular projects from the project
graph using the dependencies information should gracefully handle
projects that were completely inferred when trying to read the project
configuration.
In fact, the current migrations didn't need to read the project
configuration and could use the project graph information directly, so
the call to read the project configuration was removed.
## Related Issue(s)
Fixes#31607
## Current Behavior
`nx run lint --quiet --fix` doesn't respect `--quiet` and fixes all
issues, even silenced ones. This is different from how `eslint --quiet
--fix` behaves.
## Expected Behavior
`nx run lint --quiet --fix` should only fix issues that aren't silenced
by `--quiet`, like `eslint` does
## Related Issue(s)
Fixes#31401
This PR added two TUI environment variables to the reference page:
- NX_TUI to enabled/disable
- NX_TUI_AUTO_EXIT to control auto-exit behavior
## Current Behavior
The environment variables documentation does not include the new
Terminal UI (TUI) environment variables `NX_TUI` and `NX_TUI_AUTO_EXIT`
that were recently added to control the interactive terminal interface
for task
execution.
## Expected Behavior
The documentation now includes comprehensive information about the TUI
environment variables:
- `NX_TUI`: Controls whether the Terminal UI is enabled or disabled for
running tasks
- `NX_TUI_AUTO_EXIT`: Controls the auto-exit behavior of the TUI after
tasks complete, supporting boolean values or a number for countdown
seconds
## Related Issue(s)
Fixes#31111
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
when atomized=false, it does not generate build-ci and check-ci targets
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- when atomized=false, it should still generate build-ci and check-ci
targets
- upgrade dev.nx.gradle.project-graph version to 0.1.2
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR adds bun to list of package managers that can be used on the CI
deployment page.
Fixes#31431
## Current Behavior
The CI deployment documentation at
https://nx.dev/ci/recipes/other/ci-deployment only mentions npm, yarn,
and pnpm as supported package managers. However, Bun is actually
supported by Nx as shown in the PackageManager type
definition which includes 'bun' as a valid option.
## Expected Behavior
The documentation should accurately reflect all supported package
managers, including Bun. Users should be aware that they can use Bun as
their package manager when following the CI deployment recipes.
## Related Issue(s)
Fixes#31431
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
fix to run gradle on windows
./gradlew command is only macos
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
use @nx/gradle:gradle executor instead of command ./gradlew
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
This pull request updates the documentation to reflect changes in
project names for task dependencies. The documentation was referring to
the `modules-shared-ui` and `modules-products` packages on the chart,
but these packages are called differently.
## Current Behavior
Some links in the Angular and React tutorials are broken.
## Expected Behavior
The links in the Angular and React tutorials work correctly.
## Related Issue(s)
Fixes#31601
## Current Behavior
Using the `ng-packagr` executors in an Angular version lower than v20
results in an error due to a bad import.
## Expected Behavior
The `ng-packagr` executors should work correctly regardless of the
Angular version used.
## Related Issue(s)
Fixes#31597
Extended the `Callout` component and schema to support a new 'announcement' type with corresponding styles and icon. Updated documentation example for the new type.
This PR adds the ability to set the port of the React application when
using the generator.
e.g.
```shell
npx nx g @nx/react:app --port 8080
```
This is useful when generating multiple apps and then running them in
parallel.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Index pages read from the map.json description which is missing for a
lot of entries.
<img width="853" alt="image"
src="https://github.com/user-attachments/assets/8c0db9a2-d293-482d-8597-647cda47cc93"
/>
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The new logic
- checks the corresponding markdown file `description` property which is
also used for the HTML meta description tags
- falls back to the `map.json` description
<img width="809" alt="image"
src="https://github.com/user-attachments/assets/716358f0-bab9-4bd4-97b2-b31fa151ebe0"
/>
## 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 #
This PR updates pages like
`/technologies/typescript/api/executors/verdaccio`, such that the
backlink to the API index is correct. Even though we redirect `/nx-api`
pages, the Next.js pages router does not respect them and users see 404
instead.
This PR updates the Nodejs version installed on our docker images
contained in the publish script to be consistent with the Nx repository
Node compatibility version.
The current Nodejs version being pulled from the docker image is Node
v18 but our repository requires Node v20.19.0.
A test run can be found here:
https://github.com/nrwl/nx/actions/runs/15593332649
…le extensions for type definitions.
Updated the Rollup plugin's logic for generating type definition files
to ensure compatibility with additional file extensions, including
.cjs.js and .mjs.js.
This change improves the handling of entry points and ensures that
corresponding .d.ts files are correctly named and emitted in all
supported scenarios.
Added a comprehensive test case to validate the new behavior.
closed#29308
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
This PR modifies the populate-local-registry-storage inputs to
invalidate the cache when the native task is updated (which includes
OS/architecture information).
This change addresses MacOS failures we've been encountering in our
nightly GitHub Actions runs. The issue stems from incorrect cache
restoration when running multiple OS and Node.js version combinations,
which explains why native modules were consistently missing in most
MacOS tests.
Here is the result: https://github.com/nrwl/nx/actions/runs/15562011534
## Current Behavior
Docs do not callout potential port conflict issues with running e2e in
parallel
## Expected Behavior
Docs mention how to avoid parallel port collisions
## Related Issue(s)
Fixes #
## Current Behavior
The Nx Console installation prompt has verbose and redundant wording
that makes the message unclear.
## Expected Behavior
The prompt is simplified and more concise, focusing on the key benefits
of installing Nx Console while being more direct about what users will
gain.
## Related Issue(s)
This change improves the user experience when prompted to install Nx
Console.
## Current Behavior
The native logging is currently set to a global 'info' level, which can
produce verbose output that may not be relevant to users.
## Expected Behavior
Native logging should be scoped to the 'nx::native' module by default
with 'info' level, reducing noise while still allowing users to control
logging verbosity through the `NX_NATIVE_LOGGING` environment variable.
## Related Issue(s)
This improves the developer experience by providing more focused logging
output and reduces unnecessary verbosity in the console.
Fixes https://github.com/nrwl/nx/issues/31518
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- for the atomized test, currenly, its testClassName is just the 1st
class name in the file
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- upgrade gradle to latest version from 8.13 to 8.14
- for test task, exclude all its depends on tasks
- it currently only exclude its direct depends on, its children
- now it will go down the dependency tree and exclude all of its depends
on, its children and grandchildren
- for the atomized test target, its testClassName will be the full
package name
- e.g.
org.springframework.boot.autoconfigure.jersey.JerseyAutoConfigurationCustomObjectMapperProviderTest
- add logics to handle nested class
- exclude private class name
<img width="1081" alt="Screenshot 2025-06-06 at 2 53 39 PM"
src="https://github.com/user-attachments/assets/285792fb-f098-4511-85dc-ee1263d75929"
/>
- add build-ci target
<img width="1140" alt="Screenshot 2025-06-10 at 10 21 06 AM"
src="https://github.com/user-attachments/assets/25db4a3e-2794-4654-9a95-1b66d229340b"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Node.js application generator
(`packages/node/src/generators/application/application.ts`) is
implemented as a single large file containing ~469 lines of code. All
generator logic is mixed together in one file including:
- Option normalization and validation
- Project configuration creation
- File generation
- Build/serve target setup
- Dependency management
- ESLint configuration
- Proxy setup
This makes the code harder to maintain, test, and understand as the file
handles multiple responsibilities.
## Expected Behavior
The generator is now refactored into smaller, focused modules organized
in a `lib/` directory:
- `normalize-options.ts` - handles option normalization and validation
- `normalized-schema.ts` - defines the normalized schema interface
- `create-project.ts` - handles project configuration creation (exported
as `addProject`)
- `create-files.ts` - handles file generation (exported as
`addAppFiles`)
- `create-targets.ts` - handles build/serve target configuration
- `add-dependencies.ts` - handles dependency management (exported as
`addProjectDependencies`)
- `add-linting.ts` - handles ESLint setup (exported as
`addLintingToApplication`)
- `add-proxy.ts` - handles proxy configuration (exported as `addProxy`)
- `index.ts` - exports all the functions
The main `application.ts` file is now much cleaner at ~15 lines,
focusing on orchestrating the generator workflow by calling the
extracted functions. This separation of concerns improves:
- **Maintainability**: Each file has a single responsibility
- **Testability**: Individual functions can be tested in isolation
- **Readability**: Easier to understand what each part does
- **Reusability**: Functions can be potentially reused by other
generators
Replaced the "Enterprise" drop-down menu with a direct link to the Enterprise page for simpler navigation. Updated mobile menus to integrate enterprise items alongside solutions.
This PR makes the global install more prominent. This is important for
non-JS workspaces since they may not have node or npm available. The
installation flow should be:
1. Install Nx (e.g. `brew install nx`)
2. Run `nx init` in your project
The `create-nx-workspace` is removed since it's already mentioned on the
intro page, and it is covered in tutorials. It is also not technically
an "install" command.
Preview:
https://nx-dev-git-docs-update-installation-nrwl.vercel.app/getting-started/installation
**Note:** The cross-platform NPM install is still featured first because
it'll work for everyone. It shouldn't be a concern for non-JS devs since
other tools like Claude Code also has `npm install --global` as their
install step.
## Current Behavior
<!-- This is the behavior we have today -->
There is no easy way to inspect the hash plan for a task.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a `TaskHashPlanInspector` which can be used to provide details
about the hash plan for a task.
## Example Usage
```js
const { createProjectGraphAsync } = require('@nx/devkit');
const { HashPlanInspector } = require('nx/src/hasher/hash-plan-inspector');
(async () => {
const graph = await createProjectGraphAsync();
const hashPlanInspector = new HashPlanInspector(graph);
await hashPlanInspector.init();
const target = {
project: 'nx',
target: 'build-native',
};
console.log(
JSON.stringify(hashPlanInspector.inspectTask(target), null, 2)
);
})();
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
## Current Behavior
TypeScript transformer loading in the js package was limited to standard
Nx/TypeScript transformer plugins and didnt handle different exports
## Expected Behavior
TypeScript transformer loading should support various function-based
transformer formats in a generic way
## Related Issue(s)
Fixes#31411🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: claude[bot] <209825114+claude[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 -->
This repo uses Nx `21.2.0-beta.1`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.2.0-beta.4`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: AgentEnder <AgentEnder@users.noreply.github.com>
## Current Behavior
The codebase has separate `logError` and `logDebug` functions in the
native logging infrastructure, with both error and debug logging paths.
## Expected Behavior
Consolidate logging to use a single standardized approach. Error
messages are now logged through the debug channel for consistency.
## Related Issue(s)
This change standardizes the logging interface by removing the separate
error logging function and routing all log messages through the debug
logger.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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
PR Adds Zephyr Cloud to Partners Page
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The publish workflow was failing because the preinstall script was
exiting with code 1 when detecting an older Node.js version, causing the
entire publishing process to fail.
## Expected Behavior
The preinstall script should warn about Node.js version requirements but
not exit with an error code during publishing, allowing the workflow to
continue.
## Related Issue(s)
This fixes a critical issue preventing package publishing due to Node.js
version check failures in CI environments.
The fix changes:
- `console.error()` to `console.warn()` for better log categorization
- Removes `process.exit(1)` to prevent workflow termination
- Adds the actual Node.js version to the warning message for better
debugging
This ensures the publish workflow can complete successfully while still
providing visibility into Node.js version mismatches.
## Current Behavior
When running `nx run <project>` without specifying a target, the command
always fails with an error message "Both project and target have to be
specified", even if the project has a "run" target defined.
## Expected Behavior
When running `nx run <project>` without specifying a target, the command
should check if the project has a "run" target defined. If it does, use
it as the default target. This improves developer experience by allowing
simpler commands like `nx run myapp` instead of `nx run myapp:run`.
## Related Issue(s)
This change improves the developer experience for projects that have a
"run" target defined, making the CLI more intuitive.
## Changes Made
- Modified `packages/nx/src/command-line/run/run-one.ts` to check for a
"run" target when no target is specified
- Added comprehensive test coverage in `e2e/nx/src/run.test.ts` to
verify:
- Projects with a "run" target default to it when no target is specified
- Projects without a "run" target still show the original error message
- Maintains full backward compatibility
## Testing
- All existing tests pass
- Added new e2e tests to verify the behavior
- Ran full validation suite (`nx prepush`) successfully
- Added .pnpmrc for pnpm 10 configuration, enabling peer dependencies
and lifecycle scripts.
- Updated package.json to reflect pnpm version change to 10.11.1 and
added onlyBuiltDependencies.
- Update pipelines to reflect pnpm version update to 10.11.1
## Upgrading your pnpm version
Now to upgrade your `pnpm` version you can run `pnpm
migrate-to-pnpm-version 10`. Which would upgrade your `pnpm` and it will
run the upgrade script.
Later on if you want to upgrade to pnpm v11 you can run `pnpm
migrate-to-pnpm-version 11`.
Additionally, if you just want to upgrade to the version that is inside
of `package.json` you would run
`pnpm migrate-to-pnpm-version` without passing in a major version.
Without explicitly specifying the --name option nx adds the full
workspace name ie @workspace/remote-app of which that fails the name
validation
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Colum Ferry <cferry09@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This test is flaky.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This test is disabled and should be investigated to see why it is flaky.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `pnpm build:wasm` command fails with compilation errors due to
missing dependencies and system-dependent features being included in
WASM builds.
## Expected Behavior
WASM builds should compile successfully by excluding features that
require system access (IPC, terminals, file locking, etc.) while
maintaining these features for native builds.
## Related Issue(s)
Fixes WASM build compatibility issues
## Changes Made
### Core Changes
- Added conditional compilation flags (`#[cfg(not(target_arch =
"wasm32"))]`) to IDE console modules
- Made `socket_path` module conditional for non-WASM targets only
- Fixed unused import warnings for WASM builds in `file_lock.rs` and
`walker.rs`
### Generated File Updates
- Updated TypeScript definitions and JavaScript bindings to reflect
conditional compilation
- WASM builds now exclude system-dependent features like terminal UI and
database connections
### Technical Details
The IDE console functionality depends on:
- `interprocess` crate for IPC communication
- `jsonrpsee` crate for JSON-RPC messaging
- Terminal and file system features not available in WASM
These features are now properly isolated for native targets only while
maintaining full functionality for standard Node.js builds.
## Testing
- ✅ `pnpm build:wasm` now passes successfully
- ✅ Generated bindings properly exclude WASM-incompatible features
- ✅ Native builds retain all existing functionality
## Current Behavior
When generating a pruned pnpm lockfile, if there's no external node with
a default version for a given package and the dependency specification
for the package includes a Semver range specifier, an error is thrown.
## Expected Behavior
When generating a pruned pnpm lockfile, the parser should correctly
handle the scenario where there's no external node with a default
version for a given package, and the dependency specification for the
package includes a Semver range specifier.
## Related Issue(s)
Fixes#28627
ESLint added experimental support for typescript config files since
[9.9.0](https://eslint.org/blog/2024/08/eslint-v9.9.0-released/#experimental-typescript-configuration-files),
and as of
[9.18.0](https://eslint.org/blog/2025/01/eslint-v9.18.0-released/#stable-typescript-configuration-file-support)
that support is stable. This PR add ts/mts/cts to the list of known
eslint config files, and adds the same extensions to config file
generators
## Current Behavior
When using the eslint executor with a ts file, returns error "When using
the new Flat Config with ESLint, all configs must be named
eslint.config.js or eslint.config.cjs and .eslintrc files may not be
used. See
https://eslint.org/docs/latest/use/configure/configuration-files"
When using the eslint plugin, the inferred task is not created for
projects that do not have a non-ts eslint config.
### Workarounds
- Compiling ts rules/configs in a project. Introduces other issues
- Using jiti or comparable
- For plugin users, having a fake eslint.config.js at the root allows
the inferred task to be created. ESLint will still use the ts config.
- Cache targets are wrong
- Complications in non-monorepo workspaces
## Expected Behavior
When using the eslint executor with a ts file, no error is thrown.
When using the eslint plugin with a ts file, the inferred task is
created.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
No issues, but addresses [this
discussion](https://github.com/nrwl/nx/discussions/29710#discussion-7856165)
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Current Behavior
The webpack and rspack plugins for handling non-buildable libraries
don't properly process the exports field in package.json. They
incorrectly assume libraries have only a single entry point, typically
through a barrel file (index.ts).
When a library defines multiple export paths using the exports field
(e.g., "./*": "./src/*.ts"), the plugins fail to generate the correct
allowlist patterns for webpack externals. This causes build failures
when trying to use non-buildable libraries that expose multiple entry
points without barrel files.
Expected Behavior
The webpack and rspack plugins should properly parse the exports field
from package.json and generate appropriate allowlist patterns for all
exported subpaths. This includes:
Handling wildcard patterns ("./*": "./src/*.ts")
Processing conditional exports (import/require/development)
Supporting exact subpath exports ("./utils": "./src/utils.ts")
Escaping special characters in package names for regex patterns
Gracefully falling back to reading package.json directly when metadata
is unavailable
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Rollup build fails on Windows with errors like this:
```
[plugin rpt2] error TS6059: File '/foo/bar/baz.ts' is not under 'rootDir' 'C:/foo/bar'. 'rootDir' is expected to contain all source files.
```
This is because since
https://github.com/nrwl/nx/commit/81fe7bb278826ece0bec9ff794fa5b1ef5c0c295
the `tsconfig` path passed to `rollup-plugin-typescript2` is built using
`joinPathFragments`, which removes the drive letter on Windows.
## Expected Behavior
Rollup build should not fail.
closed#30235
## Current Behavior
nxComponentTestingPreset for webpack cannot use rspack as an executor.
## Expected Behavior
nxComponentTestingPreset for webpack can use webpack or rspack as an
executor.
## Related Issue(s)
#30235Fixes#30235
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
- Create a project that uses @nx/rspack:rspack as build target with
SkipTypeChecking set to false.
- Run build target for project.
- Type check has not been run and will not bail in case of any
typescript errors
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- It should run type checking as documented:
https://nx.dev/nx-api/rspack/executors/rspack#skiptypechecking
I looked at the webpack executor and there it also runs the type check
based on `skipTypeChecking` and not the `typeCheck` alias. So I've
adjusted it accordingly for the rspack executor.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31026
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
esbuild breaks on function checks and improperly handles dangling
promises, preventing the program to exit successfully.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The program should exit properly and no zombie processes kept running.
## 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(vite): must begin with lowercase` -->
## Current Behavior
Running `nx test … --reporter=verbose` (or any additional Vitest
reporter) on
projects that use **Vitest ≥ 0.29** hangs indefinitely at the end of the
run.
`vitest` itself finishes, but the Nx task-runner never receives the
*done*
signal because **`NxReporter` only implements the legacy
`onFinished()` hook**.
When multiple reporters are configured, Vitest now emits
`onTestRunEnd()` instead of `onFinished()`, so the promise in
`NxReporter`
remains unresolved and the worker process stays alive forever.
## Expected Behavior
`nx test` (and affected `nx run-many --target=test`) exits cleanly on
**all**
Vitest versions, regardless of how many reporters are passed.
* `NxReporter` resolves its internal promise via **either**
`onTestRunEnd` (Vitest ≥ 0.29) **or** `onFinished` (Vitest ≤ 0.28).
* No functional change in watch-mode.
* No extra timers or fallbacks – just one shared helper.
## Implementation Notes
* Added `onTestRunEnd` method that delegates to a private
`_handleFinished`.
* Re-implemented `onFinished` as a thin delegate to the same helper.
* Original error-detection logic is untouched.
## Related Issue(s)
Closes nrwl/nx#<insert-issue-number-if/when-one-exists>
Co-authored-by: Paul Bohm <{{GITHUB_NOREPLY_EMAIL}}>
## Current Behavior
Currently when we're using `rollup.config.ts` rollup is picking up wrong
tsconfig. Because of this not everything works as expected:
- `You are using one of Typescript's compiler options 'declaration',
'declarationMap' or 'composite'. In this case 'outDir' or
'declarationDir' must be specified to generate declaration files.` error
appears , because lib tsconfig.json doesn't have outputDir at all
- even if we add outDir to `tsconfig.base.json` we'll have another error
`[!] (plugin typescript) RollupError: [plugin typescript]
@rollup/plugin-typescript TS6377: Cannot write file
'/workspaces/abapify-docs/dist/tsconfig.tsbuildinfo' because it will
overwrite '.tsbuildinfo' file generated by referenced project
'/workspaces/abapify-docs/packages/abap-to-markdown'`
This happens becase it tries to write all tsbuildinfo files into a root
dist folder.
## Expected Behavior
Using rollup.config.ts should just work in a similar way as js|cjs|mjs
config work.
## Solution
According to docs:
> This option supports the same syntax as the
[--plugin](https://rollupjs.org/command-line-interface/#p-plugin-plugin-plugin)
option i.e., you can specify the option multiple times, you can omit the
@rollup/plugin- prefix and just write typescript and you can specify
plugin options via ={...}.
So it means we can use something like this:
```
rollup -c rollup.config.ts --configPlugin typescript={tsconfig:\'tsconfig.lib.json\'}
```
## Related Issue(s)
Solution is taken from this issue::
https://github.com/rollup/plugins/issues/1713#issuecomment-2201138846
## Current Behavior
The Angular ESLint packages are installed with a v20 beta version.
## Expected Behavior
The Angular ESLint packages should be installed with the stable v20
version.
## Current Behavior
The `nx report` command uses tab characters for indenting local
workspace plugins in its output, which creates inconsistent formatting
compared to other sections like 'Registered Plugins' and 'Community
plugins'.
## Expected Behavior
Local workspace plugins should be formatted consistently with other
plugin sections in the report output, without tab indentation.
## Related Issue(s)
This is a minor formatting improvement for better consistency in the nx
report output. No specific issue was filed for this change.
## Current Behavior
When using Node.js subpath imports with the same name in different
projects, the Nx graph incorrectly picks up seemingly random
dependencies between projects that shouldn't exist.
This happens because the result of the resolution performed with
TypeScript is cached using the import path as the cache key. The problem
with that is that multiple projects can have the same subpath import
name pointing to internal files of the project, so when the resolution
is made for the first project (say `project1`), the result will be
cached and incorrectly reused for other projects with the same subpath
import name. So, all projects with the same subpath import name would
resolve the dependency to the first project (`project1`).
The same could happen to projects with TS path mappings defined in the
project's tsconfig file. These TS path mappings would only apply to the
project internally and therefore, other unrelated projects could also
define them with the same name pointing to different files.
## Expected Behavior
The Node.js subpath imports should be handled correctly. The TypeScript
resolution result should be cached safely and scoped to the project from
which the import is being done.
## Related Issue(s)
Fixes#31223
## Current Behavior
Currently, IDE integration setup requires manual configuration and lacks
streamlined auto-installation capabilities for Nx Console. The logging
system also needs improvement for better developer experience.
## Expected Behavior
With these changes, the IDE integration provides:
- Prompt for automatic Nx Console installation with user preferences
- Enhanced native logger with proper formatting and levels
- Better development documentation for IDE setup
- Updated documentation links to use the new format
## Related Issue(s)
<\!-- Please link the issue being fixed so it gets closed when this is
merged. -->
This PR implements IDE integration improvements including Nx Console
auto-installation and enhanced logging capabilities.
## Current Behavior
When running the `lint` task on a project that contains nested projects,
the task runs over all the files, including the ones inside the nested
projects, but the task cache status is not affected by changes to the
files in nested projects. This only happens when the inputs are defined
with `{projectRoot}/...` (what the `@nx/eslint/plugin` infers). The
`{projectRoot}` token scopes the files inside the project without files
in other nested projects. While the `{workspaceRoot}` token would
include every file and wouldn't scope them to any particular project.
## Expected Behavior
The `@nx/eslint/plugin` should infer `lint` tasks with their inputs
using the `{workspaceRoot}` token to support nested projects. This would
be more aligned with what the tool itself does, which runs over all the
files inside the project root regardless of them being inside nested Nx
projects.
Additionally, the difference in behavior between `{workspaceRoot}` and
`{projectRoot}` should be documented.
## Related Issue(s)
Fixes#31264
## Current Behavior
We currently do not have support for Storybook 9, nor any migrations to
help users switch to it.
## Expected Behavior
Support Storybook 9 and add a migration for users to switch to v9
BREAKING CHANGE: Remove deprecated generators:
`@nx/storybook:cypress-project`,
`@nx/react-native:storybook-configuration`, `@nx/react-native:stories`,
`@nx/react-native:component-story`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Running tests in the Cursor terminal fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running tests in the Cursor terminal should pass.
## 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 -->
Node 24 is more strict for module resolution and was not able to resolve
this path.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Node 24 is now able to resolve this path.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, ndcunningham is not included in the list of authorized users
who can trigger the Claude AI assistant in GitHub workflows.
## Expected Behavior
With this change, ndcunningham will be able to trigger the Claude AI
assistant by mentioning @claude in GitHub issue comments, PR comments,
and PR reviews.
## Related Issue(s)
This change adds ndcunningham to the authorized user list for the Claude
workflow, enabling them to use the AI assistant for development tasks.
This PR updates the CI workflow in `.github/workflows/ci.yml` to improve
the setup and management of iOS simulators.
The change includes
- Enhanced error handling
- Better diagnostics
- Configurations for M-series Macs.
This change is similar to what we in `.github/workflows/e2e-matrix.yml`
so the result should be consistent across workflows.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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, if you try to import a ESM lib after you generate a Next.js
application it fails to build due to how the module exports `export *
from './lib/lib8446520.js';`.
This has been addressed with webpack and needs to be extended to
Next.js.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
You should work out of the box and you should be able to import a lib
defined like: `export * from './lib/lib8446520.js';.`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
This is also related to our webpack and rspack packages. Changes have
also been made to them to ensure consistency across bundlers.
Fixes#30714
## Current Behavior
When creating a `ts-node` transpiler, only `compilerOptions` are
provided. Because we instruct `ts-node` to skip reading the tsconfig
(this was previously done to avoid some edge cases), other options in
the tsconfig files are lost (e.g. `ts-node` specific options).
This was previously reported at https://github.com/nrwl/nx/issues/21695
and fixed by https://github.com/nrwl/nx/pull/21723, but a rework at a
later point caused a regression.
## Expected Behavior
When creating a `ts-node` transpiler, we should provide
`compilerOptions` and the `ts-node` options.
This pull request introduces several updates to the CI/CD workflows and
matrix configuration files.
The aim is to highlight critical Nx failures contained in each project
for maintainers to address.
### Changes
- Improvements to workflow caching.
- Improvements to macOS simulator handling.
- Updates to Slack notifications.
- Update matrix data processing for golden projects.
- Support for Windows has been temporarily disabled due to build 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
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
In ng-packagr-lite watch mode, all output files are written to disk on
every incremental build regardless of whether their content actually
changed. This causes downstream watchers (like Vite) to see all files as
"changed" and trigger full rebuilds instead of incremental ones.
## Expected Behavior
Only files with changed content should be written to disk during
incremental builds in watch mode. This allows downstream watchers to
properly detect which files actually changed and perform efficient
incremental rebuilds.
## Related Issue(s)
Fixes#31033🤖 Generated with [Claude Code](https://claude.ai/code)
This PR removes the `/nx-api` pages from `nx-dev`. They are already
redirected from `/nx-api` to either `/technologies` or
`/reference/core-api` URLs.
e.g. `/nx-api/nx` goes to `/reference/core-api/nx` and `/nx-api/react`
goes to `/technologies/react/api`
**Changes**:
- Remove old `nx-api.json` from being generated in
`scripts/documentation/generators/generate-manifests.ts` -- this was
used to generate the sitemap
- Remove `pages/nx-api` from Next.js app since we don't need them
- Remove workaround from link checker
`scripts/documentation/internal-link-checker.ts` -- the angular
rspack/rsbuild and other workarounds are gone now that they are proper
docs in `map.json`
- Update Powerpack/Remote Cache reference docs to exclude API documents
(since they are duplicated in the Intro page) --
`nx-dev/models-document/src/lib/mappings.ts`
- All content in `docs` have been updated with new URL structure
**Note:** Redirects are already handled, and Claude Code was used to
verify the updated `docs/` URLs (see report below). The twelve 404s
links were updated by hand.
## Verification Report
https://gist.github.com/jaysoo/c7863fe7e091cb77929d1976165c357a
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes two issues with the docs restructure:
1. `/plugin-registry` was reading from `new-nx-api.json`, which had the
wrong base path for API docs -- it was not using `mapping.ts`
2. `/reference/core-api/devkit/documents` did not statically generate
all URLs -- this required a change specifically to handle legacy devkit
documents
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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
Add LiveLoveApp and nStudio to our partners page
## 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 #
# before
plugin api docs where stuck in `api` section which doesn't make sense
# after
move plugin api docs into `guides` section and add redirect for better
discoverability
Now that Nx is merged into
[`homebrew-core`](https://github.com/Homebrew/homebrew-core/pull/225452)
we no longer need to tap to access a non-official formula.
This PR updates our brew install to remove `brew tap nrwl/nx`. It also
mentions Linux for Homebrew since it is supported across different Linux
distros.
## Current Behavior
The `@nx/angular:ng-packagr-lite` executor is generating a wrong output
on Windows.
## Expected Behavior
The `@nx/angular:ng-packagr-lite` executor should generate the correct
output on Windows.
## Related Issue(s)
Fixes#31436
- fix(rspack): choosing nest as framework should not result in error
#31204
- fix(rspack): add deprecation message for application generator
- fix(rspack): ensure application generated projects are added to
excludes
## Current Behavior
Running the `@nx/rspack:application` generator with `--framework=nest`
results in an error due to mix of inferred and executor usage throughout
the generation process.
## Expected Behavior
Running the generator should pass without failure and create a working
project.
Deprecate the generator in favour of using project specific packages
(@nx/react etc)
## Related Issue(s)
Fixes#31204
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
By default, `nx migrate` installs the latest version of `nx` in a
temporary directory to run the migration process. When this installation
fails, no helpful information is printed even when running with
`--verbose`; it only prints a generic message that the package manager
install process failed. This doesn't help when debugging/troubleshooting
issues with the installation.
## Expected Behavior
When installing the latest version of `nx` during `nx migrate` fails,
the installation logs should be printed when running with `--verbose`.
## Related Issue(s)
Fixes #
## Current Behavior
When running `nx init` in an Angular CLI repo located in a directory
that has an ancestor directory with an Nx installation, it silently
exits when trying to determine the compatibility of the Angular version.
The migration is not performed, and no feedback is given to the user.
This happens because the current implementation will determine that
ancestor directory (outside the workspace root) as the workspace root
(when starting the migration, there's no `nx` in the repo).
## Expected Behavior
Running `nx init` should work correctly, and proper feedback should be
printed to the user if it can't determine the compatibility of the
Angular version. It should correctly resolve the `@angular/core` package
from the Angular CLI workspace root.
## Related Issue(s)
Fixes#31291
## Current Behavior
The Nx Vite TsConfig paths plugin incorrectly resolves to workspace root
tsconfig files instead of project-specific ones, causing path aliases
like `@/contexts` to fail resolution.
## Expected Behavior
The plugin should check for project-specific tsconfig files
(`tsconfig.app.json`, `tsconfig.lib.json`, `tsconfig.json`) before
falling back to workspace root configurations.
## Related Issue(s)
Fixes#28945🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
The `nx graph --print` flag is documented and shows in CLI help, but
when used, it opens the graph UI in a browser instead of printing the
dependency graph to the console.
## Expected Behavior
With this PR, `nx graph --print` correctly prints the dependency graph
JSON to stdout in the terminal and exits, matching the documented
behavior and CLI help description.
## Related Issue(s)
Fixes#30255
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There are two issues when we generate a remix application with ts
solutions:
1. Running the `setup-tailwind` generator with a reference project which
now is commonly with the pattern `@nx/acme` throws an error based on the
schema.
```
Property 'project' does not match the schema.'@nx/acme' should match the pattern '^[a-zA-Z].*$'.
```
2. The `tailwind.css` inside of `root.tsx` causes error with Vite.
```
app/root.tsx (9:7): "default" is not exported by "app/tailwind.css", imported by "app/root.tsx".
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The remix project should be able to be referenced similarly to how we
handle React.
The tailwind import should not throw an error.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30343
This PR updates Vite's E2E testing setup for the Vue plugin.
Instead of commenting out the serve for vite and rsbuild when using
playwright we update the test to ensure the ports are available before
attempting to run their preview target.
This PR updates your `package.json` to add `ajv` as a devDependency to
ensure the correct version is hoisted during module resolution.
For non-pnpm package managers notably (yarn and npm) the hosited version
is outdated and it spawns errors when vite is generating types via
`vite-plugin-dts`.
```shell
- packages/vite-parent-lib9113241/vite.config.ts: Error: Cannot find module 'ajv/dist/core'
Require stack:
- /private/var/folders/tp/bfmjfn9s0hd59bm9z80j3mgm0000gn/T/nx-e2e--29165-pQZxOyX4J3ot/nx/proj2191858/node_modules/ajv-draft-04/dist/index.js
- /private/var/folders/tp/bfmjfn9s0hd59bm9z80j3mgm0000gn/T/nx-e2e--29165-pQZxOyX4J3ot/nx/proj2191858/node_modules/@rushstack/node-core-library/lib/JsonSchema.js
- /private/var/folders/tp/bfmjfn9s0hd59bm9z80j3mgm0000gn/T/nx-e2e--29165-pQZxOyX4J3ot/nx/proj2191858/node_modules/@rushstack/node-core-library/lib/index.js
- /private/var/folders/tp/bfmjfn9s0hd59bm9z80j3mgm0000gn/T/nx-e2e--29165-pQZxOyX4J3ot/nx/proj2191858/node_modules/@microsoft/api-extractor/lib/api/CompilerState.js
```
Here is an example of the failures:
- ❌ [NPM + MacOS]
https://staging.nx.app/runs/uaJ1pbWHtK/task/e2e-js%3Ae2e-local
- ✅ [PNPM + Linux]
https://staging.nx.app/runs/WRgY8Z6Jlw/task/e2e-js%3Ae2e-local
- ❌ [NPM + Linux]
https://staging.nx.app/runs/Ght82l5Upa/task/e2e-js%3Ae2e-local
This PR updates our Nest dependency to version 11.
It also fixes an issue when you generate a Nest app with
`--unitTestRunner=none` it would still generate `.spec` files
closes: #30188
## Current Behavior
<!-- This is the behavior we have today -->
`nx-mcp` fails not being able to resolve `node_modules/nx/*` files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This was fixed in an updated version so this just updates `nx-mcp`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When converting an Angular project to use Rspack with the
`@nx/angular:convert-to-rspack` generator, some target top-level options
can be lost (e.g. custom `dependsOn`, `outputs`, etc.).
## Expected Behavior
When converting an Angular project to use Rspack with the
`@nx/angular:convert-to-rspack` generator, relevant target top-level
options that wouldn't be inferred need to be kept in the converted
project.
## Current Behavior
The Claude Code setup has basic workflow automation but lacks
comprehensive tooling permissions and detailed guidance for issue
management. The workflow documentation contains redundant sections and
some outdated commands.
## Expected Behavior
With these changes, the Claude Code integration will have:
- Enhanced tool permissions for better CI/CD workflow support
- Comprehensive GitHub CLI commands for efficient multi-issue management
- Clear mandatory requirements for PR template completion
- Streamlined documentation with accurate command references
## Related Issue(s)
This PR builds upon the initial Claude Code setup from #31380 by
refining the workflow configuration and improving the developer
experience.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 affected` documentation was unclear and did not state what affected
projects actually meant.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Adds a clear definition of "affected projects" to the CLI documentation.
Affected projects are projects that have been changed and projects that
depend on the changed projects.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30712
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
## Summary
This PR integrates Claude Code AI assistant capabilities into the Nx
repository through GitHub Actions and workspace configuration.
## Changes Made
### 🤖 GitHub Actions Integration
- **Added `.github/workflows/claude.yml`**: GitHub Actions workflow that
triggers Claude Code on:
- Issue comments containing `@claude`
- Pull request review comments containing `@claude`
- Pull request reviews containing `@claude`
- New issues with `@claude` in title or body
- Configured appropriate permissions for repository access and PR/issue
management
- See [Claude Code GitHub Actions
documentation](https://docs.anthropic.com/en/docs/claude-code/cli-usage#github-actions)
for usage details
### 📝 Project Documentation & Configuration
- **Added `CLAUDE.md`**: Comprehensive instructions for Claude Code
including:
- Repository-specific guidance and best practices
- Essential commands for development workflow
- Testing procedures (individual projects → affected projects → e2e
tests)
- GitHub issue resolution workflow
- Pre-push validation requirements
- **Added `.claude/settings.json`**: Claude Code permissions and
environment configuration
- **Added `.mcp.json`**: Model Context Protocol server configuration for
Nx workspace integration
### 🔧 Workspace Setup
- **Updated `package.json`**: Added `nx-mcp` dependency for enhanced
workspace integration
- **Updated `pnpm-lock.yaml`**: Lock file changes for new dependency
- **Updated `.gitignore`**: Added Claude-specific ignore patterns
- **Updated `CODEOWNERS`**: Assigned ownership of Claude-related files
to @FrozenPandaz
- **Updated `CONTRIBUTING.md`**: Enhanced contribution guidelines with
technology stack information
## Benefits
- Enables AI-assisted development and issue resolution through GitHub
- Provides Claude with deep understanding of Nx workspace structure via
MCP
- Establishes clear development workflows and validation procedures
- Maintains security through configured permissions and environment
settings
## Usage
After this PR is merged, team members and contributors can:
1. Comment `@claude` in issues or PRs to get AI assistance
2. Use Claude Code locally with enhanced Nx workspace understanding
3. Follow established workflows for testing and validation
For more information, see the [Claude Code
documentation](https://docs.anthropic.com/en/docs/claude-code).
## Test Plan
- [x] Verify GitHub Actions workflow syntax is valid
- [x] Confirm Claude Code configuration files are properly structured
- [x] Validate new dependency integration
- [x] Test workflow triggers on issue/PR interactions
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Current Behavior
The `@nx/js/typescript` plugin writes cache files in a non-atomic
fashion, which can result in corrupted or empty files being written.
## Expected Behavior
The `@nx/js/typescript` plugin should write cache files atomically, and
they should not be corrupt. It should also retry a limited amount
attempts to account for temporary file locks.
## Related Issue(s)
Fixes#30239Fixes#31187
## Current Behavior
rspack.config.ts options related to optimizations are removed if the
mode is not "production". This makes the compile fail for all
non-production builds.
## Expected Behavior
If mode isn't set to "production" configuration related to optimization
should be passed through.
## Related Issue(s)
Fixes#31268#30292
## Current Behavior
When running `nx g @nx/eslint:convert-to-flat-config` on windows, the
ignores path is not handled correctly. After converting, the path will
have the additional `/r`
## Expected Behavior
When running `nx g @nx/eslint:convert-to-flat-config` on windows, the
ignores path should be correct.
Updates the docs structure, navigation etc to be easier + better suited
for showing Nx technology support beyond just TS.
**Notes:**
- API (`/nx-api`) tab is removed from the navigation (i.e. menu bar),
but pages still remain for now until we update references in `*.md`
files.
- Redirects are set up `/nx-api` to go to their respect new location
e.g. `/technologies` or `/reference/core-api`
- Old URLs still exist in the sitemap for now, but majority of them will
be redirected -- a follow-up PR can remove them.
**Preview:**
https://nx-dev-git-nx-dev-polyglot-docs-restructure-nrwl.vercel.app/docs
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Nx hangs when here is a `run-commands` target with no commands.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx does not hang when there is a `run-commands` target with no commands.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31345
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Command would fail silently with no error message
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Rather than erroring, Nx will find the next available port and use that.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30915
## Current Behavior
The `nx init` legacy integrated migration for Angular doesn't handle
Angular v17 because it was part of the LTS versions. With the upcoming
Angular v20, that version is no longer part of the LTS, so it needs to
be handled by the legacy migration.
## Expected Behavior
The `nx init` legacy integrated migration for Angular should handle
Angular v17 because it's no longer part of the LTS versions.
- Remove TS project reference to non-existent `tsconfig.editor.json`
file
- Ensure the `tsconfig.spec.json` file for Jest has the correct
`module`/`moduleResolution` compiler options
This PR fixes an issue when you serve nx-dev locally and navigate
between pages in the browser. You'll get an error that `gtag` is not
defined since we never loaded it. We now check that we're in production
environment before sending events.
## Current Behavior
When an `ng-package.json` file of an Angular library secondary entry
point does not specify `lib.entryFile`, the
`@nx/enforce-module-boundaries` rule throws an error. The
`ng-package.json` file of an Angular secondary entry point can be as
simple as `{}`, but it would cause the rule to throw an error.
## Expected Behavior
The `@nx/enforce-module-boundaries` rule should correctly handle an
`ng-package.json` file of an Angular library secondary entry point that
does not specify `lib.entryFile`. The property should [default to
`src/public_api.ts`](https://github.com/ng-packagr/ng-packagr/blob/22a7ba1979f117a12901dca195187948c1fd022d/src/ng-entrypoint.schema.json#L20).
Co-authored-by: Miroslav Jonaš <missing.manual@gmail.com>
## Current Behavior
AnalogJS installs 1.14.1 for Vitest support
## Expected Behavior
AnalogJS installs 1.16.1 for Vitest support
Co-authored-by: Miroslav Jonaš <missing.manual@gmail.com>
Current URL shortening logic is based on the old Nx Cloud version format
- `YYMM.DD.BuildVersion`.
Since, 2025 we changed that format to `YYYY.MM.BuildVersion` which
breaks this logic and causes the connection URL to be just host.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR improves dependency resolution for Node.js apps using Webpack or
Rspack.
While we already handle direct dependencies for non-buildable libraries,
this update ensures that **transitive dependencies** are also properly
included. This guarantees that all necessary dependencies are bundled
when the main app/library is built.
closes: https://github.com/nrwl/nx/issues/31334
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, when migrate @nx/gradle to latest, we don't check the
dev.nx.gradle.project-graph version in build file
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
we should check the project-praph in the build file and make sure it is
correct version
## 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 -->
current gradle task executor will run gradle task as it is. by default,
gradle command will run the tasks itself and its all depends on tasks.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- add excludeDependsOn in gradle executor schema with default value to
true: this allows gradle command to run tasks without its dependsOn
tasks. this improves performance time
- change project graph plugin (dev.nx.gradle.project-graph) to accept
option atomizer:
```
nxProjectReport {
atomized = false
}
```
this will disabled atomized targets to be created. check-ci will not
have dependsOn task ci, it will be test instead.
it will not created any ci and ci--* targets, but check-ci will be
created, but dependsOn test:
<img width="605" alt="Screenshot 2025-05-20 at 3 00 39 PM"
src="https://github.com/user-attachments/assets/a2e0ae20-78a1-4848-a063-5825b169c219"
/>
this is what check-ci target looks like with atomized as true:
<img width="917" alt="Screenshot 2025-05-20 at 2 59 34 PM"
src="https://github.com/user-attachments/assets/33c6af0b-3e45-498d-96d0-4f46c54a8159"
/>
- change dependsOn targets to include both project name and task name.
e.g. `spring-boot:checkFormat
`, so when excludeDependsOn is true, it will exclude exact task
- in batch runner, run test runner and build runner as same time
## 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 -->
In Module Federation apps, when remotes are defined using URLs that
include query string or hash fragments (e.g. for cache busting), those
params are not preserved after the application is built.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR ensures that query strings and hash fragments are preserved when
resolving or generating remote URLs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30602
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we try to generate a library with react it fails because `name` is
required.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This should work out of the box.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30721
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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, all tasks are cacheable
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
run and bootRun should not be cacheable
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Clarified language on cache poisoning protection to emphasize trusted CI branches. Removed redundant content regarding personal access tied to identity providers for simplification.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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, if we generate a react library with `--unitTestRunner` OOTB
it will fail when you run the `test` command because of a missing
dependency.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Generating a library with `--unitTestRunner` and then running that test
should work by default.
## 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 -->
Rust tests did not pass on MacOS
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Rust tests now pass on MacOS
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR improves the **createNodes** function of eslint's inferred
plugin by making two pragmatic choices:
- reusing the ESLint between config file's runs instead of recreating
the new one every time
- skipping ignored files checks for projects that already have eslint
config file
## Results of benchmarks on customer's repo:
### Without ESLint plugin
- create-project-graph-async - avg. 11739.1326225 -> 11 seconds
### With current ESLint plugin
- create-project-graph-async - avg. 98005.0965135 -> 98 seconds
### With modified ESLint plugin
- create-project-graph-async - avg. 13225.073817 -> 13 seconds
- (@nx/eslint/plugin:createNodes - 2206.96497, 16.69%)
## 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
#22953 updated the way that storybook parsing works to always do full TS
tree resolution instead of AST parsing. While this is more accurate,
it's orders of magnitude slower...creating a bottleneck in graph
creation for larger repos which use the plugin.
The only reason we need to do this complex functionality is to determine
if we use angular or not.
## Expected Behavior
Graph creation should be quite fast.
This PR returns the old behavior, and uses the new behavior as an
additive fallback. In most cases this will result in extremely fast
parsing when the framework is defined inline, and in the failure case,
it will result in unnoticeably slower parsing as the incremental
difference is minor.
Before:
```
Time for '@nx/storybook/plugin:createNodes' 13536.203667
```
After:
```
Time for '@nx/storybook/plugin:createNodes' 292.584667
```
An alternative solve (at least in our case) would be to add an option to
skip angular detection...essentially letting people bypass the whole
reason for doing this config parsing. Although that's probably not a
sustainable option.
NOTE: A majority of the remaining slowness in this plugin is spent
hashing the files for the target cache. If we wanted to, we could
further speed this up by making some assumptions there...but that may
drastically harm repos which rely on the fully resolution behavior
## Related Issue(s)
Fixes#31276
This PR fixes an issue where running `nx e2e <proj>` on Windows does not
kill the underlying dev/preview server when the e2e task ends.
Repro:
1. `npx create-nx-workspace@latest repro --preset=react-monorepo
--e2eTestRunner=playwright --appName=demo`
2. `cd repro && npx nx e2e demo-e2e`
This will leave the preview server running on port `4300`, and you have
to `netstat -ano | findstr :4300` to find the PID and kill it.
https://www.loom.com/share/fcbea53cdff543a98f4d4c8377027ee0
## Current Behavior
Continuous task does not kill the process correctly once discrete task
ends.
## Expected Behavior
Processes are killed correctly once task is done running.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31235
This PR disables Remix+Yarn tests. It looks like the tests aren't set up
correctly, and we're using `yarn` even thought he workspace is set up
with pnpm.
## Current Behavior
The e2e tests running Angular Rspack are not having their builds
minimized currently.
## Expected Behavior
Ensure `NODE_ENV=production` is set when calling the build commands
## Current Behavior
We currently have no method for generating Angular Rspack Module
Federation applications
## Expected Behavior
Update the `host` and `remote` generators to support a `--bundler` flag
to allow users to select Rspack as their bundler method
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.1.0-beta.1`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.1.0-beta.2`
## 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 -->
Got error: "413 Payload Too Large - PUT http://localhost:4873/nx -
request entity too large"
<img width="873" alt="Screenshot 2025-05-16 at 4 23 17 PM"
src="https://github.com/user-attachments/assets/fd151405-6f4a-4987-b9cd-63b5dc9cef2f"
/>
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
increase body size to avoid this error
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…n 75 characters of width
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Auto layout is always based on an aspect ratio which lead to horizontal
layout even when there is very little horizontal space.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Auto layout prefers vertical layout with less than 75 characters of
width which will allow 50 characters (75 * 2/3) for terminal output. It
should be enough to show a URL in most cases:
## 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 -->
Pipeline only runs on `master` and PRs
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Pipeline runs on any release branches and PRs
## 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 -->
Rule files are created by Nx Console, and gitignore updates are done
there.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Rule files are still created by Nx Console, but there is now a migration
to add those files to the gitignore rules on migration and new
workspaces.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
It adds a new "Solutions" section to the Nx Dev website with three targeted landing pages for different audiences: engineering teams, management teams platform teams, and leadership.
It creates three new page files (engineering.tsx, management.tsx, leadership.tsx, platform.tsx) that showcase Nx's benefits through various UI components like heroes, testimonials, feature sections, and FAQs. Each page highlights specific value propositions - engineering focuses on developer efficiency and standards, platform emphasizes reliable CI/CD scaling, and leadership addresses ROI and risk reduction.
The navigation is updated with a new "Solutions" dropdown menu in both desktop and mobile views, with corresponding menu items defined. The solutions pages include consistent sections like customer logos, calls-to-action, testimonials, and feature breakdowns that highlight Nx's capabilities for different stakeholders.
…jects were changed from pnpm lock file diff
Closes#29986
## Current Behavior
Nx projects that use pnpm catalogs cannot take advantage of the
`projectsAffectedByDependencyUpdates` `“auto”` setting because updating
catalog versions does not touch project files.
## Expected Behavior
When `projectsAffectedByDependencyUpdates` is set to `“auto”`, updating
a catalog dependency version should result in all projects that use it
getting marked as affected.
A catalog version update and the affected projects can be detected from
a changed pnpm lock file. This PR updates the
`getTouchedProjectsFromLockFile` logic to check the lock file for pnpm
monorepos.
Example pnpm lock file diff after catalog dependency update:
```diff
# pnpm-lock.yaml
# ...
catalogs:
default:
'@aws-sdk/client-s3':
- specifier: ^3.535.0
- version: 3.535.0
+ specifier: ^3.797.0
+ version: 3.797.0
importers:
apps/app1:
dependencies:
'@aws-sdk/client-s3':
specifier: 'catalog:'
- version: 3.535.0
+ version: 3.797.0
# ...
```
## Related Issue(s)
https://github.com/nrwl/nx/issues/29986Fixes#29986
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
These migrations should not have been removed as part of the Nx 21
update
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The migrations are restored
## 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 -->
Recording task runs does not send via the queue so the daemon could hang
without handling the response properly.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Recording task runs sends via the queue and does not hang
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When migrating our project to esm, we encountered an issue with the
playright plugin, but more generally with the `loadConfigFile` from the
devkit.
Our configuration is a `.cts` file, but it's not treated as commonjs:
`__dirname` and `__filename` are not available.
## Expected Behavior
`.cts` files are interpreted as commonJS files when in a module context.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Currently, the nightly tests are broken in a few ways this PR addresses
some of those issues but ultimately ensures that each step has a timeout
to handle the work case scenario i.e. unable to complete.
- Add bun installation and split e2e runners for macos, linux and
windows
- Add rust installation
- Add timeout for e2e tests
Here is the result of a previous run:
https://github.com/nrwl/nx/actions/runs/14999368644
The most latest run can be found here:
https://github.com/nrwl/nx/actions/runs/15027418322
**Note**: The final result will be _failure_ because many tests still
need to be addressed, so that is expected.
This PR fixes an issue with the global `nx` command, where running `nx
init` in a non-JS folder (i.e. using dot-nx setup) results in a
workspace that doesn't work with the global command.
e.g.
```
brew install nx
cd some-java-project
nx init
nx report
```
https://www.loom.com/share/e8dbb2fb7a084300a4dd1e5dff2c0db1
## Current Behavior
`nx report` or any other command fails
## Expected Behavior
`nx` commands should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Some tasks cannot be interactive because of the way they are
implemented. At the moment, those tasks can be set to interactive mode.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Tasks which cannot be interactive are not set as interactive
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There are very few logs for the running task service.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There are logs for the running task service.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, when we generate a vite library that uses `vite-plugin-dts`
it breaks the project graph and all nx commands fail.
It happens because the wrong version of `ajv` is being hoisted in
`node_modules/ajv` so the expected module path required from
`vite-plugin-dts` is not found.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx commands should work out of the box when we generate a library with
vite.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Angular plugin currently uses Angular Rspack at `^20.7.0`.
The latest release of Angular Rspack is `21.0.0`
## Expected Behavior
Use the latest version of Angular Rspack
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There is no communication between Nx CLI and Nx Console
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This enables a connection between the Nx TUI app and Nx Console so that
we can send messages to console. This is used to update MCP tools on Nx
Console to assist with LLMs
## 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 -->
Red is used as a colour when running multiple processes in the command
line. This causes confusion as red is universally the colour for
danger/errors.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Red should not be a colour in the console and blue should be used
instead.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#19901
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.0.2`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.1.0-beta.0`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`esbuild` has a [security
advisory](https://github.com/advisories/GHSA-67mh-4wv8-2f99) for
versions older than 0.25.0. `@nx/esbuild` does not allow versions
greater than 0.19.2 due to the range specified in peer dependencies.
A fix for this was attempted in #30167, but it still does not allow any
versions greater than 0.19.x due to the way [0.x.x releases are
handled](https://github.com/npm/node-semver#caret-ranges-123-025-004).
## Expected Behavior
`@nx/esbuild` allows any version from the current 0.19.2 onwards, not
including a future 1.x.x version. This will allow non-vulnerable
versions of `esbuild` to be used.
## Related Issue(s)
Fixes#30009Fixes#30370
Add documentation for `disableChecksum` flag for AWS S3 storage options
so users can opt out of validating checksum while retrieving remote
cache.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 `convert-to-rspack` generator does not handle projects that use
Prerendering or App Shell
## Expected Behavior
The generator sets up Prerendering and App Shell
Fixes https://github.com/nrwl/angular-rspack/issues/88
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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#30808
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
current ci test target does not contain inputs of test, it just contains
the test source file
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
change the ci targets to contain inputs of test
<img width="903" alt="Screenshot 2025-05-13 at 1 31 22 PM"
src="https://github.com/user-attachments/assets/d73de232-440a-439b-adb8-e22fc3fe3d8a"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently using 2021 edition of rust
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Updates to 2024 edition to support more features that are coming in
other PRs
## 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 -->
Running a single task is in this uncanny framed state and doesn't exit
immediately.
<img width="1317" alt="image"
src="https://github.com/user-attachments/assets/13e7463f-9eb0-48db-95f2-c09e203d494f"
/>
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running a single task isn't framed and exits immediately.
This also fixes scrolling in interactive mode based on whether or not
the underlying terminal is in application cursor mode or not.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: JamesHenry <james@henry.sc>
## Current Behavior
The application and library generators do not install the
`@angular/build` package when using the `vitest` test runner. This can
cause resolution issues depending on the package manager because the
package is a peer dependency of the `@analogjs/vite-plugin-angular`
package.
## Expected Behavior
The application and library generators should install the
`@angular/build` package when using the `vitest` test runner.
## Related Issue(s)
Fixes#30646
This PR refines the Next.js package plugin’s output glob to exclude the
.next/cache directory. Caching that path via AWS S3 leads to checksum
mismatches when restoring from the remote cache, so it’s now omitted.
related: https://github.com/nrwl/nx/issues/30338
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This is intended to be a super quick improvement until I can work on
something a bit more substantial.
## Current Behavior
<!-- This is the behavior we have today -->
We always try and render `[Pinned output {}]`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We only render `[{}]` on narrow widths.
## 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 -->
Not much info is shown for errors.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
More info is shown when publishing
## 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
Symlinks in the remote cache tarball are "followed". That modifies the
output of Next.js projects using pnpm, causing a restored cache not to
work in production.
## Expected Behavior
Symlinks are added to the tarball, instead of being followed. I.e. the
cache output is not modified.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Should fix#31085.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
"ERROR" is set as the default logging level when using native logging.
This causes issues with the new function of calling the native logger
from the JS side.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
"OFF" is set as the default so that no logs appear on stdout if there
was no explicit opt-in.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When running a single task it is automatically focused, but the tasks
list is visible and the task is not interactive
## Expected Behavior
When running a single task, the tui is minimal without a tasks list and
with interactivity by default
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes an issue if a JS project uses the same name as the npm
scope.
For example, if you have `@acme/acme` and `@acme/acme-e2e` projects,
then running `nx lint acme` will fail with an error:
```
NX Multiple projects matched:
@acme/acme-e2e
@acme/acme
```
## Current Behavior
Nx fails to run the task
## Expected Behavior
Nx should find the project to run the task for (ignoring scope)
## 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 -->
TUI debug mode only shows native logs since the TUI launched.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
TUI debug mode shows logs even before the TUI launched such as task
hashing logs and more.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
* There are many unwraps that we can avoid by using `parking_lot::mutex`
* There is an unnecessary `task::spawn` to dispatch actions. The channel
is non-blocking and this is wasted cycles
* There are a bunch of clones that are happening with the PtyInstances
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
* Uses `parking_lot::Mutex` and removes `unwraps()`
* Dispatches actions directly without going into tasks
* Uses tuple derefs to avoid clones, and uses 2 instead of 4
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Debugging the TUI is a chore
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Debugging the TUI is a little better..
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There's a typo.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Typo is fixed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- Currently, when we create a React, Vue or Node app we add the app name
inside `package.json` under the nx
```
{
"name": "@myworkspace/acme",
"version": "0.0.1",
"private": true,
"nx": {
"name": "acme"
}
}
```
- When we create a publishable library using React/JS generator inside a
ts project references workspace the `--importPath` option.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- Since the original intention is not known we should not automatically
add this to the project's `package.json`
- `importPath` option should not be required when using ts project
references.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
For workspaces that are not using TS project references the result
remains unchanged.
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 -->
db connections are cleaned up on SIGTERM, SIGHUP, SIGINT, AND exit. On
SIGTERM, SIGHUP, and SIGINT, the process exits there.. which short
circuits other SIGTERM, SIGHUP, and SIGINT handlers.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
db connections are only cleaned up when the process actually exits. It
does not exit the process here in response to any signals.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, because it requires to sign locally, so i thought run command
like
`:project-graph:publishToMavenLocal -x
:project-graph:signNxProjectGraphPluginPluginMarkerMavenPublication -x
:project-graph:signPluginMavenPublication -x
:project-graph:publishNxProjectGraphPluginPluginMarkerMavenPublicationToMavenLocal
-x :project-graph:publishPluginMavenPublicationToMavenLocal` would
publish the plugin locally, but it actually does not. it does not throw
an error, but does not do anything at all.
so for e2e tests, it is actually pulling the latest published gradle
plugin from maven rather than test local code, hence the e2e errors.
also, currently project graph build for java version 21, we change it to
java 17 to be used by ocean repo.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
change the command to `./gradlew :project-graph:publishToMavenLocal
-PskipSign=true` and not apply signing when skip sign is true, so this
should be able to publish plugin to local repository.
work with java 17
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
there is no idle timeout set for gradle, by default is 3 hours.
when running gradle in DTE, it seems to run into memory issue. Even
through using tooling api, the connection is closed when batch is done,
but i think the gradle daemon is still active in the background. when
running the next batch, it is going to start a new gradle daemon and i
got an error like
```
Starting a Gradle Daemon, 2 busy and 200 stopped Daemons could not be reused, use --status for details
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
add idle timeout for 10s.
this inline command will make gradle daemon to stop itself after 10s.
## 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 -->
Cleanup is happening on SIGTERM, SIGINT, and SIGHUP signals and on
exit....
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Cleanup is mostly done on exit.
## 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 -->
Whenever using the new Typescript style repos (using package.json
instead of project.json for typescript projects), we get incorrect paths
when using `resolveImportWithRequire` on Windows. Currently when trying
to find a path, we end up with a path similar to
`../C:\\dev\\nx\\file.ts` which is incorrect.
## Expected Behavior
Changing `posix.relative` to just relative, allows us to get the proper
path on Windows like so: `.\\file.ts`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
Running commands in the Nx repo panic due to a wrong published version
of `@nx/powerpack-license` package.
## Expected Behavior
Running commands in the Nx repo should not panic.
## Related Issue(s)
Fixes #
## Current Behavior
Some task outputs are missing in terminal outputs
## Expected Behavior
Task outputs are present
## 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 -->
Entire TUI exits when any process exits with a SIGINT
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
TUI stays alive when a process exits with a SIGINT
## 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 -->
Light themes are not super clear with the new TUI.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Light themes are much clearer with the new TUI.
Internal loom shared on slack for full details.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: JamesHenry <james@henry.sc>
<!--
_[Please make sure you have read the submission guidelines before
posting an
PR](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## @robby-rabbitman/nx-plus-web-test-runner
A plugin to infer [Web Test
Runner](https://modern-web.dev/docs/test-runner/overview) in a Nx
workspace.
<!--
Describe what your plugin is and what is its goal or issues it
addresses. If you don't provide a description, we will not merge your
PR.
Is it focused on a technology, tooling or behaviour? Does the plugin
provide generators, executors or graph support?
Do you know who is already using the plugin? Mention who is the author
of the plugin.
-->
Co-authored-by: robby rabbitman <robby.rabbitman@gmail.com>
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, when we use the jest configuration generator it will forcibly
update the jest version if the package already exist.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Now, the jest version will be preserved unless the option is passed to
update the version.
## 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 -->
Forked process task runner cleanup is not explicitly invoked.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Forked process task runner cleanup is explicitly invoked.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `${configDir}` template variable in tsconfig files is incorrectly
handled when inferring tasks with the `@nx/js/typescript` plugin.
## Expected Behavior
The `${configDir}` template variable in tsconfig files should be
correctly handled when inferring tasks with the `@nx/js/typescript`
plugin.
## Related Issue(s)
Fixes#30883
Updated content to specify vulnerabilities in community-built and Nx self-hosted cache solutions, highlighting risks like cache poisoning and lack of compliance with regulated industry security standards.
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## @naxodev/gonx
GoNx is an opinionated Nx plugin for Go/Golang development, forked from
the original nx-go plugin. It enables developers to manage Go projects
within an Nx ecosystem through a non-invasive approach that heavily
relies on inferred tasks and modern Nx features.
The plugin provides generators for applications and libraries with
customizable module setup, executors for building, testing, running, and
managing dependencies, and full Nx integration, including cacheable
tasks, GraphV2 support, and release capabilities. GoNx utilizes official
Go commands in the background, delivering efficient caching and
dependency graph tools for Go projects.
## Current Behavior
We currently install Rspack at `^1.2`. The latest version of Rspack is
`1.3.8`
Angular Rspack now requires at least `1.3.5`
## Expected Behavior
Rspack installations should use latest version of `1.3.8`
Fixes an issue with the docs release script when there is only one
version in a particular major version.
The `npm show [version] --json` command normally returns an array of
strings, but if there is only one version returned, it tries to be
helpful by returning a string instead. This fix normalizes that
behavior.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 21.0.0-rc.3
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 21.0.0-rc.4
## 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 -->
Tasks run via `run-commands` are not cleaned up properly.
`nx serve-docs nx-dev` in this repo did not cleanup the running server
when cancelled.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Tasks run via `run-commands` are cleaned up properly.
`nx serve-docs nx-dev` in this repo does clean up the running server
when cancelled.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request updates the CI workflow configuration to replace the
use of `pnpm/action-setup` with `corepack enable` for package manager
setup.
- NPM versions greater than 8 has an error which has been [fixed in Node
22.5.1](https://github.com/npm/cli/issues/7639), since we are still
using Node 20 we need to pin the installed npm version to 8.
- Now we are conditionally handling different package managers based on
how the repo has been configured.
Should the repository specify the package manager's version for `pnpm`
and `yarn` those versions will be respected, else it will fallback to a
`9.8` for `pnpm` and `1.22` for `yarn`.
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Disabling the schedule run for e2e matrix job as macos is still hanging.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
- Adds Briebug as an Nx Partner
- Updates Pushbased partner slogan and tags
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.0.0-rc.2`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.0.0-rc.3`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When tasks are still running but the user exits the TUI, Nx returns exit
code 0 (success)
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When tasks are still running but the user exits the TUI, Nx returns exit
code 130 (SIGINT)
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Migrate Gradle tutorial to tutorial kit section (not as an interactive
tutorial)
- remove `npx` from online tutorial instructions
- Update sidebar tutorial links to point to new tutorials
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, the command in ci workflow is `nx affected -t build`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
change to run `nx affected -t assemble, check` with batch turned on for
gradle
## 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 #
This PR makes sure that `vite:build-base` is cacheable. It's a
long-standing issue because vite is the only package using SWC to build,
thus the `targetDefaults` using TSC is not being applied. We don't
actually need to specify the executor, as `build-base` using
`@nx/next:build` (nx-dev) and `@nx/js:swc` (vite) are both cacheable.
## Current Behavior
Vue and Nuxt projects using ESLint with flat config generate projects
using the `@typescript-eslint/parser` but don't install the package.
This can result in an error if the package has not been installed
before.
## Expected Behavior
Vue and Nuxt project generators should install the
`@typescript-eslint/parser` if they generate ESLint configuration that
uses it.
## Related Issue(s)
Fixes #
Currently if Playwright runs with trace on, it'll generate `.js` files
in `test-output` folder. Trace is turned on automatically whenever a e2e
test retries, or if the user sets `trace: 'on'`, or if `--trace on` is
passed to the CLI.
These trace `.js` files are being linted, and is failing the lint task.
## Current Behavior
Lint fails when trace is on
## Expected Behavior
Lint should ignore trace files
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.0.0-rc.1`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.0.0-rc.2`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
These defaults are unnecessary and can be removed.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This is a fix when using the TUI `forked process-task-runner`. The
`SIGINT` and other signals are not handled, which causes the underlying
process (in this case `run-executor`) to be left hanging.
## Current Behavior
TUI leaves processes hanging when using `forked-process-task-runner`
## Expected Behavior
TUI should kill processes
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes the badge on package readmes, e.g.
https://www.npmjs.com/package/nx.
It currently shows the latest for `@nrwl/workspace`, which is `19.8.4`,
but we should show the latest nx (`20.8.1`).
## Current Behavior
Cypress e2e tasks fail when trying to kill the web server with:
```bash
TypeError: Cannot read properties of undefined (reading 'childProcess')
at /<repo path>/node_modules/@nx/cypress/plugins/cypress-preset.js:65:30
...
```
## Expected Behavior
Cypress e2e tasks should not fail when trying to kill the web server.
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 21.0.0-beta.12
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 21.0.0-rc.1
## 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 -->
Discrete tasks are not run with batches.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Discrete tasks are run as batches if possible.
## 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 -->
Native build is broken on Windows.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Native build is fixed on windows.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Adds continuous support for Detox, Expo and React Native
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
rspack and next do not get killed when using the tui. This appears to be
caused by them not responding correctly to SIGTERM, so we need a way to
pass signals with our `kill` call.
## Expected Behavior
We properly shutdown rspack and next servers
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This commit also contains various changes to ensure serve-static tasks
depend on their build.
BREAKING CHANGE: Remove deprecated static-serve target name from Remix
Inferred Tasks in favour of serve-static.
WIP
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 #
MacOs CI job is taking a lot longer than expected and it blocks PRs
statues from being generated.
We should keep working on it so it can be re-enabled.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 #
Defaults causing an object to be defined causes some confusing behavior
when a schema has defaults and required properties for a given object
prop. If the required prop doesn't have a default value, and another
property does, it becomes invalid to not pass the object when it would
be valid had that default not been specified.
BREAKING CHANGE: Currently if an executor's schema provides some default
values for an object's properties, those defaults cause the object to be
defined. This changes that, such that the defaults are only applied if
the object exists in the first place.
Fixes#23153
Prefer `process#kill` instead of `tree-kill` for Mac and Windows. This
fixes an issue on Windows where the `taskkill` is unsuccessful.
## Current Behavior
Windows does not always run successfully
## Expected Behavior
Windows runs successfully
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Removed the external JS script loader for a third-party B2B script as it is no longer required. This simplifies the `_app.tsx` file and avoids unnecessary script management during route changes.
Integrated Google Tag Manager (GTM) with both script and noscript tags for analytics tracking. Ensured the script uses `afterInteractive` loading strategy and includes dynamic `gaMeasurementId` for proper configuration.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
--tuiAutoExit doesn't support env vars
## Expected Behavior
NX_TUI_AUTO_EXIT can set --tuiAutoExit
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The tui displays the path to the fork script in the pty pane
## Expected Behavior
The tui displays a command that would be "close enough" to what is being
ran in the pty pane
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
this pr address comments in https://github.com/nrwl/nx/pull/30457
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- update executor description
- use pseudo terminal when run batch command
- add an e2e test to run gradle command in batch
- add migration script to change ciTargetName to ciTestTargetName
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/angular:convert-to-rspack` relies on `require.resolve` to check
if entries listed in the `polyfills` array is an npm package.
However, in some circumstances such as generating a new app, `zone.js`
is not yet installed and therefore require.resolve will not resolve the
package.
## Expected Behavior
Ensure that `zone.js` is special cased as it is a polyfill that is
always needed to be treated as a package.
This is also the only polyfill that is set during generation of an app
and therefore is the only package that should run into this issue.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
non of the gradle tasks is set as continuous
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
set only bootRun task as continuous
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Rust formatting isn't checked in CI
## Expected Behavior
Rust formatting is checked in CI
## 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. -->
BREAKING CHANGE: We are updating our minimum node version to `20.19.0`
which drops support for all prior versions.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.0.0-beta.10`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.0.0-beta.11`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
For some mysterious reason, calling `getResults` after killing a
continuous task causes the DTE agent process.. to exit.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
For some mysterious reason, allowing `getResults` to return results
after the Task has completed fixes the DTE agent process exiting.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The native file cache doesn't check NX_VERSION when determining its key
## Expected Behavior
The native cache is invalidated when updating Nx
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30940Fixes#29184
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
vt100 does not work for non TUI
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
do not use vt100 for printing to stdout. vt100 is still used for the TUI
terminal panes.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Attept to read package manager version from config before invoking
package manager CLI
BREAK CHANGE: If you have a mismatch between the `packageManager` field
in `package.json` and the actual version installed in the environment,
it may lead to unexpected behavior when installing. This should not be a
problem if you are using corepack already.
## Related Issue(s)
https://github.com/nrwl/nx/issues/29244
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
This PR removes installation instructions for Nx < 18 since it has
fallen out of support window. Users can always `npm install <plugin>` as
usual if they are on an unsupported Nx version, but the docs will assume
`nx add` moving forward.
The changes are on the plugin overview page:
https://nx-dev-git-docs-remove-nx-pre-18-install-nrwl.vercel.app/nx-api
## Current Behavior
`@monodon/rust` is outdated
## Expected Behavior
`@monodon/rust` is updated
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
…ctive mode
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Ctrl Keybindings are not sent to terminal panes when it's interactive
mode, only single key presses are sent.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ctrl Keybindings are sent to the terminal panes when it is in
interactive mode. This means that editors like `nano` and `nvim`
somewhat work in interactive mode. The rendering is still broken right
now but the keypresses work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Update the nested import paths from `ng-packagr` to handle the different
paths in the upcoming Angular v20.
We must update and release `@nx/angular` and update the Nx repo with the
new version to handle the path changes in the upcoming `ng-packagr` v20
before updating the version in the Angular v20 branch. Otherwise, a
compilation error is thrown when building the v20 branch because the
installed `@nx/angular` version does not support the new paths needed in
`ng-packagr` v20.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 PseudoTerminal does not kill it's child processes when it shuts
down.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The PseudoTerminal will kill it's child processes when it shuts down.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…out of memory
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Many pipelines are stuck because this task is causing agents to run out
of memory.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This test is disabled so that pipelines can complete.
## 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 -->
1. The continuous property is not present in the nx.json schema.
2. When tasks which do not support parallelism depend on a continuous
task, task execution is deadlocked.
3. Circular dependencies between continuous dependencies are allowed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
1. The continuous property is added to the nx.json schema.
2. An error is thrown when tasks which do not support parallelism
depends on a continuous task.
3. Circular dependencies between continuous tasks are caught and thrown
as an error.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This reverts commit 307c45542a.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Gradle tasks are run by invoking the Gradle CLI
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Gradle tasks are run through the Gradle Tooling API and is more
performant.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
## Current Behavior
The tasks inferred by the `@nx/nuxt/plugin` do not set `continuous:true`
for serve-like tasks.
## Expected Behavior
The tasks should be correctly inferred with `continuous:true`.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 21.0.0-beta.8.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 21.0.0-beta.10
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Removes the previously deprecated and unused `tsConfig` and `copyFiles`
options from the `@nx/cypress:cypress` executor.
BREAKING CHANGE: The previously deprecated and unused `tsConfig` and
`copyFiles` options from the `@nx/cypress:cypress` executor were
removed.
Removes the previously deprecated and unused `tsConfig` option from the
`@nx/jest:jest` executor.
BREAKING CHANGE: The previously deprecated and unused `tsConfig` option
from the `@nx/jest:jest` executor was removed.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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
-->
1. remove unnecessary references to `runs-on`
2. fix ordering of rule precedence example so that it matches the
explanatory paragraph
3. modify the matrix github actions example so that agents of different
types do not have the same name
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When running via run-many failures that include a continuous task are
indicated as a cancellation on the tui summary
## Expected Behavior
Failures that run to completion are not cancelled, and should be
displayed as a failure
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR bumps two v21 removals to v22:
1. SWC inline feature -- some people still use it even though it's
experimental. We should rethink how to remove this.
2. Cypress component testing not relying on `@nx/webpack:webpack`
executor -- we need a separate `webpack.cy.config.js` that only
configures the plugins needed Cypress CT.
This PR also keeps the Webpack plugin exports of `@nx/react` and
`@nx/webpack` packages. The `convert-to-inferred` and app generators
have been using the `@nx/react/webpack-plugin` and
`@nx/webpack/app-plugin` already for a while, there's no harm to keep
the exports in the index for older projects if they haven't been
updated.
This PR removes the `isolatedConfig` option that has been deprecated
since v17. Back when it was deprecated, we had a migration to remove the
option and set `webpackConfig` with a generate config file that matches
the executor's built-in behavior. Now that we're removing the option, a
similar migration is added to generate the config files for any projects
that skipped the migration the first time.
This PR updates all `.babelrc` file that still uses the deprecated
`classProperties.loose` (deprecated since v18). The top-level `loose`
option does the same thing -- previously the two options handled
different cases because `@babel/preset-env` did not include class
properties.
This PR delays deprecation of `svgr` for `@nx/next`, as Turbopack
supports it now.
This PR also deprecates all SVGR support for v22. It is not a well-used
feature, and the webpack plugin is not maintained. We'll ensure in v22
to add the SVGR webpack plugin to userland configs, but we'll not
maintain it ourselves moving forward.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
No continuous tasks are used in CI.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The local-registry is a continuous task and it is used in CI.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
gradle import e2e failed from time to time. i think it is flaky test
because it passed before.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
disable this e2e test for now. will enable it later.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When the TUI is enabled, JS errors during task running cause the process
to exit without printing out information about the error and also leave
the terminal in a broken state.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
JS errors are printed before the process exits and the terminal is
restored to a good state.
## 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 -->
The TUI is missing some standard keybindings:
Q to quit
Enter to show task output
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Q now triggers a confirmation to exit. Because Q is close to 1, users
might often accidentally hit Q so this gives them a chance to cancel the
exit.
Enter will show the task output.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…versions
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Graph fails when there is a trailing comma in a package.json
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Graph does not fail and works when there is a trailing comma in a
package.json
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`removeDependenciesFromPackageJson` tries to delete dep from `undefined`
if there is no `dependencies` or `devDependencies` in package.json
## Expected Behavior
First check if `dependencies` or `devDependencies` exists
## Related Issue(s)
Fixes#30222
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
This PR adds a button for user to undo a migration that's already been
applied and pending approval.
See: https://www.loom.com/share/97286bdc80ea4538af76a914ef8f0f8b
Also, fixes an existing issue where `migrations.json` did not record the
correct git sha for each commit.
## Current Behavior
When a migration is pending approval, the only option is to accept it.
## Expected Behavior
Allow user to undo a migration if they don't want the changes.
## 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 -->
Users migrating from Nx 17 can go up to Nx 20.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Users migrating from Nx 19 can go up to Nx 21. Users migrating from Nx
17 or 18 should go to Nx 19 first.. then go to Nx 21.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
We error when failing to find a package version via the install step,
but meant to warn. Additionally, the warning is hard to see.
## Expected Behavior
We don't error when failing to install the package, but the warning is
more visible.
## 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 -->
Everytime the TUI is rendered with a terminal pane opened, we clone the
screen. This cloning is resource intensive as we would be creating a new
screen every couple of milliseconds.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This has changes so that we can pass a reference to the screen to be
used in places where its needed. This avoids the cloning the screen.
## 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 -->
`nx:build` cannot be run in parallel with any other tasks. It was an
improper fix for an issue we were facing in our task graph. This is also
not workable if any continuous tasks are running.. which I want
`local-registry` to be running while things are built.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The proper outputs are set on `build` targets. Most of them only need
`README.md` as the output. `nx`, `create-nx-workspace`, and
`create-nx-plugin` are different and need a few more files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Remove the deprecated function `readWorkspaceConfig` from
`@nx/workspace`.
BREAKING CHANGE: The previously deprecated `readWorkspaceConfig`
function from `@nx/workspace` was removed.
## Current Behavior
Module Federation collectRemotes util looks for a hardcoded `build`
target.
## Expected Behavior
Read the remote's targets and find the correct `buildTarget` option for
the module-federation-dev-server to use
## Related Issue(s)
Fixes#30808
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
A small typo to make reader misunderstand the definition of `production`
## 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 #
Removes the usage of the `cli` property from migration definitions.
BREAKING CHANGE: The `cli` property from migration generator definitions
is no longer used. The CLI to run the migration generator will be
identified based on whether the definition is contained in `generators`
(Nx) or `schematics` (Angular CLI).
Remove the deprecated function `getJestProjects`.
BREAKING CHANGE: The previously deprecated `getJestProjects` function
was removed in favor of `getJestProjectsAsync`.
This PR adds support for package.json based secondary entry points and
implements fix for situation when package imports base entry point as
dynamic dependency and secondary entry point as static dependency.
## Current Behavior
When the package is imported from itself, check for a secondary entry
point checks only Angular-style secondary entry points.
When package is importing from the same library as dynamic import from
root and static import from secondary entry point we still get linter
errror.
## Expected Behavior
Check for secondary entry points should also support standard
package.json-based entry points.
Importing from the same library as dynamic import from root and static
import from secondary entry point should be allowed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18552
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 tasks are skipped due to a dependent task's failure, the TUI does
not recognize that the command is concluded and leaves the user in a
confusing state where Nx seems like it is still waiting for tasks.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When tasks are skipped due to a dependent task's failure, the TUI shows
that the command has concluded.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `HtmlRspackPlugin` does not support interpolation of %VAR% in the
index.html.
This is supported with a custom Webpack Plugin for `@nx/webpack` for
generating index.html files.
## Expected Behavior
The `@nx/rspack` plugin should support the same feature set as webpack
for seamless migration.
Add a new `WriteIndexHtmlPlugin` for Rspack to support this.
It should only be used when `useLegacyHtmlPlugin` is set to true
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo is using Nx `21.0.0-beta.7`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo is using Nx `21.0.0-beta.8`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates `nx release` to use the revamped versioning
implementation by default. It also updates and adds relevant
documentation, and provides an automated migration for the new
configuration structure.
For anyone exclusively versioning TS/JS packages, there should be no
real difference to your experience (although a number of bugs have been
fixed and new features around updating multiple `package.json` files at
once are now available to you with this change).
For the lifecycle of Nx v21, `release.version.useLegacyVersioning` will
remain as a option that can be set to `true` to revert to the old
behavior and configuration structure.
NOTE: This should only be a temporary solution, for example if one of
the plugins you use does provide a `VersionActions` based versioning
implementation yet. The option and legacy implementation will be removed
entirely in Nx v22 (in ~6 months).
BREAKING CHANGE:
**⚠️ For any early adopters of `VersionActions` in Nx 20.8 when it was
opt-in, there are breaking changes to the abstract class here as well.**
`manifestRootsToUpdate` has gone from `string[]` to `manifestsToUpdate:
{ manifestPath: string; preserveLocalDependencyProtocols: boolean; }[]`
to support controlling the local dependency updates per manifest in
order to support advanced source vs dist scenarios, and correspondingly
`isLocalDependencyProtocol` has been removed from the abstract class and
the method will no longer be called from the core logic. It should be
thought of as an implementation detail of `updateProjectDependencies`
instead.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 new DTE APIs are missing a few things related to task environments.
Firstly, even though it processes task envs.. they are not stored on the
`processedTasks` map. Thus, the task env is not actually used to run
tasks. Secondly, some environment variables are not set during dte..
which used to.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The.2 things that are missing are now back. The map is populated with
the task envs and the environment variables are set based on the args.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
macos ci runs are not cancelled on new CI push
## Expected Behavior
macos ci runs are cancelled on new CI push
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates the Migrate UI such that the primary CTA always performs
an action. Previously, when there is a migration to approve, the primary
CTA says `Run Migrations`, but clicking it does nothing since we're
already in the middle of running migrations.
<img width="1093" alt="Screenshot 2025-04-23 at 9 36 05 AM"
src="https://github.com/user-attachments/assets/4d55e3d0-d16b-4c4b-9b16-551690be60ab"
/>
Now, with this PR, the primary CTA will be disabled and tell the user to
approve the current migration before continuing.
## Current Behavior
Primary CTA in Migrate UI does nothing when there is a migration to
approve
## Expected Behavior
Primary CTA should reflect the current action that the user must take,
in this case to approve the migration
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The only way to set if a task is continuous is either directly in
`project.json` or via Project Graph Plugins.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Executors know if they are definitely continuous or not. Plenty of
existing continuous tasks are using executors. Executors are now able to
define if they are continuous in their `schema.json` files. Thus,
existing tasks configured with certain executors will automatically
become continuous.
## 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 -->
The `project.json` schema is missing `continuous`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `project.json` schema has `continuous` defined.
## 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 -->
`nx:build` has `build/packages/nx` as an output. At the same time,
`build-base` tasks which depend on Nx.. are compiling based on
`build/pacakges/nx`. When `nx:build` is being restored from cache..
`build/packages/nx` gets deleted.. and then restored. While it is
deleted, `tsc` tasks are unable to find modules from `nx`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This isn't necessarily the correct solution, but `nx:build` will no
longer support parallelism ensuring that it does not get restored from
the cache while other `build-base` `tsc` tasks are running. The proper
fix is to fix the outputs of `nx:build` to be more specific about the
files that it is actually modifying.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When using Module Federation with an app that defines styles as a
separate entry point, HMR fails to update in the browser. Instead of
updating automatically, a warning is shown in the console related to a
missing chunk. A full-page reload is typically required, which is not
the intended behaviour.
## Expected Behavior
<!-- This is the behaviour we should expect with the changes in this PR
-->
HMR should work with styles as an entrypoint.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
The default is for `runtimeChunk` is `config.optimization.runtimeChunk =
{name: 'runtime'}` it is _not_ the same as `single` but the naming will
be the same.
Fixes#9582
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.0.0-beta.6`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.0.0-beta.7`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Removed outdated references to RFC #30548 in FAQ and remote cache solutions components. Updated the link to point to the relevant documentation on building a custom caching 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
Flaky tasks are only shown when not using the tui
## Expected Behavior
Flaky tasks are printed at the end of the summary view
<img width="1053" alt="image"
src="https://github.com/user-attachments/assets/4b068a52-72c3-415e-af91-481c12bb3f12"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `21.0.0-beta.4`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `21.0.0-beta.6`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
… tasks
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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, only running tasks which are a PseudoTTYProcess stream
outputs to the TUI.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Most running tasks have `onOutput` even if they are not a
`PseudoTTYProcess`. This method is used to stream outputs to the TUI.
The only sort of running task which does not have this `onOutput` are
tasks with direct output... Those remain unhandled.. for now.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Updates the online tutorial experience
- Adds a landing page at
[/tutorials](https://nx-dev-git-docs-tutorial-landing-page-nrwl.vercel.app/tutorials)
- Terminal code blocks get a "run in terminal" button
- Code blocks get an "Apply file changes" button
- The apply file changes button currently only works for code blocks
that are showing the new file results (not showing the old file with
lines marked for deletion). There is nothing technical blocking this,
just time.
- Previous and next buttons do not go between tutorials
- The preview panel can be completely minimized
- Git is stubbed out
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Flag not on
## Expected Behavior
Flag on
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- [x] change init to create `createNodes` instead
- [x] unit tests
- [x] test-ci
- [x] test on windows
- [x] help metadata
- [x] external nodes
TODO:
- add publish executor?
- publish to maven central?
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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, it uses [project report
plugin](https://docs.gradle.org/current/userguide/project_report_plugin.html).
- pro: no need to maintain this plugin
- con: this plugin gives limited information
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
change the project report plugin to @nxn/gradle/plugin-v1
now the @nx/gradle plugin will use project graph plugin
(dev.nx.gradle.project-graph) created in this pr.
this plugin will create json file that is exactly what nx project grpah
expected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR ensures that when `@nx/js/typescript` is not used, we do not add
`@nx/js:typescript-sync` sync generator to targets such as build, serve,
etc.
It resolves issues where `nx init` into a repo that is compatible with
TS solution will add the sync generator, even if the plugin is unused.
It leads to errors everytime users run a task like build. The error is
like this:
```
[@nx/js:typescript-sync] The `@nx/js/typescript` plugin is not registered
...
> Would you like to ignore the sync failures and continue running the task?
Yes
No
```
It makes it confusing for users, especially new users that don't know
what sync generators are. They will always run into the error and have
to choose to continue despite the failure.
**Note:** In a future follow-up, we could consider adding better info
and prompts so we can let users know that Nx also helps keep workspace
up to date, and can learn more about it.
## Current Behavior
Users see an error when running `nx add @nx/vite` and then `nx build
<project>`.
## Expected Behavior
## 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 -->
Some tasks end but don't have their terminal outputs printed. When that
is the case, an error occurred where task terminal output was attempted
to be printed but did not exist.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Tracking terminal outputs is restored to being part of printing task
terminal output.. and printing task terminal output is guaranteed when
pseudo terminal is used.
## 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 -->
An error is occurring where it cannot find the terminal output for a
task. Turns out this is because it is trying to get terminal output
basically immediately after the task has started instead of after it has
exited.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Terminal output is retrieved after the task has exited. At this point,
terminal output is available.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `createConfig` helper from `@nx/angular-rspack` became an async
function.
This meant that the handling of custom webpack configs in the migration
done by `convert-to-rspack` was incorrect.
## Expected Behavior
Ensure the migration is handled correctly.
Ensure that Module Federation migrations work correctly.
## Related Issues
Fixes https://github.com/nrwl/angular-rspack/issues/53
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, the `convert-to-inferred` generator description inside the
rspack package references Webpack when it should reference Rspack
instead.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `convert-to-inferred` generator description should reference Rspack
instead of Webpack.
## 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 -->
Continuous tasks go until the process is done.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Continuous tasks are cleaned up after they're no longer needed. AKA once
their dependent tasks are done.
## 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. -->
See
https://github.com/nx-dotnet/nx-dotnet/blob/1ff848c54bc2207a9c77fc31c7a9a62489a30a88/packages/core/src/generators/init/generator.ts#L30-L41
## 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. -->
Co-authored-by: Miroslav Jonaš <missing.manual@gmail.com>
This PR creates a new enterprise blog post for test task-splitting
techniques
<img width="876" alt="image"
src="https://github.com/user-attachments/assets/1fe26716-e947-4c46-974c-d4d286e50d4e"
/>
## 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: Juri <juri.strumpflohner@gmail.com>
Co-authored-by: Isaac Mann <isaacplmann@gmail.com>
This PR fixes an issue if the user is not updated to an Nx version that
provides the new Migrate UI API, then it will load the run version and
error out.
<img width="2672" alt="Screenshot 2025-04-17 at 10 18 45 AM"
src="https://github.com/user-attachments/assets/2720922b-6ef5-4162-a3f1-d1ccedb60acd"
/>
The fix is to always use the local `migrate.js` module.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
Migrate UI is broken if the migrated version does not have the new API
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Migrate UI should always work
Fixes #
This PR marks dev/start from `@nx/react/router-plugin` as continuous.
Otherwise, running e2e will hang.
Repro:
- `npx create-nx-workspace@next org --preset=react-monorepo
--appName=demo --e2eTestRunner=playwright` and pick RR For SSR
- Run `nx e2e demo-e2e`
## Current Behavior
<!-- This is the behavior we have today -->
e2e hangs because dev does not finish, and it is not marked as
continuous
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
dev and start from RR should work with e2e
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR removes the `// nx-ignore-next-line` from graph client to the
migrate lib import. Without the dep being there, the tailwind styles
will not include classes used by migrate UI.
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Styles are broken for migrate UI
## Expected Behavior
Styles should work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Remove the deprecated functionalities scheduled to be removed in Nx v21.
BREAKING CHANGE: Remove the deprecated data persistence operators
previously exported in `@nx/angular` and the deprecated testing utils
previously exported in `@nx/angular/testing`.
This PR fixes an issue that blocks FreeBSD release for some reason.
When we use the `@nx/vite/plugins/nx-tsconfig-paths.plugin` plugin and
both `CI=1` and `NX_PREFER_TS_NODE=true` are set, then the graph fails
to compute. For example, running this will error out:
```shell
CI=1 NX_DAEMON=false NX_CACHE_PROJECT_GRAPH=false NX_PREFER_TS_NODE=true nx report
```
The error is like this:
```shell
⚠️ Unable to construct project graph.
Failed to process project graph.
- graph/migrate/.storybook/main.ts: TypeError: Cannot set property level of [object Object] which has only a getter
at Object.<anonymous> (/Users/jack/projects/nx/packages/nx/src/utils/output.ts:38:23)
at Module._compile (node:internal/modules/cjs/loader:1554:14)
at Module.m._compile (/Users/jack/projects/nx/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@types+node@20.16.10_typescript@5.7.3/node_modules/ts-node/src/index.ts:1618:23)
at node:internal/modules/cjs/loader:1706:10
at Object.require.extensions.<computed> [as .ts] (/Users/jack/projects/nx/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@types+node@20.16.10_typescript@5.7.3/node_modules/ts-node/src/index.ts:1621:12)
at Module.load (node:internal/modules/cjs/loader:1289:32)
at Function._load (node:internal/modules/cjs/loader:1108:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:220:24)
at Module.require (node:internal/modules/cjs/loader:1311:12)
- graph/ui-code-block/.storybook/main.ts: TypeError: Cannot set property level of [object Object] which has only a getter
at Object.<anonymous> (/Users/jack/projects/nx/packages/nx/src/utils/output.ts:38:23)
at Module._compile (node:internal/modules/cjs/loader:1554:14)
at Module.m._compile (/Users/jack/projects/nx/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@types+node@20.16.10_typescript@5.7.3/node_modules/ts-node/src/index.ts:1618:23)
at node:internal/modules/cjs/loader:1706:10
at Object.require.extensions.<computed> [as .ts] (/Users/jack/projects/nx/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@types+node@20.16.10_typescript@5.7.3/node_modules/ts-node/src/index.ts:1621:12)
at Module.load (node:internal/modules/cjs/loader:1289:32)
at Function._load (node:internal/modules/cjs/loader:1108:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:220:24)
at Module.require (node:internal/modules/cjs/loader:1311:12)
- graph/ui-project-details/.storybook/main.ts: TypeError: Cannot set property level of [object Object] which has only a getter
at Object.<anonymous> (/Users/jack/projects/nx/packages/nx/src/utils/output.ts:38:23)
at Module._compile (node:internal/modules/cjs/loader:1554:14)
at Module.m._compile (/Users/jack/projects/nx/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@types+node@20.16.10_typescript@5.7.3/node_modules/ts-node/src/index.ts:1618:23)
at node:internal/modules/cjs/loader:1706:10
at Object.require.extensions.<computed> [as .ts] (/Users/jack/projects/nx/node_modules/.pnpm/ts-node@10.9.1_@swc+core@1.5.7_@swc+helpers@0.5.11__@types+node@20.16.10_typescript@5.7.3/node_modules/ts-node/src/index.ts:1621:12)
at Module.load (node:internal/modules/cjs/loader:1289:32)
at Function._load (node:internal/modules/cjs/loader:1108:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:220:24)
at Module.require (node:internal/modules/cjs/loader:1311:12)
```
This is an issue for us only because we are pointing
`@nx/vite/plugins/nx-tsconfig-paths.plugin` to source. Normally, this
would already be in JS, and not need to go through `ts-node` or SWC.
I'm unsure what the exact cause is. There was nothing obvious in how we
register `ts-node`, and nothing in `ts-node` to suggest different
behavior with `CI=1`.
## Current Behavior
FreeBSD release is blocked
See: https://github.com/nrwl/nx/actions/runs/14500499978/job/40678818950
## Expected Behavior
FreeBSD release works
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `nx-dev:lint` task is processing the `public` directory. That
directory is meant to contain assets that ESLint shouldn't process. It
results in extra time being spent linting the project, and it could
result in some errors due to linting some generated output that's copied
there (e.g. `documentation` and `tutorials` directories).
## Expected Behavior
The `nx-dev:lint` task should not process the `public` directory.
## Related Issue(s)
Fixes #
## Current Behavior
There is no Getting Started document for helping people to get up and
running quickly with Angular Rspack applications.
There is only a blog post about scaffolding the applications.
## Expected Behavior
Add a Getting Started document to help people get up and running
## Current Behavior
A target default (`dependsOn: [^build]`) for atomized e2e tasks is
always generated to work around a previous limitation where tasks
couldn't depend on continuous tasks. That meant we couldn't add the
dependency to the app's serve task and had to add it to the build task.
With continuous tasks now working, that limitation no longer exists.
We're now able to correctly infer the task dependency on the app's serve
task, and therefore, we can and need to remove the generation of
`dependsOn: [^build]` in target defaults so it doesn't override what the
Cypress and Playwright plugins infers.
## Expected Behavior
A target default (`dependsOn: [^build]`) for atomized e2e tasks should
not be generated. Instead, the Cypress and Playwright plugins will infer
the correct `dependsOn` for the task(s) run in the configured web server
command.
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When `CI=true`, the TUI is still enabled by default.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When `CI=true`, the TUI is disabled unless it is explicitly enabled with
`NX_TUI=true`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates our nightly test configuration to align with the current
Node.js ecosystem.
Node.js v18 has reached end-of-life, so we're updating our nightly tests
to ensure compatibility with actively maintained Node.js versions.
This PR updates `lerna-smoke-tests.test.ts` test file to improve the
consistency of the snapshots.
The serializer has been updated to reduce flakiness from spacing and
line breaks.
## Current Behavior
There is currently no documetation on how to configure i18n for Angular
Rspack applications
## Expected Behavior
Add documetation giving details on how to configure i18n for Angular
Rspack applications
This PR introduces a new UI in Nx Console designed to assist users with
managing migrations more effectively.
Each migration is now presented with its status and actions, allowing
users to interact directly.
If any issues arise, users can address them in isolation without
disrupting the overall flow. The migrate ui provides a clear overview of
the migration state, helping users track progress and understand what
actions are required at each step.
## Current Behavior
The `convert-to-rspack` generator for `@nx/angular` does not currently
handle SSR Webpack applications correctly.
## Expected Behavior
Ensure that the `convert-to-rspack` generator handles SSR correctly.
## Current Behavior
The `sassImplementation` option for Webpack and Rspack is set to `sass`
by default.
`sass-embedded` offers a faster alternative.
## Expected Behavior
Switch the default `sassImplementation` option to `sass-embedded`.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 20.8.0-rc.0
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 21.0.0-beta.4
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
… again ourselves
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This article has parts of a youtube video baked into it as mp4 files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The article points to the youtube video instead of baking in mp4 files.
https://nx-dev-git-fix-docs-nrwl.vercel.app/blog/nx-made-cursor-smarter#lets-see-it-in-action
## 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 -->
The `registerForcedShutdownCallback` lifecycle hook does not exist if
the TUI is not enabled as it is not on CI. But Nx tries to invoke it
anyways so it causes an error in CI:
https://github.com/nrwl/nx/actions/runs/14471341199/job/40585817051?pr=30710#step:11:31
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `registerForcedShutdownCallback` is only utilized when the TUI is
enabled so it will not be invoked on CI where it does not exist.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The "Typescript Project Linking" concept page shows package manager
workspaces' patterns like `apps/**`. While this could be correct, it's
not what Nx generators will generate, and it can result in some nested
and non-expected directories being matched (e.g., fixtures).
## Expected Behavior
The "Typescript Project Linking" concept page should show package
manager workspaces' patterns like `apps/*` so it's aligned with what Nx
generators will generate. It would be a safer example, so it doesn't
match potentially undesired directories.
## Related Issue(s)
Fixes #
Currently, we provide `targetDefaults` for atomized targets (e.g.
`e2e-ci`) with a glob pattern that may not match nested paths.
i.e.
```
"e2e-ci--**/*": {
"dependsOn": [
"^build",
],
},
```
The `e2e-ci--**/*` pattern should be `e2e-ci--**/**`.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 generated `e2e-ci` pattern in `nx.json` does not match nested paths
for split tasks.
## Expected Behavior
The generated `e2e-ci` pattern should apply to all split tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28842
## Current Behavior
The `standaloneConfig` option has long been deprecated as it is the only
behaviour that Nx now provides.
Using it is a no-op.
## Expected Behavior
Remove the `standaloneConfig` option.
## Current Behavior
A couple of unit tests for the `@nx/cypress` graph plugin are failing
due to outdated snapshots.
## Expected Behavior
The `@nx/cypress` graph plugin tests should succeed. The test snapshots
should be updated to match the new behavior.
## Related Issue(s)
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 -->
"Printing" the command info before output causes `run-script` to hang
and not run. In addition, the screen was cleared.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The command in run-script runs without issues. The screen is not
cleared.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Cypress and Playwright graph plugins do not infer tasks configured
to take advantage of continuous tasks (do not add the task they run to
start the app/server as a dependency of the e2e task).
## Expected Behavior
The Cypress and Playwright graph plugins should infer tasks configured
to take advantage of continuous tasks.
## Related Issue(s)
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 -->
`git push -u origin HEAD` causes the following panic when the TUI is
enabled on macos:
```
Backtrace (most recent call last):
File "<unknown>:0", in __pthread_cond_wait
File "<unknown>:0", in std::sys::pal::unix::thread::Thread::new::thread_start
File "<unknown>:0", in core::ops::function::FnOnce::call_once{{vtable.shim}}
File "<unknown>:0", in std::sys::backtrace::__rust_begin_short_backtrace
File "<unknown>:0", in tokio::runtime::task::raw::poll
File "<unknown>:0", in tokio::runtime::scheduler::multi_thread::worker::Context::run_task
File "<unknown>:0", in tokio::runtime::task::raw::poll
File "<unknown>:0", in tokio::runtime::task::core::Core<T,S>::poll
File "<unknown>:0", in nx::native::tui::tui::Tui::start::{{closure}}
File "<unknown>:0", in core::option::expect_failed
The application panicked (crashed).
reader source not set
in /Users/jason/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/crossterm-0.29.0/src/event/read.rs:39
thread: tokio-runtime-worker
```
This is due to the fact that crossterm until recently did not use
/dev/tty on mac and thus could not read events correctly when forwarded
from another program such as husky.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This adds the `use-dev-tty` features so that `crossterm` utilizes
`/dev/tty` and works when forwarded from other programs such as husky on
macos.
## 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 -->
Wasm build is broken.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Wasm build is fixed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- When a user presses `ctrl+c` to force kill the TUI/Nx, continuous
tasks that are running are not killed, and the terminal can get stuck or
leave the cursor hidden
- The summary is incomplete and messy
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- When a user presses `ctrl+c` to force kill the TUI/Nx, continuous
tasks that are running are appropriately killed and everything in the
user's terminal is restored back to a good state.
- The summary looks good and contains the in progress logs for
continuous tasks that were killed
## 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 -->
Shared continuous tasks are not shown as running in the TUI
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a special status for Shared continuous tasks for the TUI where
it will say that it is running in a different nx process
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When generating `node` projects with an `e2e` project using Jest, we do
not supply any method for the node application to actually be started
before running the tests.
## Expected Behavior
Using Continuous Tasks, have the e2e project dependOn the serve of the
`node` project such that it is available for the e2e tests to run
against it.
## Current Behavior
When a continuous task is already running, parent tasks are not
scheduled.
## Expected Behavior
When a continuous task is already running, the task orchestrator should
schedule the next tasks and release the waiting threads so parent tasks
can be scheduled.
## Related Issue(s)
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 -->
Continuous tasks are not supported in DTE and there is no good API for
Agents to utilize
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is an API for agents to utilize to run continuous tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Module Federation Documentation talks about using `--devRemotes`
exclusively for serving remote applications that feature teams are
working on.
With Continuous Tasks this is no longer the case
## Expected Behavior
Add section mentioning Continuous Tasks and the change to the `serve`
flow
## Current Behavior
Continuous tasks are not set up for React Rspack Module Federation
Remote projects.
This is important because `--dev-remotes` is no longer supported with
Crystal Module Federation usage.
## Expected Behavior
Add Continuous Tasks support for React Rspack Module Federation Remote
Projects.
This replaces the need for `nx serve shell --dev-remotes=remote1`.
Instead, the command is simply `nx serve remote1` and continuous tasks
means that the `shell:serve` task is executed correctly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
<!-- This is the behavior we have today -->
<!-- This is the behavior we should expect with the changes in this PR
-->
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 -->
Unit tests are broken after rebase
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Unit tests are passing
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Node applications rely on the `@nx/js:node` executor to handle serving.
Unfortunately, it can not be determined if existing usage of the
executor is used for a continuous or finite task.
## Expected Behavior
Generate new node applications with `continuous: true` for their serve
targets
## Current Behavior
The `@nx/storybook/plugin` does not set `continuous:true` for serve-like
targets.
## Expected Behavior
The plugin should correctly set `continuous: true` for `serve` and
`serve-static`.
## Current Behavior
The `dev`, `serve`, `preview` and `serve-static` targets inferred by the
`@nx/vite/plugin` do not infer `continuous:true` indicating to Nx that
these tasks are continuous.
## Expected Behavior
Infer `continuous: true` for the serve-like targets for Vite.
## Current Behavior
Rspack and Rsbuild Inference Plugins do not infer `continuous` for serve
tasks.
## Expected Behavior
Correctly infer `continuous` true.
## Current Behavior
The `@nx/js` plugin exposes a helper to generate `build-deps` and
`watch-deps` tasks for inference plugins.
It does not currently infer `continuous` for the `watch-deps` task.
## Expected Behavior
Ensure `watch-deps` is infered with `continuous: true`
## Current Behavior
When `serve, dev, start` targets are inferred by the `@nx/remix` plugin,
they are not inferring `continuous`.
## Expected Behavior
When `NX_CONTINUOUS_TASKS_PREVIEW` env var exists, infer the
`continuous` property.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
An RFC about this feature is happening here: #29025. This has the most
information about this feature.
<!-- This is the behavior we have today -->
Nx currently does not explicitly handle tasks which run continuously
until they are terminated.
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR adds the initial support for continuous tasks which run
continuously until they are terminated. This adds the ability to depend
on continuous tasks. There is some more work to be done but this will be
enough as an MVP.
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `flat/typescript` config contains a config block with the `files`
containing an invalid empty entry.
## Expected Behavior
The `flat/typescript` config should be correct.
## Related Issue(s)
Fixes#30725
<!--
_[Please make sure you have read the submission guidelines before
posting an
PR](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## Nx Plugin for AWS (@aws/nx-plugin)
<!--
Describe what your plugin is and what is its goal or issues it
addresses. If you don't provide a description, we will not merge your
PR.
Is it focused on a technology, tooling or behaviour? Does the plugin
provide generators, executors or graph support?
Do you know who is already using the plugin? Mention who is the author
of the plugin.
-->
This plugin is for building cloud-native applications with AWS. At
present it provides the following generators:
- `ts#project` - Generate a new TypeScript library.
- `ts#infra` - Generate a Typescript AWS CDK infrastructure project for
your application.
- `ts#cloudscape-website` - Generate a new Cloudscape/React/Vite based
web application.
- `ts#cloudscape-website#auth` - Add AWS Cognito authentication to your
Cloudscape website.
- `ts#trpc-api` - Generate a tRPC backend service with Amazon API
Gateway/AWS Lambda integration and [AWS
Powertools](https://github.com/aws-powertools/powertools-lambda-typescript)
pre-configured.
- `py#project` - Generate a uv based Python project.
- `py#fast-api` - Generate a FastAPI backend service with [AWS
Powertools](https://github.com/aws-powertools/powertools-lambda-python)
pre-configured.
- `api-connection` - Connect frontend applications to backend APIs.
- `license` - Automatically manage LICENSE files and source code headers
in your workspace.
(Note that the ts/py project generators are our simplified/opinionated
generators for base projects in TypeScript and Python, eg enforcing ESM
for TypeScript etc)
Our prototyping organisation here at AWS uses the plugin to quickly
bootstrap and build prototypes for various AWS customers in different
industries.
The primary authors are Adrian Dimech @agdimech and myself (Jack
Stevenson).
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.
description: Polls Nx Cloud CI pipeline and self-healing status. Returns structured state when actionable. Spawned by /nx-cloud-ci-monitor command to monitor CI Attempt status.
model: fast
---
# CI Watcher Subagent
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
## Your Responsibilities
1. Poll CI status using the `ci_information` MCP tool
2. Implement exponential backoff between polls
3. Return structured state when an actionable condition is reached
4. Track iteration count and elapsed time
5. Output status updates based on verbosity level
## Input Parameters (from Main Agent)
The main agent may provide these optional parameters in the prompt:
# Large content fields - fetch only when returning to main agent
```
## Initial Wait
Before first poll, wait based on context:
- **Fresh start (no expected CIPE):** Wait 60 seconds to allow CI to start
- **Expecting new CIPE:** Wait 30 seconds (action already triggered)
**IMPORTANT:** Always run sleep in foreground, NOT as background command.
```bash
sleep 60# or 30 if expecting new CIPE (FOREGROUND, not background)
```
## Two-Phase Operation
The subagent operates in one of two modes depending on input:
### Mode 1: Fresh Start (no `expectedCommitSha` or `previousCipeUrl`)
Normal polling - process whatever CIPE is returned by `ci_information`.
### Mode 2: Wait-for-New-CIPE (when `expectedCommitSha` or `previousCipeUrl` provided)
**CRITICAL**: When expecting a new CIPE, the subagent must **completely ignore** the old/stale CIPE. Do NOT process its status, do NOT return actionable states based on it.
#### Phase A: Wait Mode
1. Start a **new-CIPE timeout** timer (default: 30 minutes)
2. On each poll of `ci_information`:
- Check if CIPE is NEW:
-`cipeUrl` differs from `previousCipeUrl` → **new CIPE detected**
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
[CI Monitor] Polling... (elapsed: 1m 30s)
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
[CI Monitor] Polling... (elapsed: 2m 30s)
[CI Monitor] ✓ New CI Attempt detected! URL: <newCipeUrl>, SHA: <newCommitSha>
[CI Monitor] Switching to normal polling mode...
```
### Why This Matters (Context Preservation)
**The problem**: Stale CIPE data can be very large:
-`taskOutputSummary`: potentially thousands of characters of build/test output
-`suggestedFix`: entire patch files
-`suggestedFixReasoning`: detailed explanation
If subagent returns stale CIPE data to main agent, it **pollutes main agent's context** with useless information (we already processed that CIPE). This wastes valuable context window.
**Without wait mode:**
1. Poll `ci_information` → get old CIPE with huge data
2. Return to main agent with all that stale data
3. Main agent's context gets polluted with useless info
4. Main agent has to process/ignore it anyway
**With wait mode:**
1. Poll `ci_information` → get old CIPE → **ignore it, don't return**
2. Keep waiting internally (stale data stays in subagent)
3. New CIPE appears → switch to normal mode
4. Return to main agent with only the NEW, relevant CIPE data
## Polling Loop
### Subagent State Management
Maintain internal accumulated state across polls:
```
accumulated_state = {}
```
### Call `ci_information` MCP Tool
**Wait Mode (expecting new CI Attempt):**
```
ci_information({
branch: "<branch_name>",
select: "cipeUrl,commitSha,cipeStatus"
})
```
Only fetch minimal fields needed to detect CI Attempt change. Do NOT fetch heavy fields - stale data wastes context.
Merge response into `accumulated_state`, then return merged state to main agent.
**Pagination:** Heavy string fields return first page only. If `hasMore` indicated, include in return format so main agent knows more content available.
### Return to Main Agent When
Return immediately with structured state if ANY of these conditions are true:
| `fix_auto_applying` | `selfHealingStatus == 'COMPLETED'` AND `couldAutoApplyTasks == true` AND `verificationStatus == 'COMPLETED'` |
| `fix_available` | `selfHealingStatus == 'COMPLETED'` AND `suggestedFix != null` AND (`couldAutoApplyTasks != true` OR `verificationStatus` in (`FAILED`, `NOT_EXECUTABLE`)) |
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
---
# CI Monitor Command
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from `$ARGUMENTS` and merge with defaults.
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
---
# Run Nx Generator
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
This skill applies when the user wants to:
- Create new projects like libraries or applications
- Scaffold features or boilerplate code
- Run workspace-specific or custom generators
- Do anything else that an nx generator exists for
## Generator Discovery Flow
### Step 1: List Available Generators
Use the Nx CLI to discover available generators:
- List all generators for a plugin: `npx nx list @nx/react`
- Local workspace generators (defined in the repo's own plugins)
### Step 2: Match Generator to User Request
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
- What artifact type they want to create (library, application, etc.)
- Which framework or technology stack is relevant
- Whether they mentioned specific generator names
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
## Pre-Execution Checklist
Before running any generator, complete these steps:
### 1. Fetch Generator Schema
Use the `--help` flag to understand all available options:
```bash
npx nx g @nx/react:library --help
```
Pay attention to:
- Required options that must be provided
- Optional options that may be relevant to the user's request
- Default values that might need to be overridden
### 2. Read Generator Source Code
Understanding what the generator actually does helps you:
- Know what files will be created/modified
- Understand any side effects (updating configs, installing deps, etc.)
- Identify options that might not be obvious from the schema
To find generator source code:
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
- If that fails, read directly from `node_modules/<plugin>/generators.json`
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
### 2.5 Reevaluate if the generator is right
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
### 3. Understand Repo Context
Before generating, examine the target area of the codebase:
- Look at similar existing artifacts (other libraries, applications, etc.)
- Identify patterns and conventions used in the repo
- Note naming conventions, file structures, and configuration patterns
- Try to match these patterns when configuring the generator
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
If projects or other artifacts are organized with a specific naming convention, try to match it.
### 4. Validate Required Options
Ensure all required options have values:
- Map the user's request to generator options
- Infer values from context where possible
- Ask the user for any critical missing information
## Execution
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
### Consider Dry-Run (Optional)
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
- For complex generators or unfamiliar territory: do a dry-run first
- For simple, well-understood generators: may proceed directly
- Dry-run shows file names and created/deleted/modified markers, but not content
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
---
You can run tasks with Nx in the following way.
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
## Understand which tasks can be run
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
## Run a single task
```
nx run <project>:<task>
```
where `project` is the project name defined in `package.json` or `project.json` (if present).
## Run multiple tasks
```
nx run-many -t build test lint typecheck
```
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
Examples:
-`nx run-many -t test -p proj1 proj2` — test specific projects
-`nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
-`nx run-many -t test --projects=tag:api-*` — test projects by tag
## Run tasks for affected projects
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
```
nx affected -t build test lint
```
By default it compares against the base branch. You can customize this:
-`nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
-`nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
## Useful flags
These flags work with `run`, `run-many`, and `affected`:
-`--skipNxCache` — rerun tasks even when results are cached
-`--verbose` — print additional information such as stack traces
-`--nxBail` — stop execution after the first failed task
-`--configuration=<name>` — use a specific configuration (e.g. `production`)
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
---
# Nx Workspace Exploration
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
## Listing Projects
Use `nx show projects` to list projects in the workspace.
```bash
# List all projects
nx show projects
# Filter by pattern (glob)
nx show projects --projects "apps/*"
nx show projects --projects "shared-*"
# Filter by project type
nx show projects --type app
nx show projects --type lib
nx show projects --type e2e
# Filter by target (projects that have a specific target)
nx show projects --withTarget build
nx show projects --withTarget e2e
# Find affected projects (changed since base branch)
nx show projects --affected
nx show projects --affected --base=main
nx show projects --affected --type app
# Combine filters
nx show projects --type lib --withTarget test
nx show projects --affected --exclude="*-e2e"
# Output as JSON
nx show projects --json
```
## Project Configuration
Use `nx show project <name> --json` to get the full resolved configuration for a project.
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
```bash
# Get full project configuration
nx show project my-app --json
# Extract specific parts from the JSON
nx show project my-app --json | jq '.targets'
nx show project my-app --json | jq '.targets.build'
nx show project my-app --json | jq '.targets | keys'
description="Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting."
prompt="""
# CI Monitor Command
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `ci_success` | Exit with success. Log "CIpassedsuccessfully!" |
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix:resolve<failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix:resolve<failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
---
# CI Monitor Command
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from `$ARGUMENTS` and merge with defaults.
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
---
# Run Nx Generator
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
This skill applies when the user wants to:
- Create new projects like libraries or applications
- Scaffold features or boilerplate code
- Run workspace-specific or custom generators
- Do anything else that an nx generator exists for
## Generator Discovery Flow
### Step 1: List Available Generators
Use the Nx CLI to discover available generators:
- List all generators for a plugin: `npx nx list @nx/react`
- Local workspace generators (defined in the repo's own plugins)
### Step 2: Match Generator to User Request
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
- What artifact type they want to create (library, application, etc.)
- Which framework or technology stack is relevant
- Whether they mentioned specific generator names
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
## Pre-Execution Checklist
Before running any generator, complete these steps:
### 1. Fetch Generator Schema
Use the `--help` flag to understand all available options:
```bash
npx nx g @nx/react:library --help
```
Pay attention to:
- Required options that must be provided
- Optional options that may be relevant to the user's request
- Default values that might need to be overridden
### 2. Read Generator Source Code
Understanding what the generator actually does helps you:
- Know what files will be created/modified
- Understand any side effects (updating configs, installing deps, etc.)
- Identify options that might not be obvious from the schema
To find generator source code:
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
- If that fails, read directly from `node_modules/<plugin>/generators.json`
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
### 2.5 Reevaluate if the generator is right
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
### 3. Understand Repo Context
Before generating, examine the target area of the codebase:
- Look at similar existing artifacts (other libraries, applications, etc.)
- Identify patterns and conventions used in the repo
- Note naming conventions, file structures, and configuration patterns
- Try to match these patterns when configuring the generator
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
If projects or other artifacts are organized with a specific naming convention, try to match it.
### 4. Validate Required Options
Ensure all required options have values:
- Map the user's request to generator options
- Infer values from context where possible
- Ask the user for any critical missing information
## Execution
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
### Consider Dry-Run (Optional)
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
- For complex generators or unfamiliar territory: do a dry-run first
- For simple, well-understood generators: may proceed directly
- Dry-run shows file names and created/deleted/modified markers, but not content
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
---
You can run tasks with Nx in the following way.
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
## Understand which tasks can be run
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
## Run a single task
```
nx run <project>:<task>
```
where `project` is the project name defined in `package.json` or `project.json` (if present).
## Run multiple tasks
```
nx run-many -t build test lint typecheck
```
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
Examples:
-`nx run-many -t test -p proj1 proj2` — test specific projects
-`nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
-`nx run-many -t test --projects=tag:api-*` — test projects by tag
## Run tasks for affected projects
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
```
nx affected -t build test lint
```
By default it compares against the base branch. You can customize this:
-`nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
-`nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
## Useful flags
These flags work with `run`, `run-many`, and `affected`:
-`--skipNxCache` — rerun tasks even when results are cached
-`--verbose` — print additional information such as stack traces
-`--nxBail` — stop execution after the first failed task
-`--configuration=<name>` — use a specific configuration (e.g. `production`)
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
---
# Nx Workspace Exploration
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
## Listing Projects
Use `nx show projects` to list projects in the workspace.
```bash
# List all projects
nx show projects
# Filter by pattern (glob)
nx show projects --projects "apps/*"
nx show projects --projects "shared-*"
# Filter by project type
nx show projects --type app
nx show projects --type lib
nx show projects --type e2e
# Filter by target (projects that have a specific target)
nx show projects --withTarget build
nx show projects --withTarget e2e
# Find affected projects (changed since base branch)
nx show projects --affected
nx show projects --affected --base=main
nx show projects --affected --type app
# Combine filters
nx show projects --type lib --withTarget test
nx show projects --affected --exclude="*-e2e"
# Output as JSON
nx show projects --json
```
## Project Configuration
Use `nx show project <name> --json` to get the full resolved configuration for a project.
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
```bash
# Get full project configuration
nx show project my-app --json
# Extract specific parts from the JSON
nx show project my-app --json | jq '.targets'
nx show project my-app --json | jq '.targets.build'
nx show project my-app --json | jq '.targets | keys'
@@ -28,12 +28,12 @@ Note: We reserve the right to remove unmaintained plugins from the registry. If
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
- Update the `astro-docs/src/content/approved-community-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/plugin-registry)
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/docs/plugin-registry)
description: Polls Nx Cloud CI pipeline and self-healing status. Returns structured state when actionable. Spawned by /nx-cloud-ci-monitor command to monitor CI Attempt status.
---
# CI Watcher Subagent
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
## Your Responsibilities
1. Poll CI status using the `ci_information` MCP tool
2. Implement exponential backoff between polls
3. Return structured state when an actionable condition is reached
4. Track iteration count and elapsed time
5. Output status updates based on verbosity level
## Input Parameters (from Main Agent)
The main agent may provide these optional parameters in the prompt:
# Large content fields - fetch only when returning to main agent
```
## Initial Wait
Before first poll, wait based on context:
- **Fresh start (no expected CIPE):** Wait 60 seconds to allow CI to start
- **Expecting new CIPE:** Wait 30 seconds (action already triggered)
**IMPORTANT:** Always run sleep in foreground, NOT as background command.
```bash
sleep 60# or 30 if expecting new CIPE (FOREGROUND, not background)
```
## Two-Phase Operation
The subagent operates in one of two modes depending on input:
### Mode 1: Fresh Start (no `expectedCommitSha` or `previousCipeUrl`)
Normal polling - process whatever CIPE is returned by `ci_information`.
### Mode 2: Wait-for-New-CIPE (when `expectedCommitSha` or `previousCipeUrl` provided)
**CRITICAL**: When expecting a new CIPE, the subagent must **completely ignore** the old/stale CIPE. Do NOT process its status, do NOT return actionable states based on it.
#### Phase A: Wait Mode
1. Start a **new-CIPE timeout** timer (default: 30 minutes)
2. On each poll of `ci_information`:
- Check if CIPE is NEW:
-`cipeUrl` differs from `previousCipeUrl` → **new CIPE detected**
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
[CI Monitor] Polling... (elapsed: 1m 30s)
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
[CI Monitor] Polling... (elapsed: 2m 30s)
[CI Monitor] ✓ New CI Attempt detected! URL: <newCipeUrl>, SHA: <newCommitSha>
[CI Monitor] Switching to normal polling mode...
```
### Why This Matters (Context Preservation)
**The problem**: Stale CIPE data can be very large:
-`taskOutputSummary`: potentially thousands of characters of build/test output
-`suggestedFix`: entire patch files
-`suggestedFixReasoning`: detailed explanation
If subagent returns stale CIPE data to main agent, it **pollutes main agent's context** with useless information (we already processed that CIPE). This wastes valuable context window.
**Without wait mode:**
1. Poll `ci_information` → get old CIPE with huge data
2. Return to main agent with all that stale data
3. Main agent's context gets polluted with useless info
4. Main agent has to process/ignore it anyway
**With wait mode:**
1. Poll `ci_information` → get old CIPE → **ignore it, don't return**
2. Keep waiting internally (stale data stays in subagent)
3. New CIPE appears → switch to normal mode
4. Return to main agent with only the NEW, relevant CIPE data
## Polling Loop
### Subagent State Management
Maintain internal accumulated state across polls:
```
accumulated_state = {}
```
### Call `ci_information` MCP Tool
**Wait Mode (expecting new CI Attempt):**
```
ci_information({
branch: "<branch_name>",
select: "cipeUrl,commitSha,cipeStatus"
})
```
Only fetch minimal fields needed to detect CI Attempt change. Do NOT fetch heavy fields - stale data wastes context.
Merge response into `accumulated_state`, then return merged state to main agent.
**Pagination:** Heavy string fields return first page only. If `hasMore` indicated, include in return format so main agent knows more content available.
### Return to Main Agent When
Return immediately with structured state if ANY of these conditions are true:
| `fix_auto_applying` | `selfHealingStatus == 'COMPLETED'` AND `couldAutoApplyTasks == true` AND `verificationStatus == 'COMPLETED'` |
| `fix_available` | `selfHealingStatus == 'COMPLETED'` AND `suggestedFix != null` AND (`couldAutoApplyTasks != true` OR `verificationStatus` in (`FAILED`, `NOT_EXECUTABLE`)) |
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from `${input:args}` and merge with defaults.
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
---
# CI Monitor Command
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from `$ARGUMENTS` and merge with defaults.
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
---
# Run Nx Generator
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
This skill applies when the user wants to:
- Create new projects like libraries or applications
- Scaffold features or boilerplate code
- Run workspace-specific or custom generators
- Do anything else that an nx generator exists for
## Generator Discovery Flow
### Step 1: List Available Generators
Use the Nx CLI to discover available generators:
- List all generators for a plugin: `npx nx list @nx/react`
- Local workspace generators (defined in the repo's own plugins)
### Step 2: Match Generator to User Request
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
- What artifact type they want to create (library, application, etc.)
- Which framework or technology stack is relevant
- Whether they mentioned specific generator names
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
## Pre-Execution Checklist
Before running any generator, complete these steps:
### 1. Fetch Generator Schema
Use the `--help` flag to understand all available options:
```bash
npx nx g @nx/react:library --help
```
Pay attention to:
- Required options that must be provided
- Optional options that may be relevant to the user's request
- Default values that might need to be overridden
### 2. Read Generator Source Code
Understanding what the generator actually does helps you:
- Know what files will be created/modified
- Understand any side effects (updating configs, installing deps, etc.)
- Identify options that might not be obvious from the schema
To find generator source code:
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
- If that fails, read directly from `node_modules/<plugin>/generators.json`
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
### 2.5 Reevaluate if the generator is right
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
### 3. Understand Repo Context
Before generating, examine the target area of the codebase:
- Look at similar existing artifacts (other libraries, applications, etc.)
- Identify patterns and conventions used in the repo
- Note naming conventions, file structures, and configuration patterns
- Try to match these patterns when configuring the generator
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
If projects or other artifacts are organized with a specific naming convention, try to match it.
### 4. Validate Required Options
Ensure all required options have values:
- Map the user's request to generator options
- Infer values from context where possible
- Ask the user for any critical missing information
## Execution
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
### Consider Dry-Run (Optional)
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
- For complex generators or unfamiliar territory: do a dry-run first
- For simple, well-understood generators: may proceed directly
- Dry-run shows file names and created/deleted/modified markers, but not content
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
---
You can run tasks with Nx in the following way.
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
## Understand which tasks can be run
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
## Run a single task
```
nx run <project>:<task>
```
where `project` is the project name defined in `package.json` or `project.json` (if present).
## Run multiple tasks
```
nx run-many -t build test lint typecheck
```
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
Examples:
-`nx run-many -t test -p proj1 proj2` — test specific projects
-`nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
-`nx run-many -t test --projects=tag:api-*` — test projects by tag
## Run tasks for affected projects
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
```
nx affected -t build test lint
```
By default it compares against the base branch. You can customize this:
-`nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
-`nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
## Useful flags
These flags work with `run`, `run-many`, and `affected`:
-`--skipNxCache` — rerun tasks even when results are cached
-`--verbose` — print additional information such as stack traces
-`--nxBail` — stop execution after the first failed task
-`--configuration=<name>` — use a specific configuration (e.g. `production`)
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
---
# Nx Workspace Exploration
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
## Listing Projects
Use `nx show projects` to list projects in the workspace.
```bash
# List all projects
nx show projects
# Filter by pattern (glob)
nx show projects --projects "apps/*"
nx show projects --projects "shared-*"
# Filter by project type
nx show projects --type app
nx show projects --type lib
nx show projects --type e2e
# Filter by target (projects that have a specific target)
nx show projects --withTarget build
nx show projects --withTarget e2e
# Find affected projects (changed since base branch)
nx show projects --affected
nx show projects --affected --base=main
nx show projects --affected --type app
# Combine filters
nx show projects --type lib --withTarget test
nx show projects --affected --exclude="*-e2e"
# Output as JSON
nx show projects --json
```
## Project Configuration
Use `nx show project <name> --json` to get the full resolved configuration for a project.
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
```bash
# Get full project configuration
nx show project my-app --json
# Extract specific parts from the JSON
nx show project my-app --json | jq '.targets'
nx show project my-app --json | jq '.targets.build'
nx show project my-app --json | jq '.targets | keys'
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
strategy:
fail-fast:false
matrix:
include:
- language:actions
build-mode:none
# We would like to test our Java / Kotlin... but its currently failing. We can follow up.
# - language: java-kotlin
# build-mode: autobuild
- language:javascript-typescript
build-mode:none
- language:rust
build-mode:none
- language:csharp
build-mode:autobuild
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
shell:bash
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
strategy:
fail-fast:false
matrix:
include:
- language:actions
build-mode:none
# See comment in @./codeql-master.yml about Java / Kotlin
# - language: java-kotlin
# build-mode: autobuild
- language:javascript-typescript
build-mode:none
- language:rust
build-mode:none
- language:csharp
build-mode:autobuild
# CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
shell:bash
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
uses:dawidd6/action-download-artifact@v2# Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
uses:dawidd6/action-download-artifact@268677152d06ba59fcec7a7f0b5d961b6ccd7e1e # v2# Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
// TODO (Jack): Fix Windows support as gradle fails when running nx build https://staging.nx.app/runs/LgD4vxGn8w?utm_source=pull-request&utm_medium=comment
# Check out the PR branch to get its copy of nx-release.ts
repository:${{ steps.script.outputs.repo }}
ref:${{ steps.script.outputs.ref }}
path:pr-branch-checkout
- name:(PR Release Only) Ensure that nx-release.ts has not changed in the PR being released
- name:(PR Release Only) Ensure that release scripts have not changed in the PR being released
if:${{ steps.script.outputs.ref != '' }}
env:
FILE_TO_COMPARE:"scripts/nx-release.ts"
run:|
if ! cmp -s "latest-master-checkout/${{ env.FILE_TO_COMPARE }}" "pr-branch-checkout/${{ env.FILE_TO_COMPARE }}"; then
echo "🛑 Error: The file ${{ env.FILE_TO_COMPARE }} is different on the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} vs latest master on nrwl/nx, cancelling workflow. If you did not modify the file, then you likely just need to rebase/merge latest master."
exit 1
else
echo "✅ The file ${{ env.FILE_TO_COMPARE }} is identical between the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} and latest master on nrwl/nx."
fi
# List of files that must not change in PR releases
FILES_TO_CHECK=(
"scripts/nx-release.ts"
"scripts/publish-resolve-data.js"
)
for FILE in "${FILES_TO_CHECK[@]}"; do
if ! cmp -s "latest-master-checkout/$FILE" "pr-branch-checkout/$FILE"; then
echo "🛑 Error: The file $FILE is different on the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} vs latest master on nrwl/nx, cancelling workflow."
echo "If you did not modify the file, then you likely just need to rebase/merge latest master."
exit 1
else
echo "✅ The file $FILE is identical between the ${{ steps.script.outputs.ref }} branch on ${{ steps.script.outputs.repo }} and latest master on nrwl/nx."
description: Polls Nx Cloud CI pipeline and self-healing status. Returns structured state when actionable. Spawned by /nx-cloud-ci-monitor command to monitor CI Attempt status.
mode: subagent
---
# CI Watcher Subagent
You are a CI monitoring subagent responsible for polling Nx Cloud CI Attempt status and self-healing state. You report status back to the main agent - you do NOT make apply/reject decisions.
## Your Responsibilities
1. Poll CI status using the `ci_information` MCP tool
2. Implement exponential backoff between polls
3. Return structured state when an actionable condition is reached
4. Track iteration count and elapsed time
5. Output status updates based on verbosity level
## Input Parameters (from Main Agent)
The main agent may provide these optional parameters in the prompt:
# Large content fields - fetch only when returning to main agent
```
## Initial Wait
Before first poll, wait based on context:
- **Fresh start (no expected CIPE):** Wait 60 seconds to allow CI to start
- **Expecting new CIPE:** Wait 30 seconds (action already triggered)
**IMPORTANT:** Always run sleep in foreground, NOT as background command.
```bash
sleep 60# or 30 if expecting new CIPE (FOREGROUND, not background)
```
## Two-Phase Operation
The subagent operates in one of two modes depending on input:
### Mode 1: Fresh Start (no `expectedCommitSha` or `previousCipeUrl`)
Normal polling - process whatever CIPE is returned by `ci_information`.
### Mode 2: Wait-for-New-CIPE (when `expectedCommitSha` or `previousCipeUrl` provided)
**CRITICAL**: When expecting a new CIPE, the subagent must **completely ignore** the old/stale CIPE. Do NOT process its status, do NOT return actionable states based on it.
#### Phase A: Wait Mode
1. Start a **new-CIPE timeout** timer (default: 30 minutes)
2. On each poll of `ci_information`:
- Check if CIPE is NEW:
-`cipeUrl` differs from `previousCipeUrl` → **new CIPE detected**
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
[CI Monitor] Polling... (elapsed: 1m 30s)
[CI Monitor] Still seeing previous CI Attempt (ignoring): <oldCipeUrl>
[CI Monitor] Polling... (elapsed: 2m 30s)
[CI Monitor] ✓ New CI Attempt detected! URL: <newCipeUrl>, SHA: <newCommitSha>
[CI Monitor] Switching to normal polling mode...
```
### Why This Matters (Context Preservation)
**The problem**: Stale CIPE data can be very large:
-`taskOutputSummary`: potentially thousands of characters of build/test output
-`suggestedFix`: entire patch files
-`suggestedFixReasoning`: detailed explanation
If subagent returns stale CIPE data to main agent, it **pollutes main agent's context** with useless information (we already processed that CIPE). This wastes valuable context window.
**Without wait mode:**
1. Poll `ci_information` → get old CIPE with huge data
2. Return to main agent with all that stale data
3. Main agent's context gets polluted with useless info
4. Main agent has to process/ignore it anyway
**With wait mode:**
1. Poll `ci_information` → get old CIPE → **ignore it, don't return**
2. Keep waiting internally (stale data stays in subagent)
3. New CIPE appears → switch to normal mode
4. Return to main agent with only the NEW, relevant CIPE data
## Polling Loop
### Subagent State Management
Maintain internal accumulated state across polls:
```
accumulated_state = {}
```
### Call `ci_information` MCP Tool
**Wait Mode (expecting new CI Attempt):**
```
ci_information({
branch: "<branch_name>",
select: "cipeUrl,commitSha,cipeStatus"
})
```
Only fetch minimal fields needed to detect CI Attempt change. Do NOT fetch heavy fields - stale data wastes context.
Merge response into `accumulated_state`, then return merged state to main agent.
**Pagination:** Heavy string fields return first page only. If `hasMore` indicated, include in return format so main agent knows more content available.
### Return to Main Agent When
Return immediately with structured state if ANY of these conditions are true:
| `fix_auto_applying` | `selfHealingStatus == 'COMPLETED'` AND `couldAutoApplyTasks == true` AND `verificationStatus == 'COMPLETED'` |
| `fix_available` | `selfHealingStatus == 'COMPLETED'` AND `suggestedFix != null` AND (`couldAutoApplyTasks != true` OR `verificationStatus` in (`FAILED`, `NOT_EXECUTABLE`)) |
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from `$ARGUMENTS` and merge with defaults.
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Monitor Nx Cloud CI pipeline and handle self-healing fixes automatically. Checks for Nx Cloud connection before starting.
---
# CI Monitor Command
You are the orchestrator for monitoring Nx Cloud CI pipeline executions and handling self-healing fixes. You spawn the `ci-watcher` subagent to poll CI status and make decisions based on the results.
| `--auto-fix-workflow` | false | Attempt common fixes for pre-CIPE failures (e.g., lockfile updates) |
| `--new-cipe-timeout` | 10 | Minutes to wait for new CIPE after action |
| `--local-verify-attempts` | 3 | Max local verification + enhance cycles before pushing to CI |
Parse any overrides from `$ARGUMENTS` and merge with defaults.
## Nx Cloud Connection Check
**CRITICAL**: Before starting the monitoring loop, verify the workspace is connected to Nx Cloud.
### Step 0: Verify Nx Cloud Connection
1.**Check `nx.json`** at workspace root for `nxCloudId` or `nxCloudAccessToken`
2.**If `nx.json` missing OR neither property exists** → exit with:
```
[ci-monitor] Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
```
3. **If connected** → continue to main loop
## Session Context Behavior
**Important:** Within a Claude Code session, conversation context persists. If you Ctrl+C to interrupt the monitor and re-run `/ci-monitor`, Claude remembers the previous state and may continue from where it left off.
- **To continue monitoring:** Just re-run `/ci-monitor` (context is preserved)
- **To start fresh:** Use `/ci-monitor --fresh` to ignore previous context
- **For a completely clean slate:** Exit Claude Code and restart `claude`
## Default Behaviors by Status
The subagent returns with one of the following statuses. This table defines the **default behavior** for each status. User instructions can override any of these.
| `fix_auto_applying` | Fix will be auto-applied by self-healing. Do NOT call MCP. Record `last_cipe_url`, spawn new subagent in wait mode to poll for new CIPE. |
| `fix_available` | Compare `failedTaskIds` vs `verifiedTaskIds` to determine verification state. See **Fix Available Decision Logic** section below. |
| `fix_failed` | Self-healing failed to generate fix. Attempt local fix based on `taskOutputSummary`. If successful → commit, push, loop. If not → exit with failure. |
| `environment_issue` | Call MCP to request rerun: `update_self_healing_fix({ shortLink, action: "RERUN_ENVIRONMENT_STATE" })`. New CIPE spawns automatically. Loop to poll for new CIPE. |
| `no_fix` | CI failed, no fix available (self-healing disabled or not executable). Attempt local fix if possible. Otherwise exit with failure. |
| `no_new_cipe` | Expected CIPE never spawned (CI workflow likely failed before Nx tasks). Report to user, attempt common fixes if configured, or exit with guidance. |
- If fix needs enhancement → use Apply Locally + Enhance Flow above
- If fix is wrong → reject via MCP, fix from scratch, commit, push
### Auto-Apply Eligibility
The `couldAutoApplyTasks` field indicates whether the fix is eligible for automatic application:
- **`true`**: Fix is eligible for auto-apply. Subagent keeps polling while verification is in progress. Returns `fix_auto_applying` when verified, or `fix_available` if verification fails.
- **`false`** or **`null`**: Fix requires manual action (apply via MCP, apply locally, or reject)
**Key point**: When subagent returns `fix_auto_applying`, do NOT call MCP to apply - self-healing handles it. Just spawn a new subagent in wait mode.
### Apply vs Reject vs Apply Locally
- **Apply via MCP**: Calls `update_self_healing_fix({ shortLink, action: "APPLY" })`. Self-healing agent applies the fix in CI and a new CIPE spawns automatically. No local git operations needed.
- **Apply Locally**: Runs `nx apply-locally <shortLink>`. Applies the patch to your local working directory and sets state to `APPLIED_LOCALLY`. Use this when you want to enhance the fix before pushing.
- **Reject via MCP**: Calls `update_self_healing_fix({ shortLink, action: "REJECT" })`. Marks fix as rejected. Use only when the fix is completely wrong and you'll fix from scratch.
### Apply Locally + Enhance Flow
When the fix needs enhancement (use `nx apply-locally`, NOT reject):
1. Apply the patch locally: `nx apply-locally <shortLink>` (this also updates state to `APPLIED_LOCALLY`)
2. Make additional changes as needed
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Reject + Fix From Scratch Flow
When the fix is completely wrong:
1. Call MCP to reject: `update_self_healing_fix({ shortLink, action: "REJECT" })`
2. Fix the issue from scratch locally
3. Commit and push:
```bash
git add -A
git commit -m "fix: resolve <failedTaskIds>"
git push origin $(git branch --show-current)
```
4. Loop to poll for new CIPE
### Environment Issue Handling
When `failureClassification == 'ENVIRONMENT_STATE'`:
**CRITICAL**: When passing `expectedCommitSha` or `last_cipe_url` to the subagent, it enters **wait mode**:
- Subagent will **completely ignore** the old/stale CIPE
- Subagent will only wait for new CIPE to appear
- Subagent will NOT return to main agent with stale CIPE data
- Once new CIPE detected, subagent switches to normal polling
**Why wait mode matters for context preservation**: Stale CIPE data can be very large (task output summaries, suggested fix patches, reasoning). If subagent returns this to main agent, it pollutes main agent's context with useless data since we already processed that CIPE. Wait mode keeps stale data in the subagent, never sending it to main agent.
### Step 4: Progress Tracking
After each action:
- If state changed significantly → reset `no_progress_count = 0`
- If state unchanged → `no_progress_count++`
- On new CI attempt detected → reset `local_verify_count = 0`
description: Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
---
# Run Nx Generator
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
This skill applies when the user wants to:
- Create new projects like libraries or applications
- Scaffold features or boilerplate code
- Run workspace-specific or custom generators
- Do anything else that an nx generator exists for
## Generator Discovery Flow
### Step 1: List Available Generators
Use the Nx CLI to discover available generators:
- List all generators for a plugin: `npx nx list @nx/react`
- Local workspace generators (defined in the repo's own plugins)
### Step 2: Match Generator to User Request
Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
- What artifact type they want to create (library, application, etc.)
- Which framework or technology stack is relevant
- Whether they mentioned specific generator names
**IMPORTANT**: When both a local workspace generator and an external plugin generator could satisfy the request, **always prefer the local workspace generator**. Local generators are customized for the specific repo's patterns and conventions.
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
## Pre-Execution Checklist
Before running any generator, complete these steps:
### 1. Fetch Generator Schema
Use the `--help` flag to understand all available options:
```bash
npx nx g @nx/react:library --help
```
Pay attention to:
- Required options that must be provided
- Optional options that may be relevant to the user's request
- Default values that might need to be overridden
### 2. Read Generator Source Code
Understanding what the generator actually does helps you:
- Know what files will be created/modified
- Understand any side effects (updating configs, installing deps, etc.)
- Identify options that might not be obvious from the schema
To find generator source code:
- For plugin generators: Use `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"` to find the generators.json, then locate the source from there
- If that fails, read directly from `node_modules/<plugin>/generators.json`
- For local generators: They are typically in `tools/generators/` or a local plugin directory. You can search the repo for the generator name to find it.
### 2.5 Reevaluate if the generator is right
Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request?
If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
### 3. Understand Repo Context
Before generating, examine the target area of the codebase:
- Look at similar existing artifacts (other libraries, applications, etc.)
- Identify patterns and conventions used in the repo
- Note naming conventions, file structures, and configuration patterns
- Try to match these patterns when configuring the generator
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible.
If projects or other artifacts are organized with a specific naming convention, try to match it.
### 4. Validate Required Options
Ensure all required options have values:
- Map the user's request to generator options
- Infer values from context where possible
- Ask the user for any critical missing information
## Execution
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally.
Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
### Consider Dry-Run (Optional)
Running with `--dry-run` first is strongly encouraged but not mandatory. Use your judgment:
- For complex generators or unfamiliar territory: do a dry-run first
- For simple, well-understood generators: may proceed directly
- Dry-run shows file names and created/deleted/modified markers, but not content
- There are cases where a generator does not support dry-run (for example if it had to install an npm package) - in that case --dry-run might fail. Don't be discouraged but simply move on to running the generator for real and iterating from there.
description: Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
description: Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
---
You can run tasks with Nx in the following way.
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Look at the package.json or lockfile to determine which package manager is in use.
For more details on any command, run it with `--help` (e.g. `nx run-many --help`, `nx affected --help`).
## Understand which tasks can be run
You can check those via `nx show project <projectname> --json`, for example `nx show project myapp --json`. It contains a `targets` section which has information about targets that can be run. You can also just look at the `package.json` scripts or `project.json` targets, but you might miss out on inferred tasks by Nx plugins.
## Run a single task
```
nx run <project>:<task>
```
where `project` is the project name defined in `package.json` or `project.json` (if present).
## Run multiple tasks
```
nx run-many -t build test lint typecheck
```
You can pass a `-p` flag to filter to specific projects, otherwise it runs on all projects. You can also use `--exclude` to exclude projects, and `--parallel` to control the number of parallel processes (default is 3).
Examples:
-`nx run-many -t test -p proj1 proj2` — test specific projects
-`nx run-many -t test --projects=*-app --exclude=excluded-app` — test projects matching a pattern
-`nx run-many -t test --projects=tag:api-*` — test projects by tag
## Run tasks for affected projects
Use `nx affected` to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
```
nx affected -t build test lint
```
By default it compares against the base branch. You can customize this:
-`nx affected -t test --base=main --head=HEAD` — compare against a specific base and head
-`nx affected -t test --files=libs/mylib/src/index.ts` — specify changed files directly
## Useful flags
These flags work with `run`, `run-many`, and `affected`:
-`--skipNxCache` — rerun tasks even when results are cached
-`--verbose` — print additional information such as stack traces
-`--nxBail` — stop execution after the first failed task
-`--configuration=<name>` — use a specific configuration (e.g. `production`)
description: "Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks."
---
# Nx Workspace Exploration
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
Keep in mind that you might have to prefix commands with `npx`/`pnpx`/`yarn` if nx isn't installed globally. Check the lockfile to determine the package manager in use.
## Listing Projects
Use `nx show projects` to list projects in the workspace.
```bash
# List all projects
nx show projects
# Filter by pattern (glob)
nx show projects --projects "apps/*"
nx show projects --projects "shared-*"
# Filter by project type
nx show projects --type app
nx show projects --type lib
nx show projects --type e2e
# Filter by target (projects that have a specific target)
nx show projects --withTarget build
nx show projects --withTarget e2e
# Find affected projects (changed since base branch)
nx show projects --affected
nx show projects --affected --base=main
nx show projects --affected --type app
# Combine filters
nx show projects --type lib --withTarget test
nx show projects --affected --exclude="*-e2e"
# Output as JSON
nx show projects --json
```
## Project Configuration
Use `nx show project <name> --json` to get the full resolved configuration for a project.
**Important**: Do NOT read `project.json` directly - it only contains partial configuration. The `nx show project` command returns the full resolved config including inferred targets from plugins.
You can read the full project schema at `node_modules/nx/schemas/project-schema.json` to understand nx project configuration options.
```bash
# Get full project configuration
nx show project my-app --json
# Extract specific parts from the JSON
nx show project my-app --json | jq '.targets'
nx show project my-app --json | jq '.targets.build'
nx show project my-app --json | jq '.targets | keys'
1. Suggest relevant commands from the "Essential Commands" section when applicable
2. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
analysis
3. Mention the plugin ecosystem and support for various frameworks when relevant
4. Emphasize the importance of running the full validation suite before committing changes
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this
file.
## Documentation Contributions
When working on Nx documentation, all documentation content lives in the `astro-docs/` folder. This is the new Astro-based documentation site built with Starlight.
**Important**: Before making any documentation changes, read the `astro-docs/README.md` file for detailed guidance on:
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
### 2. Analyze the Plan
- Look for a plan or implementation details in the issue description
- Check comments for additional context or clarification
- Identify affected projects and components
### 3. Implement the Solution
- Follow the plan outlined in the issue
- Make focused changes that address the specific problem
- Ensure code follows existing patterns and conventions
### 4. Run Full Validation
Use the testing workflow from the "Essential Commands" section.
### 5. Submit Pull Request
- Create a descriptive PR title that references the issue
- **Always fill in the PR template** - don't leave it empty
- Include "Fixes #ISSUE_NUMBER" in the PR description
- Provide a clear summary of changes made
- Request appropriate reviewers
## Pull Request Template
**IMPORTANT**: When creating a pull request, you MUST fill in the template found in `.github/PULL_REQUEST_TEMPLATE.md`.
Do not leave the template sections empty. The template includes:
### Required Sections
1.**Current Behavior**: Describe the behavior we have today
2.**Expected Behavior**: Describe the behavior we should expect with the changes in this PR
3.**Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
### Template Format
```markdown
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
Fixes #ISSUE_NUMBER
```
### Guidelines
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
- Use `fix:`, `feat:`, `chore:`, etc. as appropriate types.
- Scope is **required** for all commits. Possible scopes are listed in `scripts/commitizen.js`.
- Read the submission guidelines in CONTRIBUTING.md before posting
- For complex changes, you can request a dedicated Nx release by mentioning the Nx team
- Always link the related issue using "Fixes #ISSUE_NUMBER" to automatically close it when merged
<!-- nx configuration start-->
<!-- Leave the start & end comments to automatically receive updates. -->
# General Guidelines for working with Nx
- When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly
- You have access to the Nx MCP server and its tools, use them to help the user
- For understanding the workspace structure, projects, or available tasks, use the `/nx-workspace` skill which provides guidance on exploring Nx workspaces
- For questions around nx configuration, best practices or if you're unsure, use the `nx_docs` MCP tool to get relevant, up-to-date docs. Always use this instead of assuming things about nx configuration
- For Nx plugin best practices, check `node_modules/@nx/<plugin>/PLUGIN.md`. Not all plugins have this file - proceed without it if unavailable.
1. Suggest relevant commands from the "Essential Commands" section when applicable
2. Highlight Nx's focus on monorepos and its key features like smart task execution, code generation, and project graph
analysis
3. Mention the plugin ecosystem and support for various frameworks when relevant
4. Emphasize the importance of running the full validation suite before committing changes
Always strive to provide accurate, helpful responses that align with the best practices and workflows described in this
file.
## Documentation Contributions
When working on Nx documentation, all documentation content lives in the `astro-docs/` folder. This is the new Astro-based documentation site built with Starlight.
**Important**: Before making any documentation changes, read the `astro-docs/README.md` file for detailed guidance on:
When cloning reproduction repos, please clone within `./tmp/claude/repro-ISSUE_NUMBER`
### 2. Analyze the Plan
- Look for a plan or implementation details in the issue description
- Check comments for additional context or clarification
- Identify affected projects and components
### 3. Implement the Solution
- Follow the plan outlined in the issue
- Make focused changes that address the specific problem
- Ensure code follows existing patterns and conventions
### 4. Run Full Validation
Use the testing workflow from the "Essential Commands" section.
### 5. Submit Pull Request
- Create a descriptive PR title that references the issue
- **Always fill in the PR template** - don't leave it empty
- Include "Fixes #ISSUE_NUMBER" in the PR description
- Provide a clear summary of changes made
- Request appropriate reviewers
## Pull Request Template
**IMPORTANT**: When creating a pull request, you MUST fill in the template found in `.github/PULL_REQUEST_TEMPLATE.md`.
Do not leave the template sections empty. The template includes:
### Required Sections
1.**Current Behavior**: Describe the behavior we have today
2.**Expected Behavior**: Describe the behavior we should expect with the changes in this PR
3.**Related Issue(s)**: Link the issue being fixed so it gets closed when the PR is merged
### Template Format
```markdown
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR -->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is merged. -->
Fixes #ISSUE_NUMBER
```
### Guidelines
- Ensure your commit message follows the conventional commit format (use `pnpm commit`)
- Use `fix:`, `feat:`, `chore:`, etc. as appropriate types.
- Scope is **required** for all commits. Possible scopes are listed in `scripts/commitizen.js`.
- Read the submission guidelines in CONTRIBUTING.md before posting
- For complex changes, you can request a dedicated Nx release by mentioning the Nx team
- Always link the related issue using "Fixes #ISSUE_NUMBER" to automatically close it when merged
<!-- nx configuration start-->
<!-- Leave the start & end comments to automatically receive updates. -->
# General Guidelines for working with Nx
- When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly
- You have access to the Nx MCP server and its tools, use them to help the user
- For understanding the workspace structure, projects, or available tasks, use the `/nx-workspace` skill which provides guidance on exploring Nx workspaces
- For questions around nx configuration, best practices or if you're unsure, use the `nx_docs` MCP tool to get relevant, up-to-date docs. Always use this instead of assuming things about nx configuration
- For Nx plugin best practices, check `node_modules/@nx/<plugin>/PLUGIN.md`. Not all plugins have this file - proceed without it if unavailable.
<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>
</a>
## Got a Question?
We are trying to keep GitHub issues for bug reports and feature requests. Using the `nrwl` tag
on [Stack Overflow](https://stackoverflow.com/questions/tagged/nrwl) is a much better place to ask general questions
about how to use Nx.
We are trying to keep GitHub issues for bug reports and feature requests.
You can join our [Discord](https://go.nx.dev/community) for general questions and seeking help from others.
## Found an Issue?
@@ -27,14 +18,25 @@ can [submit a Pull Request](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.
Source code and documentation are included in the top-level folders listed below.
-`docs` - Markdown and configuration files for documentation including tutorials, guides for each supported platform,
and API docs.
-`e2e` - E2E tests.
-`packages` - Source code for Nx packages such as Angular, React, Web, NestJS, Next and others including generators and
executors (or builders).
-`e2e` - E2E tests for the Nx packages
-`graph` - Source code for the Nx Graph application which shows the project graph, task graph, project details, and more in the browser.
-`docs` - Markdown and configuration files for documentation including tutorials, guides for each supported platform,
and API docs.
-`nx-dev` - Source code for the Nx documentation site which displays the markdown in `docs` and more.
-`tools` - Workspace-specific tooling and plugins
-`scripts` - Miscellaneous scripts for project tasks such as building documentation, testing, and code formatting.
-`tmp` - Folder used by e2e tests. If you are a WebStorm user, make sure to mark this folder as excluded.
## Technologies
This repo contains a mix of different technologies, including:
- **Rust**: The core of Nx is written in Rust, which provides performance and safety.
- **TypeScript**: The primary language for Nx packages and the Nx DevKit.
- **Kotlin**: Used for the Gradle and Java plugins.
## Development Workstation Setup
If you are using `VSCode`, and provided you have [Docker](https://docker.com) installed on your machine, then you can leverage [Dev Containers](https://containers.dev) through this [VSCode extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers), to easily setup your development environment, with everything needed to contribute to Nx, already installed (namely `NodeJS`, `Yarn`, `Rust`, `Cargo`, plus some useful extensions like `Nx Console`).
@@ -183,76 +185,73 @@ To build Nx on Windows, you need to use WSL.
## Documentation Contributions
We would love for you to contribute to our documentation as well! Please feel welcome to submit fixes or enhancements to
our existing documentation pages and the `nx-dev` application in this repo.
our existing documentation pages, `astro-docs` and the `nx-dev` application in this repo.
### Documentation Structure
#### Documentation Pages
Our documentation pages can be found within this repo under the `docs` directory.
Our documentation pages can be found within this repo under the `astro-docs/src/content/docs` directory.
The `docs/map.json` file is considered our source of truth for our site's structure, and should be updated when adding a
new page to our documentation to ensure that it is included in the documentation site. We also run automated scripts
based on this `map.json` data to safeguard against common human errors that could break our site.
Documentation is written in `.mdoc` (Markdoc) or `.mdx` (MDX) format and supports custom Markdoc tags for rich content
such as videos, graphs, interactive components, and more. See the `astro-docs/README.md` for a full list of available
custom tags and their usage.
When you make a change to the `map.json` file, make sure to run `pnpm documentation` to propagate your changes to the `nx-dev` application.
The sidebar structure is defined in `astro-docs/sidebar.mts` and should be updated when adding new sections or pages
to ensure proper navigation.
#### Astro-Docs Application
Our public `nx.dev/docs` documentation site is built with [Astro](https://astro.build) and [Starlight](https://starlight.astro.build),
and can be found in the `astro-docs` directory of this repo. See [docs README for more details](./astro-docs/README.md)
#### Nx-Dev Application
Our public `nx.dev` documentation site is a [Next.js](https://nextjs.org/) application, that can be found in
the `nx-dev` directory of this repo.
The documentation site is consuming the `docs/` directly by copy-ing its content while deploying, so the website is
always in sync and reflects the latest version of `docs/`.
The `nx-dev` directory contains a [Next.js](https://nextjs.org/) application used for blog posts and landing pages.
Jump to [Running the Documentation Site Locally](#running-the-documentation-site-locally) to see how to preview your
changes while serving.
### Changing Generated API documentation
`.md` files documenting the API for our CLI (including executor and generator API docs) are generated via the
corresponding `schema.json` file for the given command.
API documentation for CLI commands, executors, and generators is automatically generated during the build process from
the corresponding `schema.json` files in each package.
After adjusting the `schema.json` file, `.md` files for these commands can be generated by running:
The documentation is generated using content loaders in the `astro-docs` application and requires a rebuild to reflect
changes. After adjusting a `schema.json` file:
```bash
pnpm documentation
```
This will update the corresponding contents of the `docs` directory. These are generated automatically on push (via
husky) as well.
1. Restart the development server with `nx serve astro-docs` to see the changes
2. Or run `nx preview astro-docs` to view the built site locally
Note that adjusting the `schema.json` files will also affect the CLI manuals and Nx Console behavior, in addition to
adjusting the docs.
the generated documentation.
### Running the Documentation Site Locally
To run `nx-dev` locally, run the command:
To run the documentation site locally, run the command:
```bash
npx nx serve-docs nx-dev
```shell
nx serve astro-docs
```
You can then access the application locally at `localhost:4200`. Changes to markdown documentation files will be automatically applied to the site when you refresh the browser.
You can then access the application locally at `localhost:4321`. Changes to markdoc files should reflect automatically in the browser on save.
#### Troubleshooting: `JavaScript heap out of memory`
#### Working with Plugin Registry
If you see an error that states: `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory`,
you need
to [increase the max memory size of V8's old memory section](https://nodejs.org/api/cli.html#--max-old-space-sizesize-in-megabytes):
To view plugin registry statistics (GitHub stars, npm downloads, etc.) during local development:
```bash
export NODE_OPTIONS="--max-old-space-size=4096"
NX_DOCS_PLUGIN_STATS=true nx serve astro-docs
```
After configuring this, try to run `npx nx serve nx-dev` again.
Note: Plugin stats are disabled by default in development to improve performance.
### PR Preview
When submitting a PR, this repo will automatically generate a preview of the `nx-dev` application based on the contents
When submitting a PR, this repo will automatically generate a preview of the documentation site based on the contents
of your pull request.
Once the preview site is launched, a comment will automatically be added to your PR with the link your PR's preview. To
check your docs changes, make sure to select `Preview` from the version selection box of the site.
Once the preview site is launched, a comment will automatically be added to your PR with the link to your PR's preview.
## Submission Guidelines
@@ -333,6 +332,7 @@ The scope must be one of the following:
- express - anything Express specific
- js - anything related to @nx/js package or general js/ts support
- linter - anything Linter specific
- module-federation - anything Nx Module Federation specific
- nest - anything Nest specific
- nextjs - anything Next specific
- node - anything Node specific
@@ -374,6 +374,57 @@ To simplify and automate the process of committing with this format,
**Nx is a [Commitizen](https://github.com/commitizen/cz-cli) friendly repository**, just do `git add` and
execute `pnpm commit`.
##### Using the Interactive Commit Tool
Instead of `git commit`, use:
```bash
pnpm commit
```
This will launch an interactive prompt that will:
1. Ask you to select the type of change (feat, fix, docs, cleanup, chore)
2. Let you choose the appropriate scope from the predefined list
3. Guide you through writing a clear, descriptive commit message
4. Ensure your commit follows the conventional commit format
##### Available Commit Types
- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation only changes
- **cleanup**: A code change that neither fixes a bug nor adds a feature
- **chore**: Other changes that don't modify src or test files
##### Available Scopes
The repository includes many predefined scopes. Use the one which is most specific to the changes being committed
- **core**: anything Nx core specific
- **angular**: anything Angular specific
- **react**: anything React specific
- **nextjs**: anything Next specific
- **node**: anything Node specific
- **devkit**: devkit-related changes
- **graph**: anything graph app specific
- **testing**: anything testing specific (e.g. jest or cypress)
- **misc**: misc stuff
- **repo**: anything related to managing the repo itself
- **nx-dev**: anything related to docs infrastructure
For the complete list of available scopes, see `/scripts/commitizen.js`.
##### Example Commits
```bash
feat(core): add new project graph visualization
fix(angular): resolve build issues with standalone components
docs(misc): update contributing guidelines
chore(repo): bump dependencies
cleanup(devkit): refactor utility functions for better readability
```
#### PR releases
If you are working on a particularly complex change or feature addition, you can request a dedicated Nx release for the associated pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate.
[](https://gitter.im/nrwl-nx/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
[](https://go.nx.dev/community)
@@ -19,9 +19,7 @@
<hr>
# Smart Monorepos · Fast CI
Build system, optimized for monorepos, with AI-powered architectural awareness and advanced CI capabilities.
# The Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.
Create a new Nx workspace with
@@ -35,7 +33,7 @@ npx create-nx-workspace
npx nx init
```
to add Nx to your existing workspace to get faster task scheduling, caching and more. More [in the docs](https://nx.dev/getting-started/intro#try-nx-yourself).
to add Nx to your existing workspace to get faster task scheduling, caching and more. More [in the docs](https://nx.dev/getting-started/intro).
## Learn about CI with Nx Cloud
@@ -47,7 +45,7 @@ Connect your existing Nx workspace with
npx nx connect
```
Learn more in the [Nx CI docs »](https://nx.dev/ci/intro?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo)
Learn more in the [Nx CI docs »](https://nx.dev/ci/getting-started/intro?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo)
## Useful links
@@ -58,7 +56,7 @@ Learn more in the [Nx CI docs »](https://nx.dev/ci/intro?utm_source=nxrepo
Nx/Nrwl takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations.
If you believe you have found a security vulnerability in any Nx-owned repository that meets Nx's definition of a security vulnerability, please report it to us as described below.
## Reporting Security Issues
**Please do not report security vulnerabilities through public GitHub issues.**
Instead, please report them to the Security Team at security@nrwl.io.
You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
Nx follows the principle of Coordinated Vulnerability Disclosure.
## What Should Be Reported
The security email is for **demonstrable, verified vulnerabilities within the Nx codebase itself**.
**Please do not use the security email for:**
- Reports about outdated dependencies (e.g., "package X has a newer version available")
- Reports about dependencies with known CVEs that do not directly affect Nx functionality
- General vulnerability scanner output
If you have a concern about an outdated dependency that you believe impacts Nx users, please open a [GitHub issue](https://github.com/nrwl/nx/issues/new/choose) instead.
[](https://starlight.astro.build)
The Nx documentation site built with Astro and Starlight, featuring advanced content management through Markdoc and dynamic plugin documentation generation.
## Architecture Overview
This documentation site leverages Astro's static site generation capabilities with Starlight for documentation-specific features. The architecture consists of:
### Core Technologies
- [**Astro**](https://docs.astro.build) - Static site generator with island architecture
- [**Starlight**](https://starlight.astro.build) - Documentation theme with built-in navigation, search, and i18n
- **React** - For implementing UI components
- **Netlify** - Deployment and hosting
### Key Features
- [Markdoc](https://markdoc.dev) with custom tags for rich content such as videos, graphs, etc.
- TailwindCSS for styling in Astro and React components
- Dynamic API documentation generation from Nx packages and CLI commands
- Community plugin registry
## Information Architecture Principles
When creating or reorganizing documentation, follow these 5 principles to determine where content belongs.
### 1. Progressive Disclosure (The "Journey" Rule)
- **Concept:** Don't overwhelm the user. Reveal complexity only as they advance in their journey.
- **The Test:** _Is this for the First 30 Minutes (Getting Started), the First 30 Days (Features), or Forever (Reference)?_
### 2. Category Homogeneity (The "Scan" Rule)
- **Concept:** Items in a list must be of the same "type" (noun, verb, or concept) to reduce cognitive load.
- **The Test:** _Does this list mix Concepts (Mental Model), Tasks (Update Nx), and Products (React)? If yes, split it._
### 3. Type-Based Navigation (The "Intent" Rule)
- **Concept:** Separate **Learning** (Narrative/Guides) from **Looking Up** (Reference/API).
- **The Test:** _Is the user here to learn a workflow (Guide) or look up a flag syntax (Reference)?_
### 4. The Pen & Paper Test (The "Theory" Rule)
- **Concept:** Distinguish Architecture from Features to keep "Core Concepts" pure.
- **The Test:** _Can I explain this using only a pen and paper?_
- **Yes:** It goes in **How Nx Works** (Architecture).
- **No (I need a terminal):** It goes in **Platform Features** (Feature).
### 5. Universal vs. Specific (The "Placement" Rule)
- **Concept:** Distinguish Platform features from Ecosystem tools to prevent "Features" from becoming a junk drawer.
- **The Test:** _Does this feature apply to EVERY user (e.g., Caching, Agents)?_
- **Yes:** **Platform Features**.
- **No (Only React users):** **Technologies**.
### Sidebar Structure
The sidebar has 4 top-level sections that follow the user journey:
-`{% install_nx_console %}` - IDE extension installer
#### Content Enhancement
-`{% badge %}` - Status/label pills
-`{% metrics %}` - Metrics display
-`{% testimonial %}` - Customer testimonials
## Development Workflow
### Getting Started
```bash
# Install dependencies and link workspace packages
# This will build Nx packages as well for API docs
nx serve astro-docs
# Or run astro dev directly
# This will not build Nx packages
cd astro-docs
npx astro dev
# Custom ports (useful for AI agents with git worktrees)
npx astro dev --port 3000
```
### Adding New Content
#### Regular Documentation
1. Create `.mdoc` file in `src/content/docs/`
2. Add frontmatter with title and description
3. Use Markdoc tags for rich content
4. File location determines URL structure
Example:
```markdown
---
title: 'My New Guide'
description: 'Learn how to use this feature'
---
# Introduction
{% aside type="note" title="Important" %}
This is a note about the feature.
{% /aside %}
```
#### Adding Custom Markdoc Tags
1. Create Astro component in `src/components/markdoc/`
2. (Optional) Create React component for more complex components, or ones that need to be shared with blog or non-docs pages
3. Register in `markdoc.config.mjs`
4. Define attributes and validation
### Updating Plugin Documentation
Plugin documentation is auto-generated during build. To update:
1. Make changes to the plugin's schema/implementation
2. Run the build process
3. The loader will automatically fetch and generate updated docs
### Sidebar Management
The sidebar structure is defined in `sidebar.mts`. To add new sections:
```javascript
exportconstsidebar=[
{
label:'Section Name',
items:[
{
label:'Page Title',
link:'path/to/page',
},
// Nested sections
{
label:'Subsection',
collapsed:true,
items:[...]
}
]
}
];
```
> Note there is a special case for sidebar items appearing in the sidebar. Such as the `Reference` section which is handled via the `[sidebar-reference-updater](./src/plugins/sidebar-reference-updater.middleware.ts)` middleware.
## Styling and Theming
- Uses Tailwind CSS v4 with Vite plugin
- Global styles in `src/styles/global.css`
- Component-specific styles use Tailwind utilities
- Dark/light mode support built into Starlight and customized in `global.css`
## Configuration Files
### `astro.config.mjs`
- Site configuration
- Integration setup (React, Markdoc, Starlight)
- Vite plugins
- Build options
### `markdoc.config.mjs`
- Custom tag definitions
- Attribute validation
- Component mappings
### `sidebar.mts`
- Navigation structure
- Section organization
- Dynamic content injection points
## Banner Configuration
The floating banner promotes events/webinars. It's fetched at **build time** from a Framer CMS page and stored as an Astro content collection.
### Setup
Set `BANNER_URL` to point to a Framer page that renders banner JSON:
2.**Technologies** - Framework and tool-specific guides (React, Angular, Node, build tools, test tools)
3.**Knowledge Base** - Recipes, troubleshooting, and topic-specific guides
4.**Reference** - Exhaustive facts, no narrative (CLI commands, configuration, API docs)
## The Nx voice
Nx documentation is **direct, practical, and confident**. We write like a knowledgeable colleague pairing with you — not like a textbook, not like a marketing page, and not like a chatbot.
The voice should be:
- **Conversational but efficient.** Use contractions. Get to the point. Don't pad sentences.
- **Second person.** Write "you" — address the reader directly.
- **Action-oriented.** Lead with what the reader can _do_, not what Nx _is_.
- **Honest about tradeoffs.** Don't oversell. If something has limitations, say so.
| "You can speed up builds by enabling remote caching." | "Nx allows you to speed up builds." |
| "Run `nx build` to build your project." | "In order to build your project, you can run the `nx build` command." |
| "This works best with fewer than 50 projects." | "This feature can easily scale to any number of projects." |
| "Nx reads your `vite.config.ts` and infers build targets automatically." | "Nx provides a robust and comprehensive mechanism for inferring build targets." |
| "If the cache is stale, delete `.nx/cache` and retry." | "Should you encounter issues with caching, you may want to consider clearing your cache directory." |
### Anti-AI language
Documentation must not read like it was generated by an AI assistant. Even when AI tools are used in the writing process, the output must be edited to sound like a human wrote it.
**Never use these phrases:**
- "It's important to note that..."
- "It's worth noting that..." / "It should be noted that..."
- "In this section, we will explore..."
- "Let's dive into..." / "Let's take a closer look at..."
- "Whether you're a beginner or an experienced developer..."
- "In today's fast-paced development environment..."
- "Unlock the power of..." / "Harness the power of..."
- "Take your workspace to the next level"
- "Streamline your workflow" (as a generic claim without specifics)
- "This comprehensive guide will..."
- "Without further ado..."
- "In conclusion..." / "To summarize..." / "As we've seen..."
- "Seamless" / "Seamlessly" (unless describing an actual integration)
**Avoid hedging words unless genuinely needed:**
- "Essentially" / "Basically" / "Effectively"
- "Generally speaking"
- "It is worth mentioning"
- "Arguably"
- "Needless to say"
- "As a matter of fact"
**Watch for AI-style sentence patterns:**
- Sentences that start with "This allows you to..." or "This enables you to..." — rewrite to lead with the reader's action.
- Paragraphs that start with a general claim and then restate it slightly differently. Say it once.
- Excessive use of "robust", "leverage", "utilize", "facilitate", "comprehensive", "aforementioned."
- Lists where every item starts with the same grammatical structure repeated 5+ times with slight variation. Vary your phrasing.
### Self-referential writing
Don't write about the document itself.
Do:
- "Nx uses a project graph to determine task dependencies."
Don't:
- "This page explains how Nx uses a project graph."
- "In this guide, we'll walk through..."
- "This document covers..."
Get right to the point. The reader already knows they're on a page — they want the information.
### Building trust
Don't use filler words that undermine the reader's trust.
- Don't use "easily", "simply", "just", or "straightforward" — if something were truly simple, you wouldn't need to document it. These words also make readers feel bad when they struggle.
- Don't use marketing language: "This feature will save you hours" or "Nx makes CI effortless."
- Be specific instead: "Remote caching can reduce CI times from 45 minutes to under 5 minutes for cache-hit builds."
### Customer perspective
Focus on what the reader can do, not what Nx does.
Do:
- "Use `nx affected` to run tasks only for projects impacted by your changes."
Don't:
- "Nx allows you to run affected tasks."
- "Nx provides the ability to run tasks selectively."
Words like "allow" and "enable" are signals you're writing from the product's perspective instead of the reader's.
## Language
Write in US English.
### Active voice
Use active voice in most cases.
Do: "Nx caches the build output."
Don't: "The build output is cached by Nx."
Exception: When "Nx" as the subject sounds awkward, passive voice is fine. "The output is stored in `.nx/cache`" is better than "Nx stores the output in `.nx/cache`" if Nx isn't the focus of the sentence.
### Contractions
Use contractions. They make the text feel natural.
- "You'll need to configure..." not "You will need to configure..."
- "It doesn't support..." not "It does not support..."
Don't contract for emphasis in warnings or error descriptions:
- "**Do not** delete the `nx.json` file."
- "Requests to localhost **are not** allowed."
Don't contract proper nouns: "the Vite plugin is..." not "Vite's a plugin..."
### Capitalization
Use sentence case for headings. Capitalize proper nouns only.
-`# Use remote caching to speed up CI`
-`## Configure the Vite plugin`
Feature names are lowercase unless they are a proper product name:
| Correct | Incorrect |
| -------------- | -------------- |
| remote caching | Remote Caching |
| task pipeline | Task Pipeline |
| project graph | Project Graph |
| Nx Cloud | nx cloud |
| Nx Console | nx console |
| Nx Agents | nx agents |
| Nx Replay | nx replay |
### Acronyms
Spell out acronyms on first use per page. Don't spell out widely-known ones: CI, CD, API, URL, CLI, PR, IDE.
Don't make acronyms plural with apostrophes. Use `APIs`, not `API's`.
### Numbers
Spell out zero through nine. Use numerals for 10 and above. Always use numerals with units: "5 minutes", "3 projects."
### Possessives
Don't use possessives on product names. "the Docker CLI", not "Docker's CLI." "the Nx configuration", not "Nx's configuration."
## Text
### Headings
- Don't skip heading levels (e.g., `##` to `####`).
- Don't use code in headings unless it's essential (like a CLI command).
- Don't use bold text in headings.
- Keep headings short and scannable. Lead with keywords.
### Line length
- Wrap lines at approximately 100 characters for readability in diffs.
- Start each new sentence on a new line.
- Exception: Don't break links across lines.
### Punctuation
- Use serial (Oxford) commas: "React, Angular, and Vue."
- Use one space between sentences.
- Don't use semicolons. Use two sentences instead.
- Don't use em dashes or en dashes. Use commas or separate sentences.
### Placeholder text
Use `<` and `>` for values the reader must replace:
```shell
nx run <project-name>:build
```
If the placeholder is inline, wrap it in a single backtick: `<your-project>`.
### Bold
Use bold for:
- UI elements: "Select **Add Connection**."
- Navigation paths: "Go to **Settings** > **Workspace**."
Don't use bold for emphasis or keywords. If you need emphasis, rewrite the sentence to be clearer.
### Inline code
Use inline code (single backticks) for:
- Commands and CLI arguments: `nx build`, `--parallel`
- Short outputs and values: `true`, `false`, `success`
### Code blocks
Use triple backticks with a language identifier:
````markdown
```json
{
"targetDefaults": {
"build": {
"cache": true
}
}
}
```
````
- Always specify a syntax language. Use `plaintext` if nothing else fits.
- Add a blank line before and after code blocks.
- For long config files, show only the relevant section and use comments to indicate omitted parts:
```json
{
// ... other config
"targetDefaults": {
"build": {
"cache": true
}
}
}
```
## Links
Links help readers find related information, but too many links make text hard to read.
### General rules
- Don't duplicate links. If you link to a page once, don't link to it again on the same page.
- Don't use links in headings.
- Avoid more than 15 links to other pages on any single page.
- Avoid multiple links in a single paragraph when possible.
### Link text
Use descriptive text, not "here" or "this page."
Do:
- "For more information, see [remote caching](/features/cache)."
- "To configure task pipelines, see [task pipeline configuration](/concepts/task-pipeline-configuration)."
Don't:
- "For more information, see [this page](/features/cache)."
- "Click [here](/features/cache) to learn more."
- "For more information, see the [Remote Caching](/features/cache) documentation."
Standard patterns:
- `For more information, see [link text](url).`
- `To <do this thing>, see [link text](url).`
### External links
Minimize external links. They break over time and are hard to maintain. When you must link externally, prefer official documentation (e.g., Vite docs, Webpack docs) over blog posts or third-party guides.
## Lists
- Use ordered lists for sequences of steps.
- Use unordered lists when order doesn't matter.
- Use dashes (`-`) for unordered lists.
- Start ordered list items with `1.` (Markdown auto-increments).
- Make list items parallel in structure.
- Add a colon after the introductory phrase.
- Don't use list items to complete an introductory sentence.
Do:
```markdown
You can clear the cache in the following ways:
- Delete the `.nx/cache` directory manually.
- Run `nx reset` to clear all cached results.
```
Don't:
```markdown
You can clear the cache by:
- Deleting the `.nx/cache` directory manually.
- Running `nx reset`.
```
## Tables
Use tables for structured data that benefits from a matrix layout. For simple lists of items with descriptions, use a regular list instead.
- Don't leave cells empty. Use "N/A" or "None."
- Use sentence case for headers.
- Keep the header and delimiter rows the same length.
## Nx-specific terminology
Use these terms consistently. When writing about Nx concepts, use the exact term from this list.
"comment":"package.json#scripts runs in the project root directory with astro assumes is where the node_modules is. which fails. so run the scripts in project.json#targets with --root command instead",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jason Jean
