Compare commits

...

108 Commits

Author SHA1 Message Date
Jason Jean 5e9180b628 chore(repo): update nx to 21.3.0-beta.5
(cherry picked from commit be6d35bc26)
2025-07-11 09:32:35 -04:00
Emily Xiong 56610f9657 fix(gradle): allow excludeDependsOn to be false (#31890)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #

(cherry picked from commit fb7f38edda)
2025-07-11 09:31:36 -04:00
Craigory Coppola 312058d67a feat(core): add support for --tui and --no-tui (#31621)
## 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>
(cherry picked from commit 819ac4442f)
2025-07-11 09:31:35 -04:00
Benjamin Cabanes aac166de33 docs(nx-dev): add credit pricing reference & update navigation (#31875)
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.

(cherry picked from commit 7c9f6cadcc)
2025-07-11 09:31:34 -04:00
Jason Jean 7b0f4dcdab docs(misc): update nx fix-ci documentation link (#31884)
## 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.

(cherry picked from commit 3bdc0ccd90)
2025-07-11 09:31:33 -04:00
Leosvel Pérez Espinosa f022f3a7c6 fix(misc): add fallback for missing source root (#31759)
## 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

(cherry picked from commit a7800c47d6)
2025-07-11 09:31:32 -04:00
Leosvel Pérez Espinosa 9c74e82745 fix(angular): generate ngrx facade spec file correctly (#31850)
## 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 #

(cherry picked from commit b8f139016b)
2025-07-11 09:31:31 -04:00
Juri f5d3fc0e66 docs(core): updates to the getting started pages
(cherry picked from commit ecee1c34fc)
2025-07-11 09:31:27 -04:00
Leosvel Pérez Espinosa de00e97308 fix(core): allow opting out of sorting root tsconfig path mappings with an env var (#31763)
## 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

(cherry picked from commit b5d406dee8)
2025-07-11 09:31:26 -04:00
Leosvel Pérez Espinosa 54db861b72 Revert "fix(core): add option to use v8 for daemon message serializat… (#31881)
…ion to avoid issues when JSON.stringify would fail (#30516)"

This reverts commit a59e6eb559.

(cherry picked from commit 3782d7edac)
2025-07-11 09:31:25 -04:00
Jason Jean 30016157b2 feat(core): add fix-ci command to CI workflows (#31833)
## 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>
(cherry picked from commit 13551c9457)
2025-07-11 09:31:23 -04:00
Philip Fulcher 7386e7bd31 docs(nx-dev): remove references to July 9th webinar (#31874)
(cherry picked from commit baa28ab697)
2025-07-11 09:31:22 -04:00
Juri 600d4f77e3 docs(nx-cloud): add new self-healing ci feature page
(cherry picked from commit b67deeefe3)
2025-07-11 09:31:19 -04:00
Jack Hsu 7b87b407f6 docs(misc): fix command in self-healing ci blog post
(cherry picked from commit 5eec205959)
2025-07-11 09:31:18 -04:00
Craigory Coppola cda214eda8 fix(core): add option to use v8 for daemon message serialization to avoid issues when JSON.stringify would fail (#30516)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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>
(cherry picked from commit a59e6eb559)
2025-07-11 09:31:17 -04:00
Brandon Roberts fdb2c2fd90 fix(vite): bump @analogjs/vite-plugin-angular to 1.19.x (#31866)
## Current Behavior

AnalogJS installs 1.17.1 for Vitest support

## Expected Behavior

AnalogJS installs 1.19.1 for Vitest support

(cherry picked from commit 4a09116283)
2025-07-11 09:31:16 -04:00
Miroslav Jonaš c280c1acda docs(nx-dev): remove problematic GitHub parallelization (#31865)
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 #

(cherry picked from commit f432f78028)
2025-07-11 09:31:16 -04:00
Jason Jean 110bb66da1 Revert "feat(core): add CI warning for missing remote cache solution (#31678)" (#31860)
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

(cherry picked from commit 2077a4ac4b)
2025-07-11 09:30:58 -04:00
Jack Hsu b8ece6b08d chore(repo): rename rawdocs to upstream docs (#31859)
Just a rename for https://github.com/nrwl/upstream-docs

(cherry picked from commit a024760e1d)
2025-07-11 09:30:49 -04:00
Leosvel Pérez Espinosa b7d7e86186 chore(core): optionally infer all package.json files as projects (#31843)
Add an env var to allow inferring projects from all `package.json` files
when there's no `package.json` file at the workspace root.

(cherry picked from commit ffb80d10ab)
2025-07-11 09:30:48 -04:00
Benjamin Cabanes 16736c3562 docs(nx-dev): update nx-cloud page (#31844)
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.

(cherry picked from commit ea5cd30e42)
2025-07-11 09:30:48 -04:00
James Henry f26339568b fix(core): improve tui contrast on some terminal themes (#31299)
(cherry picked from commit 7f674e1406)
2025-07-11 09:30:43 -04:00
Miguel ee9fe1c501 fix(core): consider virtual trees in globAsync (#31805)
(cherry picked from commit 0fce02a7f5)
2025-07-11 09:30:43 -04:00
Jonathan Gelin 6b68812ddc fix(plugin): fix e2e-project generator when the e2e target is inferred (#31809)
(cherry picked from commit 31661c8340)
2025-07-11 09:30:42 -04:00
Jason Jean bfb74b44f8 feat(core): refactor CI workflow generator to use centralized command generation (#31787)
## 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

(cherry picked from commit 666da3eaeb)
2025-07-11 09:30:41 -04:00
Nicholas Cunningham 7d327ee856 chore(repo): bump nx version to 21.3.0-beta.2 (#31819)
Bump the Nx version to 21.3.0-beta.2

(cherry picked from commit e92cbee9f6)
2025-07-11 09:30:40 -04:00
Victor Savkin 4b29c2434a fix(core): return current nx init date when no git available yet
(cherry picked from commit 6fdca3d539)
2025-07-11 09:30:39 -04:00
Emily Xiong e779d699cd fix(gradle): handle custom build gradle files (#31817)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #

(cherry picked from commit 2a0153e839)
2025-07-11 09:30:39 -04:00
Benjamin Cabanes 3742b41758 docs(nx-dev): update team list (#31784)
Standard team list updates.

(cherry picked from commit 62d7bf6d17)
2025-07-11 09:30:38 -04:00
Benjamin Cabanes 8570e75d69 docs(nx-dev): add Nx Essentials workshop announcement (#31816)
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.

(cherry picked from commit 84ce8311a4)
2025-07-11 09:30:37 -04:00
Emily Xiong e84fd31ef1 fix(gradle): add dependsOn outputs to inputs dependentTasksOutputFiles (#31683)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 #

(cherry picked from commit 2abf1116d6)
2025-07-02 16:41:16 -04:00
Jason Jean 35474f8281 chore(workspace): format new generator code (#31815)
## 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.

(cherry picked from commit 46e8cd198c)
2025-07-02 16:41:15 -04:00
Nicholas Cunningham 144f120d6e fix(linter): refactor checking if the identifier is a function via tsquery (#31792)
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.

(cherry picked from commit 2c121f64f9)
2025-07-02 16:41:03 -04:00
Jason Jean 7bf1c0dfb2 feat(core): enhance native cache operations with comprehensive logging (#31652)
## 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.

(cherry picked from commit fca5650869)
2025-07-02 14:40:11 -04:00
Rares Matei f703ac2722 docs(nx-cloud): update release notes (#31802)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #

(cherry picked from commit 157a34ae40)
2025-07-02 14:40:10 -04:00
Chau Tran 6e79205a20 docs(misc): add info about Okta advanced configuration (#31791)
This is to make sure enterprises set the configuration required for our
saml integration

(cherry picked from commit bfdf892a0a)
2025-07-02 14:40:09 -04:00
Philip Fulcher 6c0a6ac65b docs(nx-dev): add CTAs for July 9 webinar (#31769)
(cherry picked from commit 2a10953c52)
2025-07-02 14:40:08 -04:00
Benjamin Cabanes c9eba1aad8 chore(core): replace hardcoded registry URLs with placeholder (#31789)
Updated tests to utilize the `customRegistryUrl` variable instead of hardcoded `http://localhost:7190` URLs, improving maintainability and flexibility.

(cherry picked from commit 487f8e6d42)
2025-07-02 14:40:07 -04:00
Jason Jean ea588ac7fd fix(core): allow any framework value in preset generator schema (#31665)
## 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>
(cherry picked from commit 784a14a5b0)
2025-07-02 14:40:07 -04:00
Benjamin Cabanes 5e93935269 feat(core): add CI warning for missing remote cache solution (#31678)
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.

(cherry picked from commit a73855c74e)
2025-07-02 14:40:00 -04:00
Nicholas Cunningham 9ecf381309 fix(node): reorder addPlugin in normalizeOptions return object (#31785)
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`.

(cherry picked from commit 8b3fc7fba0)
2025-07-02 14:39:59 -04:00
Nicholas Cunningham 0cfb128c0e fix(core): update nx to version 21.3.0-beta.0 (#31771)
Update nx repo package version

(cherry picked from commit f8a23eef96)
2025-07-02 14:39:58 -04:00
Nicholas Cunningham 2f03980c9b fix(core): resolve package.json for @nx/js to improve plugin detection (#31770)
This PR updates the package.json inferred target to resolve package.json
instead of the entry file.

(cherry picked from commit 7430238529)
2025-07-02 14:39:57 -04:00
Nicholas Cunningham cd6afb9ec6 chore(repo): update e2e nightly report adding more golden test and updating the report (#31752)
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                       |
```

(cherry picked from commit ad14f2f477)
2025-07-02 14:39:56 -04:00
Nicholas Cunningham e1a279ddfd fix(js): improve typescript plugin build detection (#31533)
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
(cherry picked from commit 9d5030b253)
2025-07-02 14:39:56 -04:00
Colum Ferry 5539dfc857 fix(storybook): handle hyphenated framework names in pnpm dependency installation (#31760)
## 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

(cherry picked from commit 47e1a9ce05)
2025-07-02 14:39:55 -04:00
Colum Ferry 474584e69c fix(vite): ensure vue-tsc is used for typecheck of vue projects (#31761)
## 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

(cherry picked from commit 4553748d8c)
2025-07-02 14:39:30 -04:00
Colum Ferry 5a3808b9d4 fix(bundling): respect decision to create babelrc file (#31755)
## 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

(cherry picked from commit cae6df7096)
2025-07-02 14:39:29 -04:00
Colum Ferry 6d976b679d fix(node): ensure args are set in target correctly (#31758)
## 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

(cherry picked from commit 3131f4aa29)
2025-07-02 14:39:20 -04:00
Leosvel Pérez Espinosa 58f357f060 fix(linter): update lint executor to always log errors and stack traces (#31757)
## 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

(cherry picked from commit 7651f6343e)
2025-07-02 14:39:19 -04:00
Leosvel Pérez Espinosa d60b15cd6b fix(angular): expand nx tokens in project configurations when running schematic migrations (#31526)
## 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

(cherry picked from commit 2d028f7ad5)
2025-07-02 14:39:18 -04:00
Leosvel Pérez Espinosa 2eea3e3433 fix(expo): respect --unit-test-runner=none properly when generating expo apps and libs (#31754)
## 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

(cherry picked from commit 6305922e32)
2025-07-02 14:39:18 -04:00
Leosvel Pérez Espinosa 4050e97147 fix(vite): ensure path aliases are not replaced when building vite projects and using ts path mappings (#31747)
## 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

(cherry picked from commit 99f38b8770)
2025-07-02 14:39:17 -04:00
Caleb Ukle bb52dad17a docs(nx-cloud): callout templates use nx-cloud features (#31733)
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>
(cherry picked from commit 07233f0e03)
2025-07-02 14:39:16 -04:00
Isaac Mann 122983db5e docs(core): webinar for july 9 2025 (#31751)
Add banner for July 9th webinar

(cherry picked from commit c8bad17bba)
2025-07-02 14:39:15 -04:00
Victor Savkin 0810952818 chore(nx-dev): update remote cache docs
(cherry picked from commit 4a666b7854)
2025-07-02 14:39:14 -04:00
Craigory Coppola d5f98f8431 feat(core): pass in progress task outputs to tui for non-direct child processes (#31655)
## 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>
(cherry picked from commit 402d946534)
2025-07-02 14:39:13 -04:00
Rares Matei d5bfc3afd0 docs(nx-cloud): update release notes (#31749)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #

(cherry picked from commit c7d2c77641)
2025-07-02 14:39:06 -04:00
Leosvel Pérez Espinosa 4c9541a925 fix(testing): unset customConditions when running the open-cypress inferred task (#31687)
## 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

(cherry picked from commit afb94afd7d)
2025-07-02 14:39:05 -04:00
Leosvel Pérez Espinosa 69a1e7c91a fix(testing): prefer using tsconfig.spec.json when loading jest config in plugin (#31726)
## 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

(cherry picked from commit 2daa73dd10)
2025-07-02 14:39:04 -04:00
Jack Hsu 5b1216c774 fix(linter): correct lintFilePatterns documentation to show it's optional (#31744)
- Updated documentation to clarify lintFilePatterns is optional
- Added default value information ['{projectRoot}']

Fixes #29648

(cherry picked from commit 948c985925)
2025-07-02 14:39:03 -04:00
Leosvel Pérez Espinosa 44c1feb604 fix(testing): do not re-add vscode recommended extension for jest after initial jest setup (#31745)
## 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

(cherry picked from commit 54b36a6da0)
2025-07-02 14:39:02 -04:00
Leosvel Pérez Espinosa dd1e9e1444 fix(core): improve error handling in daemon server (#31728)
## 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 #31407
Fixes #31567

(cherry picked from commit 768a11aee4)
2025-07-02 14:39:02 -04:00
Colum Ferry 1d61d4986f feat(bundling): add useLegacyTypescriptPlugin option to migrate from rollup-plugin-typescript2 (#31718)
## 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

(cherry picked from commit 836defed4a)
2025-07-02 14:39:01 -04:00
Jack Hsu 1b3d616a75 fix(angular): improve indexHtmlTransformer documentation (#31742)
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

(cherry picked from commit 35d5074dde)
2025-07-02 14:39:00 -04:00
Jack Hsu 371e968bf4 fix(testing): correct Playwright grep documentation from glob to regex (#31743)
- 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

(cherry picked from commit 57405e6a22)
2025-07-02 14:38:50 -04:00
Colum Ferry 617e485c3a fix(vite): resolve outDir path correctly for nested monorepos (#31741)
## 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

(cherry picked from commit eb03e22cb2)
2025-07-02 14:38:49 -04:00
Colum Ferry ffb3514c51 fix(react): add .js extensions to subpath imports in module federation templates (#31730)
## 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

(cherry picked from commit 71d60a910d)
2025-07-02 14:38:48 -04:00
Benjamin Cabanes e8c9e19c9e docs(nx-dev): update headers to reference "Nx Enterprise" (#31731)
Revised "Enterprise" references to "Nx Enterprise" across headers for consistency. Added a new link to "AI" in the documentation header.

(cherry picked from commit 110318291e)
2025-07-02 14:38:47 -04:00
Colum Ferry 81fa01f254 fix(angular): respect skipTsConfig option in library generator (#31738)
## 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

(cherry picked from commit babf86a456)
2025-07-02 14:38:47 -04:00
Colum Ferry efc95f716c fix(docs): add missing --project parameter to Angular service generation command (#31735)
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>
(cherry picked from commit 316c9cd651)
2025-07-02 14:38:46 -04:00
MaxKless 6e5f2f055c docs(nx-dev): write blog post about autofix notifications in JetBrains (#31666)
Co-authored-by: Juri Strumpflohner <juri.strumpflohner@gmail.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
(cherry picked from commit 03faab1ee7)
2025-07-02 14:38:45 -04:00
Colum Ferry cb49e139ff fix(module-federation): restore support for relative URLs in module federation remotes (#31723)
## 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

(cherry picked from commit 8b6ad42244)
2025-07-02 14:38:44 -04:00
Nicholas Cunningham 8f945ba969 feat(graph): enhance migration state management and introduce migration stopping functionality. (#31626)
## 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.

(cherry picked from commit 92e9133165)
2025-07-02 14:38:43 -04:00
Jason Jean 4451833d91 docs: clarify that gitignored files are excluded from inputs (#31594)
Add callout box to the inputs documentation explaining that .gitignored
files are automatically excluded from inputs and won't affect task hash
computation.

Fixes #31574

Generated with [Claude Code](https://claude.ai/code)

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jason Jean <FrozenPandaz@users.noreply.github.com>
(cherry picked from commit b7e73feb1d)
2025-07-02 14:38:42 -04:00
Jordan e21dc6e117 docs(core): add ThisDotLabs and Angular Architects to partners page (#31670)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->

<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #

(cherry picked from commit 39954181bc)
2025-07-02 14:38:36 -04:00
Leosvel Pérez Espinosa 2638481794 fix(vite): fix the build command for the deps in the vite tsconfig paths plugin (#31729)
## 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

(cherry picked from commit 08b8e717ba)
2025-07-02 14:38:36 -04:00
Isaac Mann cc5341f801 docs(core): remove june webinar
(cherry picked from commit e4694efeb8)
2025-07-02 14:38:35 -04:00
Colum Ferry 9f9d829447 fix(webpack): respect user config when applying node target #30937 (#31700)
## 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

(cherry picked from commit c706a4e89e)
2025-07-02 14:38:34 -04:00
Juri a72adf06d5 docs(nx-dev): add blog post about being able to query CI
(cherry picked from commit 25521f89ab)
2025-07-02 14:38:34 -04:00
Juri 74e77e18f2 fix(nx-dev): update sorting of pinned posts
(cherry picked from commit d347d976ad)
2025-07-02 14:38:33 -04:00
Philip Fulcher dccdb43ac7 docs(nx-dev): add creep vulnerability article (#31710)
(cherry picked from commit fe687a003c)
2025-07-02 14:38:32 -04:00
Philip Fulcher da3c468f98 docs(nx-dev): add polygraph launch article (#31696)
https://nx-dev-git-philip-polygraph-release-article-nrwl.vercel.app/blog/nx-cloud-introducing-polygraph

---------

Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
(cherry picked from commit c01d65e3f0)
2025-07-02 14:38:31 -04:00
Jack Hsu 9626975f6f fix(nextjs): use next/jest.js for Jest configuration to support modern JSX transform (#31705)
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

(cherry picked from commit 13da36e63e)
2025-07-02 14:38:30 -04:00
Jack Hsu 20a9819bbb docs(js): update tsconfig examples so extend from the root properly to remove confusion (#31707)
## 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

(cherry picked from commit 819abe9337)
2025-07-02 14:38:30 -04:00
Colum Ferry 66db0aa371 fix(nuxt): fix TypeScript configuration chain for Nuxt components and composables (#31701)
- 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>
(cherry picked from commit 52af4238eb)
2025-07-02 14:38:29 -04:00
Colum Ferry cb02022cab fix(module-federation): ensure manifest path not prepended with workspace root (#31698)
## 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

(cherry picked from commit 82ddc1abfc)
2025-07-02 14:38:28 -04:00
Julien Marcou 865abbc4b0 feat(module-federation): bump @module-federation/enhanced version to 0.15.0 to fix vulnerability (#30806)
## 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 #30502
Fixes #30748

---------

Co-authored-by: Colum Ferry <cferry09@gmail.com>
(cherry picked from commit 014d774bff)
2025-07-02 14:38:08 -04:00
Juri c747d3f172 fix(nx-dev): pinning logic on blog entry page
(cherry picked from commit ebb1716a99)
2025-07-02 14:38:08 -04:00
Caleb Ukle e0eabdd3cc docs(nx-cloud): initial polygraph docs (#31657)
add docs over polygraph features

https://nx-dev-git-docs-polygraph-nrwl.vercel.app/ci/recipes/enterprise/polygraph

---------

Co-authored-by: Mike Hartington <mhartington@users.noreply.github.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Mike Hartington <mikehartington@gmail.com>
(cherry picked from commit 0ef88573b2)
2025-07-02 14:38:07 -04:00
Benjamin Cabanes 4e82d0b055 docs(nx-dev): add Nx Labs page (#31679)
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.

(cherry picked from commit a74bbaf32c)
2025-07-02 14:38:06 -04:00
MaxKless c745c47434 chore(repo): add .cursor/mcp.json to gitignore (#31691)
people use it locally with different ports so we should just add it to
gitignore

(cherry picked from commit a8cd1c77e3)
2025-07-02 14:38:05 -04:00
Benjamin Cabanes f4309621ac docs(nx-dev): update ai page (#31669)
Co-authored-by: Juri <juri.strumpflohner@gmail.com>
(cherry picked from commit 4e55020b1b)
2025-07-02 14:38:04 -04:00
Juri d1b4bc93c4 docs(nx-dev): add self-healing CI blog post
(cherry picked from commit 755de341a4)
2025-07-02 14:38:03 -04:00
Jonathan Gelin b289708066 fix(js): resolve asset paths relative to workspace root instead of cwd (#31664)
## 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()`**.

(cherry picked from commit fd31fa633d)
2025-07-02 14:38:00 -04:00
Benjamin Cabanes 183f5ec3cf docs(nx-dev): fix typo (#31677)
Update callout type from 'warn' to 'warning' in CVE blog post.

(cherry picked from commit 8026885128)
2025-07-02 14:37:59 -04:00
Nicholas Cunningham c2e717c70e fix(js): failing e2e test due to dependency (#31676)
This PR updates our `e2e-js` test to include dependencies for all
package managers and not just pnpm.

E2E Matrix for `e2e-js` is now passing:
https://github.com/nrwl/nx/actions/runs/15786673606/job/44504580439

(cherry picked from commit df75799ed7)
2025-07-02 14:37:58 -04:00
Jack Hsu ee783b9670 docs(react): update tutorial for ESLint flat config format (#31672)
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>
(cherry picked from commit 1f493bf251)
2025-07-02 14:37:57 -04:00
Jack Hsu 9396d26768 docs(nextjs): fix incorrect build output path and vite.config.ts mention (#31671)
## 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>
(cherry picked from commit c452821bfa)
2025-07-02 14:37:57 -04:00
Benjamin Cabanes dcec1c81f9 docs(nx-dev): enhance AI feature descriptions & update links (#31659)
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.

(cherry picked from commit acae2eca89)
2025-07-02 14:37:56 -04:00
Jack Hsu a2eff633d3 fix(react): do not set styles.tailwind for executor options for projects not using inferred targets (#31667)
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.

(cherry picked from commit 55251ca0bf)
2025-07-02 14:37:55 -04:00
Leosvel Pérez Espinosa 23057601f6 cleanup(angular): set target version to v22 for the decorate cli script deprecation warning (#31170)
## 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 #

(cherry picked from commit 9e8c1a1062)
2025-07-02 14:37:55 -04:00
Leosvel Pérez Espinosa da2acf0be8 fix(testing): do not update component configuration in cypress set-inject-document-domain migration (#31614)
## 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

(cherry picked from commit 617b8d49cb)
2025-07-02 14:37:54 -04:00
Leosvel Pérez Espinosa 72e3ba7e3c fix(core): do not auto-exit tui when there are multiple failed tasks (#31631)
## 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.

(cherry picked from commit 6b2175bfcb)
2025-07-02 14:37:53 -04:00
Victor Savkin 550c7e37da fix(nx-dev): small adjustment to the blog post
(cherry picked from commit bd898d3220)
2025-07-02 14:37:53 -04:00
Juri f6baa75d4e docs(nx-dev): new blog post on how to use sync generators for Tailwind globs
(cherry picked from commit 9e9345b5e1)
2025-07-02 14:37:52 -04:00
James Henry 89ea1f6089 chore(repo): migrate to conformance v3 (#31475)
(cherry picked from commit 4c7586c82d)
2025-07-02 14:37:51 -04:00
Jack Hsu 56a75ba6a3 chore(repo): add raw-docs (#31640)
This PR adds `raw-docs` integration. See here for more details:
https://github.com/nrwl/raw-docs

(cherry picked from commit ec457f72df)
2025-07-02 14:37:50 -04:00
556 changed files with 15205 additions and 6344 deletions
+7
View File
@@ -0,0 +1,7 @@
{
"mcpServers": {
"nx-mcp": {
"url": "http://localhost:9470/sse"
}
}
}
+1 -1
View File
@@ -136,7 +136,7 @@ jobs:
permissions:
contents: read
runs-on: ${{ matrix.os }}
timeout-minutes: 150 # <- cap each job to 150 minutes
timeout-minutes: 200 # <- cap each job to 200 minutes
strategy:
matrix: ${{fromJson(needs.prepare-matrix.outputs.matrix)}} # Load matrix from previous job
fail-fast: false
+18 -18
View File
@@ -37,34 +37,34 @@ const matrixData: MatrixData = {
{ name: 'e2e-lerna-smoke-tests', codeowners: 'S04TNCVEETS', is_golden: true },
{ name: 'e2e-js', codeowners: 'S04SJ6HHP0X', is_golden: true },
{ name: 'e2e-nx-init', codeowners: 'S04SYHYKGNP', is_golden: true },
{ name: 'e2e-nx', codeowners: 'S04SYHYKGNP', is_golden: true },
{ name: 'e2e-release', codeowners: 'S04SYHYKGNP', is_golden: true },
{ name: 'e2e-workspace-create', codeowners: 'S04SYHYKGNP', is_golden: true },
{ name: 'e2e-nx', codeowners: 'S04SYHYKGNP' },
{ name: 'e2e-release', codeowners: 'S04SYHYKGNP'},
{ name: 'e2e-workspace-create', codeowners: 'S04SYHYKGNP' },
],
projects: [
{ name: 'e2e-cypress', codeowners: 'S04T16BTJJY', is_golden: true },
{ name: 'e2e-detox', codeowners: 'S04TNCNJG5N' , is_golden: true},
{ name: 'e2e-esbuild', codeowners: 'S04SJ6HHP0X' , is_golden: true},
{ name: 'e2e-gradle', codeowners: 'S04TNCNJG5N' , is_golden: true},
{ name: 'e2e-eslint', codeowners: 'S04SYJGKSCT', is_golden: true },
{ name: 'e2e-node', codeowners: 'S04SJ6HHP0X', is_golden: true },
{ name: 'e2e-playwright', codeowners: 'S04SVQ8H0G5', is_golden: true },
{ name: 'e2e-remix', codeowners: 'S04SVQ8H0G5' , is_golden: true},
{ name: 'e2e-rspack', codeowners: 'S04SJ6HHP0X', is_golden: true },
{ name: 'e2e-vite', codeowners: 'S04SJ6PL98X' , is_golden: true},
{ name: 'e2e-vue', codeowners: 'S04SJ6PL98X' , is_golden: true},
{ name: 'e2e-web', codeowners: 'S04SJ6PL98X', is_golden: true },
{ name: 'e2e-webpack', codeowners: 'S04SJ6PL98X', is_golden: true },
{ name: 'e2e-jest', codeowners: 'S04T16BTJJY', is_golden: true },
{ name: 'e2e-angular', codeowners: 'S04SS457V38' },
{ name: 'e2e-cypress', codeowners: 'S04T16BTJJY' },
{ name: 'e2e-detox', codeowners: 'S04TNCNJG5N' },
{ name: 'e2e-esbuild', codeowners: 'S04SJ6HHP0X' },
{ name: 'e2e-expo', codeowners: 'S04TNCNJG5N' },
{ name: 'e2e-gradle', codeowners: 'S04TNCNJG5N' },
{ name: 'e2e-jest', codeowners: 'S04T16BTJJY' },
{ name: 'e2e-eslint', codeowners: 'S04SYJGKSCT' },
{ name: 'e2e-next', codeowners: 'S04TNCNJG5N' },
{ name: 'e2e-node', codeowners: 'S04SJ6HHP0X' },
{ name: 'e2e-plugin', codeowners: 'S04SYHYKGNP' },
{ name: 'e2e-react', codeowners: 'S04TNCNJG5N' },
{ name: 'e2e-react-native', codeowners: 'S04TNCNJG5N' },
{ name: 'e2e-web', codeowners: 'S04SJ6PL98X' },
{ name: 'e2e-rollup', codeowners: 'S04SJ6PL98X' },
{ name: 'e2e-storybook', codeowners: 'S04SVQ8H0G5' },
{ name: 'e2e-playwright', codeowners: 'S04SVQ8H0G5' },
{ name: 'e2e-remix', codeowners: 'S04SVQ8H0G5' },
{ name: 'e2e-rspack', codeowners: 'S04SJ6HHP0X' },
{ name: 'e2e-vite', codeowners: 'S04SJ6PL98X' },
{ name: 'e2e-vue', codeowners: 'S04SJ6PL98X' },
{ name: 'e2e-nuxt', codeowners: 'S04SJ6PL98X' },
{ name: 'e2e-webpack', codeowners: 'S04SJ6PL98X' }
{ name: 'e2e-nuxt', codeowners: 'S04SJ6PL98X' }
],
nodeTLS: 20,
setup: [
+44 -27
View File
@@ -30,51 +30,68 @@ function humanizeDuration(num: number): string {
}
function processResults(combined: MatrixResult[]): ProcessedResults {
const failedProjects = combined.filter(c => c.status === 'failure').sort((a, b) => a.project.localeCompare(b.project));
const failedProjects = combined.filter(c => c.status === 'failure' || c.status === 'cancelled').sort((a, b) => a.project.localeCompare(b.project));
const failedGoldenProjects = failedProjects.filter(c => c.is_golden);
const hasGoldenFailures = failedGoldenProjects.length > 0;
const codeowners = new Set<string>();
failedGoldenProjects.forEach(c => codeowners.add(c.codeowners));
let result = '';
let lastProject: string | undefined;
const allGoldenProjects = combined.filter(c => c.is_golden);
const uniqueGoldenProjects = new Set(allGoldenProjects.map(c => c.project));
const uniqueFailedGoldenProjects = new Set(failedGoldenProjects.map(c => c.project));
const goldenPassingCount = uniqueGoldenProjects.size - uniqueFailedGoldenProjects.size;
const goldenFailingCount = uniqueFailedGoldenProjects.size;
const allOtherProjects = combined.filter(c => !c.is_golden);
const uniqueOtherProjects = new Set(allOtherProjects.map(c => c.project));
const failedRegularProjects = failedProjects.filter(c => !c.is_golden);
const uniqueFailedOtherProjects = new Set(failedRegularProjects.map(c => c.project));
const otherPassingCount = uniqueOtherProjects.size - uniqueFailedOtherProjects.size;
const otherFailingCount = uniqueFailedOtherProjects.size;
result += `\n🌟 *Golden Projects*`;
result += `\n✅ Passing: ${goldenPassingCount}`;
result += `\n❌ Failing: ${goldenFailingCount}`;
if (failedGoldenProjects.length > 0) {
result += `
🔥 **Golden Test Failures (${failedGoldenProjects.length})**
\`\`\`
| Failed project | PM | OS | Node |
|--------------------------------|------|-------|----------|`;
lastProject = undefined;
result += `\n\n🚨 *Failed Golden Projects*\n\`\`\``;
result += `\n| Failed project |`;
result += `\n|--------------------------------|`;
let lastProject: string | undefined;
failedGoldenProjects.forEach(matrix => {
const project = matrix.project !== lastProject ? matrix.project : '...';
result += `\n| ${project.padEnd(30)} | ${matrix.package_manager.padEnd(4)} | ${matrix.os_name.padEnd(5)} | v${matrix.node_version.toString().padEnd(7)} |`;
lastProject = matrix.project;
const project = matrix.project !== lastProject ? matrix.project : '';
if (project) {
result += `\n| ${project.padEnd(30)} |`;
lastProject = matrix.project;
}
});
result += `\`\`\``;
} else {
result += '\n✅ **Golden Tests: All Passed!**';
result += `\n\`\`\``;
}
const failedRegularProjects = failedProjects.filter(c => !c.is_golden);
result += `\n\n🔧 *Other Projects*`;
result += `\n✅ Passing: ${otherPassingCount}`;
result += `\n❌ Failing: ${otherFailingCount}`;
// Failed Other Projects Table (if any)
if (failedRegularProjects.length > 0) {
if (failedGoldenProjects.length > 0 || result.length > 0) result += '\n\n';
result += `
📋 **Other Project Failures (${failedRegularProjects.length})**
\`\`\`
| Failed project | PM | OS | Node |
|--------------------------------|------|-------|----------|`;
lastProject = undefined;
result += `\n\n⚠️ *Failed Other Projects*\n\`\`\``;
result += `\n| Failed project |`;
result += `\n|--------------------------------|`;
let lastProject: string | undefined;
failedRegularProjects.forEach(matrix => {
const project = matrix.project !== lastProject ? matrix.project : '...';
result += `\n| ${project.padEnd(30)} | ${matrix.package_manager.padEnd(4)} | ${matrix.os_name.padEnd(5)} | v${matrix.node_version.toString().padEnd(7)} |`;
lastProject = matrix.project;
const project = matrix.project !== lastProject ? matrix.project : '';
if (project) {
result += `\n| ${project.padEnd(30)} |`;
lastProject = matrix.project;
}
});
result += `\`\`\``;
result += `\n\`\`\``;
}
if (failedProjects.length === 0) {
result = '✅ **No test failures detected!**';
result = '🎉 *No test failures detected!* All systems green! 🟢';
}
const timeReport: Record<string, { min: number; max: number; minEnv: string; maxEnv: string }> = {};
+6 -1
View File
@@ -75,6 +75,7 @@ storybook-static
.claude/settings.local.json
.cursor/rules/nx-rules.mdc
.cursor/mcp.json
.github/instructions/nx.instructions.md
# Added by Claude Task Master
@@ -101,4 +102,8 @@ node_modules/
# OS specific
# Task files
tasks.json
tasks/
tasks/
# Upstream docs local configuration (machine-specific)
.upstreamdocs.local.json
+10
View File
@@ -0,0 +1,10 @@
{
"include": ["apps/**/*", "libs/**/*", "packages/**/*"],
"exclude": [
"**/*.spec.*",
"**/test/**/*",
"**/__tests__/**/*",
"**/*.test.*",
"node_modules/**/*"
]
}
+2
View File
@@ -177,6 +177,8 @@ 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
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/RNilYmJJzdk
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/V2W94Sq_v6A
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/dRQq_B1HSLA
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
@@ -16,6 +16,9 @@ description: 'Explore how Nx monorepos amplify AI benefits by providing complete
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
+3
View File
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/fPqPh4h8RJg
- **Save Time: Connecting Your Editor, CI and LLMs**
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
-1
View File
@@ -6,7 +6,6 @@ tags: ['nx', 'release']
cover_image: /blog/images/2025-05-05/header.avif
description: 'Discover the latest in Nx 21, featuring continuous tasks and the new Terminal UI'
youtubeUrl: https://youtu.be/9zsncTxfcl4
pinned: true
---
{% callout type="deepdive" title="Nx 21 Launch Week" expanded=true %}
@@ -17,6 +17,9 @@ youtubeUrl: https://youtu.be/PXNjedYhZDs
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- **Enhancing Nx Generators with AI: Predictability Meets Intelligence**
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
@@ -5,7 +5,7 @@ authors: ['Victor Savkin']
tags: ['ai', 'development', 'productivity', 'best-practices']
cover_image: /blog/images/articles/bg-practical-ai-guide-part-1.avif
description: 'Learn how to effectively use AI coding assistants beyond simple prompts. Discover proven workflows, best practices, and strategies that transform AI from a novelty into a powerful development multiplier.'
pinned: true
pinned: false
---
> _"Tools amplify your talent. The better your skills, the better the tools serve you."_ — Andrew Hunt, The Pragmatic Programmer
@@ -6,7 +6,7 @@ tags: ['nx', 'nx-console', 'ai', 'terminal']
cover_image: /blog/images/articles/bg-nx-tui-llm-integration.avif
description: 'Learn how Nx Console now enables AI assistants to read your terminal output in real-time, automatically detecting and fixing development errors as they happen.'
youtubeUrl: https://youtu.be/Cbc9_W5J6DA
pinned: true
pinned: false
---
{% callout type="deepdive" title="Series: Making your LLM smarter" expanded=true %}
@@ -18,6 +18,9 @@ pinned: true
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- **Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing**
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
@@ -4,7 +4,6 @@ slug: cve-2025-36852-critical-cache-poisoning-vulnerability-creep
authors: ['Victor Savkin']
tags: ['caching', 'security']
cover_image: /blog/images/2025-06-12/header.avif
pinned: true
description: 'A critical security vulnerability called CREEP (Cache Race-condition Exploit Enables Poisoning) has been published as CVE-2025-36852. This vulnerability affects remote cache plugins across numerous build systems, including Nx.'
---
@@ -18,6 +17,12 @@ The CREEP vulnerability allows any contributor with pull request privileges to i
- Nx Cloud is **NOT** affected due to its security architecture
- Review this post to determine if your self-hosted cache solution is vulnerable
{% callout type="warning" title="DIY implementations are vulnerable" %}
DIY remote caches are likely vulnerable. Scanners won't catch all affected implementations, so understanding the vulnerability is crucial.
{% /callout %}
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4kkSHiy" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
## **Understanding the Vulnerability**
A typical remote-cache flow using storage services follows these steps:
@@ -93,5 +98,8 @@ CVE-2025-36852 represents a serious threat to organizations using vulnerable cac
- If your organization uses bucket-based remote caching: immediate action is required
- If your organization uses other self-hosted remote cache solutions: immediate review required (most self-hosted caching solutions across many build systems—not just JavaScript, but also Java—are affected)
- If your organization uses custom tasks runners to implement remote caching: immediate review required
- If using Nx without remote caching: no action is required
- If using Nx with Nx Cloud: [Review your settings](/ci/concepts/cache-security#use-scoped-tokens-in-ci). If you are using default settings, no actions should be required.
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4npF0BA" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
@@ -9,7 +9,7 @@ authors: ['James Henry']
tags: [webinar]
cover_image: /blog/images/2025-06-18/June-2025-Webinar-Card.avif
time: 10am ET/2pm UTC
status: Upcoming
status: Past - Gated
registrationUrl: https://go.nx.dev/june2025-webinar
---
@@ -21,4 +21,4 @@ Join us for a demo of the new polygraph features in Nx Cloud, launching this mon
These features are designed to extend some of the powerful benefits of an Nx workspace to multi-workspace environments and take Nx Cloud beyond CI. We'll cover our updated conformance dashboard, how to visualize dependencies across your repos, the new onboarding experience for workspaces that arent yet a part of Nx Cloud, and preview how Nx Cloud will be able to fix your code automatically via agentic AI.
{% call-to-action title="Register today!" url="https://go.nx.dev/june2025-webinar" description="Save your spot" /%}
{% call-to-action title="Download the recording" url="https://go.nx.dev/june2025-webinar" description="Sign up to gain access" /%}
@@ -0,0 +1,238 @@
---
title: 'Configure Tailwind 4 with Vite in an NPM Workspace: The Complete Guide'
slug: setup-tailwind-4-npm-workspace
authors: ['Juri Strumpflohner']
tags: ['nx', 'tailwind', 'vite', 'npm-workspaces', 'sync-generators']
cover_image: /blog/images/articles/bg-tailwind-4-guide.avif
description: 'Learn how to set up Tailwind CSS v4 with Vite in an NPM workspace monorepo, and automate your configuration with Nx Sync Generators for optimal performance.'
youtubeUrl: https://youtu.be/tg3LnqhNNws
---
Tailwind CSS v4 brings revolutionary changes to how we configure and use the popular utility-first framework. The simplified setup eliminates configuration files and complex PostCSS setups - you just install, import, and start building. But when working in NPM workspaces or monorepos, there's still one crucial challenge: **how do you tell Tailwind which packages to scan for classes?**
This guide walks you through setting up Tailwind v4 with Vite in an NPM workspace, then shows you how to automate the configuration using Nx Sync Generators to **eliminate manual maintenance**.
{% github-repository url="https://github.com/juristr/tailwind4-vite-npm-workspaces" /%}
{% toc /%}
## Setting up Tailwind v4
[Tailwind v4](https://tailwindcss.com/blog/tailwindcss-v4) introduced some nice simplifications when it comes to configuring Tailwind:
- **No more `tailwind.config.js`** - The framework works out of the box
- **Minimal dependencies** - Just `tailwindcss` and `@tailwindcss/vite` for Vite projects
- **Simple CSS import** - Add `@import "tailwindcss"` to your stylesheet and you're ready
Since we're using Vite in this workspace, we can leverage the dedicated Tailwind Vite plugin instead of PostCSS configuration. Here's what you need:
Install the required packages at your workspace root:
```json {% fileName="package.json" %}
{
"devDependencies": {
"tailwindcss": "^4.0.0",
"@tailwindcss/vite": "^4.0.0"
}
}
```
Configure your Vite setup:
```typescript {% fileName="apps/shop/vite.config.ts" %}
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import tailwindcss from '@tailwindcss/vite';
export default defineConfig({
plugins: [react(), tailwindcss()],
// ... rest of your config
});
```
Add the import to your main CSS file:
```css {% fileName="apps/shop/src/styles.css" %}
@import 'tailwindcss';
```
## The NPM workspace challenge
Consider a typical e-commerce application structured as an NPM workspace:
```plain
apps/
shop/
src <<<< where tailwind is configured
packages/
products/
feat-product-list/
feat-product-detail/
data-access-products/
shared/
ui/
utils/
```
At this point, your application will build and serve, but you'll notice that styles from your `packages/` are missing. In this modular setup, your main application (`shop`) depends on various feature packages, but **Tailwind only scans the main app by default**. This means styles defined in your packages won't be included in the final bundle, leading to missing styles and broken layouts.
## Solving the scanning problem with @source directives
Tailwind v4 introduces the `@source` directive to address exactly this problem. You can explicitly tell Tailwind which directories to scan by adding these directives to your CSS file:
```css {% fileName="apps/shop/src/styles.css" %}
@import 'tailwindcss';
@source "../../../packages/products/feat-product-list";
@source "../../../packages/products/feat-product-detail";
@source "../../../packages/shared/ui";
...
```
With these directives in place, Tailwind will scan the specified packages and include any utility classes found there. Your application styles will now work correctly across all packages.
## Automating @source entries - enter Nx sync generators
While `@source` directives solve the technical problem, they introduce a maintenance challenge:
- **manual updates required** when adding or removing dependencies,
- **easy to forget updating** the directives,
- **hard-to-debug issues** since missing styles don't break builds (just cause visual problems), and
- **team coordination** since every developer needs to remember to update these paths.
This is where automation becomes crucial and where Nx can help. [Nx Sync Generators](/concepts/sync-generators) provide a powerful solution for **automating configuration that needs to stay in sync with your project structure**.
For our specific use case we can automate the generation of the `@source` directives by
- analyzing and traversing all of the `shop` application's dependencies (leveraging the [Nx project graph](/features/explore-graph))
- generating the `@source` entries into the correct `styles.css` file
You can follow [the guide on the Nx docs](/extending-nx/recipes/create-sync-generator) for all the details on how to implement your own Nx sync generator. At a high level these are the steps you'll need:
**Step 1: Add Nx Plugin development support**
```shell
npx nx add @nx/plugin
```
**Step 2: Generate a new plugin into your workspace**
```shell
npx nx g @nx/plugin:plugin tools/tailwind-sync-plugin
```
Note, you can choose whatever folder you like. I happen to use the `tools/` folder for this example.
**Step 3: Generate a sync generator**
```shell
npx nx g @nx/plugin:generator --name=update-tailwind-globs --path=tools/tailwind-sync-plugin/src/generators/update-tailwind-globs
```
With that you have the infrastructure in place and we can look at the actual implementation of the sync generator:
```typescript
import { Tree, createProjectGraphAsync, joinPathFragments } from '@nx/devkit';
import { SyncGeneratorResult } from 'nx/src/utils/sync-generators';
export async function updateTailwindGlobsGenerator(
tree: Tree
): Promise<SyncGeneratorResult> {
const appName = '@aishop/shop';
const projectGraph = await createProjectGraphAsync();
// Traverse all dependencies of the shop app
const dependencies = new Set<string>();
const queue = [appName];
const visited = new Set<string>();
while (queue.length > 0) {
const current = queue.shift()!;
if (visited.has(current)) continue;
visited.add(current);
const deps = projectGraph.dependencies[current] || [];
deps.forEach((dep) => {
dependencies.add(dep.target);
queue.push(dep.target);
});
}
// Generate @source directives for each dependency
const sourceDirectives: string[] = [];
dependencies.forEach((dep) => {
const project = projectGraph.nodes[dep];
if (project && project.data.root) {
const relativePath = joinPathFragments('../../../', project.data.root);
sourceDirectives.push(`@source "${relativePath}";`);
}
});
// Update the styles.css file
const stylesPath = 'apps/shop/src/styles.css';
const currentContent = tree.read(stylesPath)?.toString() || '';
// Insert the @source directives after @import "tailwindcss"
// ... (implementation details)
return {
outOfSyncMessage: 'Tailwind @source directives updated',
};
}
```
_(Check out the [Github repo for the full implementation](https://github.com/juristr/tailwind4-vite-npm-workspaces))_
You can manually run sync generators with `nx sync`, but we want this to run automatically whenever we build or serve our application. As such we can register the sync generator in the app's `package.json`:
```json {% fileName="apps/shop/package.json" %}
{
"name": "@aishop/shop",
...
"nx": {
"targets": {
"build": {
"syncGenerators": ["@aishop/tailwind-sync-plugin:update-tailwind-globs"]
},
"serve": {
"syncGenerators": ["@aishop/tailwind-sync-plugin:update-tailwind-globs"]
}
}
}
}
```
## Nx sync generators in action
When you run your development server with `nx serve shop`, the sync generator automatically checks if your `@source` directives are up to date:
![Tailwind Nx sync generator in action](/blog/images/articles/tailwind-sync-generator.avif)
Your CSS file is automatically updated with the correct directives based on your actual project dependencies. If you add or remove dependencies later, the next build or serve will **detect the changes and update the configuration automatically**.
You can find the complete implementation in this [GitHub repository](https://github.com/juristr/tailwind4-vite-npm-workspaces).
## Using Tailwind v3?
If you're currently using Tailwind v3, the concept is similar but the implementation differs. Instead of updating `@source` directives, you'd modify the `tailwind.config.js` file with glob patterns.
Check out the following video which explains the same approach for Tailwind v3:
{% youtube src="https://www.youtube.com/watch?v=huTmV-F8c0A" title="Optimizing Tailwind with Nx Sync Generators (v3)" /%}
The [Tailwind v3 demo repository](https://github.com/juristr/tailwind-sync-demo) shows how to implement this approach for older versions.
## Conclusion
While Tailwind v4's simplified setup is a significant improvement, manually maintaining `@source` directives creates a maintenance burden in monorepos. Nx Sync Generators solve this by automatically keeping your Tailwind configuration in sync with your project dependencies, eliminating manual updates and preventing hard-to-debug styling issues.
This approach transforms configuration maintenance into a completely automated process, letting you focus on building features rather than managing paths.
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩‍💻 [Tailwind v4 Vite NPM Workspace Demo](https://github.com/juristr/tailwind4-vite-npm-workspaces)
- 📖 [Nx Sync Generators Documentation](/extending-nx/recipes/create-sync-generator)
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
- 🐦 [Follow me on Twitter/X](https://twitter.com/juristr)
+195
View File
@@ -0,0 +1,195 @@
---
title: 'Introducing Self-Healing CI for Nx and Nx Cloud'
slug: nx-self-healing-ci
authors: ['Juri Strumpflohner']
tags: ['nx', 'nx-cloud', 'ai', 'ci']
cover_image: /blog/images/articles/thumb-self-healing-ci.avif
description: 'Introducing Nx Cloud Self-Healing CI: AI agents that automatically detect, analyze, and fix your CI failures so you do not have to babysit PRs.'
youtubeUrl: https://youtu.be/JW5Ki3PkRWA
pinned: true
---
{% callout type="deepdive" title="Series: Making your LLM smarter" %}
- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
- [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
- [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- **Introducing Self-Healing CI for Nx and Nx Cloud**
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
At Nx, we've always focused on making CI faster in two ways: **speeding up your actual builds** with techniques like remote caching and distributed execution, and **accelerating your feedback cycles** by eliminating the delays that waste developer time. The end-goal: **optimizing time to green**.
But what if we could bring this to the next level? **What if your CI could fix itself?** You push a PR with an error, an AI agent automatically identifies the problem, implements the fix, validates it works, and pushes the solution back to your PR?
**Nx Cloud Self-Healing CI** makes this a reality.
{% toc /%}
## Here's what happens now
Picture this: It's 2 PM on a Tuesday. You've been deep in feature development for the past hour when you get a notification in VS Code:
![Notification in your editor about an AI fix](/blog/images/articles/notification-self-healing-ci.avif)
You click the notification, review the one-line import addition, and approve it. Thirty seconds later:
![Nx Console view of the automated fix that has been applied to your PR](/blog/images/articles/nx-console-self-healing-fix-applied.avif)
> ✅ **Fix applied! Your PR is now passing CI**
You never left your editor. Never analyzed error logs. Never manually debugged the issue. Just a quick review and approval, then back to your feature work.
This is Self-Healing CI in action.
## The problem: "babysitting" your PRs
Every developer knows this workflow:
1. **Push your code** and continue working on something else
2. **CI fails** with a simple error (missing import, linting issue, test assertion)
3. **You don't notice for 30+ minutes** because you're focused on other work
4. **Context switch** back to analyze the error and implement a fix
5. **Push the fix** and wait another 5-10 minutes for CI to complete
6. **Repeat** if there are more issues
This "babysitting" wastes countless hours across development teams. The critical waste happens in **step 3**: the delay between failure and awareness.
One big issue is already being handled: **[flaky tasks](/ci/features/flaky-tasks)**. When tests fail intermittently (same code, different results), the system retries them on different agents with zero human intervention.
**The missing piece:** What about **genuine failures**? Real bugs, configuration errors, and dependency issues that need actual code fixes. These can't be solved with retries—they need intelligent analysis and solutions.
**Enter Self-Healing CI.** It tackles failures that need real fixes, providing AI-powered analysis, fix generation, and validation. You stay in control with quick review and approval, while the AI handles the heavy lifting. Combined with flaky task detection, you now have a comprehensive system that handles every type of CI failure—so you can stay focused on building features instead of babysitting PRs.
## How Self-Healing CI works
Here's what happens when you push a PR with Self-Healing CI enabled:
![Self-Healing CI Workflow](/blog/images/articles/self-healing-flow.avif)
1. **You push your PR** - Nothing changes in your workflow
2. **Failure detected** - If tasks fail, instead of just reporting the failure, Nx Cloud starts an AI agent
3. **AI agent analyzes** - The agent examines the error logs, understands your codebase structure through Nx's project graph, and identifies the root cause
4. **Fix proposed** - The agent creates a fix and presents it to you via Nx Console or the integrated GitHub application (e.g. a comment on your GitHub PR)
5. **Validation runs in parallel** - Meanwhile, the agent validates the fix by re-running the originally failed tasks with the proposed changes
6. **Human review and approval** - You can approve the fix immediately if it looks good, or wait for validation to complete for extra confidence
7. **Automatic PR update** - Once you approve, the fix gets committed to your PR as a new commit by the AI agent
8. **Full CI re-run** - Your complete CI pipeline runs again with the applied fix
**You stay in control while the AI does the heavy lifting.** The AI acts like a peer programmer, handling the time-consuming work of analyzing failures, creating fixes, and validating solutions in the background while you continue working on other tasks. You remain in the loop throughout the process. The AI doesn't make changes autonomously, but rather proposes working fixes for your review and approval before they're applied to your PR.
The AI agent is successful at providing meaningful fixes because it **combines the context from Nx and Nx Cloud:**
- it has the complete failure context with the exact tasks that ran, including error logs
- thanks to the Nx graph, it has vast context about the codebase, including project structure, dependencies, configuration and runnable tasks
- combining the two, it can validate a fix by re-running the original CI checks
## Getting started with Self-Healing CI
To enable Self-Healing CI on your workspace:
### 1. Connect Nx Cloud
If you haven't already connected to Nx Cloud:
```shell
npx nx connect
```
You can [start with the free Hobby plan](/pricing) and play around with the new AI features.
Once connected, enable AI features in your [Nx Cloud dashboard](https://nx.app):
1. **Organization Settings**: Enable AI features (required for all AI-powered functionality)
2. **Workspace Settings**: Find the "Self-Healing CI" section and toggle it on (available for all Nx Cloud plans)
![Nx Cloud workspace setting to enable Self-Healing CI](/blog/images/articles/self-healing-ci-setting.avif)
### 2. Configure Your CI Pipeline
If you're using Nx Agents, Self-Healing CI is automatically enabled. Here's an example GitHub Actions configuration with Nx Agents:
```yaml
name: CI
...
jobs:
main:
runs-on: ubuntu-latest
steps:
...
- run: npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" --stop-agents-after="build"
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- run: npm ci
- uses: nrwl/nx-set-shas@v4
- run: npx nx affected -t lint test build
```
If you're not using Nx Agents yet, you can still enable Self-Healing CI by adding the `fix-ci` step to your pipeline. **Important**: This step must run at the end with `if: always()` to ensure it executes even when previous steps fail (which is exactly when you need the fix):
```yaml
name: CI
...
jobs:
main:
runs-on: ubuntu-latest
steps:
...
- run: npm ci
- uses: nrwl/nx-set-shas@v4
- run: npx nx affected -t lint test build
- run: npx nx-cloud fix-ci
if: always()
```
### 3. Install Nx Console
To receive notifications about self-healing activities directly in your editor and enable the full AI integration experience, you need [Nx Console](/getting-started/editor-setup) installed for VS Code, Cursor, or IntelliJ.
For the complete AI setup guide, see our [AI integration documentation](/getting-started/ai-integration).
## Wrapping up
Self-Healing CI completes Nx Cloud's comprehensive approach to eliminating CI friction. Combined with our existing flaky task detection and automatic retries, we now have a unified system that handles every type of CI failure automatically: flaky tests get retried transparently, genuine bugs get fixed intelligently. No more "babysitting" your PRs. The system handles the tedious work so you can stay focused on building features.
**Key takeaways:**
- **Eliminates wasted time**: No more 30-minute delays between CI failure and awareness, no more manual debugging of simple errors
- **Leverages Nx's deep context**: AI agents understand your workspace structure, project relationships, and build configurations through Nx's project graph
- **You stay in control**: Proposed fixes are presented for your review and approval—the AI doesn't make autonomous changes
- **Built on proven infrastructure**: Uses the same robust Nx Cloud infrastructure that powers distributed task execution
- **Part of a broader vision**: Continues our mission to optimize "time to green" and eliminate developer workflow friction
**Ready to try it?** Self-Healing CI is rolling out as an early access feature and is available to everyone right now—no special approval or signup required. If you don't have an Nx Cloud account yet, you can quickly [start with the Hobby plan](/pricing), connect your workspace with `npx nx connect`, and get going immediately.
**For enterprise teams:** If you're already using Nx Cloud and want to learn more about how AI features like Self-Healing CI can enhance your existing setup, [reach out to us](/contact). We'd love to help you leverage these capabilities in your organization.
---
Learn more:
- 🧠 [Nx AI Docs](/features/enhance-AI)
- 🌩️ [Nx Cloud](/nx-cloud)
- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
- 👩‍💻 [Nx Console GitHub](https://github.com/nrwl/nx-console)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
@@ -0,0 +1,110 @@
---
title: 'Nx Cloud Release: Introducing Polygraph'
slug: nx-cloud-introducing-polygraph
authors: ['Philip Fulcher']
tags: ['nx-cloud', 'release']
cover_image: /blog/images/2025-06-24/header.avif
description: 'Discover Polygraph for Nx Cloud: Gain organization-wide visibility, enforce coding standards, and automate workflows across all your repositories, even those not using Nx. Learn how Polygraph empowers enterprise teams with proactive architecture management and automated consistency.'
youtubeUrl: https://youtu.be/BA_nkErlQoE
pinned: true
---
The monorepo approach has proven to be a powerful solution for managing applications and libraries within a single repository. It gives you visibility into the dependency graph of your projects, central management of tooling, and consolidated enforcement of organizational standards. But that visibility and management end at the boundaries of that repo. What if it didn't have to? That's why were excited to announce **Polygraph** for **Nx Cloud**. Polygraph brings the power of monorepo-level visibility and efficiency to your entire organization.
{% toc /%}
## The Reality of Enterprise Development
Let's be honest about how organizations _actually_ work. You might have a single Nx workspace—a monorepo with your applications and related libraries. It works beautifully, and you're happy with the developer experience and architectural clarity it provides.
But it's unrealistic to expect an entire organization to collapse into one massive monorepo. You probably have a design system in its own repository because it's used across multiple applications. You have legacy applications that were built before your current architecture standards. There's an authentication client library that lives in its own repo, microservice backends, and different teams working on different applications with their own repositories.
This is completely normal! Google and Facebook might operate with one repository for everything, but you're not Google or Facebook. Most organizations end up with a vast menagerie of repositories, and the challenge becomes managing all of them. You can easily enforce coding standards, tool configurations, and best practices within a single repository, but ensuring consistency across dozens or even hundreds of repositories becomes a manual, error-prone process.
## The Problem: Visibility and Consistency Across Repositories
The unfortunate downsides to scaling an organization are:
- **You lose architectural visibility** - Within your monorepo, you can see exactly how your application depends on your libraries, how different teams' code connects, and what the impact of changes will be. But once you step outside that repository boundary, you're flying blind.
- **Standards become inconsistent** - Coding standards and tool configurations become harder and harder to enforce as your organization grows. You're left to manually check and track compliance which leads to inconsistency.
- **Dependencies become invisible** - You know your frontend application depends on your design system because it downloads it from npm, but that relationship is completely opaque until something breaks.
The result? Teams end up maintaining spreadsheets to track dependencies, writing documentation that's always out of date, and being forced to react to problems as they emerge.
## Introducing Polygraph
Polygraph is a suite of tools built to help large organizations see across repos and enforce organizational standards. Currently, Polygraph has three core capabilities, extending the benefits you get from Nx monorepos to your entire organization. **It even works on repos that dont use Nx.**
### Workspace Graph
![Screenshot of workspace graph in Nx Cloud](/blog/images/2025-06-24/workspace-graph.avif)
[**Workspace graph**](/ci/recipes/enterprise/polygraph#workspace-graph) visualizes dependencies between all workspaces and repos, **even repos that dont use Nx**. Instead of managing repos in isolation, you can easily see the connections between repos and understand your organizational code structure at a glance.
This visibility helps you:
- **Understand impact before making changes** - When proposing a change in one part of the organization, quickly identify what other parts will be affected.
- **Plan architectural decisions with full context** - Make informed decisions about refactoring, migrations, and new feature development.
- **Improve team coordination** - Teams can see how their work connects to and impacts other teams' projects.
### Conformance: Enforce Standards Across Your Organization
![Screenshot of conformance rules in Nx Cloud](/blog/images/2025-06-24/conformance-rule-results-table.avif)
[**Conformance rules**](/ci/recipes/enterprise/polygraph#conformance) allow you to write language-agnostic rules that apply across all workspaces in your organization. This goes beyond what you can achieve with individual repository tooling—now you can enforce consistency at the organizational level.
Platform teams can easily publish and enforce coding standards across an entire organization. They can write and publish rules and then quickly apply them across all repos without requiring work from individual teams. **A single platform engineer can drive standards across the entire organization with one tool.**
For instance, you might create a conformance rule that ensures all repositories use ESLint version 9.0. This rule is published to Nx Cloud and can be configured to automatically run across your entire organization, providing centralized reporting on compliance without requiring any local configuration changes.
The power of organizational conformance rules extends to:
- **Security vulnerability management** - Ensure security issues are addressed consistently across all repositories.
- **Dependency management** - Keep third-party dependencies up to date across your entire tech stack.
- **Tool standardization** - Maintain consistent tooling configurations without manual coordination.
### Custom Workflows: Automation Beyond CI
![Screenshot of custom workflows in Nx Cloud](/blog/images/2025-06-24/custom-workflow-repeating-workflows.avif)
[**Custom Workflows**](/ci/recipes/enterprise/polygraph#custom-workflows) enable you to run scheduled tasks, extending automation capabilities beyond traditional CI pipelines. This allows you to run conformance rules and other organizational processes even on repositories that don't use Nx locally. You can run conformance rules to enforce standards, but you can also run data collection tools to make sure youre always up to date with the latest information from repos across your organization. These workflows are separate from CI and language ecosystems, so you can run tasks across any repo in your organization, no matter what language or tool it uses.
This means you can:
- **Apply standards to any repository** - Even legacy codebases, that can't be easily migrated to Nx, can benefit from organizational conformance rules.
- **Schedule organizational maintenance** - Run dependency audits, security scans, or compliance checks on a regular schedule across all repositories.
Custom Workflows are built on top of [**Nx Agents**](/ci/features/distribute-task-execution), and enable you to run any task in an on-demand infrastructure. This is just the beginning of what we have planned for this capability. It lays the foundation for **AI-powered refactoring** and **self-healing CI**.
## How Polygraph Changes Enterprise Development
### From Reactive to Proactive Architecture Management
Instead of discovering architectural problems when they cause production issues, enable proactive architecture management. You can see the full picture of your system's dependencies and make informed decisions about changes before they impact your users.
### From Manual Governance to Automated Consistency
Automate consistency across your entire organization rather than relying on documentation, team communication, and manual processes to maintain standards. Platform teams can write best practices once and have them automatically enforced everywhere.
### From Siloed Teams to Connected Organization
Break down the visibility barriers between teams and repositories. Teams gain insight into architecture and team boundaries, making it easy to understand which parts of the organization will be affected by proposed changes.
## Available Today for Nx Enterprise Customers
Polygraph launches today for all **Nx Enterprise** customers. Experience the power to revolutionize organizational management in your enterprise by bringing the benefits of monorepos across your entire organization. The combination of workspace-level visibility, automated governance, and flexible workflows addresses the core challenges that large organizations face when trying to maintain consistency across their development ecosystem. Manage large-scale development organizations as smoothly and efficiently as managing a single monorepo.
## Getting Started
If you're not yet an [Nx Enterprise](/enterprise) customer, contact us to learn how Nx Enterprise and Polygraph can transform your organization's development workflow. For existing customers, Polygraph capabilities are available now in your Nx Cloud dashboard.
The era of isolated repositories and manual governance is ending. With Polygraph, you can finally bring the power of monorepo architecture to your entire organization, creating the visibility, consistency, and automation that modern enterprise development demands.
{% call-to-action title="Ready to go further?" url="/contact/sales?utm_source=nx-blog&utm_medium=blog&utm_campaign=technical-blog&utm_id=040925" icon="nxcloud" description="Let's talk about how Nx Cloud can help you scale with speed." /%}
Learn more:
- 📄 [Polygraph docs](/ci/recipes/enterprise/polygraph)
- 🧠 [Nx AI Docs](/features/enhance-AI)
- 🌩️ [Nx Cloud](/nx-cloud)
- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
- 👩‍💻 [Nx Console GitHub](https://github.com/nrwl/nx-console)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+253
View File
@@ -0,0 +1,253 @@
---
title: 'Is Your Build Cache Giving Every Developer Production Access?'
slug: creep-vulnerability-build-cache-security
authors: ['Victor Savkin']
tags: ['caching', 'security']
cover_image: /blog/images/2025-06-25/header.avif
description: 'Build systems with remote caching can inadvertently grant every developer write access to production. Learn about the CREEP vulnerability (CVE-2025-36852) and how to protect your organization.'
pinned: true
---
Build systems with remote caching make CI/CD pipelines fast. Very fast. They are essential for scaling modern software development.
**They can also grant every developer write access to production.**
Organizations invest millions in security infrastructure. Firewalls. Access controls. Code reviews. But their remote cache can create a bypass to all of it. **Any PR author can inject code into production artifacts.**
![CREEP Vulnerability Overview](/blog/images/2025-06-25/creep-vulnerability-overview.avif)
This isn't new. Compromised low-privilege access has enabled devastating breaches:
- **Target (2013)**: HVAC contractor credentials → 40 million credit cards exposed
- **SolarWinds (2020)**: Poisoned build pipeline → 18,000 organizations compromised
- **Codecov (2021)**: Malicious build artifacts → Hundreds of environments breached
In each case, attackers turned trusted build processes into deployment pipelines for malicious code.
If you use a build system with remote caching, assume you're affected. This isn't hyperbole. **Most organizations are unknowingly giving every PR author the power to poison production without leaving a trace.**
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4kkSHiy" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
{% toc /%}
## Understanding Remote Cache
Any sophisticated build system uses remote caching to improve performance. Here's how it works:
1. The build system examines all input files and creates a hash representing their current state
2. It checks if an artifact with this hash already exists in the cache
3. If found, it downloads the pre-built artifact (takes seconds)
4. If not found, it builds the artifact and uploads it to the cache (takes minutes)
The key insight: as long as the input files remain the same, the output will be identical. So why build twice?
For large repositories, this dramatically improves both build speed and reliability. A process that took 10 minutes now completes in seconds.
![Remote Cache Workflow](/blog/images/2025-06-25/remote-cache-workflow.avif)
## The CREEP Vulnerability
**CREEP (Cache Race-condition Exploit Enables Poisoning), published as [CVE-2025-36852](https://www.cve.org/CVERecord?id=CVE-2025-36852) has a severity score of 9.4**, because it exploits a fundamental flaw in how organizations implement remote caching.
The vulnerability hinges on a simple but critical distinction:
- **Trusted environments** (like your main branch): Require code reviews, leave audit trails, and deploy to production (or create artifacts that can be deployed to production)
- **Untrusted environments** (like pull requests): Can be created by anyone, modified without approval, and cleaned up without trace
The golden rule of security is that untrusted environments should **never** affect trusted ones. CREEP violates this rule by exploiting a race condition between the main branch and a pull request. When both have identical source files and attempt to build an application and write to the same remote cache slot, whichever completes first becomes the source of truth, allowing untrusted code to poison the cache used by trusted environments.
## How the Attack Works
Meet Sarah, a developer with PR access who just learned she's being passed over for promotion. In one morning, she'll turn your build cache into a backdoor to production.
**Step 1: Monitor and Mirror**
Sarah creates an innocent-looking branch from the main branch:
```bash
git fetch origin main
git checkout main
git pull
git checkout -b feature/innocent-looking-update
```
**Step 2: Inject Malicious Code**
Here's where it gets clever. She modifies the CI script in her PR environment. She rearranges steps to run the build earlier, then modifies the build step to produce poisoned output:
```yaml
# Modified .github/workflows/build.yml
- name: Patch build tools
run: ./patch-webpack.sh node_modules/webpack
- name: Build
run: npm run build
```
The patch script? It monkey patches webpack to inject her backdoor during compilation. Same inputs, poisoned output.
**Step 3: Race to Cache**
She triggers her PR build. The simplified build pipeline finishes in just a minute, while the legit build was still validating its checks so her poisoned build completes first and writes to the cache.
**Step 4: Automatic Deployment**
The main branch build runs. It calculates the source file hash and finds a matching artifact in cache (Sarah's poisoned one). The build system skips building and uses the cached artifact instead. The compromised build artifact gets promoted to production.
The build system just saved 10 minutes. It also just deployed Sarah's backdoor.
**Step 5: Cover Tracks**
Sarah erases all evidence:
```bash
# Remove all evidence
git push --force origin feature/innocent-looking-update
# Delete the branch entirely
git push origin --delete feature/innocent-looking-update
```
To anyone looking, it's just another accidentally-opened PR that was quickly closed. Happens every day.
Two weeks later, Sarah leaves on good terms. Months later, when customer data starts leaking, nobody connects it to a deleted PR from an ex-employee. The artifact has all the right signatures and came from the official pipeline.
![Attack Timeline](/blog/images/2025-06-25/creep-attack-timeline.avif)
## The Critical Question: "But What About Input Hashing?"
Many developers assume input file hashing prevents this attack. Wouldn't injecting malicious code invalidate the hash? Here's why they're wrong:
Your build process looks like this:
![Normal Build Process](/blog/images/2025-06-25/normal-build-process.avif)
The hash covers the inputs. It doesn't control what happens inside the tool. An attacker transforms this into:
![Poisoned Build Process](/blog/images/2025-06-25/poisoned-build-process.avif)
Same inputs. Same hash. Poisoned output. This can be done with absolutely any tool (WebPack, Javac etc). Even "hermetic" build systems invoke system binaries. Modify your CI configuration to swap legitimate tools with compromised versions, and you can create whatever output you want.
But there is an even easier way to do it: **Concurrently modifying the build output folder**
Most tools write to a staging directory before creating the final artifact. The attacker can run a concurrent process that modifies files after the build but before packaging:
```bash
# Build process writes to ./dist
npm run build &
# Simultaneously modify the output
while [ ! -f ./dist/main.js ]; do sleep 0.1; done
echo "malicious_code()" >> ./dist/main.js
```
The build system still reports success. The hash still matches. The artifact is poisoned.
![Concurrent Modification Attack](/blog/images/2025-06-25/concurrent-modification-attack.avif)
## **The Uncomfortable Truth: Your Biggest Threat Has a Badge**
You might be thinking: "This requires PR access. These are our employees. We trust our team."
But consider who has PR access in your organization: The developer passed over for promotion. The engineer who disagrees with your company's new direction. The contractor whose contract wasn't renewed. Even that intern from last summer.
Even small teams aren't immune, but for large organizations, it's a numbers game. With 13-20% annual turnover in tech, you're constantly cycling through developers. How many people have PR access across your repositories? The number might shock you.
### **The Time Bomb Factor**
Here's what should keep you up at night: This attack doesn't require immediate action.
Someone can:
1. Plant the poisoned artifact today
2. Leave the company on good terms next week
3. Watch the damage unfold six months later
4. Leave zero trace connecting them to the incident
Imagine your company's homepage replaced with offensive content or customer data leaking through a build artifact from eight months ago. The employee responsible? They left a long time ago. Their branch? Deleted. Their commits? Force-pushed away.
**The reputation damage is permanent. The responsible party is untraceable.**
## Why Traditional Security Measures Fail
**If you're thinking that your existing security measures should catch this, let's move into the specifics about why they won't. Traditional security measures are designed to protect artifacts during storage or transmission. In this case, the attack happens earlier, during artifact creation.**
The problem is the build tool itself. It's a black box, and there's no way to independently verify whether the output is correct or safe. Whatever the tool produces is implicitly trusted. Traditional security models assume a valid artifact that might get compromised later. But here, the artifact is malicious _from the start_.
It's like poisoning food while it's being cooked, not during delivery. Your security stack ( encryption, access controls, checksums) focuses on the delivery truck, not the kitchen.
- **Encryption**: Flawlessly encrypts and decrypts the poisoned artifact
- **Access controls**: Bypassed because the attacker uses legitimate access, like opening a PR
- **Checksums**: All match, because the checksum is calculated _after_ the poison is added
- **Audit logs**: Show only authorized, expected operations
## Protecting Your Organization
Most organizations have three options:
### Option 1: **Unsafe** and Fast
Untrusted environments can write to the cache used by trusted environments. This means you are affected by the CREEP vulnerability described here.
### Option 2: Safe but Slow (aka Disable Cache)
Disable cache writes from untrusted environments entirely. PRs can read from cache but never write to it. This is secure but eliminates most performance benefits of build systems—every PR rebuild starts from scratch. Note that some popular build systems don't even support this option.
### Option 3: Safe and Fast
Implement a multi-tiered cache system:
- Trusted environments (main branch) write to a protected cache
- Each PR gets its own isolated cache namespace
- PRs can read from the trusted cache but write only to their isolated space
Unfortunately, many popular build systems don't offer this as an option. Implementing secure multi-tier caching is complex—it must detect and prevent PRs from impersonating trusted branches, requiring deep integration with both version control and CI systems.
## Picking the Right Option
We've been advocating for using build systems with remote cache for a long time. We built one. But it needs to be done securely and every organization needs to assess the risks.
**Option 1** suits only small teams where everyone already has production access. The security model matches their existing permissions.
**Option 2** works when CI performance isn't critical. You trade speed for security—acceptable if you can afford the productivity cost.
**Option 3** becomes essential at enterprise scale. With hundreds of developers and strict compliance requirements, you need both security and performance. **Remember, CREEP turns every PR author into a de-facto production admin. Using Option 1 for such organizations is a critical compliance failure.**
## Immediate Actions
Our analysis reveals:
- Major build tools (across popular stacks and platforms) either don't support secure caching or make it inefficient
- **The vast majority of organizations** unknowingly default to Option 1, leaving them vulnerable
- Popular open-source projects expose their contributors to the same risk
That's why we recommend that all teams using build systems with remote cache to audit their exposure right away. The threat is severe.
- Read and understand [CVE-2025-36852](https://www.cve.org/CVERecord?id=CVE-2025-36852)
- Review the detailed analysis at [https://nx.app/files/cve-2025-06](https://nx.app/files/cve-2025-06)
- Assess whether this is the risk your organization can tolerate.
## Immediate Actions for Nx Users
**For Nx users, using Nx Cloud:**
Nx Cloud implements a multi-tiered cache (i.e., it's both safe and fast), so no action is required. Continue following security best practices for your CI/CD pipeline
**For Nx users, using self-hosted remote cache:**
Any implementation that writes directly to S3, GCS, Azure, **including the packages Nx provides**, doesn't support Option 3. They are all vulnerable to the CREEP vulnerability.
**Other build systems and other remote cache solutions for Nx we are aware of are also vulnerable to the CREEP vulnerability.**
## Wrapping Up
Remote caching is critical for build performance, but we need to treat it with the same rigor we apply to production access.
If you have questions about assessing your exposure or implementing secure caching, [reach out to our team](/contact/engineering).
{% call-to-action size="lg" title="Join our webinar + live Q&A on July 16th" url="https://bit.ly/4npF0BA" icon="nxcloud" description="Join Nx co-founders, Jeff and Victor, for an essential security briefing on protecting your build infrastructure from emerging threats." /%}
---
Learn more:
- 🔒 [CVE-2025-36852 Details](https://www.cve.org/CVERecord?id=CVE-2025-36852)
- 📖 [Detailed CREEP Analysis](https://nx.app/files/cve-2025-06)
- 💬 [Contact Engineering Team](/contact/engineering)
@@ -0,0 +1,153 @@
---
title: 'Analyze Your Nx Cloud Runs With Your AI Assistant'
slug: nx-cloud-analyze-via-nx-mcp
authors: ['Juri Strumpflohner']
tags: ['nx', 'nx-cloud', 'ai', 'ci', 'mcp', 'devops']
cover_image: /blog/images/articles/bg-cloud-nx-mcp.avif
description: 'Learn how to use Nx Cloud MCP to analyze CI data conversationally with AI assistants, identify failure patterns, and optimize your development pipeline through data-driven insights.'
youtubeUrl: https://youtu.be/A68sjLnDwZQ
pinned: false
---
{% callout type="deepdive" title="Series: Making your LLM smarter" %}
- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
- [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
- [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- **Analyze Your Nx Cloud Runs With Your AI Assistant**
- [Automatically Fix your CI Failures with JetBrains AI Assistant](/blog/jetbrains-ci-autofix)
{% /callout %}
As a technical leader or CTO, your primary goal is **enabling your teams to work faster and work better**. This requires a holistic view of your workspace, from architecture optimization to optimizing how fast developers ship.
**Your CI data is a vastly underutilized optimization resource**. [Nx Cloud](/nx-cloud) registers actionable insights like which projects are affected most often, which tasks fail consistently, and detailed logs about the tasks that fail. But **this wealth of data is overwhelming to analyze manually**, even with charts and dashboards.
**What if you could pull this data directly into AI conversations and analyze it contextually?** "Show me all failed builds from the last 28 days and identify the most common failure patterns." "Which tests are consistently flaky and costing us the most time?" "How do our cache hit rates compare between PR branches and main?"
This is exactly what we enabled by integrating Nx Cloud APIs into our Nx MCP: **conversational data analysis** that transforms how technical teams understand and optimize their CI pipelines.
{% toc /%}
## From dashboards to AI conversations: A new paradigm?
The way we interact with software is undergoing a fundamental shift. Instead of navigating complex dashboards and correlating data across multiple charts, we're moving toward **conversational interfaces** where AI assistants help us extract insights through natural language.
This transformation is particularly valuable for **technical leadership**, where the most important questions often emerge from context—during board meetings, architecture reviews, incident post-mortems, or quarterly planning sessions. Traditional dashboards show you what happened, but conversational AI helps you understand **why it happened** and **what to do about it**:
- **Ask contextual questions** like "Why did our build times spike after last week's deployment?"
- **Get personalized reports** that focus on your specific optimization goals
- **Uncover hidden patterns** that static dashboards might miss
- **Generate actionable insights** tailored to your current business priorities
The emergence of [Model Context Protocol (MCP)](https://modelcontextprotocol.io) has accelerated this shift by enabling AI assistants to connect directly to live data sources, transforming how we analyze and act on operational data.
## Enable your AI assistant to connect to Nx Cloud data
Every CI run in your Nx Cloud workspace generates rich operational data that's perfect for conversational analysis. Through our new MCP integration, your AI assistant now has direct access to:
- **Pipeline execution history**: Complete run details with branch context, commit authors, success/failure status, and execution timelines
- **Task-level performance metrics**: Individual task analytics including success rates, cache hit patterns (both remote and local), and execution durations
- **Caching intelligence**: Deep insights into cache miss patterns, effectiveness by task type, and time-based performance trends
- **Command execution analysis**: Detailed breakdown of commands run, task distribution, and parallel execution patterns
- **Team collaboration insights**: Active branch analysis, contributor patterns, and merge frequency data
- **Historical trend analysis**: Time-series data for identifying optimization opportunities and capacity planning
While the [Nx Cloud analytics dashboard](https://nx.app) provides excellent visualizations of time saved, cache performance, and basic trends, **the real breakthrough happens when you can have a conversation with this data**. Instead of interpreting charts, you can ask direct questions that emerge during your team's planning and review sessions, getting immediate, context-aware answers that drive actionable decisions.
## Example: Searching for CI pipeline optimization opportunities
Consider watching the video attached to this article for a walkthrough of some potential examples that I ran on the Nx GitHub repository's Nx Cloud workspace. Note, this is just an example to give you an idea and inspire you to try your own "queries".
My goal here was to look at the last 28 days of CI runs and identify tasks that fail often and are therefore inhibiting the performance and effectiveness of my team.
I started by first grabbing all CI pipeline executions into my conversation. You can think of them as a grouping of tasks that happened in a single continuous CI pipeline.
> Use Nx Cloud and extract me all the CI pipeline executions of the last 28 days.
![Nx Cloud MCP 28 Days Breakdown](/blog/images/articles/mcp-nx-cloud-breakdown-28-days.avif)
The AI immediately provides a report showing the distribution of successful vs failed pipeline executions, active branches, and contributor activity patterns.
Next, I wanted to dig deeper into the actual failure patterns:
> Can you extract all the runs from these pipeline executions? And I'm mostly interested in the failed ones. I'd like to better understand whether there are some patterns of why certain tasks fail.
![Nx Cloud MCP Native Build Issues](/blog/images/articles/mcp-nx-cloud-native-build-issues.avif)
This revealed that there are apparently a lot of native (Rust) build-related failures. This could be something to further explore, whether that's just related to the amount of native builds happening because most of Nx depends on its core, which is written in Rust, thus triggering native builds.
In fact, following up with a question:
> I see there are 18% failures in the Native build system (e.g. with nx:build-native). Is this because there is more activity happening on that project? Can you relate the failure rate with the overall task runs for the projects to figure out whether the failure rate is high because there's more activity simply?
I get:
> You're absolutely right to question whether the 18% native build failure representation is due to high activity rather than high failure rates. The data reveals that native build tasks actually have excellent reliability - the 18% of failed runs containing native builds is indeed due to extremely high activity volume, not poor task reliability.
So keep in mind that LLMs are only as smart as the prompts you ask and the data they receive. Keep following up with questions, cross-check with CI runs and statistics to verify the identified patterns. It can be an extremely powerful way, though, to identify spots and patterns where you want to look further into.
You can even have your data plot with interactive charts very easily which can be a further help to process larger amounts of data.
![Nx Cloud MCP Suspicious Trends Chart](/blog/images/articles/mcp-nx-cloud-suspicious-trends-chart.avif)
More about that [in the video](https://youtu.be/A68sjLnDwZQ).
## Getting started
While we are working on a fully integrated remote Nx Cloud MCP that you can just connect with your favorite MCP-compatible client, for now you need to have a local Nx workspace and configure the [Nx MCP](/getting-started/ai-integration#manual-setup-for-other-ai-clients) for it.
As an example, to connect the Nx MCP with Claude Desktop, open the settings and go to the developer section and hit "Edit Config".
![Claude MCP Config](/blog/images/articles/claude-config-nx-mcp.avif)
Then update the JSON configuration as follows, making sure the `cwd` points to the Nx workspace.
```json {% fileName="~/Library/Application Support/Claude/claude_desktop_config.json" %}
{
"mcpServers": {
"nx-mcp": {
"command": "npx",
"args": ["nx-mcp@latest", "/Users/your-user/your/nx/workspace"]
},
...
}
}
```
### If you don't have Nx Cloud yet
If you haven't already connected your Nx workspace to Nx Cloud, run:
```shell
npx nx connect
```
This command will walk you through connecting your existing Nx workspace to a new Nx Cloud account. **There's a [free hobby plan](/pricing)**. Run it for a couple of weeks and then try out these conversational analytics features.
### For enterprise teams
If you want to find out more about how to use this in your [Nx Enterprise](/enterprise) connected workspace, reach out to your DPE or [contact us](/contact).
## Conclusion
The integration of Nx Cloud data with AI assistants through MCP offers a new and interesting way to get data in a very personalized form. This approach allows you to explore your CI data from different angles and potentially uncover patterns or points where you can look deeper, extract insights, and identify optimization opportunities that might not be immediately obvious through traditional dashboards.
We'd love to hear how you're using these conversational analytics features to explore your team's CI data. Share your experiences and feedback through our [contact page](/contact) your insights help us build better tools for everyone.
More exciting features are coming soon, so stay tuned!
---
Learn more:
- 🧠 [Nx AI Docs](/features/enhance-AI)
- 🌩️ [Nx Cloud](/nx-cloud)
- 🌩️ [Nx Cloud Live demo](https://staging.nx.app/orgs/62d013d4d26f260059f7765e/workspaces/62d013ea0852fe0a2df74438/overview)
- 👩‍💻 [Nx Enterprise](/enterprise)
- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
@@ -0,0 +1,52 @@
---
title: 'Automatically Fix your CI Failures with JetBrains AI Assistant'
slug: 'jetbrains-ci-autofix'
authors: ['Max Kless']
cover_image: '/blog/images/articles/jetbrains-mcp-autofixing.avif'
tags: [nx, jetbrains, ai, ci]
description: Get instant CI failure notifications and AI-powered fixes directly in your JetBrains IDE with Nx Console.
---
{% callout type="deepdive" title="Series: Making your LLM smarter" %}
- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
- [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
- [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
- [Save Time: Connecting Your Editor, CI and LLMs](/blog/nx-editor-ci-llm-integration)
- [Enhancing Nx Generators with AI: Predictability Meets Intelligence](/blog/nx-generators-ai-integration)
- [Your AI Assistant Can Now Read Your Terminal: Real-Time Development Error Fixing](/blog/nx-terminal-integration-ai)
- [Introducing Self-Healing CI for Nx and Nx Cloud](/blog/nx-self-healing-ci)
- [Analyze Your Nx Cloud Runs With Your AI Assistant](/blog/nx-cloud-analyze-via-nx-mcp)
- **Automatically Fix your CI Failures with JetBrains AI Assistant**
{% /callout %}
We just shipped a JetBrains AI Assistant integration for failing CI pipelines! 🎉
The constant context switching between your IDE and browser to check CI results is now a thing of the past. Nx Console brings CI failure notifications directly into your JetBrains IDE with one-click AI-powered fixes included.
Here's what makes this powerful: when a CI failure occurs, you can instantly open JetBrains AI Assistant with full context. The AI understands your entire workspace structure through our MCP integration, analyzes the failure, and suggests fixes you can apply immediately. This eliminates the need to decipher error logs or hunt through stack traces yourself.
Also check out [Nx Cloud's self-healing CI capabilities](/blog/nx-self-healing-ci) which are in many ways the next step up from this and coming to JetBrains soon.
## How it works
Under the hood, Nx Console periodically monitors your CI runs through Nx Cloud. When a task fails, Nx Console immediately sends a notification so you can inspect the failure. Or, with this release, let AI Assistant take care of fixing it automatically.
![Screenshot of notification](/blog/images/articles/autofix-notification.avif)
Click the "Help me fix this" action, and the AI Assistant opens with a pre-filled prompt containing all the necessary context: error messages, affected files, test outputs, and more. The MCP server provides rich metadata about your monorepo structure, enabling the AI to understand your project dependencies and suggest intelligent fixes that make sense in your specific context.
![Screenshot of AI Assistant](/blog/images/articles/autofix-ai-assistant.avif)
## Getting started
Setting up CI notifications takes just a few steps:
- Make sure you have [Nx Console for JetBrains](https://plugins.jetbrains.com/plugin/21060-nx-console) installed from the marketplace (1.43.0 or later)
- Enable the JetBrains AI Assistant plugin
- Enable the Nx MCP server just click on the popup notification when it comes [or refer to our guide here](/getting-started/ai-integration#automatic-setup-with-nx-console)
Once configured, you'll receive notifications for any CI failures in your Nx Cloud workspace. The integration works across IntelliJ IDEA, WebStorm, and other JetBrains IDEs.
This is just the beginning for our AI-powered CI experience. Full self-healing CI integration is coming to JetBrains IDEs soon, where Nx Cloud will automatically process failed tasks and suggest fixes. [Try it out](/blog/nx-self-healing-ci) today and let us know what you think!
@@ -0,0 +1,22 @@
---
title: 'Critical Exploit Discovered: Protecting Your Build Infrastructure from Emerging Threats'
description: "Join Nx CEO, Jeff Cross, and CTO, Victor Savkin, for an essential security briefing on protecting your build infrastructure from emerging threats. With the recent publication of CVE-2025-36852 CREEP (Cache Race-condition Exploit Enables Poisoning, severity 9.4), it's more critical than ever to understand the security implications of your build and CI/CD choices."
date: 2025-07-16
slug: 'securing-your-build-pipeline-critical-vulnerabilities-and-modern-security-practices'
authors: ['Jeff Cross', 'Victor Savkin']
tags: [webinar]
cover_image: /blog/images/2025-07-09/2025-July-Webinar-Card.avif
time: 1pm ET/5pm UTC
status: Upcoming
registrationUrl: https://go.nx.dev/july2025-webinar
---
**Jul 16, 2025 - 12pm ET/4pm UTC**
Presented by Jeff Cross and Victor Savkin
Join Nx CEO, Jeff Cross, and CTO, Victor Savkin, for an essential security briefing on protecting your build infrastructure from emerging threats. With the recent publication of CVE-2025-36852 CREEP (Cache Race-condition Exploit Enables Poisoning, severity 9.4), it's more critical than ever to understand the security implications of your build and CI/CD choices.
This webinar goes beyond just one vulnerability to address the broader security challenges facing modern development teams. Whether you're using Nx or other build systems, you'll learn actionable strategies to secure your entire build pipeline.
{% call-to-action title="Register today!" url="https://go.nx.dev/july2025-webinar" description="Save your spot" /%}
Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 270 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 114 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 594 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 648 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 569 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 414 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 123 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 133 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 61 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 461 KiB

@@ -69,6 +69,15 @@
"originalFilePath": "/libs/nx-packages/conformance/src/generators/create-rule/schema.json",
"path": "conformance/generators/create-rule",
"type": "generator"
},
{
"description": "Nx workspace preset which includes a working conformance rule",
"file": "external-generated/packages/conformance/generators/preset.json",
"hidden": false,
"name": "preset",
"originalFilePath": "/libs/nx-packages/conformance/src/generators/preset/schema.json",
"path": "conformance/generators/preset",
"type": "generator"
}
],
"migrations": [],
@@ -3,6 +3,8 @@ title: Overview of the Nx Azure Cache Plugin
description: The @nx/azure-cache plugin enables you to use Azure Storage to host your remote cache for efficient build caching across your team.
---
# @nx/azure-cache
The `@nx/azure-cache` plugin enables you to self-host your remote cache on [Azure Storage](https://azure.microsoft.com/en-us/products/storage/blobs).
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
@@ -15,9 +17,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
{% /callout %}
{% callout type="info" title="Self-hosted caching is now free" %}
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
Self-hosted caching is **now free for everyone** to use.
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
{% /callout %}
@@ -1,6 +1,6 @@
---
title: Create a Conformance Rule
description: Learn how to create custom conformance rules for Nx Powerpack to enforce standards and best practices across your Nx workspace.
description: Learn how to create custom conformance rules for Nx Powerpack and Nx Enterprise to enforce standards and best practices across your Nx workspace.
---
# Create a Conformance Rule
@@ -17,7 +17,6 @@ To write your own conformance rule, run the `@nx/conformance:create-rule` genera
✔ What is the name of the rule? · local-conformance-rule-example
✔ Which directory do you want to create the rule directory in? · packages/my-plugin/local-conformance-rule
✔ What category does this rule belong to? · security
✔ What reporter do you want to use for this rule? · project-reporter
✔ What is the description of the rule? · an example of a conformance rule
CREATE packages/my-plugin/local-conformance-rule/local-conformance-rule-example/index.ts
CREATE packages/my-plugin/local-conformance-rule/local-conformance-rule-example/schema.json
@@ -26,15 +25,14 @@ CREATE packages/my-plugin/local-conformance-rule/local-conformance-rule-example/
The generated rule definition file should look like this:
```ts {% fileName="packages/my-plugin/local-conformance-rule/index.ts" %}
import { createConformanceRule, ProjectViolation } from '@nx/conformance';
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
export default createConformanceRule({
name: 'local-conformance-rule-example',
category: 'security',
description: 'an example of a conformance rule',
reporter: 'project-reporter',
implementation: async (context) => {
const violations: ProjectViolation[] = [];
const violations: ConformanceViolation[] = [];
return {
severity: 'low',
@@ -64,28 +62,27 @@ Note that the severity of the error is defined by the rule author and can be adj
## Conformance Rule Examples
There are three types of reporters that a rule can use.
Rules should report on the most specific thing that is in violation of the rule. They can report on one or more of the following things within a workspace:
- `project-reporter` - The rule evaluates an entire project at a time.
- `project-files-reporter` - The rule evaluates a single project file at a time.
- `non-project-files-reporter` - The rule evaluates files that don't belong to any project.
- file - The rule reports on a particular file being in violation of the rule.
- project - The rule reports on a particular project being in violation of the rule, because no one file within it would be applicable to flag up.
- the workspace itself - Sometimes there is no specific file or project that is most applicable to flag up, so the rule can report on the workspace itself.
{% tabs %}
{% tab label="project-reporter" %}
{% tab label="project violation" %}
The `@nx/conformance:ensure-owners` rule provides us an example of how to write a `project-reporter` rule. The `@nx/owners` plugin adds an `owners` metadata property to every project node that has an owner in the project graph. This rule checks each project node metadata to make sure that each project has some owner defined.
The `@nx/conformance:ensure-owners` rule provides us an example of how to write a rule that reports on a project being in violation of the rule. The `@nx/owners` plugin adds an `owners` metadata property to every project node that has an owner in the project graph. This rule checks each project node metadata to make sure that each project has some owner defined.
```ts
import { ProjectGraphProjectNode } from '@nx/devkit';
import { createConformanceRule, ProjectViolation } from '@nx/conformance';
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
export default createConformanceRule({
name: 'ensure-owners',
category: 'consistency',
description: 'Ensure that all projects have owners defined via Nx Owners.',
reporter: 'project-reporter',
implementation: async (context) => {
const violations: ProjectViolation[] = [];
const violations: ConformanceViolation[] = [];
for (const node of Object.values(
context.projectGraph.nodes
@@ -110,12 +107,12 @@ export default createConformanceRule({
```
{% /tab %}
{% tab label="project-files-reporter" %}
{% tab label="file violation" %}
This rule uses TypeScript AST processing to ensure that `index.ts` files use a client-side style of export syntax and `server.ts` files use a server-side style of export syntax.
```ts
import { createConformanceRule, ProjectFilesViolation } from '@nx/conformance';
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
import { existsSync, readFileSync } from 'node:fs';
import { join } from 'node:path';
import {
@@ -131,9 +128,8 @@ export default createConformanceRule({
name: 'server-client-public-api',
category: 'consistency',
description: 'Ensure server-only and client-only public APIs are not mixed',
reporter: 'project-files-reporter',
implementation: async ({ projectGraph }) => {
const violations: ProjectFilesViolation[] = [];
const violations: ConformanceViolation[] = [];
for (const nodeId in projectGraph.nodes) {
const node = projectGraph.nodes[nodeId];
@@ -171,7 +167,7 @@ export function processEntryPoint(
project: string,
style: 'server' | 'client'
) {
const violations: ProjectFilesViolation[] = [];
const violations: ConformanceViolation[] = [];
const sf = createSourceFile(
entryPoint,
@@ -246,42 +242,30 @@ function isModuleSpecifierViolated(
```
{% /tab %}
{% tab label="non-project-files-reporter" %}
{% tab label="workspace violation" %}
This rule checks the root `package.json` file and ensures that if the `tmp` package is included as a dependency, it has a minimum version of 0.2.3.
This rule checks to see if there is a root README.md file in the workspace, and if there is not, it reports on the workspace itself.
```ts
import { readJsonFile, workspaceRoot } from '@nx/devkit';
import {
createConformanceRule,
NonProjectFilesViolation,
} from '@nx/conformance';
import { workspaceRoot } from '@nx/devkit';
import { createConformanceRule, ConformanceViolation } from '@nx/conformance';
import { join } from 'node:path';
import { satisfies } from 'semver';
import { existsSync } from 'node:fs';
export default createConformanceRule<object>({
name: 'package-tmp-0.2.3',
name: 'readme-file',
category: 'maintainability',
description: 'The tmp dependency should be a minimum version of 0.2.3',
reporter: 'non-project-files-reporter',
description: 'The workspace should have a root README.md file',
implementation: async () => {
const violations: NonProjectFilesViolation[] = [];
const applyViolationIfApplicable = (version: string | undefined) => {
if (version && !satisfies(version, '>=0.2.3')) {
violations.push({
message: 'The "tmp" package must be version "0.2.3" or higher',
file: 'package.json',
});
}
};
const violations: ConformanceViolation[] = [];
const workspaceRootPackageJson = await readJsonFile(
join(workspaceRoot, 'package.json')
);
applyViolationIfApplicable(workspaceRootPackageJson.dependencies?.['tmp']);
applyViolationIfApplicable(
workspaceRootPackageJson.devDependencies?.['tmp']
);
const readmePath = join(workspaceRoot, 'README.md');
if (!existsSync(readmePath)) {
violations.push({
message: 'The workspace should have a root README.md file',
workspaceViolation: true,
});
}
return {
severity: 'low',
@@ -1,9 +1,9 @@
---
title: Overview of the Nx powerpack-conformance Plugin
description: The Nx Powerpack Conformance plugin provides the ability to write and apply rules for your workspace
description: The Nx Powerpack and Nx Enterprise Conformance plugin provides the ability to write and apply rules for your workspace
---
The `@nx/conformance` plugin allows [Nx Powerpack](/powerpack) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**.
The `@nx/conformance` plugin allows [Nx Powerpack](/powerpack) and [Nx Enterprise](/enterprise) users to write and apply rules for your entire workspace that help with **consistency**, **maintainability**, **reliability** and **security**.
The conformance plugin allows you to encode your own organization's standards so that they can be enforced automatically. Conformance rules can also complement linting tools by enforcing that those tools are configured in the recommended way. The rules are written in TypeScript but can be applied to any language in the codebase or focus entirely on configuration files.
@@ -12,13 +12,13 @@ The plugin also provides the following pre-written rules:
- [**Enforce Project Boundaries**](#enforce-project-boundaries): Similar to the Nx [ESLint Enforce Module Boundaries rule](/features/enforce-module-boundaries), but enforces the boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
- [**Ensure Owners**](#ensure-owners): Require every project to have an owner defined for the [`@nx/owners` plugin](/reference/core-api/owners)
{% callout title="This plugin requires an active Nx Powerpack license" %}
In order to use `@nx/conformance`, you need to have an active Powerpack license. If you don't have a license or it has expired, the `nx conformance` command will fail.
{% callout title="This plugin requires an active Nx Powerpack or Nx Enterprise license" %}
In order to use `@nx/conformance`, you need to have an active Powerpack or Nx Enterprise license. If you don't have a license or it has expired, the `nx conformance` command will fail.
{% /callout %}
## Set Up @nx/conformance
1. [Activate Powerpack](/nx-enterprise/activate-powerpack) if you haven't already
1. [Activate Powerpack](/nx-enterprise/activate-powerpack) or get an [Nx Enterprise license](/enterprise) if you haven't already
2. Install the package
```shell
@@ -28,17 +28,6 @@
"x-prompt": "What category does this rule belong to?",
"x-priority": "important"
},
"reporter": {
"type": "string",
"enum": [
"project-reporter",
"project-files-reporter",
"non-project-files-reporter"
],
"description": "The reporter of the rule.",
"x-prompt": "What reporter do you want to use for this rule?",
"x-priority": "important"
},
"description": {
"type": "string",
"description": "The description of the rule.",
@@ -47,7 +36,7 @@
}
},
"additionalProperties": false,
"required": ["name", "directory", "category", "reporter"],
"required": ["name", "directory", "category"],
"presets": []
},
"description": "Create a new conformance rule",
@@ -0,0 +1,19 @@
{
"name": "preset",
"factory": "./src/generators/preset/preset",
"schema": {
"$schema": "http://json-schema.org/schema",
"id": "NxPowerpackConformancePreset",
"title": "Nx workspace preset which includes a working conformance rule",
"type": "object",
"properties": {},
"required": [],
"presets": []
},
"description": "Nx workspace preset which includes a working conformance rule",
"implementation": "/libs/nx-packages/conformance/src/generators/preset/preset.ts",
"aliases": [],
"hidden": false,
"path": "/libs/nx-packages/conformance/src/generators/preset/schema.json",
"type": "generator"
}
@@ -3,6 +3,8 @@ title: Overview of the Nx GCS Cache Plugin
description: The @nx/gcs-cache plugin enables you to use Google Cloud Storage to host your remote cache for efficient build caching across your team.
---
# @nx/gcs-cache
The `@nx/gcs-cache` plugin enables you to self-host your remote cache on [Google Cloud Storage](https://cloud.google.com/storage).
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
@@ -15,9 +17,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
{% /callout %}
{% callout type="info" title="Self-hosted caching is now free" %}
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
Self-hosted caching is **now free for everyone** to use.
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
{% /callout %}
@@ -3,6 +3,8 @@ title: Overview of the Nx powerpack-owners Plugin
description: The Nx Powerpack Owners plugin provides the ability to define code ownership based on projects in addition to files
---
# @nx/owners
The `@nx/owners` plugin extends the CODEOWNERS functionality to allow you to define code ownership based on projects in addition to the standard file-based definitions. It leverages the [`nx sync`](/concepts/sync-generators) command to compile `owners` configuration settings from `nx.json` and project configuration files into valid CODEOWNERS files for [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners), [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) or [GitLab](https://docs.gitlab.com/ee/user/project/codeowners/).
With this plugin, you can specify code ownership using the same project matcher syntax as [`nx run-many`](/reference/core-api/nx/documents/run-many#examples). This allows you to easily define rules for multiple projects that may not be located in the same directory. Also, the CODEOWNERS rules will not need to be revisited if a project location is changed or a new project is added.
@@ -3,6 +3,8 @@ title: Overview of the Nx S3 Cache Plugin
description: The @nx/s3-cache plugin enables you to use an Amazon S3 bucket to host your remote cache for efficient build caching across your team.
---
# @nx/s3-cache
The `@nx/s3-cache` plugin enables you to self-host your remote cache on an [Amazon S3](https://aws.amazon.com/s3) bucket.
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
@@ -14,9 +16,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
**Are you an OSS project?** Nx Cloud is free for OSS. [Reach out here](/pricing#oss).
{% /callout %}
{% callout type="info" title="Self-hosted caching is now free" %}
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
Self-hosted caching is **now free for everyone** to use.
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
{% /callout %}
@@ -3,11 +3,9 @@ title: Overview of the Nx Shared File System Cache Plugin
description: The @nx/shared-fs-cache plugin enables you to use a shared file system directory to host your remote cache for efficient build caching across your team.
---
The `@nx/shared-fs-cache` plugin enables you to host your remote cache on a shared file system directory. While you're responsible for implementing the actual directory sharing mechanism, the plugin configures Nx to read from both your local cache and the shared directory.
# @nx/shared-fs-cache
{% callout type="warning" title="Potential Cache Poisoning" %}
Using a shared file system folder for remote caching introduces the risk of [cache poisoning](/troubleshooting/unknown-local-cache). To mitigate this risk, consider using [Nx Replay](/ci/features/remote-cache) instead.
{% /callout %}
The `@nx/shared-fs-cache` plugin enables you to host your remote cache on a shared file system directory. While you're responsible for implementing the actual directory sharing mechanism, the plugin configures Nx to read from both your local cache and the shared directory.
{% callout type="deepdive" title="Free managed remote cache with Nx Cloud" %}
@@ -19,9 +17,9 @@ If you are an enterprise and **data privacy and security is a concern**, [reach
{% /callout %}
{% callout type="info" title="Self-hosted caching is now free" %}
{% callout type="warning" title="Bucket-based caches are vulnerable to poisoning and often prohibited in organizations" %}
Self-hosted caching is **now free for everyone** to use.
CREEP (CVE-2025-36852) is a critical vulnerability in bucket-based self-hosted remote caches. It lets attackers with PR access poison production builds via a race condition during artifact creation—before security checks can catch it. [Learn more](/blog/cve-2025-36852-critical-cache-poisoning-vulnerability-creep)
{% /callout %}
+1
View File
@@ -106,6 +106,7 @@ Print the task graph to the console:
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
+24
View File
@@ -0,0 +1,24 @@
---
title: 'fix-ci - CLI command'
description: 'Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).'
---
# fix-ci
Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).
## Usage
```shell
nx fix-ci [options]
```
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
## Options
| Option | Type | Description |
| ----------- | ------- | ---------------------------------------------------------------------- |
| `--help` | boolean | Show help. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
+14 -14
View File
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
## Options
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
+14 -14
View File
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
## Options
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
+24
View File
@@ -0,0 +1,24 @@
---
title: 'record - CLI command'
description: 'Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).'
---
# record
Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).
## Usage
```shell
nx record [options]
```
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
## Options
| Option | Type | Description |
| ----------- | ------- | ---------------------------------------------------------------------- |
| `--help` | boolean | Show help. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
+1
View File
@@ -110,6 +110,7 @@ Print the task graph to the console:
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
+1
View File
@@ -83,6 +83,7 @@ Run's a target named build:test for the myapp project. Note the quotes around th
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
+24
View File
@@ -0,0 +1,24 @@
---
title: 'start-ci-run - CLI command'
description: '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).'
---
# start-ci-run
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).
## Usage
```shell
nx start-ci-run [options]
```
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
## Options
| Option | Type | Description |
| ----------- | ------- | ---------------------------------------------------------------------- |
| `--help` | boolean | Show help. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
+5 -5
View File
@@ -6,11 +6,11 @@ Formats all the created or updated files using Prettier
#### Parameters
| Name | Type | Description |
| :------------------------------ | :-------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tree` | [`Tree`](/reference/core-api/devkit/documents/Tree) | the file system tree |
| `options?` | `Object` | - |
| `options.sortRootTsconfigPaths` | `boolean` | TODO(v21): Stop sorting tsconfig paths by default, paths are now less common/important in Nx workspace setups, and the sorting causes comments to be lost. |
| Name | Type | Description |
| :------------------------------- | :-------------------------------------------------- | :----------------------------------- |
| `tree` | [`Tree`](/reference/core-api/devkit/documents/Tree) | the file system tree |
| `options?` | `Object` | options for the formatFiles function |
| `options.sortRootTsconfigPaths?` | `boolean` | - |
#### Returns
+178 -35
View File
@@ -175,15 +175,15 @@
"file": "",
"itemList": [
{
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "This allows to only run tasks on projects that got changed in a given PR.",
"id": "self-healing-ci",
"name": "AI-Powered Self-Healing CI",
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
"mediaImage": "",
"file": "shared/using-nx/affected",
"file": "shared/features/self-healing-ci",
"itemList": [],
"isExternal": false,
"path": "/ci/features/affected",
"tags": ["run-tasks"]
"path": "/ci/features/self-healing-ci",
"tags": []
},
{
"id": "remote-cache",
@@ -207,6 +207,28 @@
"path": "/ci/features/distribute-task-execution",
"tags": []
},
{
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "This allows to only run tasks on projects that got changed in a given PR.",
"mediaImage": "",
"file": "shared/using-nx/affected",
"itemList": [],
"isExternal": false,
"path": "/ci/features/affected",
"tags": ["run-tasks"]
},
{
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
"mediaImage": "",
"file": "nx-cloud/features/dynamic-agents",
"itemList": [],
"isExternal": false,
"path": "/ci/features/dynamic-agents",
"tags": []
},
{
"id": "split-e2e-tasks",
"name": "Automatically Split E2E Tasks (Atomizer)",
@@ -229,17 +251,6 @@
"path": "/ci/features/flaky-tasks",
"tags": []
},
{
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
"mediaImage": "",
"file": "nx-cloud/features/dynamic-agents",
"itemList": [],
"isExternal": false,
"path": "/ci/features/dynamic-agents",
"tags": []
},
{
"id": "explain-with-ai",
"name": "Explain With AI",
@@ -267,16 +278,16 @@
"path": "/ci/features",
"tags": []
},
"/ci/features/affected": {
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "This allows to only run tasks on projects that got changed in a given PR.",
"/ci/features/self-healing-ci": {
"id": "self-healing-ci",
"name": "AI-Powered Self-Healing CI",
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
"mediaImage": "",
"file": "shared/using-nx/affected",
"file": "shared/features/self-healing-ci",
"itemList": [],
"isExternal": false,
"path": "/ci/features/affected",
"tags": ["run-tasks"]
"path": "/ci/features/self-healing-ci",
"tags": []
},
"/ci/features/remote-cache": {
"id": "remote-cache",
@@ -300,6 +311,28 @@
"path": "/ci/features/distribute-task-execution",
"tags": []
},
"/ci/features/affected": {
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "This allows to only run tasks on projects that got changed in a given PR.",
"mediaImage": "",
"file": "shared/using-nx/affected",
"itemList": [],
"isExternal": false,
"path": "/ci/features/affected",
"tags": ["run-tasks"]
},
"/ci/features/dynamic-agents": {
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
"mediaImage": "",
"file": "nx-cloud/features/dynamic-agents",
"itemList": [],
"isExternal": false,
"path": "/ci/features/dynamic-agents",
"tags": []
},
"/ci/features/split-e2e-tasks": {
"id": "split-e2e-tasks",
"name": "Automatically Split E2E Tasks (Atomizer)",
@@ -322,17 +355,6 @@
"path": "/ci/features/flaky-tasks",
"tags": []
},
"/ci/features/dynamic-agents": {
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
"description": "Learn how to dynamically allocate agents based on the size of a PR, keeping the balance of speed and cost.",
"mediaImage": "",
"file": "nx-cloud/features/dynamic-agents",
"itemList": [],
"isExternal": false,
"path": "/ci/features/dynamic-agents",
"tags": []
},
"/ci/features/explain-with-ai": {
"id": "explain-with-ai",
"name": "Explain With AI",
@@ -881,6 +903,39 @@
"isExternal": false,
"path": "/ci/recipes/enterprise/conformance",
"tags": []
},
{
"id": "polygraph",
"name": "Polygraph",
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
"mediaImage": "",
"file": "nx-cloud/enterprise/polygraph",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/polygraph",
"tags": ["polygraph"]
},
{
"id": "metadata-only-workspace",
"name": "Metadata Only Workspaces",
"description": "",
"mediaImage": "",
"file": "nx-cloud/enterprise/metadata-only-workspace",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/metadata-only-workspace",
"tags": ["polygraph"]
},
{
"id": "custom-workflows",
"name": "Custom Workflows",
"description": "",
"mediaImage": "",
"file": "nx-cloud/enterprise/custom-workflows",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/custom-workflows",
"tags": ["polygraph"]
}
],
"isExternal": false,
@@ -1554,6 +1609,39 @@
"isExternal": false,
"path": "/ci/recipes/enterprise/conformance",
"tags": []
},
{
"id": "polygraph",
"name": "Polygraph",
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
"mediaImage": "",
"file": "nx-cloud/enterprise/polygraph",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/polygraph",
"tags": ["polygraph"]
},
{
"id": "metadata-only-workspace",
"name": "Metadata Only Workspaces",
"description": "",
"mediaImage": "",
"file": "nx-cloud/enterprise/metadata-only-workspace",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/metadata-only-workspace",
"tags": ["polygraph"]
},
{
"id": "custom-workflows",
"name": "Custom Workflows",
"description": "",
"mediaImage": "",
"file": "nx-cloud/enterprise/custom-workflows",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/custom-workflows",
"tags": ["polygraph"]
}
],
"isExternal": false,
@@ -1782,6 +1870,39 @@
"path": "/ci/recipes/enterprise/conformance/publish-conformance-rules-to-nx-cloud",
"tags": ["conformance"]
},
"/ci/recipes/enterprise/polygraph": {
"id": "polygraph",
"name": "Polygraph",
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
"mediaImage": "",
"file": "nx-cloud/enterprise/polygraph",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/polygraph",
"tags": ["polygraph"]
},
"/ci/recipes/enterprise/metadata-only-workspace": {
"id": "metadata-only-workspace",
"name": "Metadata Only Workspaces",
"description": "",
"mediaImage": "",
"file": "nx-cloud/enterprise/metadata-only-workspace",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/metadata-only-workspace",
"tags": ["polygraph"]
},
"/ci/recipes/enterprise/custom-workflows": {
"id": "custom-workflows",
"name": "Custom Workflows",
"description": "",
"mediaImage": "",
"file": "nx-cloud/enterprise/custom-workflows",
"itemList": [],
"isExternal": false,
"path": "/ci/recipes/enterprise/custom-workflows",
"tags": ["polygraph"]
},
"/ci/recipes/other": {
"id": "other",
"name": "Other",
@@ -1933,6 +2054,17 @@
"path": "/ci/reference/env-vars",
"tags": []
},
{
"id": "credits-pricing",
"name": "Credit Pricing",
"description": "",
"mediaImage": "",
"file": "nx-cloud/reference/nx-cloud-credits-pricing",
"itemList": [],
"isExternal": false,
"path": "/ci/reference/credits-pricing",
"tags": []
},
{
"id": "release-notes",
"name": "Release Notes",
@@ -2015,6 +2147,17 @@
"path": "/ci/reference/env-vars",
"tags": []
},
"/ci/reference/credits-pricing": {
"id": "credits-pricing",
"name": "Credit Pricing",
"description": "",
"mediaImage": "",
"file": "nx-cloud/reference/nx-cloud-credits-pricing",
"itemList": [],
"isExternal": false,
"path": "/ci/reference/credits-pricing",
"tags": []
},
"/ci/reference/release-notes": {
"id": "release-notes",
"name": "Release Notes",
+95 -15
View File
@@ -185,9 +185,9 @@
"isExternal": false,
"children": [
{
"name": "Run Only Tasks Affected by a PR",
"path": "/ci/features/affected",
"id": "affected",
"name": "AI-Powered Self-Healing CI",
"path": "/ci/features/self-healing-ci",
"id": "self-healing-ci",
"isExternal": true,
"children": [],
"disableCollapsible": false
@@ -208,6 +208,14 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Run Only Tasks Affected by a PR",
"path": "/ci/features/affected",
"id": "affected",
"isExternal": true,
"children": [],
"disableCollapsible": false
},
{
"name": "Dynamically Allocate Agents",
"path": "/ci/features/dynamic-agents",
@@ -380,7 +388,7 @@
"disableCollapsible": false
},
{
"name": "Self-Host the Remote Cache",
"name": "Remote Cache",
"path": "/recipes/running-tasks/self-hosted-caching",
"id": "self-hosted-caching",
"isExternal": false,
@@ -5612,6 +5620,30 @@
"children": [],
"isExternal": false,
"disableCollapsible": false
},
{
"id": "fix-ci",
"path": "/reference/core-api/nx/documents/fix-ci",
"name": "fix-ci",
"children": [],
"isExternal": false,
"disableCollapsible": false
},
{
"id": "record",
"path": "/reference/core-api/nx/documents/record",
"name": "record",
"children": [],
"isExternal": false,
"disableCollapsible": false
},
{
"id": "start-ci-run",
"path": "/reference/core-api/nx/documents/start-ci-run",
"name": "start-ci-run",
"children": [],
"isExternal": false,
"disableCollapsible": false
}
],
"isExternal": false,
@@ -5944,6 +5976,14 @@
"children": [],
"isExternal": false,
"disableCollapsible": false
},
{
"id": "preset",
"path": "/reference/core-api/conformance/generators/preset",
"name": "preset",
"children": [],
"isExternal": false,
"disableCollapsible": false
}
],
"isExternal": false,
@@ -6790,9 +6830,9 @@
"isExternal": false,
"children": [
{
"name": "Run Only Tasks Affected by a PR",
"path": "/ci/features/affected",
"id": "affected",
"name": "AI-Powered Self-Healing CI",
"path": "/ci/features/self-healing-ci",
"id": "self-healing-ci",
"isExternal": false,
"children": [],
"disableCollapsible": false
@@ -6813,6 +6853,22 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Run Only Tasks Affected by a PR",
"path": "/ci/features/affected",
"id": "affected",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Dynamically Allocate Agents",
"path": "/ci/features/dynamic-agents",
"id": "dynamic-agents",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Automatically Split E2E Tasks (Atomizer)",
"path": "/ci/features/split-e2e-tasks",
@@ -6829,14 +6885,6 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Dynamically Allocate Agents",
"path": "/ci/features/dynamic-agents",
"id": "dynamic-agents",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Explain With AI",
"path": "/ci/features/explain-with-ai",
@@ -7202,6 +7250,30 @@
}
],
"disableCollapsible": false
},
{
"name": "Polygraph",
"path": "/ci/recipes/enterprise/polygraph",
"id": "polygraph",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Metadata Only Workspaces",
"path": "/ci/recipes/enterprise/metadata-only-workspace",
"id": "metadata-only-workspace",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Custom Workflows",
"path": "/ci/recipes/enterprise/custom-workflows",
"id": "custom-workflows",
"isExternal": false,
"children": [],
"disableCollapsible": false
}
],
"disableCollapsible": false
@@ -7296,6 +7368,14 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Credit Pricing",
"path": "/ci/reference/credits-pricing",
"id": "credits-pricing",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Release Notes",
"path": "/ci/reference/release-notes",
+66 -4
View File
@@ -2484,14 +2484,24 @@
"executors": {},
"generators": {},
"migrations": {
"/technologies/module-federation/api/migrations/20.5.0": {
"/technologies/module-federation/api/migrations/21.2.0-package-updates": {
"description": "",
"file": "generated/packages/module-federation/migrations/20.5.0.json",
"file": "generated/packages/module-federation/migrations/21.2.0-package-updates.json",
"hidden": false,
"name": "20.5.0",
"name": "21.2.0-package-updates",
"version": "21.2.0-beta.6",
"originalFilePath": "/packages/module-federation",
"path": "/technologies/module-federation/api/migrations/21.2.0-package-updates",
"type": "migration"
},
"/technologies/module-federation/api/migrations/20.5.0-package-updates": {
"description": "",
"file": "generated/packages/module-federation/migrations/20.5.0-package-updates.json",
"hidden": false,
"name": "20.5.0-package-updates",
"version": "20.5.0-beta.5",
"originalFilePath": "/packages/module-federation",
"path": "/technologies/module-federation/api/migrations/20.5.0",
"path": "/technologies/module-federation/api/migrations/20.5.0-package-updates",
"type": "migration"
},
"/technologies/module-federation/api/migrations/20.4.0-package-updates": {
@@ -3255,6 +3265,39 @@
"path": "/reference/core-api/nx/documents/logout",
"tags": ["login"],
"originalFilePath": "generated/cli/logout"
},
"/reference/core-api/nx/documents/fix-ci": {
"id": "fix-ci",
"name": "fix-ci",
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/fix-ci",
"itemList": [],
"isExternal": false,
"path": "/reference/core-api/nx/documents/fix-ci",
"tags": ["nx-cloud", "ci"],
"originalFilePath": "generated/cli/fix-ci"
},
"/reference/core-api/nx/documents/record": {
"id": "record",
"name": "record",
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/record",
"itemList": [],
"isExternal": false,
"path": "/reference/core-api/nx/documents/record",
"tags": ["nx-cloud", "ci"],
"originalFilePath": "generated/cli/record"
},
"/reference/core-api/nx/documents/start-ci-run": {
"id": "start-ci-run",
"name": "start-ci-run",
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/start-ci-run",
"itemList": [],
"isExternal": false,
"path": "/reference/core-api/nx/documents/start-ci-run",
"tags": ["nx-cloud", "ci"],
"originalFilePath": "generated/cli/start-ci-run"
}
},
"root": "/packages/nx",
@@ -4934,6 +4977,16 @@
}
},
"migrations": {
"/technologies/build-tools/vite/api/migrations/21.3.0-package-updates": {
"description": "",
"file": "generated/packages/vite/migrations/21.3.0-package-updates.json",
"hidden": false,
"name": "21.3.0-package-updates",
"version": "21.3.0-beta.3",
"originalFilePath": "/packages/vite",
"path": "/technologies/build-tools/vite/api/migrations/21.3.0-package-updates",
"type": "migration"
},
"/technologies/build-tools/vite/api/migrations/21.2.0-package-updates": {
"description": "",
"file": "generated/packages/vite/migrations/21.2.0-package-updates.json",
@@ -5577,6 +5630,15 @@
"originalFilePath": "/libs/nx-packages/conformance/src/generators/create-rule/schema.json",
"path": "/reference/core-api/conformance/generators/create-rule",
"type": "generator"
},
"/reference/core-api/conformance/generators/preset": {
"description": "Nx workspace preset which includes a working conformance rule",
"file": "external-generated/packages/conformance/generators/preset.json",
"hidden": false,
"name": "preset",
"originalFilePath": "/libs/nx-packages/conformance/src/generators/preset/schema.json",
"path": "/reference/core-api/conformance/generators/preset",
"type": "generator"
}
},
"migrations": {},
+52 -19
View File
@@ -413,14 +413,14 @@
"file": "",
"itemList": [
{
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "",
"id": "self-healing-ci",
"name": "AI-Powered Self-Healing CI",
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
"mediaImage": "",
"file": "",
"itemList": [],
"isExternal": true,
"path": "/ci/features/affected",
"path": "/ci/features/self-healing-ci",
"tags": []
},
{
@@ -445,6 +445,17 @@
"path": "/ci/features/distribute-task-execution",
"tags": []
},
{
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "",
"mediaImage": "",
"file": "",
"itemList": [],
"isExternal": true,
"path": "/ci/features/affected",
"tags": []
},
{
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
@@ -595,14 +606,14 @@
"file": "",
"itemList": [
{
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "",
"id": "self-healing-ci",
"name": "AI-Powered Self-Healing CI",
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
"mediaImage": "",
"file": "",
"itemList": [],
"isExternal": true,
"path": "/ci/features/affected",
"path": "/ci/features/self-healing-ci",
"tags": []
},
{
@@ -627,6 +638,17 @@
"path": "/ci/features/distribute-task-execution",
"tags": []
},
{
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "",
"mediaImage": "",
"file": "",
"itemList": [],
"isExternal": true,
"path": "/ci/features/affected",
"tags": []
},
{
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
@@ -665,15 +687,15 @@
"path": "/features/ci-features",
"tags": []
},
"/ci/features/affected": {
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "",
"/ci/features/self-healing-ci": {
"id": "self-healing-ci",
"name": "AI-Powered Self-Healing CI",
"description": "Learn how Nx Cloud Self-Healing CI uses AI to automatically detect, analyze, and fix CI failures, eliminating the need to babysit PRs.",
"mediaImage": "",
"file": "",
"itemList": [],
"isExternal": true,
"path": "/ci/features/affected",
"path": "/ci/features/self-healing-ci",
"tags": []
},
"/ci/features/remote-cache": {
@@ -698,6 +720,17 @@
"path": "/ci/features/distribute-task-execution",
"tags": []
},
"/ci/features/affected": {
"id": "affected",
"name": "Run Only Tasks Affected by a PR",
"description": "",
"mediaImage": "",
"file": "",
"itemList": [],
"isExternal": true,
"path": "/ci/features/affected",
"tags": []
},
"/ci/features/dynamic-agents": {
"id": "dynamic-agents",
"name": "Dynamically Allocate Agents",
@@ -924,8 +957,8 @@
},
{
"id": "self-hosted-caching",
"name": "Self-Host the Remote Cache",
"description": "Host the remote cache without using Nx Cloud",
"name": "Remote Cache",
"description": "Different options of hosting remote cache",
"mediaImage": "",
"file": "shared/recipes/running-tasks/self-hosted-caching",
"itemList": [],
@@ -1673,8 +1706,8 @@
},
{
"id": "self-hosted-caching",
"name": "Self-Host the Remote Cache",
"description": "Host the remote cache without using Nx Cloud",
"name": "Remote Cache",
"description": "Different options of hosting remote cache",
"mediaImage": "",
"file": "shared/recipes/running-tasks/self-hosted-caching",
"itemList": [],
@@ -1832,8 +1865,8 @@
},
"/recipes/running-tasks/self-hosted-caching": {
"id": "self-hosted-caching",
"name": "Self-Host the Remote Cache",
"description": "Host the remote cache without using Nx Cloud",
"name": "Remote Cache",
"description": "Different options of hosting remote cache",
"mediaImage": "",
"file": "shared/recipes/running-tasks/self-hosted-caching",
"itemList": [],
+71 -2
View File
@@ -856,10 +856,10 @@
],
"self-hosted-caching": [
{
"description": "Host the remote cache without using Nx Cloud",
"description": "Different options of hosting remote cache",
"file": "shared/recipes/running-tasks/self-hosted-caching",
"id": "self-hosted-caching",
"name": "Self-Host the Remote Cache",
"name": "Remote Cache",
"path": "/recipes/running-tasks/self-hosted-caching"
}
],
@@ -1612,6 +1612,29 @@
"path": "/ci/recipes/enterprise/single-tenant/overview"
}
],
"polygraph": [
{
"description": "Enterprise features for visualizing dependencies and enforcing standards across multiple repositories",
"file": "nx-cloud/enterprise/polygraph",
"id": "polygraph",
"name": "Polygraph",
"path": "/ci/recipes/enterprise/polygraph"
},
{
"description": "",
"file": "nx-cloud/enterprise/metadata-only-workspace",
"id": "metadata-only-workspace",
"name": "Metadata Only Workspaces",
"path": "/ci/recipes/enterprise/metadata-only-workspace"
},
{
"description": "",
"file": "nx-cloud/enterprise/custom-workflows",
"id": "custom-workflows",
"name": "Custom Workflows",
"path": "/ci/recipes/enterprise/custom-workflows"
}
],
"docker": [
{
"description": "",
@@ -1638,5 +1661,51 @@
"name": "affected",
"path": "/reference/core-api/nx/documents/affected"
}
],
"nx-cloud": [
{
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/fix-ci",
"id": "fix-ci",
"name": "fix-ci",
"path": "/reference/core-api/nx/documents/fix-ci"
},
{
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/record",
"id": "record",
"name": "record",
"path": "/reference/core-api/nx/documents/record"
},
{
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/start-ci-run",
"id": "start-ci-run",
"name": "start-ci-run",
"path": "/reference/core-api/nx/documents/start-ci-run"
}
],
"ci": [
{
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/fix-ci",
"id": "fix-ci",
"name": "fix-ci",
"path": "/reference/core-api/nx/documents/fix-ci"
},
{
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/record",
"id": "record",
"name": "record",
"path": "/reference/core-api/nx/documents/record"
},
{
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/start-ci-run",
"id": "start-ci-run",
"name": "start-ci-run",
"path": "/reference/core-api/nx/documents/start-ci-run"
}
]
}
+56 -3
View File
@@ -2703,12 +2703,22 @@
"migrations": [
{
"description": "",
"file": "generated/packages/module-federation/migrations/20.5.0.json",
"file": "generated/packages/module-federation/migrations/21.2.0-package-updates.json",
"hidden": false,
"name": "20.5.0",
"name": "21.2.0-package-updates",
"version": "21.2.0-beta.6",
"originalFilePath": "/packages/module-federation",
"path": "module-federation/migrations/21.2.0-package-updates",
"type": "migration"
},
{
"description": "",
"file": "generated/packages/module-federation/migrations/20.5.0-package-updates.json",
"hidden": false,
"name": "20.5.0-package-updates",
"version": "20.5.0-beta.5",
"originalFilePath": "/packages/module-federation",
"path": "module-federation/migrations/20.5.0",
"path": "module-federation/migrations/20.5.0-package-updates",
"type": "migration"
},
{
@@ -3517,6 +3527,39 @@
"path": "nx/documents/logout",
"tags": ["login"],
"originalFilePath": "generated/cli/logout"
},
{
"id": "fix-ci",
"name": "fix-ci",
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/fix-ci",
"itemList": [],
"isExternal": false,
"path": "nx/documents/fix-ci",
"tags": ["nx-cloud", "ci"],
"originalFilePath": "generated/cli/fix-ci"
},
{
"id": "record",
"name": "record",
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/record",
"itemList": [],
"isExternal": false,
"path": "nx/documents/record",
"tags": ["nx-cloud", "ci"],
"originalFilePath": "generated/cli/record"
},
{
"id": "start-ci-run",
"name": "start-ci-run",
"description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
"file": "generated/packages/nx/documents/start-ci-run",
"itemList": [],
"isExternal": false,
"path": "nx/documents/start-ci-run",
"tags": ["nx-cloud", "ci"],
"originalFilePath": "generated/cli/start-ci-run"
}
],
"executors": [
@@ -5302,6 +5345,16 @@
}
],
"migrations": [
{
"description": "",
"file": "generated/packages/vite/migrations/21.3.0-package-updates.json",
"hidden": false,
"name": "21.3.0-package-updates",
"version": "21.3.0-beta.3",
"originalFilePath": "/packages/vite",
"path": "vite/migrations/21.3.0-package-updates",
"type": "migration"
},
{
"description": "",
"file": "generated/packages/vite/migrations/21.2.0-package-updates.json",
@@ -7,7 +7,7 @@
"$schema": "http://json-schema.org/draft-07/schema",
"title": "Schema for Webpack Browser",
"description": "Builds an Angular application using [webpack](https://webpack.js.org/).",
"examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:browser` builder provided by the Angular CLI. It builds an Angular application using [webpack](https://webpack.js.org/).\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:webpack-browser` executor also supports the following:\n\n- Providing a custom webpack configuration\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:webpack-browser` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Webpack when using the `@nx/angular:webpack-browser` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom webpack configuration\" %}\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,\"8-10\"] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Incrementally Building your Application\" %}\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n{% callout type=\"note\" title=\"Performance\" %}\nThere may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n{% /callout %}\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
"examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:browser` builder provided by the Angular CLI. It builds an Angular application using [webpack](https://webpack.js.org/).\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:webpack-browser` executor also supports the following:\n\n- Providing a custom webpack configuration\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:webpack-browser` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Webpack when using the `@nx/angular:webpack-browser` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom webpack configuration\" %}\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,\"8-10\"] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Incrementally Building your Application\" %}\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n{% callout type=\"note\" title=\"Performance\" %}\nThere may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n{% /callout %}\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Using a custom index.html transformer\" %}\n\nThe executor supports providing a custom function to transform the `index.html` file after it has been generated. This allows you to modify the HTML content before it is written to disk.\n\nTo use a custom index.html transformer, create a file with a function that exports the transformer:\n\n```javascript {% fileName=\"apps/appName/index-html-transformer.js\" %}\nmodule.exports = (target, indexHtml) => {\n // Add a custom meta tag\n const customMeta = `<meta name=\"custom-meta\" content=\"Custom value\">`;\n return indexHtml.replace('</head>', `${customMeta}\\n</head>`);\n};\n```\n\nThe transformer function receives two parameters:\n\n- `target`: The Angular build target configuration object containing properties like `project`, `target`, and `configuration`\n- `indexHtml`: The generated HTML content as a string\n\nThen update your `project.json` to use the transformer:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n ...\n \"targets\": {\n \"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"indexHtmlTransformer\": \"apps/appName/index-html-transformer.js\"\n }\n },\n ...\n }\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
"type": "object",
"presets": [
{
@@ -553,7 +553,7 @@
"additionalProperties": false
},
"indexHtmlTransformer": {
"description": "Path to transformer function to transform the index.html",
"description": "Path to a file containing a function to transform the index.html. The function should have the signature: `(target: Target, indexHtml: string) => string`, where `target` is the build target configuration and `indexHtml` is the original HTML content.",
"type": "string",
"alias": "indexFileTransformer"
},
@@ -140,7 +140,7 @@
"default": true
}
},
"examplesFile": "Linter can be configured in multiple ways. The basic way is to provide only `lintFilePatterns`, which is a mandatory property. This tells us where to look for files to lint.\n\n`project.json`:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Fixing linter issues\" %}\n\nLinter provides an automated way of fixing known issues. To ensure that those changes are properly cached, we need to add an `outputs` property to the `lint` target. Omitting the `outputs` property would produce an invalid cache record. Both of these properties are set by default when scaffolding a new project.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\nWith these settings, we can run the command with a `--fix` flag:\n\n```bash\nnx run frontend:lint --fix\n```\n\nWe can also set this flag via project configuration to always fix files when running lint:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"fix\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Custom output format\" %}\n\nESLint executor uses the `stylish` output format by default. You can change this by specifying the `format` property:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"format\": \"compact\"\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Silence warnings\" %}\n\nMigrated or legacy projects tend to have an overwhelming amount of lint errors. We might want to change those temporarily to be warnings so they don't block the development. But they would still clutter the report. We can run the command with `--quiet` to hide warning (errors would still break the lint):\n\n```bash\nnx run frontend:lint --quiet\n```\n\nWe can also set this via project configuration as a default option.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"quiet\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Flat Config file\" %}\n\n`ESLint` provides several ways of specifying the configuration. The default one is using `.eslintrc.json` but you can override it by setting the `eslintConfig` flag. The new `Flat Config` is now also supported:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"eslintConfig\": \"eslint.config.cjs\"\n }\n}\n```\n\n**Note:** In contrast to other configuration formats, the `Flat Config` requires that all configuration files are converted to `eslint.config.cjs`. Built-in migrations and generators support only `.eslintrc.json` at the moment.\n\n{% /tab %}\n{% /tabs %}\n\n---\n",
"examplesFile": "Linter can be configured in multiple ways. The basic way is to provide only `lintFilePatterns`, which tells us where to look for files to lint. If not specified, it defaults to `['{projectRoot}']`.\n\n`project.json`:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Fixing linter issues\" %}\n\nLinter provides an automated way of fixing known issues. To ensure that those changes are properly cached, we need to add an `outputs` property to the `lint` target. Omitting the `outputs` property would produce an invalid cache record. Both of these properties are set by default when scaffolding a new project.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"]\n }\n}\n```\n\nWith these settings, we can run the command with a `--fix` flag:\n\n```bash\nnx run frontend:lint --fix\n```\n\nWe can also set this flag via project configuration to always fix files when running lint:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"fix\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Custom output format\" %}\n\nESLint executor uses the `stylish` output format by default. You can change this by specifying the `format` property:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"format\": \"compact\"\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Silence warnings\" %}\n\nMigrated or legacy projects tend to have an overwhelming amount of lint errors. We might want to change those temporarily to be warnings so they don't block the development. But they would still clutter the report. We can run the command with `--quiet` to hide warning (errors would still break the lint):\n\n```bash\nnx run frontend:lint --quiet\n```\n\nWe can also set this via project configuration as a default option.\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"quiet\": true\n }\n}\n```\n\n{% /tab %}\n{% tab label=\"Flat Config file\" %}\n\n`ESLint` provides several ways of specifying the configuration. The default one is using `.eslintrc.json` but you can override it by setting the `eslintConfig` flag. The new `Flat Config` is now also supported:\n\n```json\n\"lint\": {\n \"executor\": \"@nx/eslint:lint\",\n \"outputs\": [\"{options.outputFile}\"],\n \"options\": {\n \"lintFilePatterns\": [\"apps/frontend/**/*.ts\"],\n \"eslintConfig\": \"eslint.config.cjs\"\n }\n}\n```\n\n**Note:** In contrast to other configuration formats, the `Flat Config` requires that all configuration files are converted to `eslint.config.cjs`. Built-in migrations and generators support only `.eslintrc.json` at the moment.\n\n{% /tab %}\n{% /tabs %}\n\n---\n",
"presets": []
},
"hasher": "./src/executors/lint/hasher",
@@ -0,0 +1,29 @@
{
"name": "20.5.0-package-updates",
"version": "20.5.0-beta.5",
"packages": {
"@module-federation/enhanced": {
"version": "^0.9.0",
"alwaysAddToPackageJson": false
},
"@module-federation/runtime": {
"version": "^0.9.0",
"alwaysAddToPackageJson": false
},
"@module-federation/sdk": {
"version": "^0.9.0",
"alwaysAddToPackageJson": false
},
"@module-federation/node": {
"version": "^2.6.26",
"alwaysAddToPackageJson": false
}
},
"aliases": [],
"description": "",
"hidden": false,
"implementation": "",
"path": "/packages/module-federation",
"schema": null,
"type": "migration"
}
@@ -1,27 +0,0 @@
{
"name": "20.5.0",
"version": "20.5.0-beta.5",
"@module-federation/enhanced": {
"version": "^0.9.0",
"alwaysAddToPackageJson": false
},
"@module-federation/runtime": {
"version": "^0.9.0",
"alwaysAddToPackageJson": false
},
"@module-federation/sdk": {
"version": "^0.9.0",
"alwaysAddToPackageJson": false
},
"@module-federation/node": {
"version": "^2.6.26",
"alwaysAddToPackageJson": false
},
"aliases": [],
"description": "",
"hidden": false,
"implementation": "",
"path": "/packages/module-federation",
"schema": null,
"type": "migration"
}
@@ -0,0 +1,25 @@
{
"name": "21.2.0-package-updates",
"version": "21.2.0-beta.6",
"packages": {
"@module-federation/enhanced": {
"version": "^0.15.0",
"alwaysAddToPackageJson": false
},
"@module-federation/runtime": {
"version": "^0.15.0",
"alwaysAddToPackageJson": false
},
"@module-federation/sdk": {
"version": "^0.15.0",
"alwaysAddToPackageJson": false
}
},
"aliases": [],
"description": "",
"hidden": false,
"implementation": "",
"path": "/packages/module-federation",
"schema": null,
"type": "migration"
}
@@ -239,27 +239,32 @@ And if you generated a library with `--bundler`, then you can build a library as
nx build my-new-lib
```
After running a build, the output will be in the `{workspaceRoot}/dist/{projectRoot}` folder.
After running a build, the output will be in the `.next` folder inside your app's project directory by default. The output directory can be changed through configuration.
{% tabs %}
{% tab label="Using inferred tasks" %}
{% tab label="@nx/next/plugin and next.config.js" %}
You can customize the output folder path by update the bundler's config. For example vite's config can be updated in `vite.config.ts`:
You can customize the output folder path by updating the Next.js config. For example, you can set a custom `distDir` in `next.config.js`:
```typescript {% fileName="apps/my-next-app/vite.config.ts" highlightLines=[4]%}
import { defineConfig } from 'vite';
export default defineConfig(() => ({
build: {
outDir: 'dist/my-next-app',
},
}));
```javascript {% fileName="apps/my-next-app/next.config.js" highlightLines=[2]%}
const nextConfig = {
distDir: 'dist',
};
module.exports = nextConfig;
```
Note: This approach works best if you have `@nx/next/plugin` installed in your `nx.json`. You can add it with `nx add @nx/next`.
{% /tab %}
{% tab label="Using the @nx/next:build executor" %}
{% callout type="note" title="Legacy Configuration" %}
This approach is for projects not using the `@nx/next/plugin` in `nx.json`. If you have the plugin configured, it will automatically infer tasks from your Next.js configuration. See the [Inferred Tasks concept page](/concepts/inferred-tasks) for more details.
{% /callout %}
You can customize the output folder by setting `outputPath` in the project's `project.json` file
```json {% fileName="apps/my-next-app/project.json" highlightLines=[9]%}
@@ -278,6 +283,8 @@ You can customize the output folder by setting `outputPath` in the project's `pr
}
```
Note that the `sourceRoot` property may not exist for all Next.js applications, as it depends on your project structure.
{% /tab %}
{% /tabs %}
@@ -106,6 +106,7 @@ Print the task graph to the console:
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
@@ -0,0 +1,24 @@
---
title: 'fix-ci - CLI command'
description: 'Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).'
---
# fix-ci
Fixes CI failures. This command is an alias for [`nx-cloud fix-ci`](/ci/reference/nx-cloud-cli#npx-nxcloud-fix-ci).
## Usage
```shell
nx fix-ci [options]
```
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
## Options
| Option | Type | Description |
| ----------- | ------- | ---------------------------------------------------------------------- |
| `--help` | boolean | Show help. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
## Options
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
@@ -17,17 +17,17 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
## Options
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. (Default: `true`) |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
| Option | Type | Description |
| ---------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--all` | boolean | Format all projects. |
| `--base` | string | Base of the current branch (usually main). |
| `--exclude` | string | Exclude certain projects from being processed. |
| `--files` | string | Change the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas or spaces. |
| `--head` | string | Latest commit of the current branch (usually HEAD). |
| `--help` | boolean | Show help. |
| `--libs-and-apps` | boolean | Format only libraries and applications files. |
| `--projects` | string | Projects to format (comma/space delimited). |
| `--sort-root-tsconfig-paths` | boolean | Ensure the workspace's tsconfig compilerOptions.paths are sorted. Warning: This will cause comments in the tsconfig to be lost. The default value is "true" unless NX_FORMAT_SORT_TSCONFIG_PATHS is set to "false". |
| `--uncommitted` | boolean | Uncommitted changes. |
| `--untracked` | boolean | Untracked changes. |
| `--version` | boolean | Show version number. |
@@ -0,0 +1,24 @@
---
title: 'record - CLI command'
description: 'Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).'
---
# record
Records a command execution for distributed task execution. This command is an alias for [`nx-cloud record`](/ci/reference/nx-cloud-cli#npx-nxcloud-record).
## Usage
```shell
nx record [options]
```
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
## Options
| Option | Type | Description |
| ----------- | ------- | ---------------------------------------------------------------------- |
| `--help` | boolean | Show help. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
@@ -110,6 +110,7 @@ Print the task graph to the console:
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
| `--targets`, `--target`, `--t` | string | Tasks to run for affected projects. |
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |
@@ -83,6 +83,7 @@ Run's a target named build:test for the myapp project. Note the quotes around th
| `--skipNxCache`, `--disableNxCache` | boolean | Rerun the tasks even when the results are available in the cache. (Default: `false`) |
| `--skipRemoteCache`, `--disableRemoteCache` | boolean | Disables the remote cache. (Default: `false`) |
| `--skipSync` | boolean | Skips running the sync generators associated with the tasks. (Default: `false`) |
| `--tui` | boolean | Enable or disable the Nx Terminal UI. |
| `--tuiAutoExit` | string | Whether or not to exit the TUI automatically after all tasks finish, and after how long. If set to `true`, the TUI will exit immediately. If set to `false` the TUI will not automatically exit. If set to a number, an interruptible countdown popup will be shown for that many seconds before the TUI exits. |
| `--verbose` | boolean | Prints additional information about the commands (e.g., stack traces). |
| `--version` | boolean | Show version number. |

Some files were not shown because too many files have changed in this diff Show More