chore(core): try new nx patch

## Current Behavior
The `createConfig` helper from `@nx/angular-rspack` became an async
function.
This meant that the handling of custom webpack configs in the migration
done by `convert-to-rspack` was incorrect.

## Expected Behavior
Ensure the migration is handled correctly.
Ensure that Module Federation migrations work correctly.

## Related Issues
Fixes https://github.com/nrwl/angular-rspack/issues/53

.github/ISSUE_TEMPLATE/1-bug.yml

@@ -60,7 +60,7 @@ body:
       label: Package Manager Version
       description: |
         If `nx report` doesn't work, please provide the name and the version of your package manager.
-        You can get version information by running `yarn --version`, `pnpm --version` or `npm --version`, depending on the package manager used.
+        You can get version information by running `PACKAGE_MANAGER --version`, where PACKAGE_MANAGER is any of `yarn`, `pnpm`, `bun` or `npm`, depending on the package manager used.
   - type: checkboxes
     id: os
     attributes:

.github/workflows/ci.yml

@@ -22,24 +22,25 @@ jobs:
       NX_NATIVE_LOGGING: 'false'
       NX_E2E_RUN_E2E: 'true'
       NX_CI_EXECUTION_ENV: 'linux'
-      NX_CLOUD_DTE_V2: 'true'
-      NX_CLOUD_DTE_SUMMARY: 'true'
       NX_CLOUD_NO_TIMEOUTS: 'true'
-      
+      NX_CLOUD_USE_NEW_STREAM_OUTPUT: 'true'
+
     steps:
       - name: Checkout
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 0
+          filter: tree:0
 
       - name: Fetch Master
         run: git fetch origin master:master
         if: ${{ github.event_name == 'pull_request' }}
-        
 
       - name: Set SHAs
         uses: nrwl/nx-set-shas@v4
-      
+        with:
+          main-branch-name: 'master'
+
       - name: Start CI Run
         run: npx nx-cloud@next start-ci-run --distribute-on="./.nx/workflows/dynamic-changesets.yaml" --stop-agents-after="e2e"
 
@@ -65,33 +66,8 @@ jobs:
       - name: Install Rust
         uses: dtolnay/rust-toolchain@stable
 
-      - name: Check Documentation
-        run: pnpm nx documentation
-        timeout-minutes: 20
-
-      - name: Run Checks/Lint/Test/Build
-        run: |
-          pids=()
-
-          pnpm nx-cloud record -- nx format:check --base=$NX_BASE --head=$NX_HEAD &
-          pids+=($!)
-
-          pnpm nx-cloud record -- nx sync:check
-          pids+=($!)
-
-          pnpm nx-cloud record -- nx-cloud conformance:check
-          pids+=($!)
-
-          pnpm nx run-many -t check-imports check-commit check-lock-files check-codeowners --parallel=1 --no-dte &
-          pids+=($!)
-
-          pnpm nx affected --targets=lint,test,build,e2e,e2e-ci --base=$NX_BASE --head=$NX_HEAD --parallel=3 &
-          pids+=($!)
-
-          for pid in "${pids[@]}"; do
-            wait "$pid"
-          done
-        timeout-minutes: 100
+      - name: Test
+        run: npx nx run @nx/nx-source:populate-local-registry-storage
 
   main-macos:
     runs-on: macos-latest
@@ -102,16 +78,17 @@ jobs:
       SELECTED_PM: 'npm'
     steps:
       - name: Checkout
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 0
+          filter: tree:0
 
       - name: Fetch Master
         run: git fetch origin master:master
         if: ${{ github.event_name == 'pull_request' }}
 
       - name: Restore Homebrew packages
-        uses: actions/cache@v3
+        uses: actions/cache@v4
         with:
           path: |
             /usr/local/Homebrew
@@ -126,7 +103,7 @@ jobs:
         timeout-minutes: 20
 
       - name: Save Homebrew Cache
-        uses: actions/cache@v3
+        uses: actions/cache@v4
         with:
           path: |
             /usr/local/Homebrew
@@ -149,6 +126,8 @@ jobs:
 
       - name: Set SHAs
         uses: nrwl/nx-set-shas@v4
+        with:
+          main-branch-name: 'master'
 
       - name: Run E2E Tests for macOS
         run: |
@@ -157,4 +136,4 @@ jobs:
             pnpm nx affected -t e2e-macos-local --parallel=1 --base=$NX_BASE --head=$NX_HEAD
           else
             echo "Skip E2E tests for macOS as there are no changes in React Native projects."
-          fi
+          fi

.github/workflows/e2e-matrix.yml

@@ -24,24 +24,28 @@ jobs:
         os:
           - ubuntu-latest
           - macos-latest
+          - windows-latest
         node_version:
-          - 18
           - 20
           - 22
           # - 23
         exclude:
-          # run just node v20 on macos
-          - os: macos-latest
-            node_version: 18
+          # run just node v20 on macos and windows
           - os: macos-latest
             node_version: 22
           # - os: macos-latest
           #   node_version: 23
+          - os: windows-latest
+            node_version: 22
+          # - os: windows-latest
+          #   node_version: 23
 
     name: Cache install (${{ matrix.os }}, node v${{ matrix.node_version }})
     steps:
       - name: Checkout
         uses: actions/checkout@v4
+        with:
+          fetch-depth: 1
 
       - uses: pnpm/action-setup@v4
         name: Install pnpm
@@ -99,300 +103,41 @@ jobs:
         if: steps.cache-cypress.outputs.cache-hit != 'true'
         run: npx cypress install
 
+  prepare-matrix:
+    name: Prepare matrix combinations
+    if: ${{ github.repository_owner == 'nrwl' }}
+    runs-on: ubuntu-latest
+    outputs:
+      matrix: ${{ steps.process-json.outputs.MATRIX }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 1
+
+      - name: Process matrix data
+        id: process-json
+        run:
+          echo "MATRIX=$(npx tsx .github/workflows/nightly/process-matrix.ts | jq -c .)" >> $GITHUB_OUTPUT
+
   e2e:
     if: ${{ github.repository_owner == 'nrwl' }}
-    needs: preinstall
+    needs:
+      - preinstall
+      - prepare-matrix
     permissions:
       contents: read
     runs-on: ${{ matrix.os }}
-    timeout-minutes: 90
     strategy:
-      matrix:
-        os:
-          - ubuntu-latest
-          - macos-latest
-        node_version:
-          - 18
-          - 20
-          - 22
-          # - 23
-        package_manager:
-          - npm
-          - yarn
-          - pnpm
-        project:
-          - e2e-angular
-          - e2e-cypress
-          - e2e-detox
-          - e2e-esbuild
-          - e2e-eslint
-          - e2e-expo
-          - e2e-gradle
-          - e2e-jest
-          - e2e-js
-          - e2e-lerna-smoke-tests
-          - e2e-next
-          - e2e-node
-          - e2e-nuxt
-          - e2e-nx-init
-          - e2e-nx
-          - e2e-playwright
-          - e2e-plugin
-          - e2e-react
-          - e2e-react-native
-          - e2e-release
-          - e2e-remix
-          - e2e-rollup
-          - e2e-storybook
-          - e2e-vite
-          - e2e-vue
-          - e2e-web
-          - e2e-webpack
-          - e2e-workspace-create
-        include:
-          # os short names
-          - os: ubuntu-latest
-            os_name: 'Linux'
-          - os: macos-latest
-            os_name: 'MacOS'
-          # test timeouts
-          - os: ubuntu-latest
-            os_timeout: 60
-          - os: macos-latest
-            os_timeout: 90
-          # codeowner groups
-          - project: e2e-angular
-            codeowners: 'S04SS457V38'
-          - project: e2e-cypress
-            codeowners: 'S04T16BTJJY'
-          - project: e2e-detox
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-esbuild
-            codeowners: 'S04SJ6HHP0X'
-          - project: e2e-expo
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-gradle
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-jest
-            codeowners: 'S04T16BTJJY'
-          - project: e2e-js
-            codeowners: 'S04SJ6HHP0X'
-          - project: e2e-lerna-smoke-tests
-            codeowners: 'S04TNCVEETS'
-          - project: e2e-eslint
-            codeowners: 'S04SYJGKSCT'
-          - project: e2e-next
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-node
-            codeowners: 'S04SJ6HHP0X'
-          - project: e2e-nx-init
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-nx
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-plugin
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-release
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-react
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-react-native
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-web
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-rollup
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-storybook
-            codeowners: 'S04SVQ8H0G5'
-          - project: e2e-playwright
-            codeowners: 'S04SVQ8H0G5'
-          - project: e2e-remix
-            codeowners: 'S04SVQ8H0G5'
-          - project: e2e-vite
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-vue
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-nuxt
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-webpack
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-workspace-create
-            codeowners: 'S04SYHYKGNP'
-        exclude:
-          # exclude react-native tests from ubuntu
-          - os: ubuntu-latest
-            project: e2e-react-native
-          - os: ubuntu-latest
-            project: e2e-detox
-          - os: ubuntu-latest
-            project: e2e-expo
-          # exclude non-CNW/Lerna tests from non-LTS node versions
-          - node_version: 18
-            project: e2e-angular
-          - node_version: 18
-            project: e2e-cypress
-          - node_version: 18
-            project: e2e-detox
-          - node_version: 18
-            project: e2e-esbuild
-          - node_version: 18
-            project: e2e-expo
-          - node_version: 18
-            project: e2e-gradle
-          - node_version: 18
-            project: e2e-jest
-          - node_version: 18
-            project: e2e-js
-          - node_version: 18
-            project: e2e-eslint
-          - node_version: 18
-            project: e2e-next
-          - node_version: 18
-            project: e2e-node
-          - node_version: 18
-            project: e2e-nuxt
-          - node_version: 18
-            project: e2e-nx-init
-          - node_version: 18
-            project: e2e-nx
-          - node_version: 18
-            project: e2e-plugin
-          - node_version: 18
-            project: e2e-playwright
-          - node_version: 18
-            project: e2e-react
-          - node_version: 18
-            project: e2e-react-native
-          - node_version: 18
-            project: e2e-web
-          - node_version: 18
-            project: e2e-remix
-          - node_version: 18
-            project: e2e-rollup
-          - node_version: 18
-            project: e2e-storybook
-          - node_version: 18
-            project: e2e-vite
-          - node_version: 18
-            project: e2e-vue
-          - node_version: 18
-            project: e2e-webpack
-          - node_version: 22
-            project: e2e-angular
-          - node_version: 22
-            project: e2e-cypress
-          - node_version: 22
-            project: e2e-detox
-          - node_version: 22
-            project: e2e-esbuild
-          - node_version: 22
-            project: e2e-expo
-          - node_version: 22
-            project: e2e-gradle
-          - node_version: 22
-            project: e2e-jest
-          - node_version: 22
-            project: e2e-js
-          - node_version: 22
-            project: e2e-eslint
-          - node_version: 22
-            project: e2e-next
-          - node_version: 22
-            project: e2e-node
-          - node_version: 22
-            project: e2e-nuxt
-          - node_version: 22
-            project: e2e-nx-init
-          - node_version: 22
-            project: e2e-nx
-          - node_version: 22
-            project: e2e-plugin
-          - node_version: 22
-            project: e2e-playwright
-          - node_version: 22
-            project: e2e-react
-          - node_version: 22
-            project: e2e-react-native
-          - node_version: 22
-            project: e2e-web
-          - node_version: 22
-            project: e2e-remix
-          - node_version: 22
-            project: e2e-rollup
-          - node_version: 22
-            project: e2e-storybook
-          - node_version: 22
-            project: e2e-vite
-          - node_version: 22
-            project: e2e-vue
-          - node_version: 22
-            project: e2e-webpack
-          # - node_version: 23
-          #   project: e2e-angular
-          # - node_version: 23
-          #   project: e2e-cypress
-          # - node_version: 23
-          #   project: e2e-detox
-          # - node_version: 23
-          #   project: e2e-esbuild
-          # - node_version: 23
-          #   project: e2e-expo
-          # - node_version: 23
-          #   project: e2e-gradle
-          # - node_version: 23
-          #   project: e2e-jest
-          # - node_version: 23
-          #   project: e2e-js
-          # - node_version: 23
-          #   project: e2e-eslint
-          # - node_version: 23
-          #   project: e2e-next
-          # - node_version: 23
-          #   project: e2e-node
-          # - node_version: 23
-          #   project: e2e-nuxt
-          # - node_version: 23
-          #   project: e2e-nx-init
-          # - node_version: 23
-          #   project: e2e-nx
-          # - node_version: 23
-          #   project: e2e-plugin
-          # - node_version: 23
-          #   project: e2e-playwright
-          # - node_version: 23
-          #   project: e2e-react
-          # - node_version: 23
-          #   project: e2e-react-native
-          # - node_version: 23
-          #   project: e2e-web
-          # - node_version: 23
-          #   project: e2e-remix
-          # - node_version: 23
-          #   project: e2e-rollup
-          # - node_version: 23
-          #   project: e2e-storybook
-          # - node_version: 23
-          #   project: e2e-vite
-          # - node_version: 23
-          #   project: e2e-vue
-          # - node_version: 23
-          #   project: e2e-webpack
-          # run just npm v20 on macos
-          - os: macos-latest
-            package_manager: yarn
-          - os: macos-latest
-            package_manager: pnpm
-          - os: macos-latest
-            node_version: 18
-          - os: macos-latest
-            node_version: 22
-          # - os: macos-latest
-          #   node_version: 23
+      matrix: ${{fromJson(needs.prepare-matrix.outputs.matrix)}} # Load matrix from previous job
       fail-fast: false
 
     name: ${{ matrix.os_name }}/${{ matrix.package_manager }}/${{ matrix.node_version }} ${{ join(matrix.project) }}
     steps:
       - name: Checkout
         uses: actions/checkout@v4
+        with:
+          fetch-depth: 1
 
       - name: Prepare dir for output
         run: mkdir -p outputs
@@ -470,30 +215,28 @@ jobs:
 
       - name: Set starting timestamp
         id: before-e2e
+        shell: bash
         run: |
           echo "timestamp=$(date +%s)" >> $GITHUB_OUTPUT
 
       - name: Run e2e tests
         id: e2e-run
-        run: pnpm nx run-many -t e2e-local -p ${{ matrix.project }}
+        run: pnpm nx run ${{ matrix.project }}:e2e-local
+        shell: bash
         timeout-minutes: ${{ matrix.os_timeout }}
         env:
-          GIT_AUTHOR_EMAIL: test@test.com
-          GIT_AUTHOR_NAME: Test
-          GIT_COMMITTER_EMAIL: test@test.com
-          GIT_COMMITTER_NAME: Test
           NX_E2E_CI_CACHE_KEY: e2e-gha-${{ matrix.os }}-${{ matrix.node_version }}-${{ matrix.package_manager }}
+          NX_DAEMON: 'true'
+          NX_PERF_LOGGING: 'false'
+          NX_E2E_VERBOSE_LOGGING: 'true'
+          NX_NATIVE_LOGGING: 'false'
+          NX_E2E_RUN_E2E: 'true'
+          NX_CLOUD_NO_TIMEOUTS: 'true'
+          NX_E2E_SKIP_CLEANUP: 'true'
           NODE_OPTIONS: --max_old_space_size=8192
           SELECTED_PM: ${{ matrix.package_manager }}
           npm_config_registry: http://localhost:4872
           YARN_REGISTRY: http://localhost:4872
-          NX_CACHE_DIRECTORY: 'tmp'
-          NX_E2E_SKIP_CLEANUP: 'true'
-          NX_E2E_RUN_E2E: 'true'
-          NX_E2E_VERBOSE_LOGGING: 'true'
-          NX_PERF_LOGGING: 'false'
-          NX_DAEMON: 'true'
-          NX_SKIP_LOG_GROUPING: 'true'
 
       - name: Save matrix config in file
         if: ${{ always() }}
@@ -506,24 +249,23 @@ jobs:
           matrix=$((
             echo '${{ toJSON(matrix) }}'
           ) | jq --argjson delta $delta -c '. + { "status": "${{ steps.e2e-run.outcome}}", "duration": $delta }')
-          echo "$matrix" > matrix
-          path=outputs/${{ matrix.os_name}}-${{ matrix.node_version}}-${{ matrix.package_manager}}-${{ matrix.project }}
-          echo "path=$path" >> $GITHUB_OUTPUT
-          echo "$matrix" > $path
+          echo "$matrix" > 'outputs/matrix.json'
 
       - name: Upload matrix config
         uses: actions/upload-artifact@v4
         if: ${{ always() }}
         with:
-          name: outputs
+          name: ${{ matrix.os_name}}-${{ matrix.node_version}}-${{ matrix.package_manager}}-${{ matrix.project }}
           overwrite: true
           if-no-files-found: 'ignore'
-          path: ${{ steps.save-matrix.outputs.path }}
+          path: 'outputs/matrix.json'
 
       - name: Setup tmate session
         if: ${{ github.event_name == 'workflow_dispatch' && inputs.debug_enabled && failure() }}
         uses: mxschmitt/action-tmate@v3.8
         timeout-minutes: 15
+        with:
+          sudo: ${{ matrix.os != 'windows-latest' }} # disable sudo for windows debugging
 
   process-result:
     if: ${{ always() && github.repository_owner == 'nrwl' }}
@@ -535,16 +277,18 @@ jobs:
       pm-duration: ${{ steps.process-json.outputs.SLACK_PM_DURATION }}
       codeowners: ${{ steps.process-json.outputs.CODEOWNERS }}
     steps:
+      - name: Prepare dir for output
+        run: mkdir -p outputs
+
       - name: Load outputs
         uses: actions/download-artifact@v4
         with:
-          name: outputs
           path: outputs
 
       - name: Join and stringify matrix configs
         id: combine-json
         run: |
-          combined=$((jq -s . outputs/*) | jq tostring)
+          combined=$((jq -s . outputs/*/matrix.json) | jq tostring)
           echo "combined=$combined" >> $GITHUB_OUTPUT
 
       - name: Make slack outputs
@@ -581,6 +325,7 @@ jobs:
             });
             result += `\`\`\``;
             core.setOutput('SLACK_MESSAGE', trimSpace(result));
+            console.log(trimSpace(result));
 
             function humanizeDuration(num) {
               let res = '';
@@ -608,7 +353,7 @@ jobs:
             };
             const macosProjects = ['e2e-detox', 'e2e-expo', 'e2e-react-native'];
             combined.forEach((matrix) => {
-              if (matrix.os_name === 'Linux' && matrix.node_version === 18) {
+              if (matrix.os_name === 'Linux' && matrix.node_version === 20) {
                 pmReport[matrix.package_manager] += matrix.duration;
               }
               if (matrix.os_name === 'Linux' || macosProjects.includes(matrix.project)) {

.github/workflows/e2e-windows.yml

@@ -1,471 +0,0 @@
-name: E2E matrix (Windows)
-
-on:
-  schedule:
-    - cron: "0 5 * * *"
-  workflow_dispatch:
-    inputs:
-      debug_enabled:
-        type: boolean
-        description: 'Run the build with tmate debugging enabled (https://github.com/marketplace/actions/debugging-with-tmate)'
-        required: false
-        default: false
-
-env:
-  CYPRESS_CACHE_FOLDER: ${{ github.workspace }}/.cypress
-
-permissions: { }
-jobs:
-  preinstall:
-    if: ${{ github.repository_owner == 'nrwl' }}
-    runs-on: windows-latest
-    strategy:
-      matrix:
-        node_version:
-          - 18
-          - 20
-          - 22
-          # - 23
-
-    name: Cache install (node v${{ matrix.node_version }})
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - uses: pnpm/action-setup@v4
-        name: Install pnpm
-        with:
-          version: 9.8.0
-          run_install: false
-
-      - name: Set node
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ matrix.node_version }}
-          cache: 'pnpm'
-
-      - name: Cache node_modules
-        id: cache-modules
-        uses: actions/cache@v4
-        with:
-          lookup-only: true
-          path: '**/node_modules'
-          key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ hashFiles('pnpm-lock.yaml') }}
-
-      - name: Install packages
-        if: steps.cache-modules.outputs.cache-hit != 'true'
-        run: pnpm install --frozen-lockfile
-
-      - name: Cache Cypress
-        id: cache-cypress
-        uses: actions/cache@v4
-        with:
-          lookup-only: true
-          path: '${{ github.workspace }}/.cypress'
-          key: windows-cypress
-
-      - name: Install Cypress
-        if: steps.cache-cypress.outputs.cache-hit != 'true'
-        run: pnpm cypress install
-
-  e2e:
-    if: ${{ github.repository_owner == 'nrwl' }}
-    needs: preinstall
-    permissions:
-      contents: read
-    runs-on: windows-latest
-    strategy:
-      matrix:
-        node_version:
-          - 18
-          - 20
-          - 22
-          # - 23
-        package_manager:
-          - npm
-        project:
-          - e2e-angular
-          - e2e-cypress
-          - e2e-esbuild
-          - e2e-eslint
-          - e2e-jest
-          - e2e-js
-          - e2e-lerna-smoke-tests
-          - e2e-next
-          - e2e-node
-          - e2e-nuxt
-          - e2e-nx-init
-          - e2e-nx
-          - e2e-playwright
-          - e2e-plugin
-          - e2e-react
-          - e2e-release
-          - e2e-remix
-          - e2e-rollup
-          - e2e-storybook
-          - e2e-vite
-          - e2e-vue
-          - e2e-web
-          - e2e-webpack
-          - e2e-workspace-create
-        include:
-          # codeowner groups
-          - project: e2e-angular
-            codeowners: 'S04SS457V38'
-          - project: e2e-cypress
-            codeowners: 'S04T16BTJJY'
-          - project: e2e-esbuild
-            codeowners: 'S04SJ6HHP0X'
-          - project: e2e-jest
-            codeowners: 'S04T16BTJJY'
-          - project: e2e-js
-            codeowners: 'S04SJ6HHP0X'
-          - project: e2e-lerna-smoke-tests
-            codeowners: 'S04TNCVEETS'
-          - project: e2e-eslint
-            codeowners: 'S04SYJGKSCT'
-          - project: e2e-next
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-node
-            codeowners: 'S04SJ6HHP0X'
-          - project: e2e-nx-init
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-nx
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-plugin
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-release
-            codeowners: 'S04SYHYKGNP'
-          - project: e2e-react
-            codeowners: 'S04TNCNJG5N'
-          - project: e2e-web
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-rollup
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-storybook
-            codeowners: 'S04SVQ8H0G5'
-          - project: e2e-playwright
-            codeowners: 'S04SVQ8H0G5'
-          - project: e2e-remix
-            codeowners: 'S04SVQ8H0G5'
-          - project: e2e-vite
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-vue
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-nuxt
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-webpack
-            codeowners: 'S04SJ6PL98X'
-          - project: e2e-workspace-create
-            codeowners: 'S04SYHYKGNP'
-        exclude:
-          # exclude non-CNW/Lerna tests from non-LTS node versions
-          - node_version: 18
-            project: e2e-angular
-          - node_version: 18
-            project: e2e-cypress
-          - node_version: 18
-            project: e2e-esbuild
-          - node_version: 18
-            project: e2e-jest
-          - node_version: 18
-            project: e2e-js
-          - node_version: 18
-            project: e2e-eslint
-          - node_version: 18
-            project: e2e-next
-          - node_version: 18
-            project: e2e-node
-          - node_version: 18
-            project: e2e-nuxt
-          - node_version: 18
-            project: e2e-nx-init
-          - node_version: 18
-            project: e2e-nx
-          - node_version: 18
-            project: e2e-plugin
-          - node_version: 18
-            project: e2e-playwright
-          - node_version: 18
-            project: e2e-react
-          - node_version: 18
-            project: e2e-web
-          - node_version: 18
-            project: e2e-remix
-          - node_version: 18
-            project: e2e-rollup
-          - node_version: 18
-            project: e2e-storybook
-          - node_version: 18
-            project: e2e-vite
-          - node_version: 18
-            project: e2e-vue
-          - node_version: 18
-            project: e2e-webpack
-          - node_version: 22
-            project: e2e-angular
-          - node_version: 22
-            project: e2e-cypress
-          - node_version: 22
-            project: e2e-esbuild
-          - node_version: 22
-            project: e2e-jest
-          - node_version: 22
-            project: e2e-js
-          - node_version: 22
-            project: e2e-eslint
-          - node_version: 22
-            project: e2e-next
-          - node_version: 22
-            project: e2e-node
-          - node_version: 22
-            project: e2e-nuxt
-          - node_version: 22
-            project: e2e-nx-init
-          - node_version: 22
-            project: e2e-nx
-          - node_version: 22
-            project: e2e-plugin
-          - node_version: 22
-            project: e2e-playwright
-          - node_version: 22
-            project: e2e-react
-          - node_version: 22
-            project: e2e-web
-          - node_version: 22
-            project: e2e-remix
-          - node_version: 22
-            project: e2e-rollup
-          - node_version: 22
-            project: e2e-storybook
-          - node_version: 22
-            project: e2e-vite
-          - node_version: 22
-            project: e2e-vue
-          - node_version: 22
-            project: e2e-webpack
-          # - node_version: 23
-          #   project: e2e-angular
-          # - node_version: 23
-          #   project: e2e-cypress
-          # - node_version: 23
-          #   project: e2e-esbuild
-          # - node_version: 23
-          #   project: e2e-jest
-          # - node_version: 23
-          #   project: e2e-js
-          # - node_version: 23
-          #   project: e2e-eslint
-          # - node_version: 23
-          #   project: e2e-next
-          # - node_version: 23
-          #   project: e2e-node
-          # - node_version: 23
-          #   project: e2e-nuxt
-          # - node_version: 23
-          #   project: e2e-nx-init
-          # - node_version: 23
-          #   project: e2e-nx
-          # - node_version: 23
-          #   project: e2e-plugin
-          # - node_version: 23
-          #   project: e2e-playwright
-          # - node_version: 23
-          #   project: e2e-react
-          # - node_version: 23
-          #   project: e2e-web
-          # - node_version: 23
-          #   project: e2e-remix
-          # - node_version: 23
-          #   project: e2e-rollup
-          # - node_version: 23
-          #   project: e2e-storybook
-          # - node_version: 23
-          #   project: e2e-vite
-          # - node_version: 23
-          #   project: e2e-vue
-          # - node_version: 23
-          #   project: e2e-webpack
-      fail-fast: false
-
-    name: ${{ matrix.project }} (v${{ matrix.node_version }})
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Prepare dir for output
-        run: mkdir -p outputs
-
-      - uses: pnpm/action-setup@v4
-        name: Install pnpm
-        with:
-          version: 9.8.0
-          run_install: false
-
-      - name: Use Node.js ${{ matrix.node_version }}
-        uses: actions/setup-node@v4
-        with:
-          node-version: ${{ matrix.node_version }}
-          cache: 'pnpm'
-
-      - name: Cache node_modules
-        id: cache-modules
-        uses: actions/cache@v4
-        with:
-          path: '**/node_modules'
-          key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ github.run_id }}
-
-      - name: Install packages
-        run: pnpm install --frozen-lockfile
-
-      - name: Cache Cypress
-        id: cache-cypress
-        uses: actions/cache@v4
-        with:
-          path: '${{ github.workspace }}/.cypress'
-          key: ${{ runner.os }}-cypress
-
-      - name: Install Cypress
-        if: steps.cache-cypress.outputs.cache-hit != 'true'
-        run: npx cypress install
-
-      - name: Configure git metadata (needed for lerna smoke tests)
-        run: |
-          git config --global user.email test@test.com
-          git config --global user.name "Test Test"
-
-      - name: Run e2e tests
-        id: e2e-run
-        run: pnpm nx run ${{ matrix.project }}:e2e-local
-        shell: bash
-        timeout-minutes: 180
-        env:
-          GIT_AUTHOR_EMAIL: test@test.com
-          GIT_AUTHOR_NAME: Test
-          GIT_COMMITTER_EMAIL: test@test.com
-          GIT_COMMITTER_NAME: Test
-          NX_E2E_CI_CACHE_KEY: e2e-gha-windows-${{ matrix.node_version }}-${{ matrix.package_manager }}
-          NODE_OPTIONS: --max_old_space_size=8192
-          SELECTED_PM: ${{ matrix.package_manager }}
-          npm_config_registry: http://localhost:4872
-          NX_CACHE_DIRECTORY: 'tmp'
-          NX_E2E_SKIP_CLEANUP: 'true'
-          NX_E2E_RUN_E2E: 'true'
-          NX_E2E_VERBOSE_LOGGING: 'true'
-          NX_PERF_LOGGING: 'false'
-          NX_DAEMON: 'true'
-          NX_SKIP_LOG_GROUPING: 'true'
-
-      - name: Save matrix config in file
-        if: ${{ always() }}
-        id: save-matrix
-        shell: bash
-        run: |
-          matrix=$((
-            echo '${{ toJSON(matrix) }}'
-          ) | jq -c '. + { "status": "${{ steps.e2e-run.outcome}}" }')
-          echo "$matrix" > matrix
-          path=outputs/windows-${{ matrix.node_version}}-${{ matrix.package_manager}}-${{ matrix.project }}
-          echo "path=$path" >> $GITHUB_OUTPUT
-          echo "$matrix" > $path
-
-      - name: Upload matrix config
-        uses: actions/upload-artifact@v4
-        if: ${{ always() }}
-        with:
-          name: outputs
-          overwrite: true
-          if-no-files-found: 'ignore'
-          path: ${{ steps.save-matrix.outputs.path }}
-
-      - name: Setup tmate session
-        if: ${{ github.event_name == 'workflow_dispatch' && inputs.debug_enabled && failure() }}
-        uses: mxschmitt/action-tmate@v3.8
-        timeout-minutes: 15
-        with:
-          sudo: false # disable sudo for windows debugging
-
-  process-result:
-    if: ${{ always() && github.repository_owner == 'nrwl' }}
-    runs-on: ubuntu-latest
-    needs: e2e
-    outputs:
-      message: ${{ steps.process-json.outputs.SLACK_MESSAGE }}
-      codeowners: ${{ steps.process-json.outputs.CODEOWNERS }}
-    steps:
-      - name: Load outputs
-        uses: actions/download-artifact@v4
-        with:
-          name: outputs
-          path: outputs
-
-      - name: Join and stringify matrix configs
-        id: combine-json
-        shell: bash
-        run: |
-          combined=$((jq -s . outputs/*) | jq tostring)
-          echo "combined=$combined" >> $GITHUB_OUTPUT
-
-      - name: Make slack outputs
-        id: process-json
-        uses: actions/github-script@v7
-        env:
-          GITHUB_TOKEN: ${{ github.token }}
-        with:
-          script: |
-            const combined = JSON.parse(${{ steps.combine-json.outputs.combined }});
-            const failedProjects = combined.filter(c => c.status === 'failure').sort((a, b) => a.project.localeCompare(b.project));
-
-            // codeowners
-            const codeowners = new Set();
-            failedProjects.forEach(c => {
-              codeowners.add(c.codeowners);
-            });
-            core.setOutput('CODEOWNERS', Array.from(codeowners).join(','));
-
-            // message
-            let result = `
-              *OS* Windows
-              *Package manager* npm
-              \`\`\`
-              | Failed project                 | Node |
-              |--------------------------------|------|`;
-            failedProjects.forEach(matrix => {
-              result += `\n| ${matrix.project.padEnd(30)} | v${matrix.node_version}  |`
-            });
-            result += `\`\`\``;
-            const message = result.split('\n').map(l => l.trim()).join('\n');
-            core.setOutput('SLACK_MESSAGE', message);
-
-  report-failure:
-    if: ${{ failure() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
-    needs: process-result
-    runs-on: ubuntu-latest
-    name: Report failure
-    steps:
-      - name: Send notification
-        uses: ravsamhq/notify-slack-action@v2
-        with:
-          status: 'failure'
-          message_format: '{emoji} Workflow has {status_message} ${{ needs.process-result.outputs.message }}'
-          notification_title: '{workflow}'
-          footer: '<{run_url}|View Run> / Last commit <{commit_url}|{commit_sha}>'
-          mention_groups: ${{ needs.process-result.outputs.codeowners }}
-        env:
-          SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}
-
-  report-success:
-    if: ${{ success() && github.repository_owner == 'nrwl' && github.event_name != 'workflow_dispatch' }}
-    needs: e2e
-    runs-on: ubuntu-latest
-    name: Report success
-    steps:
-      - name: Send notification
-        uses: ravsamhq/notify-slack-action@v2
-        with:
-          status: ${{ needs.e2e.result }}
-          message_format: '{emoji} Workflow has {status_message}'
-          notification_title: '{workflow}'
-          footer: '<{run_url}|View Run> / Last commit <{commit_url}|{commit_sha}>'
-        env:
-          SLACK_WEBHOOK_URL: ${{ secrets.ACTION_MONITORING_SLACK }}

.github/workflows/issue-notifier.yml

@@ -50,7 +50,7 @@ jobs:
 
       - name: Collect Issue Data
         id: collect
-        run: npx ts-node ./scripts/issues-scraper/index.ts
+        run: npx tsx ./scripts/issues-scraper/index.ts
         env:
           GITHUB_TOKEN: ${{ github.token }}
 

.github/workflows/nightly/process-matrix.ts

@@ -0,0 +1,117 @@
+type MatrixDataProject = {
+  name: string,
+  codeowners: string,
+};
+
+type MatrixDataOS = {
+  os: string, // GH runner machine name: e.g. ubuntu-latest
+  os_name: string, // short name that will be printed in the report and on the action
+  os_timeout: number, // 60
+  package_managers: string[], // package managers to run on this OS
+  node_versions: number[], // node versions to run on this OS
+  excluded?: string[], // projects to exclude from running on this OS
+};
+
+type MatrixData = {
+  coreProjects: MatrixDataProject[],
+  projects: MatrixDataProject[],
+  nodeTLS: number,
+  setup: MatrixDataOS[],
+}
+
+// TODO: Extract Slack groups into named groups for easier maintenance
+const matrixData: MatrixData = {
+  coreProjects: [
+    { name: 'e2e-lerna-smoke-tests', codeowners: 'S04TNCVEETS' },
+    { name: 'e2e-js', codeowners: 'S04SJ6HHP0X' },
+    { name: 'e2e-nx-init', codeowners: 'S04SYHYKGNP' },
+    { name: 'e2e-nx', codeowners: 'S04SYHYKGNP' },
+    { name: 'e2e-release', codeowners: 'S04SYHYKGNP' },
+    { name: 'e2e-workspace-create', codeowners: 'S04SYHYKGNP' }
+  ],
+  projects: [
+    { 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' }
+  ],
+  nodeTLS: 20,
+  setup: [
+    { os: 'ubuntu-latest', os_name: 'Linux', os_timeout: 60, package_managers: ['npm', 'pnpm', 'yarn'], node_versions: [20, 22], excluded: ['e2e-detox', 'e2e-react-native', 'e2e-expo'] },
+    { os: 'macos-latest', os_name: 'MacOS', os_timeout: 90, package_managers: ['npm'], node_versions: [20] },
+    { os: 'windows-latest', os_name: 'WinOS', os_timeout: 180, package_managers: ['npm'], node_versions: [20], excluded: ['e2e-detox', 'e2e-react-native', 'e2e-expo'] }
+  ]
+};
+
+const matrix: Array<{
+  project: string,
+  codeowners: string,
+  node_version: number,
+  package_manager: string,
+  os: string,
+  os_name: string,
+  os_timeout: number
+}> = [];
+
+function addMatrixCombo(project: MatrixDataProject, nodeVersion: number, pm: number, os: number) {
+  matrix.push({
+    project: project.name,
+    codeowners: project.codeowners,
+    node_version: nodeVersion,
+    package_manager: matrixData.setup[os].package_managers[pm],
+    os: matrixData.setup[os].os,
+    os_name: matrixData.setup[os].os_name,
+    os_timeout: matrixData.setup[os].os_timeout,
+  });
+}
+
+function processProject(project: MatrixDataProject, nodeVersion?: number) {
+  for (let os = 0; os < matrixData.setup.length; os++) {
+    for (let pm = 0; pm < matrixData.setup[os].package_managers.length; pm++) {
+      if (!matrixData.setup[os].excluded || !matrixData.setup[os].excluded?.includes(project.name)) {
+        if (nodeVersion) {
+          addMatrixCombo(project, nodeVersion, pm, os);
+        } else {
+          for (let n = 0; n < matrixData.setup[os].node_versions.length; n++) {
+            addMatrixCombo(project, matrixData.setup[os].node_versions[n], pm, os);
+          }
+        }
+      }
+    }
+  }
+}
+
+// process core projects
+for (let p = 0; p < matrixData.coreProjects.length; p++) {
+  processProject(matrixData.coreProjects[p]);
+}
+// process other projects
+for (let p = 0; p < matrixData.projects.length; p++) {
+  processProject(matrixData.projects[p], matrixData.nodeTLS);
+}
+
+if (matrix.length > 256) {
+  throw new Error('You have exceeded the size of the matrix. GitHub allows only 256 jobs in a matrix. Found ${matrix.length} jobs.');
+}
+
+// print result to stdout for pipeline to consume
+process.stdout.write(JSON.stringify({ include: matrix }, null, 0));

.github/workflows/publish.yml

@@ -294,14 +294,12 @@ jobs:
     timeout-minutes: 45
     steps:
       - uses: actions/checkout@v4
-        if: ${{ github.event_name != 'schedule' && !github.event.inputs.pr }}
         with:
           repository: ${{ needs.resolve-required-data.outputs.repo }}
           ref: ${{ needs.resolve-required-data.outputs.ref }}
 
       - name: Build
         id: build
-        if: ${{ github.event_name != 'schedule' && !github.event.inputs.pr }}
         uses: cross-platform-actions/action@v0.25.0
         env:
           DEBUG: napi:*
@@ -343,7 +341,6 @@ jobs:
             echo "COMPLETE"
 
       - name: Upload artifact
-        if: ${{ github.event_name != 'schedule' && !github.event.inputs.pr }}
         uses: actions/upload-artifact@v4
         with:
           name: bindings-freebsd

.gitignore

@@ -2,6 +2,7 @@ node_modules
 /.idea
 /.fleet
 /.vscode
+/.cursor
 dist
 /build
 /coverage
@@ -65,3 +66,6 @@ target
 /wasi-sdk*
 
 vite.config.*.timestamp*
+
+
+storybook-static

.nx/workflows/agents.yaml

@@ -19,6 +19,20 @@ launch-templates:
           key: 'pnpm-lock.yaml'
           paths: .pnpm-store
           base-branch: 'master'
+
+      - name: Install zip and unzip
+        script: sudo apt-get -yqq install zip unzip
+
+      - name: Install bun
+        script: |
+          curl -fsSL https://bun.sh/install | bash
+          echo "BUN_INSTALL=$HOME/.bun" >> $NX_CLOUD_ENV
+          echo "PATH=$HOME/.bun/bin:$PATH" >> $NX_CLOUD_ENV
+
+      - name: Check bun
+        script: |
+          bun --version
+
       - name: Install e2e deps
         script: |
           sudo apt-get update
@@ -50,8 +64,6 @@ launch-templates:
       - name: Load Cargo Env
         script: echo "PATH=$HOME/.cargo/bin:$PATH" >> $NX_CLOUD_ENV
 
-      - name: Install zip and unzip
-        script: sudo apt-get -yqq install zip unzip
   linux-extra-large:
     resource-class: 'docker_linux_amd64/extra_large'
     image: 'ubuntu22.04-node20.11-v10'
@@ -72,6 +84,20 @@ launch-templates:
           key: 'pnpm-lock.yaml'
           paths: .pnpm-store
           base-branch: 'master'
+
+      - name: Install zip and unzip
+        script: sudo apt-get -yqq install zip unzip
+
+      - name: Install bun
+        script: |
+          curl -fsSL https://bun.sh/install | bash
+          echo "BUN_INSTALL=$HOME/.bun" >> $NX_CLOUD_ENV
+          echo "PATH=$HOME/.bun/bin:$PATH" >> $NX_CLOUD_ENV
+
+      - name: Check bun
+        script: |
+          bun --version
+
       - name: Install e2e deps
         script: |
           sudo apt-get update
@@ -102,6 +128,3 @@ launch-templates:
 
       - name: Load Cargo Env
         script: echo "PATH=$HOME/.cargo/bin:$PATH" >> $NX_CLOUD_ENV
-
-      - name: Install zip and unzip
-        script: sudo apt-get -yqq install zip unzip

.nx/workflows/dynamic-changesets.yaml

@@ -1,10 +1,24 @@
 distribute-on:
   default: auto linux-medium, 1 linux-extra-large
 assignment-rules:
-  - project: nx-dev
-    target: build-base
-    runs-on:
-      - linux-extra-large
-  - target: test
-    runs-on:
-      - linux-medium
+  - projects:
+      - nx-dev
+    targets:
+      - build*
+    run-on:
+      - agent: linux-extra-large
+        parallelism: 1
+
+  - targets:
+      - lint
+    run-on:
+      - agent: linux-medium
+        parallelism: 6
+
+  - targets:
+      - '*'
+    run-on:
+      - agent: linux-medium
+        parallelism: 3
+      - agent: linux-extra-large
+        parallelism: 3

.nxignore

@@ -2,3 +2,4 @@ nx-dev/**/jest.config.js
 .next
 _files
 _solution
+nx-dev/tutorial/**/templates

.prettierignore

@@ -47,5 +47,6 @@ CODEOWNERS
 .pnpm-store
 
 /.nx/workspace-data
+/.nx/workflows/dynamic-changesets.yaml
 _files
 _solution

CODEOWNERS

@@ -145,8 +145,8 @@ rust-toolchain @nrwl/nx-native-reviewers
 /packages/devkit/public-api.ts @FrozenPandaz @vsavkin
 
 # Gradle
-/packages/gradle/** @FrozenPandaz @xiongemi
-/e2e/gradle/** @FrozenPandaz @xiongemi
+/packages/gradle/** @FrozenPandaz @MaxKless @xiongemi
+/e2e/gradle/** @FrozenPandaz @MaxKless @xiongemi
 
 # Nx-Plugin
 /docs/generated/packages/plugin/** @nrwl/nx-devkit-reviewers @nrwl/nx-docs-reviewers

README.md

@@ -21,7 +21,7 @@
 
 # Smart Monorepos · Fast CI
 
-Nx is a build system, optimized for monorepos, with plugins for popular frameworks and tools and advanced CI capabilities including caching and distribution.
+Build system, optimized for monorepos, with AI-powered architectural awareness and advanced CI capabilities.
 
 Create a new Nx workspace with
 

community/approved-plugins.json

@@ -513,5 +513,10 @@
     "name": "nx-foundry",
     "description": "Foundry generators and inferred tasks for Nx",
     "url": "https://github.com/juliangsibecas/nx-foundry"
+  },
+  {
+    "name": "@aws/nx-plugin",
+    "description": "Nx Plugin for AWS: Accelerate building cloud-native applications with AWS",
+    "url": "https://github.com/awslabs/nx-plugin-for-aws"
   }
 ]

docs/README.md

@@ -299,6 +299,14 @@ Have a more decent button-like widget that you can place below sections of a tut
 {% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=64" /%}
 ```
 
+#### Course video embed
+
+This is for embedding a video just like with the Youtube component, but in addition to have a link to a Nx Course (nx.dev/courses) video to improve the discoverability of these courses.
+
+```markdown
+{% course-video src="https://youtu.be/3hW53b1IJ84" courseTitle="From PNPM Workspaces to Distributed CI" courseUrl="/courses/pnpm-nx-next/lessons-01-nx-init" title="Initialize Nx in Your Project with nx init" /%}
+```
+
 #### Project Details View
 
 Embed a Project Details View that is identical what is shown in Nx Console or `nx show project myproject --web`

docs/blog/2022-03-29-the-react-cli-you-always-wanted-but-didnt-know-about.md

@@ -19,9 +19,7 @@ While speed is of major importance, developer ergonomics shouldn't be left behin
 
 ## Update (Aug 2023): Want a non-monorepo setup?
 
-This article walks you through how to setup a new Nx monorepo workspace with React. If you rather prefer starting with a single-project setup (also named "standalone") then you might want to have a look at this tutorial (including video):
-
-[/getting-started/tutorials/react-standalone-tutorial](/getting-started/tutorials/react-standalone-tutorial)
+This article walks you through how to setup a new Nx monorepo workspace with React. If you rather prefer starting with a single-project setup (also named "standalone") then you might want to have a look at the standalone tutorial (including video).
 
 ## Why use a devtool CLI?
 

docs/blog/2022-05-02-nx-v14-is-out-here-is-all-you-need-to-know.md

@@ -197,14 +197,14 @@ This can be a game-changer when building huge apps. Stay tuned for more content
 
 We recommend this approach if you want to speed up local serve and build times, but you still deploy the application as a whole.
 
-Read more on our docs: [/concepts/module-federation/faster-builds-with-module-federation](/concepts/module-federation/faster-builds-with-module-federation)
+Read more in our docs: [/concepts/module-federation/faster-builds-with-module-federation](/concepts/module-federation/faster-builds-with-module-federation)
 
 ## Micro Frontend Architecture with Nx
 
 As mentioned in the previous section, Nx v14 comes with out-of-the-box for Webpack Module Federation. The Micro Frontend architecture builds on top of that and adds the ability for independent deployability. While Module Federation enables faster builds by vertically slicing your application into smaller ones, the MFE architecture layers _independent deployments_  
 on top of federation. Teams should only choose MFEs if they want to deploy their host and remotes on different cadences.
 
-Read more on our docs: [/concepts/module-federation/micro-frontend-architecture](/concepts/module-federation/micro-frontend-architecture)
+Read more in our docs: [/concepts/module-federation/micro-frontend-architecture](/concepts/module-federation/micro-frontend-architecture)
 
 ## Dark mode for Project Graph as well as path tracking
 
@@ -242,7 +242,7 @@ In version 13.4 we released a brand new dedicated package for developing pure Ja
 
 We kept improving it, adding SWC support (including an easy migration between TSC → SWC using an Nx generator) and we're currently looking into automated publishing support.
 
-Read all the details on our docs: [/getting-started/intro](/getting-started/intro)
+Read all the details in our docs: [/getting-started/intro](/getting-started/intro)
 
 ## React
 

docs/blog/2022-07-14-setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx.md

@@ -9,6 +9,15 @@ description: Learn to set up a monorepo with PNPM workspaces for Remix and React
 
 In this article we're going to have a deep dive into setting up a new monorepo using [PNPM workspaces](https://pnpm.io/workspaces) that hosts a Remix application as well as a React-based library. We will learn how to run commands with PNPM, how to run them in parallel and finally we're going to add Nx for a more sophisticated task scheduling, including command caching and more.
 
+{% callout type="warning" title="Updated video!" %}
+
+We made a lot of improvements since we last wrote this article. Here's our **updated content**:
+
+- [the full all-in-one video on Youtube](https://youtu.be/zX-1tpqUG5c)
+- [our free course: From PNPM Workspaces to Distributed CI](/courses/pnpm-nx-next)
+
+{% /callout %}
+
 **Important:** If you are already familiar with the setup and configuration of a new PNPM workspace, feel free to skip to the part where we add Nx later in the article.
 
 **Prefer a video walkthrough?**
@@ -744,5 +753,5 @@ You can find an example of such setup on the **Nx Recipe GitHub repository**:
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nrwl Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nrwl Youtube Channel](https://www.youtube.com/@nxdevtools)
 - 🥚 [Free Egghead course](https://egghead.io/courses/scale-react-development-with-nx-4038)

docs/blog/2022-08-02-nx-14-5-cypess-v10-output-globs-linter-perf-react-tailwind-support.md

@@ -300,5 +300,5 @@ npx nx migrate --run-migrations
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nrwl Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nrwl Youtube Channel](https://www.youtube.com/@nxdevtools)
 - 🥚 [Free Egghead course](https://egghead.io/courses/scale-react-development-with-nx-4038)

docs/blog/2022-08-18-helping-the-environment-by-saving-two-centuries-of-compute-time.md

@@ -94,5 +94,5 @@ How to enable it? [Read more on the Lerna docs](https://lerna.js.org/docs/featur
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nrwl Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nrwl Youtube Channel](https://www.youtube.com/@nxdevtools)
 - 🥚 [Free Egghead course](https://egghead.io/courses/scale-react-development-with-nx-4038)

docs/blog/2022-10-14-whats-new-in-nx-15.md

@@ -181,7 +181,6 @@ It is an ongoing process, and we have a lot of content to cover! We follow the [
 
 Besides the two new [package-based](/getting-started/tutorials/typescript-packages-tutorial) and [integrated style tutorials](/getting-started/tutorials/react-monorepo-tutorial) we also have two brand new reworked tutorials
 
-- [/getting-started/tutorials/react-standalone-tutorial](/getting-started/tutorials/react-standalone-tutorial)
 - [/getting-started/tutorials](/getting-started/tutorials)
 
 Stay tuned for more updates to come.
@@ -257,5 +256,5 @@ npx nx migrate --run-migrations
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nrwl Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nrwl Youtube Channel](https://www.youtube.com/@nxdevtools)
 - 🥚 [Free Egghead course](https://egghead.io/courses/scale-react-development-with-nx-4038)

docs/blog/2022-12-06-nx-15-3-standalone-projects-vite-task-graph-and-more.md

@@ -200,7 +200,7 @@ npx nx g @nrwl/vite:configuration
 
 This will adjust the NxExt Vite plugin configuration to match the one provided by our core team. Check out our docs for more info: [/nx-api/vite/generators/configuration](/nx-api/vite/generators/configuration)
 
-You can also find all the details about the new Vite package on our docs: [/nx-api/vite](/nx-api/vite)
+You can also find all the details about the new Vite package in our docs: [/nx-api/vite](/nx-api/vite)
 
 ## Adopting Nx has never been easier
 
@@ -271,7 +271,7 @@ This process will ask you a few questions about which operations are cacheable.
 }
 ```
 
-Read more on our docs: [/recipes/adopting-nx/adding-to-existing-project](/recipes/adopting-nx/adding-to-existing-project)
+Read more in our docs: [/recipes/adopting-nx/adding-to-existing-project](/recipes/adopting-nx/adding-to-existing-project)
 
 ## Root-level Scripts
 
@@ -312,7 +312,7 @@ npx nx docs
 
 As the next steps you might obviously want to add `docs` to the [cacheable operations](/ci/reference/config) and [fine-tune it's cache inputs](/recipes/running-tasks/configure-inputs).
 
-Read more about it on our docs: [/recipes/running-tasks/root-level-scripts](/recipes/running-tasks/root-level-scripts)
+Read more about it in our docs: [/recipes/running-tasks/root-level-scripts](/recipes/running-tasks/root-level-scripts)
 
 ## Simplified Nx run-commands
 
@@ -386,7 +386,7 @@ For simple commands this was a huge overhead, so we simplified it to just this:
 
 Simple, isn't it! Obviously the expanded form is still there and also useful for when you need more options, run multiple commands or features such as argument forwarding.
 
-You can read all about it on our docs: [/recipes/running-tasks/run-commands-executor](/recipes/running-tasks/run-commands-executor)
+You can read all about it in our docs: [/recipes/running-tasks/run-commands-executor](/recipes/running-tasks/run-commands-executor)
 
 ## Coming up
 

docs/blog/2023-02-09-setup-react-and-tailwind-the-easy-way.md

@@ -39,7 +39,7 @@ And so did also [Fireship](https://youtu.be/2OTq15A5s0Y) and ultimately [Dan Abr
 
 Code generators speed up such configuration tasks. They are valuable for scaffolding the initial project structure and adding new features to the app setup, such as Tailwind.
 
-Nx has such generators. To use them, you need an Nx-based React setup. If you're starting new, you can create an [Nx Standalone React project](/getting-started/tutorials/react-standalone-tutorial) easily using the following command
+Nx has such generators. To use them, you need an Nx-based React setup. If you're starting new, you can create an Nx Standalone React project easily using the following command
 
 ```shell
 $ npx create-nx-workspace reactapp --preset=react-standalone
@@ -59,7 +59,7 @@ You can pass `--vite=false` if you still want to keep the Webpack configuration
 
 ## Generating a Tailwind Setup
 
-Once you have a [Nx-based React](/getting-started/tutorials/react-standalone-tutorial) setup, adding Tailwind is as easy as running:
+Once you have a [Nx-based React](/getting-started/tutorials/react-monorepo-tutorial) setup, adding Tailwind is as easy as running:
 
 ```shell
 $ npx nx g @nrwl/react:setup-tailwind
@@ -79,7 +79,6 @@ You'll get
 
 You should be all setup and ready now! Here are some related resources to explore:
 
-- [Nx docs: React Standalone tutorial](/getting-started/tutorials/react-standalone-tutorial)
 - [Nx docs: React Monorepo tutorial](/getting-started/tutorials/react-monorepo-tutorial)
 - [Youtube: Is CRA Dead](https://youtu.be/fkTz6KJxhhE)
 - [Nx docs: Migrate CRA to React and Vite](/recipes/adopting-nx/adding-to-existing-project)

docs/blog/2023-02-16-nx-15-7-node-support-angular-lts-lockfile-pruning.md

@@ -151,7 +151,7 @@ Inspired by our new [Vite setup](/nx-api/vite), which allows for a more modular
 
 ![](/blog/images/2023-02-16/emRP2gF7umWc4UE-.avif)
 
-If you want to upgrade but still retain the previous behavior, we introduced an `isolatedConfig` mode that can be set to `false`. More details on our docs: [/recipes/webpack/webpack-config-setup](/recipes/webpack/webpack-config-setup)
+If you want to upgrade but still retain the previous behavior, we introduced an `isolatedConfig` mode that can be set to `false`. More details in our docs: [/recipes/webpack/webpack-config-setup](/recipes/webpack/webpack-config-setup)
 
 ## How to Update Nx
 
@@ -185,5 +185,5 @@ So keep an eye on our [Twitter](https://twitter.com/nxdevtools), [Youtube](https
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nrwl Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nrwl Youtube Channel](https://www.youtube.com/@nxdevtools)
 - 🥚 [Free Egghead course](https://egghead.io/courses/scale-react-development-with-nx-4038)

docs/blog/2023-02-22-whats-new-with-lerna-6-5.md

@@ -124,4 +124,4 @@ You can find [a roadmap for all the features we plan to add in Lerna 7](https://
 - [🧠 Lerna Docs](https://lerna.js.org/)
 - [👩‍💻 Lerna GitHub](https://github.com/lerna/lerna)
 - [💬 Nx Official Discord Server](https://go.nx.dev/community)
-- [📹 Nrwl Youtube Channel](https://www.youtube.com/nrwl_io)
+- [📹 Nrwl Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2023-08-10-create-your-own-create-react-app-cli.md

@@ -636,7 +636,7 @@ This should give you a good insight into how to get started. But there's more to
 - We could also include "[executors](/extending-nx/recipes/local-executors)", which are wrappers around tasks to abstract the lower-level details of it
 - etc.
 
-Now clearly this was a simple example of how you could build your own CRA using Nx. If you want to see a real-world React setup powered by Nx, check out our React Tutorial: [/getting-started/tutorials/react-standalone-tutorial](/getting-started/tutorials/react-standalone-tutorial)
+Now clearly this was a simple example of how you could build your own CRA using Nx. If you want to see a real-world React setup powered by Nx, check out our React Tutorial: [/getting-started/tutorials/react-monorepo-tutorial](/getting-started/tutorials/react-monorepo-tutorial)
 
 ## Learn more
 

docs/blog/2023-09-06-nx-16-8-release.md

@@ -306,7 +306,7 @@ We've also added the ability to sort the registry by these metrics as a way of s
 
 ![](/blog/images/2023-09-06/f0AhdlWaIcC96LXK.avif)
 
-Go [check it out now](/plugin-registry) live on our docs site!
+Go [check it out now](/plugin-registry) live in our docs site!
 
 ## DOCS ENHANCEMENT: Redesigned Intro & Examples
 

docs/blog/2023-10-20-nx-17-release.md

@@ -54,8 +54,6 @@ And you'll have access to Nx generators so that you can generate Vue application
 
 We're very excited for this support to land, and we're eager to get it into our user's hands and see what Nx can do to help Vue developers so we can continue to refine our support and make Vue with Nx an excellent developer experience.
 
-If you're eager to learn more, make sure to check out our new [Vue standalone tutorial](/getting-started/tutorials/vue-standalone-tutorial).
-
 ## Enhancements to Module Federation Support
 
 Nx already had great support for Module Federation — Nx 17 improves on this support:
@@ -236,7 +234,7 @@ For more [checkout our API docs](/nx-api/nx/documents/release), and be sure to c
 
 At Nx, we're OBSESSED with building a better, more robust experience for our developers. Towards this end, we're now in [v2 of our Project Inference API](/extending-nx/recipes/project-graph-plugins).
 
-This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](/getting-started/tutorials/vue-standalone-tutorial).
+This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](/nx-api/vue).
 
 Interestingly, v2 includes support for dynamic targets as well. This opens up exciting new doors to reducing configuration, and we hope to expand on this to better support our first-party plugins in the near future.
 

docs/blog/2023-11-21-ai-assistant.md

@@ -35,7 +35,7 @@ In a nutshell, the Nx Docs AI Assistant works in the following way:
 
 This is based on the Web Q&A Tutorial from OpenAI [(https://platform.openai.com/docs/tutorials/web-qa-embeddings)](https://platform.openai.com/docs/tutorials/web-qa-embeddings) and Supabase’s Vector Search example [(https://supabase.com/docs/guides/ai/examples/nextjs-vector-search)](https://supabase.com/docs/guides/ai/examples/nextjs-vector-search).
 
-It’s important to note here that we are not “training the model on our docs”. The model is pretrained. We are just giving the model parts of our docs which are relevant to the user’s question, and the model creates a coherent answer to the question. It’s basically like pasting in ChatGPT a docs page and asking it “how do I do that?”. Except in this case, we’re first searching our documentation and giving GPT only the relevant parts (more about how we do that later in this article), which it can “read” and extract information from.
+It’s important to note here that we are not “training the model in our docs”. The model is pretrained. We are just giving the model parts of our docs which are relevant to the user’s question, and the model creates a coherent answer to the question. It’s basically like pasting in ChatGPT a docs page and asking it “how do I do that?”. Except in this case, we’re first searching our documentation and giving GPT only the relevant parts (more about how we do that later in this article), which it can “read” and extract information from.
 
 ## Step 1: Preprocessing our docs
 

docs/blog/2023-12-28-highlights-2023.md

@@ -220,7 +220,7 @@ And you'll then have access to Nx generators so you can create Vue applications,
 
 ![](/blog/images/2023-12-28/bodyimg6.gif)
 
-Checkout out our [Vue standalone tutorial](/getting-started/tutorials/vue-standalone-tutorial) for more, as well as our [Vue API docs](/nx-api/vue), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
+Checkout out our [Vue API docs](/nx-api/vue), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
 
 ### Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
 
@@ -328,7 +328,7 @@ You can also browse them in the [nx-recipes](https://github.com/nrwl/nx-recipes)
 
 {% tweet url="https://twitter.com/juristr/status/1736023402933318011" /%}
 
-And obviously, we jumped on the AI train as well. A couple of months ago, we added the [Nx Assistant](/ai-chat). A ChatGPT-powered interface trained on our docs. [Katerina](https://twitter.com/psybercity) wrote about it [on our blog](/blog/nx-docs-ai-assistant). The AI chat allows to interactively ask questions about Nx and will give you relevant answers from our docs (including linking to the sources).
+And obviously, we jumped on the AI train as well. A couple of months ago, we added the [Nx Assistant](/ai-chat). A ChatGPT-powered interface trained in our docs. [Katerina](https://twitter.com/psybercity) wrote about it [on our blog](/blog/nx-docs-ai-assistant). The AI chat allows to interactively ask questions about Nx and will give you relevant answers from our docs (including linking to the sources).
 
 ## New Tagline: Smart Monorepos — Fast CI
 

docs/blog/2024-01-24-monorepos-the-benefits-challenges-and-importance-of-tooling-support.md

@@ -0,0 +1,17 @@
+---
+title: 'Monorepos: the Benefits, Challenges, and Importance of Tooling Support '
+description: 'Learn how monorepos and better tooling can help you overcome challenges in software development like scalability, maintenance, communication, and cost.'
+date: 2024-01-24
+slug: 'monorepos-the-benefits-challenges-and-importance-of-tooling-support'
+authors: ['Juri Strumpflohner']
+tags: [webinar]
+cover_image: /blog/images/2024-01-24/january-webinar-card.png
+status: Past - Gated
+registrationUrl: https://go.nx.dev/january-webinar
+---
+
+Presented by Juri Strumpflohner
+
+Learn how monorepos and better tooling can help you overcome challenges in software development like scalability, maintenance, communication, and cost.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/january-webinar" description="Sign up to gain access" /%}

docs/blog/2024-02-09-versioning-and-releasing-packages.md

@@ -21,9 +21,7 @@ As you can see `@tuskdesign/forms` relies on `@tuskdesign/buttons` and as such h
 
 ---
 
-**Prefer a video?**
-
-{% youtube src="https://www.youtube.com/embed/KjZKFGu3_9I?si=L-8oRzy-hV-WF_pS" title="Versioning and Releasing Packages in a Monorepo" /%}
+{% link-card title="Free Course: Versioning and Releasing NPM packages with Nx" type="external" url="https://www.epicweb.dev/tutorials/versioning-and-releasing-npm-packages-with-nx" icon="/documentation/shared/images/nx-release-course-logo.webp" /%}
 
 ---
 

docs/blog/2024-03-11-nx-agents-walkthrough-effortlessly-fast-ci-built-for-monorepos.md

@@ -0,0 +1,17 @@
+---
+title: 'Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos'
+description: 'Learn how you can streamline your existing CI config to its absolute simplest form, reducing CI times from 30 minutes to ~5 minutes with Nx Agents. '
+date: 2024-03-11
+slug: 'nx-agents-walkthrough-effortlessly-fast-ci-built-for-monorepos'
+authors: ['Rareș Matei']
+tags: [webinar]
+cover_image: /blog/images/2024-03-11/march-webinar.png
+status: Past - Gated
+registrationUrl: https://go.nx.dev/march-webinar
+---
+
+Presented by Rareș Matei
+
+Learn how you can streamline your existing CI config to its absolute simplest form, reducing CI times from 30 minutes to ~5 minutes with Nx Agents.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/march-webinar" description="Sign up to gain access" /%}

docs/blog/2024-03-21-reliable-ci.md

@@ -4,7 +4,6 @@ slug: 'reliable-ci-a-new-execution-model-fixing-both-flakiness-and-slowness'
 authors: [Victor Savkin]
 cover_image: '/blog/images/2024-03-21/featured_img.png'
 tags: [nx, nx-cloud, releases]
-pinned: true
 description: 'Learn how Nx Cloud revolutionizes CI with a task-based execution model that solves both flaky tests and slow pipelines.'
 ---
 

docs/blog/2024-04-17-making-the-argument-for-monorepos.md

@@ -0,0 +1,17 @@
+---
+title: 'Making the Argument for Monorepos'
+description: 'Trying to convince your colleagues to use a monorepo? Already using a monorepo and need to justify that decision? Check out this webinar to learn 7 essential reasons for using monorepos and bust a few myths and misconceptions along the way.'
+date: 2024-04-17
+slug: 'making-the-argument-for-monorepos'
+authors: ['Miroslav Jonaš']
+tags: [webinar]
+cover_image: /blog/images/2024-04-17/april-webinar.png
+status: Past - Gated
+registrationUrl: https://go.nx.dev/april-webinar
+---
+
+Presented by Miroslav Jonaš
+
+Trying to convince your colleagues to use a monorepo? Already using a monorepo and need to justify that decision? Check out this webinar to learn 7 essential reasons for using monorepos and bust a few myths and misconceptions along the way.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/april-webinar" description="Sign up to gain access" /%}

docs/blog/2024-06-26-monorepos-and-ci-can-be-a-mess-heres-how-nx-and-nx-cloud-fixed-it.md

@@ -0,0 +1,19 @@
+---
+title: "Monorepos and CI can be a Mess - Here's How Nx and Nx Cloud Fixed It"
+description: "Continuous Integration (CI) in monorepos can be notoriously slow and unreliable, quickly become a bottleneck for scaling monorepos.
+Learn how Nx and Nx Cloud's new task-based approach ensures fast, resilient, and efficient CI for your monorepo projects."
+date: 2024-06-26
+slug: 'monorepos-and-ci-can-be-a-mess-heres-how-nx-and-nx-cloud-fixed-it'
+authors: ['Juri Strumpflohner']
+tags: [webinar]
+cover_image: /blog/images/2024-06-26/June-Webinar-card.png
+status: Past - Gated
+registrationUrl: https://go.nx.dev/june-webinar
+---
+
+Presented by Juri Strumpflohner
+
+Continuous Integration (CI) in monorepos can be notoriously slow and unreliable, quickly become a bottleneck for scaling monorepos.
+Learn how Nx and Nx Cloud's new task-based approach ensures fast, resilient, and efficient CI for your monorepo projects.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/june-webinar" description="Sign up to gain access" /%}

docs/blog/2024-09-25-evolving-nx.md

@@ -7,11 +7,11 @@ cover_image: /blog/images/evolving-nx/thumbnail.png
 description: Nx's journey from a side project to a tool for millions, including Nx Cloud and Nx Powerpack developments.
 ---
 
-_Update from Jeff Cross, October 17, 2024_
+{% callout type="info" title="Update - March 31st, 2025" %}
 
-In my original version of this post, I said that Powerpack is completely new functionality. I mistakenly thought that all custom remote cache solutions were using private/unsupported APIs, but I've since learned that we've had docs and some APIs that helped people build their own remote caches. I'm sorry for the error, and have updated the text to indicate that Powerpack is mostly new functionality. We've also updated the [Powerpack page](/powerpack) to make it more explicit how some teams can get free Powerpack licenses.
+Self-hosted caching is now free for everyone. Read more [in our blog post](/blog/custom-runners-and-self-hosted-caching) and in our documentation about [remote caching options with Nx](/remote-cache).
 
----
+{% /callout %}
 
 Over the years, Nx has grown from a small 20% side project of our consulting business into a tool that empowers millions of developers worldwide and helps Fortune 500 companies ship high-quality software faster. In the last two years, we successfully transformed our consulting business into a product company, where our team can fully focus on evolving Nx and building Nx Cloud to extend Nx's capabilities beyond local development.
 
@@ -24,11 +24,13 @@ When we have new ideas to make Nx better, we've always had two options: it could
 
 ## Introducing Nx Powerpack
 
-**[Nx Powerpack](/powerpack)** — our newest product designed to elevate the Nx CLI experience for enterprise environments. Powerpack offers advanced features like self-hosted remote cache storage, code ownership for monorepos, and workspace conformance, seamlessly integrating into sealed systems with strict security requirements. It's also designed for ease of implementation, helping enterprises bypass lengthy procurement processes and quickly access the tools they need.
+**[Nx Powerpack](/powerpack)** — our newest product designed to elevate the Nx CLI experience for enterprise environments. Powerpack offers advanced features like ~~self-hosted remote cache storage,~~ code ownership for monorepos, and workspace conformance, seamlessly integrating into sealed systems with strict security requirements. It's also designed for ease of implementation, helping enterprises bypass lengthy procurement processes and quickly access the tools they need.
 
 > If you want to get into the technical details, we wrote a separate blog post diving deeper into the technical details: [Introducing Nx Powerpack](/blog/introducing-nx-powerpack).
 
-Powerpack is mostly new functionality. However, this change coincides with some Nx improvements that will eventually interfere with users who were relying on our original filesystem-based implementation of local caching. We've completely rewritten Nx's local caching to be faster and more secure, partly by using a local database instead of checking the filesystem for artifact metadata. With this rewrite, any custom remote caches that rely on metadata reflected in the filesystem will not work as of Nx 21. This is why we decided to build an API into Powerpack to be able to connect Nx's cache to different clouds and data sources. Now with Powerpack, teams can use an officially-supported implementation of remote caching, without needing to use Nx Cloud.
+Powerpack is mostly new functionality. ~~However, this change coincides with some Nx improvements that will eventually interfere with users who were relying on our original filesystem-based implementation of local caching. We've completely rewritten Nx's local caching to be faster and more secure, partly by using a local database instead of checking the filesystem for artifact metadata. With this rewrite, any custom remote caches that rely on metadata reflected in the filesystem will not work as of Nx 21. This is why we decided to build an API into Powerpack to be able to connect Nx's cache to different clouds and data sources. Now with Powerpack, teams can use an officially-supported implementation of remote caching, without needing to use Nx Cloud.~~
+
+_Edit: Self-hosted caching with Nx is now completely free for everyone. Read more in [our latest announcement.](/blog/custom-runners-and-self-hosted-caching)_
 
 There's a Steve Jobs quote that I think rings true with all of us at Nx:
 
@@ -42,7 +44,10 @@ Like many open source projects, one of the bigger challenges to sustainability i
 
 ### What about my open-source repo ?
 
-Open source projects can continue to use Nx Cloud for **free** the same way they always have, and they can continue to use Nx with all its features. If you are an open-source maintainer and you want to use Powerpack, you will get a **free license**. Just reach out to us at [powerpack-support@nrwl.io](mailto:powerpack-support@nrwl.io).
+Open Source projects can:
+
+- Get all Powerpack features as well as fully managed remote caching (and more) via the free Nx Cloud OSS plan. [Learn more here](/nx-enterprise/powerpack/licenses-and-trials#powerpack-for-oss-projects).
+- Get self-hosted remote caches via the according Nx plugins. [Learn more in the docs](/recipes/running-tasks/self-hosted-caching).
 
 ## How to Get Nx Powerpack
 

docs/blog/2024-09-25-introducing-nx-powerpack.md

@@ -4,17 +4,22 @@ slug: introducing-nx-powerpack
 authors: [Juri Strumpflohner]
 tags: [nx, release]
 cover_image: /blog/images/introducing-powerpack/thumbnail.png
-youtubeUrl: https://youtu.be/KZ0nh2lj8zE
 description: Introducing Nx Powerpack, a paid extension suite for enterprise use cases, ensuring Nx remains open source and existing features are free.
 ---
 
+{% callout type="info" title="Update - March 31st, 2025" %}
+
+Self-hosted caching is now free for everyone. Read more [in our blog post](/blog/custom-runners-and-self-hosted-caching) and in our documentation about [remote caching options with Nx](/remote-cache).
+
+{% /callout %}
+
 Today we're introducing our latest product, **Nx Powerpack**, a suite of paid extensions for Nx, specifically designed around common enterprise needs. Now, before anyone draws the wrong conclusions:
 
 - No, we're **not going to restrict Nx's license**, lock you in, and then harvest. Nx remains MIT licensed and fully open source.
 - No, we're **not placing existing features behind a paywall**. Nx Powerpack introduces new features on top of Nx (more about that below).
 - Yes, we still **strongly believe in OSS and our community**, and we will keep improving Nx more than ever; if anything, Powerpack will help us fund our OSS work on Nx core and ensure its long-term sustainability.
 
-### What about my open-source repo ?
+### What about my open-source repo?
 
 Open source projects can continue to use Nx Cloud for **free** the same way they always have, and they can continue to use Nx with all its features. If you are an open-source maintainer and you want to use Powerpack, you will get a **free license**. Just reach out to us at [powerpack-support@nrwl.io](mailto:powerpack-support@nrwl.io).
 
@@ -23,10 +28,9 @@ So this leaves us with:
 
 > But why are we releasing Nx Powerpack under a commercial license? Read all about our strategy, the reasoning behind Powerpack and OSS funding in the **blog post from our CEO, Jeff Cross**: [Evolving Nx](/blog/evolving-nx).
 
-But now to the fun, technical part! Nx Powerpack is a bundle that - in this very first release - comes with three major features:
+But now to the fun, technical part! Nx Powerpack is a bundle that - in this very first release - comes with these major features:
 
 - [Codeowners for monorepos](#codeowners-for-monorepos)
-- [Self-hosted cache storage](#selfhosted-cache-storage)
 - [Workspace conformance (beta)](#workspace-conformance-beta)
 
 Let's dive in!
@@ -38,7 +42,7 @@ All Powerpack features require a dedicated commercial license. You can get one h
 Once you have your license, run the following command
 
 ```shell
-npx nx activate-powerpack <your-license>
+npx nx register <your-activation-key>
 ```
 
 ## Codeowners for Monorepos
@@ -61,7 +65,7 @@ One of the downsides of how codeowners works on today's VCS providers is that **
 In a monorepo you reason based on projects. That's what you pass to your [Nx run commands](/features/run-tasks), what you see on the [project graph](/features/explore-graph) and also where owners should be defined. To get started install the Codeowners Powerpack plugin:
 
 ```shell
-npx nx add @nx/powerpack-owners
+npx nx add @nx/owners
 ```
 
 This will allow you to define an owners section in your `nx.json` where you can define owners at the project level or even leverage project tags. Here's a small example:
@@ -122,73 +126,17 @@ A dedicated `nx sync` command automatically synchronizes these definitions to a
 
 Read all about how to [configure Codeowners for your project in our docs](/nx-enterprise/powerpack/owners).
 
-## Self-hosted Cache Storage
-
-A continuous effort on our Nx core is to improve speed. Last year, we began **rewriting performance-critical parts of Nx into Rust**, and more core components are being rewritten. As part of this effort, we also changed how we manage local cache, moving from a **file-based to a database-based approach**. In addition to small performance gains from reduced I/O, this opens up many opportunities for improving local cache handling, such as keeping only relevant cache based on usage, more easily controlling maximum cache size, and optimizing task orchestration by running failed tasks earlier.
-
-As part of this new approach we're also going to [deprecate custom task runners](/deprecated/legacy-cache) in Nx 20. I bring this up because it might affect users that relied on 3rd party tools that hooked into the task runners API.
-
-To fill in on the custom task runner API we're providing a new Powerpack plugin that allows you to use S3 or a network drive as your storing mechanism for your Nx cache.
-
-Here's an example of how to get started with [Amazon S3](https://aws.amazon.com/s3) based remote caching. First add the Powerpack plugin:
-
-```shell
-npx nx add @nx/powerpack-s3-cache
-```
-
-This will update your `nx.json` to add the new `cache` section.
-
-```json {% fileName="nx.json" %}
-{
-    ...
-    "s3": {
-        "bucket": "your-s3-bucket-name",
-        "region": "us-east-1"
-    }
-}
-```
-
-To then leverage the S3 powered remote cache on CI, [follow the official AWS documentation](https://github.com/aws-actions/configure-aws-credentials). Here's a short example snippet using OIDC to authenticate with AWS on GitHub Actions:
-
-```yaml {% fileName=".github/workflows/ci.yml" %}
-name: CI
-...
-permissions:
-  id-token: write
-  ...
-
-jobs:
-  main:
-    runs-on: ubuntu-latest
-    steps:
-        ...
-
-      - name: 'Configure AWS Credentials'
-        uses: aws-actions/configure-aws-credentials@v4.0.2
-        with:
-          role-to-assume: arn:aws:iam::123456789123:role/GhAIBucketUserRole
-          aws-region: us-east-1
-
-        ...
-
-      - run: pnpm exec nx affected -t lint test build
-```
-
-Similarly you can **set up network file based caching** using the `nx add @nx/powerpack-shared-fs-cache` package and by setting the `cacheDirectory` path in your `nx.json`.
-
-Read all about how to [set up S3 or network drive based caching for your Nx workspace in our docs](/nx-enterprise/powerpack/custom-caching).
-
 ## Workspace Conformance (Beta)
 
-We're releasing the `@nx/powerpack-conformance` plugin in an early preview. This new package focuses specifically on the maintainability of your monorepo. It allows you to encode your organization's standards so they can be enforced automatically. In this first version, the workspace conformance package ships with:
+We're releasing the `@nx/conformance` plugin in an early preview. This new package focuses specifically on the maintainability of your monorepo. It allows you to encode your organization's standards so they can be enforced automatically. In this first version, the workspace conformance package ships with:
 
-- [Enforce Module Boundaries](/nx-api/powerpack-conformance#enforce-module-boundaries): Similar to the Nx ESLint [Enforce Module Boundaries rule](https://nx-dev-git-docs-powerpack-nrwl.vercel.app/features/enforce-module-boundaries), but enforces boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
-- [Ensure Owners](/nx-api/powerpack-conformance#ensure-owners): Requires every project to have an owner defined for the `@nx/powerpack-owners` plugin.
+- [Enforce Module Boundaries](/nx-api/conformance#enforce-module-boundaries): Similar to the Nx ESLint [Enforce Module Boundaries rule](https://nx-dev-git-docs-powerpack-nrwl.vercel.app/features/enforce-module-boundaries), but enforces boundaries on every project dependency, not just those created from TypeScript imports or `package.json` dependencies.
+- [Ensure Owners](/nx-api/conformance#ensure-owners): Requires every project to have an owner defined for the `@nx/owners` plugin.
 
 To get started, install the following package:
 
 ```shell
-npx nx add @nx/powerpack-conformance
+npx nx add @nx/conformance
 ```
 
 This allows you to define conformance rules in your `nx.json`. Here is an example:
@@ -199,12 +147,12 @@ This allows you to define conformance rules in your `nx.json`. Here is an exampl
     "conformance": {
         "rules": [
             {
-                "rule": "@nx/powerpack-conformance/enforce-module-boundaries",
+                "rule": "@nx/conformance/enforce-module-boundaries",
                 "projects": ["!remix-app-e2e"],
                 "options": {}
             },
             {
-                "rule": "@nx/powerpack-conformance/ensure-owners",
+                "rule": "@nx/conformance/ensure-owners",
                 "projects": ["!remix-app-e2e"]
             },
             {
@@ -218,7 +166,7 @@ This allows you to define conformance rules in your `nx.json`. Here is an exampl
 You can also define rules locally, as shown in the example above, which are simple TypeScript files:
 
 ```ts
-import { createConformanceRule } from '@nx/powerpack-conformance';
+import { createConformanceRule } from '@nx/conformance';
 
 const rule = createConformanceRule({
   name: 'local-conformance-rule-example',

docs/blog/2024-10-25-sports-retailer-success.md

@@ -2,9 +2,8 @@
 title: Improve your architecture and CI pipeline times with Nx projects
 slug: improve-architecture-and-ci-times-with-projects
 authors: [Philip Fulcher]
-tags: [nx, 'customer story']
+tags: ['customer story']
 cover_image: '/blog/images/2024-10-25/header.avif'
-pinned: true
 description: "US sports retailer's Nx monorepo transformation: CI pipeline times from 1hr to 7-9min, cache hit rates from 20% to 57%."
 ---
 

docs/blog/2025-01-06-nx-update-20-3.md

@@ -2,7 +2,7 @@
 title: 'Nx Update: 20.3!'
 slug: nx-update-20-3
 authors: [Zack DeRose]
-tags: [nx]
+tags: [nx, release]
 cover_image: /blog/images/2025-01-06/nx-20-3.png
 description: Discover the latest in Nx 20.3, featuring TypeScript project references, enhanced Rspack support, Nx Console improvements, and powerful Nx Cloud updates.
 ---
@@ -15,7 +15,7 @@ It's been a few months now since our last major update with [Nx 20](), let's che
 - [Nx Cloud Enhancements](#nx-cloud-enhancements)
 - [Angular 19 Support](#angular-19-support)
 - [Core Performance Improvements](#core-performance-improvements)
-- [Powerpack Updates](#powerpack-updates)
+- [Self-hosted Cache Updates](#selfhosted-cache-updates)
 - [RFC for Infinite Tasks](#rfc-for-infinite-tasks)
 
 You can also catch most of these updates direct from the team from our livestream:
@@ -191,31 +191,19 @@ We've also introduced spinners into the terminal ui for instances where a task i
 
 ![](/blog/images/2025-01-06/project-graph-spinner.gif)
 
-## Powerpack Updates
+## Self-hosted Cache Updates
 
-[Nx Powerpack](/nx-enterprise/powerpack) is a suite of paid extensions for the Nx CLI, that enables some features like [allowing for third-party storage services to be used for your remoted and shared caching](/nx-enterprise/powerpack/custom-caching), [specifying specific developers as owners of specific projects in your repo](/nx-enterprise/powerpack/owners), and [running language-agnostic conformance rules](/nx-enterprise/powerpack/conformance):
+> Update: Self-hosted cache was previously part of Powerpack. But no more, it is no free for everyone to use.
 
-{% cards cols="2" lgCols="3" mdCols="3" smCols="2" %}
+We just improved support for our [self-hosted caching packages](/recipes/running-tasks/self-hosted-caching) by adding adapters for [Azure](/nx-api/azure-cache) and [Google Cloud Storage](/nx-api/gcs-cache) as supported storage providers (in addition to [S3](/nx-api/s3-cache) or [simply using a shared file system](/nx-api/shared-fs-cache)).
 
-    {% link-card title="Conformance" type="Powerpack Feature" url="/nx-enterprise/powerpack/conformance" icon="CheckBadgeIcon" /%}
-    {% link-card title="Owners" type="Powerpack Feature"  url="/nx-enterprise/powerpack/owners" icon="UserGroupIcon" /%}
-    {% link-card title="Self-Hosted Remote Cache" type="Powerpack Feature"  url="/nx-enterprise/powerpack/custom-caching" icon="ServerIcon" /%}
-
-{% /cards %}
-
-Recently, we've added support for [Azure](/nx-api/powerpack-azure-cache) and [Google Cloud Storage](/nx-api/powerpack-gcs-cache) as supported storage providers (in addition to [S3](/nx-api/powerpack-s3-cache) or [simply using a shared file system](/nx-api/powerpack-shared-fs-cache)).
-
-We've also [added support for S3 compatible providers](/nx-api/powerpack-s3-cache#s3-compatible-providers) such as:
+We've also [added support for S3 compatible providers](/nx-api/s3-cache#s3-compatible-providers) such as:
 
 - [MinIO](https://min.io/product/s3-compatibility)
 - [LocalStack](https://www.localstack.cloud)
 - [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces)
 - [Cloudflare](https://www.cloudflare.com/developer-platform/solutions/s3-compatible-object-storage)
 
-We've also added the capability to allow folks to authenticate their Powerpack license via Nx Cloud (rather than requiring that the license be committed to the repository). This should enable oss library authors use Powerpack - without exposing their private license via their repo.
-
-We are offering free Nx Powerpack licenses to all open source libraries. We also offer free licenses to smaller businesses. If you are interested, you may [request a license now using Nx Cloud](/nx-enterprise/powerpack/free-licenses-and-trials).
-
 ## RFC for Infinite Tasks
 
 Last up, we have an [RFC for the concept of "Infinite Tasks"](https://github.com/nrwl/nx/discussions/29025) on GitHub now. This is a new feature that we'll be adding soon to support non-discrete tasks in terms of the task dependencies. It should come in handy for use-cases like:

docs/blog/2025-01-09-who-gave-js-a-build-step.md

@@ -199,4 +199,4 @@ We have an input format we want to work with - and an output format that we want
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nx Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-01-22-nx-cloud-scale-your-ci-and-team-with-ease.md

@@ -0,0 +1,17 @@
+---
+title: 'Nx Cloud: Scale Your CI and Team with Ease'
+description: 'Learn how you can attain fast, reliable CI and better coordination across your technical organization with Nx Cloud, and see our new multi-workspace features for organizational scaling in action.'
+date: 2025-01-22
+slug: 'nx-cloud-scale-your-ci-and-team-with-ease'
+authors: ['Nicole Oliver', 'Rareș Matei', 'James Henry']
+tags: [webinar]
+cover_image: /blog/images/2025-01-22/Jan-webinar-image.png
+status: Past - Gated
+registrationUrl: https://go.nx.dev/jan2025-webinar
+---
+
+Presented by Nicole Oliver, Rareș Matei, and James Henry
+
+Learn how you can attain fast, reliable CI and better coordination across your technical organization with Nx Cloud, and see our new multi-workspace features for organizational scaling in action.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/jan2025-webinar" description="Sign up to gain access" /%}

docs/blog/2025-01-28-managing-ts-pkgs-in-monorepos.md

@@ -672,4 +672,4 @@ Also check out our docs:
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nx Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-01-29-new-nx-experience.md

@@ -380,4 +380,4 @@ If you're working in a large monorepo and **struggling with the performance issu
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nx Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-02-03-workspace-structure.md

@@ -215,4 +215,4 @@ If you want more insight into this topic, here are other resources we recommend:
 - 🧠 [Nx Docs](/getting-started/intro)
 - 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
 - 💬 [Nx Official Discord Server](https://go.nx.dev/community)
-- 📹 [Nx Youtube Channel](https://www.youtube.com/nrwl_io)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-02-06-hetzner-cloud-success-story.md

@@ -0,0 +1,90 @@
+---
+title: 'Hetzner Cloud gets More Features to Market with Faster, More Reliable CI'
+slug: hetzner-cloud-success-story
+authors: [Juri Strumpflohner]
+tags: ['customer story']
+description: Discover how Hetzner Cloud uses Nx Enterprise to ship new features to market faster and with more reliability.
+youtubeUrl: https://www.youtube.com/watch?v=2BLqiNnBPuU
+cover_image: /blog/images/articles/hetzner-cloud-story-bg.jpg
+pinned: true
+metrics:
+  - value: '116+'
+    label: 'projects in modular architecture'
+  - value: '85%'
+    label: 'cache hit rate'
+  - value: '6 days'
+    label: 'of computation saved every single day'
+  - value: '45→6'
+    label: 'minutes on CI'
+---
+
+Hetzner Cloud is a leading provider of cloud infrastructure solutions, known for its reliability and flexibility. Their platform enables businesses to deploy and manage cloud environments efficiently, catering to a broad range of use cases, from hosting applications to scaling complex workloads. As the company grew, its engineering team faced challenges in maintaining development speed and team collaboration.
+
+## Challenge
+
+As Hetzner Cloud scaled its operations, two primary challenges emerged:
+
+- **Team structure and scaling** – The growing codebase made it difficult to organize teams efficiently and allocate clear ownership.
+- **CI performance** – Long feedback loops slowed down development, making it harder to ship updates quickly.
+
+> Changes often required modifying several repositories and running multiple pipelines, adding unnecessary complexity and slowing development.
+
+They found themselves in the situation that plagues most large organizations: the struggle with code organization. Over time, a monolithic architecture can become difficult to manage, with tightly interwoven dependencies making it hard to separate concerns. Hetzner Cloud's engineering team needed a structured approach to:
+
+- Modularize their monolithic application into smaller, more manageable units.
+- Allocate teams more effectively by defining ownership at a modular level.
+- Enforce clear boundaries between different parts of the system to prevent unintentional dependencies.
+
+In addition to their monolith, Hetzner Cloud had multiple related projects spread across GitLab. Changes often required modifying several repositories and running multiple pipelines, adding unnecessary complexity and slowing development.
+
+Their existing CI setup presented another major challenge.
+
+- Pipelines took **45 minutes per run**, introducing significant delays in shipping features.
+- GitLab merge trains helped maintain code quality but resulted in redundant work, repeatedly running tests and builds even when unchanged code was involved.
+
+Hetzner Cloud needed a solution that would streamline their development process, consolidate fragmented projects, and significantly improve CI performance.
+
+## Solution
+
+After evaluating Nx and Turborepo, Hetzner Cloud selected Nx for its advanced monorepo management capabilities. They started a [Nx Enterprise](/enterprise) contract and closely collaborated with the Nx Developer Productivity Engineers to assess Hetzner's current software landscape and evaluate the best strategy. Their goal was not necessarily to create a monorepo in the first place, but to modularize their monolithic application. Nx provided the right tools to:
+
+- **Break down the monolith** into modular packages without affecting deployment.
+- **Define clear domain boundaries** using [module boundary rules](/features/enforce-module-boundaries) and [conformance rules](/nx-api/conformance).
+- **Improve ownership management** by having a more modular structure with clear boundaries allowing for easier allocaton of owernship. Something that could further be improved in the future by using [CodeOwners](/nx-enterprise/powerpack/owners).
+
+Beyond modularization, Nx helped consolidate fragmented projects into a single, structured workspace. This reduced the overhead of maintaining multiple repositories and simplified dependency management. Using the [Nx Graph](/features/explore-graph), the team gained visibility into their project relationships, making it easier to coordinate work and optimize collaboration.
+
+{% testimonial
+    name="Pavlo Grosse"
+    title="Senior Software Engineer, Hetzner Cloud"
+    image="/documentation/blog/images/articles/pavlo-grosse.avif" %}
+Junior developers were amazed at how fast things became. They'd run tests expecting them to take 20 minutes, and they'd finish in seconds!
+{% /testimonial %}
+
+To tackle the CI performance bottleneck, Hetzner Cloud adopted [Nx Cloud](/ci/features/remote-cache), highly leveraging its [Nx Replay feature](/ci/features/remote-cache), ability to [distribute runs](/ci/features/distribute-task-execution) and re-run [flaky tasks automatically](/ci/features/flaky-tasks). These capabilities allowed them to optimize their CI workflows and eliminate inefficiencies that had previously slowed down development cycles.
+
+- **Minimized redundant processing** – PRs in merge trains only reprocessed necessary parts, restoring everything else from the [Nx remote cache](/ci/features/remote-cache).
+- **Drastic CI time reduction** – Pipelines that previously took **45 minutes** now averaged **6 minutes**, even as more projects were onboarded.
+- **Improved debugging capabilities** – Nx Cloud provides insights into task execution times and makes it easy to search logs of failed ones, making troubleshooting more efficient.
+
+Also having the **[Nx Console extension in their IDE](/getting-started/editor-setup)** was a big time saver when working with a large workspace with hundreds of projects. It allows you to explore the workspace in a more visual way and trigger tasks directly from within the IDE vs typing commands in the terminal.
+
+## Results
+
+### From a Monolith to a Modular Architecture with 116+ Projects
+
+By structuring their codebase into fine-grained packages, Hetzner Cloud successfully transitioned from a large monolith to a modular architecture. This shift **made the codebase easier to maintain and evolve**, reducing dependencies between different parts of the system. It also allowed teams to be allocated more effectively, ensuring **clear ownership of specific areas** within the codebase, leading to a more efficient and scalable development process.
+
+### Pipeline Speed Improved Despite Codebase Growing to Hundreds of Projects
+
+CI performance saw a dramatic improvement. **Build times dropped from 45 minutes to most runs being around 6 minutes**, with some reaching up to 20 minutes. As Hetzner Cloud modularized the monolith into separate projects and brought in additional ones, **the codebase grew, yet CI execution time kept decreasing**, making scaling seamless. An 85% cache hit rate saved a staggering 6 days of compute time per day, totaling 197 days saved monthly.
+
+### Shipping Features Faster
+
+Consolidating projects into a single repository **eliminated the complexity of managing multiple repositories and pipelines**, reducing overhead from maintaining separate CI setups. This simplified cross-project changes, **allowing the team to ship features faster** and with greater confidence.
+
+### Continuous Refinement in Collaboration with Nx DPE Team
+
+Hetzner Cloud continues to **work closely with the Nx Developer Productivity Engineering (DPE) team** to monitor and refine their setup. By actively collaborating, they ensure that their monorepo remains optimized and that their CI is continuously improved. This ongoing partnership allows Hetzner Cloud to adapt to new challenges, fine-tune configurations, and further push the boundaries of efficiency in their development workflow.
+
+{% call-to-action title="Want to achieve similar results?" url="/enterprise" icon="nxcloud" description="Learn more about Nx Enterprise or get started with a free trial." /%}

docs/blog/2025-02-12-nx-agents-changes-the-math.md

@@ -0,0 +1,78 @@
+---
+title: 'Vattenfall changes the math on concurrent PRs with Nx Agents'
+slug: nx-agents-changes-the-math
+authors: [Philip Fulcher]
+tags: ['customer story']
+cover_image: /blog/images/2025-02-12/header.avif
+description: 'Vattenfall solves their CI runner limitation using Nx Cloud, improving from 4 concurrent PRs to 100.'
+metrics:
+  - value: '4→100'
+    label: 'concurrent PRs on CI'
+  - value: '44%'
+    label: 'reduction in CI runtimes'
+  - value: '> 1 year'
+    label: 'of computation saved every 30 days'
+---
+
+[Vattenfall](https://group.vattenfall.com/), a world leader in energy production, has been rapidly expanding their IT organization over the past few years – exponentially growing both their development teams and their codebase. As more developers joined and modular frontends proliferated, what started as a performant CI pipeline began showing signs of strain. The increasing complexity of their applications and test suites, combined with their commitment to maintaining high quality standards, created unprecedented demands on their CI infrastructure. Their CI provider had a limit of 100 CI runners in a pool, combined with a limit of one pool. If a single runner per PR would be enough, this would lead to 100 concurrent PRs. More than enough for most teams. However, their workspace needed 25+ runners to complete in a timely manner. This resulted in only four concurrent PRs available, slowing down their team immensely and blocking important work from making it through CI.
+
+## Hitting the limits of CI providers
+
+It's typical for some limits to be imposed by your CI provider. You may have a set number of persistent runners that can't be increased. Even if you have ephemeral runners, you likely have a limit on how many of those runners can be active at a time. These limits might be driven by cost control or technical limitations by the provider, but they all mean the same thing: **the number of concurrent PRs you can run is limited by your number of runners**.
+
+In a world where each PR needs one runner for CI, you can have one concurrent PR running for each runner you have. But a single runner per PR just doesn’t scale. Instead, you’ll need to distribute tasks across multiple runners.
+
+Now you're in a balancing act of how many runners can be assigned to a PR so that it completes faster vs how many PRs can be run at the same time. Your number of concurrent PRs becomes your available runners divided by the number of runners for each PR.
+
+![Formula for calcuating number of concurrent PRs: "Available Runners" divided by "Runners per PR" equals "Concurrent PRs".](/blog/images/2025-02-12/previous-formula.avif)
+
+## Nx Agents unlocks concurrency
+
+Working with our [Nx Enterprise](/enterprise) team, Vattenfall was able to unblock their team with Nx Agents enabling **more concurrent PR runs**. Not only that, but Nx Agents **lowered PR runtimes by 44%** and unlocked other features and tools that had been limited by their number of runners.
+
+Nx Agents makes it quick and easy to enable task distribution in your PR runs without consuming CI runners. How?
+
+When using Nx Agents, the tasks for your PR are now completed by Nx Agents rather than your CI runners. Your CI runner starts, runs your configured Nx commands to collect the tasks that need to be completed, and sends them to Nx Cloud. From there, Nx Agents are spun up and complete the work for each task to report back to the CI runner.
+
+![Illustration showing Nx Agents pulling a task to complete.](/blog/images/2025-02-12/agents.avif)
+
+This reduces our concurrency calculation to be 1:1 with our number of runners while still reaping the benefits of parallelism across multiple agents.
+
+![Modified Formula for calcuating number of concurrent PRs: "Runners per PR" is scratched out and replaced by "Nx Cloud" leaving "Available Runners" equals "Concurrent PRs".](/blog/images/2025-02-12/new-formula.avif)
+
+## From 4 concurrent PRs to 100
+
+So, how did Nx Agents help with the concurrent PR runs problem Vattenfall was facing? Our Nx Enterprise team was able to [trial Agents](/enterprise/trial) with them, quickly resulting in huge benefits for their team. They were able to re-enable that 100 PR concurrency by distributing all work to Nx Agents. Their limited pool of 100 runners was again able to handle 100 concurrent PRs, while still retaining the benefits of distributing tasks across Nx Agents. Nx Agents will continue to scale, adding more agents as needed to keep PR runtimes within reason. Concurrent PR runs will continue to match their number of CI runners no matter how many agents they need to distribute tasks.
+
+![Graph showing pipeline improvements before and after Nx Agents. CI pipeline times (in minutes) improve from 70 moinutes to less than 10 minutes. Concurrent PRs improve from 4 to 100.](/blog/images/2025-02-12/pipeline-improvements.avif)
+
+## Unlocking more than just concurrent PR runs
+
+What else did Vattenfall unlock with more concurrent PR runs?
+
+### Reduced CI runtimes by 44%
+
+This increase in concurrent PRs is a big win in and of itself, but it also resulted in faster CI run times. Average CI runtimes went from 39 minutes to 22 minutes, a **44% improvement**. Not only are there more PRs running concurrently, they're running faster.
+
+### Enabling flaky test detection to avoid PR re-runs
+
+Using Nx Agents has also enabled flaky task retries for them, reducing the number of times that PRs have to be re-run. Tasks that fail only sometimes and only in certain environments are called "flaky tasks." They are enormously time-consuming to identify and debug. **Nx Cloud can reliably detect flaky tasks and automatically schedule them to be re-run on a different agent**. By re-running flaky tasks until they pass, Nx Cloud ensures that the PR run completes the first time and doesn’t have to be re-run just to get a flaky task to pass.
+
+### Unlocking RenovateBot
+
+RenovateBot helps automate dependency updates by creating pull requests when dependencies need to be updated. Previously, this PR would have consumed more CI runners and would have been yet another blocker on their team for making progress. They had to prioritize the runners for PRs created by engineers rather than allow RenovateBot to run. With the increased concurrency allowed by Nx Agents, they are now able to run RenovateBot on a regular basis.
+
+{% testimonial
+name="Martijn van der Meij"
+title="Solution Designer, Vattenfall"
+image="/documentation/blog/images/2025-02-12/martijn.avif" %}
+Other engineers in other business units are seeing the advantage of Nx, and their managers are talking to our managers about copying the way we work. **They're saying "Nx is solving this problem we didn't even know we had"**
+{% /testimonial %}
+
+## What could Nx Agents unlock for you?
+
+What's blocking you from getting your products to market fast? Let our team figure it out for you! With Nx Enterprise, you receive expert guidance from day one, ensuring your setup is optimized for maximum efficiency. Whether you're starting fresh, migrating, or scaling your developer platform, we'll work with you to tailor the perfect solution for your team.
+
+{% call-to-action title="Get a Free Trial of Nx Enterprise" url="/enterprise" icon="nxcloud" description="Learn more about our enterprise offerings or request a free trial of Nx Enterprise" %}
+
+{% /call-to-action %}

docs/blog/2025-02-17-monorepos-are-ai-future-proof.md

@@ -0,0 +1,153 @@
+---
+title: 'Nx Just Made Your LLM Way Smarter'
+slug: nx-just-made-your-llm-smarter
+authors: ['Juri Strumpflohner']
+tags: ['nx']
+description: 'Learn how monorepos with Nx enhance AI capabilities by providing rich metadata and context, making LLMs smarter and more architecturally aware.'
+cover_image: /blog/images/articles/monorepos-are-ai-future-proof-bg.jpg
+youtubeUrl: https://youtu.be/RNilYmJJzdk
+---
+
+{% callout type="deepdive" title="Series: Making your LLM smarter" expanded=true %}
+
+- **Nx Just Made Your LLM Way 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)
+
+{% /callout %}
+
+Everyone is constantly pushing to be more productive: delivering more features, reducing overhead, and keeping up with increasing demands. Companies want to move faster, and engineering teams work toward the same goal, looking for ways to streamline development and ship more with fewer resources. LLMs offer a promising way to boost efficiency, whether by assisting individual developers or improving workflows across a team.
+
+However, the quality of an LLM's response depends entirely on the data and context it has access to. Ask an LLM (in this case, GitHub Copilot with GPT-4o) about the structure of an NPM workspace monorepo, and you probably won't be satisfied with the result:
+
+![nx-ai-before-workspace-structure.avif](/blog/images/articles/nx-ai-before-workspace-structure.avif)
+
+Now compare that result, using the exact same question, but with additional context provided to the LLM:
+
+![nx-ai-after-workspace-structure.avif](/blog/images/articles/nx-ai-after-workspace-structure.avif)
+
+The difference is huge. Copilot now understands the architectural structure of the workspace. It recognizes that there are apps and libraries, their types (such as "data access" libraries), and how each relates to other projects in the monorepo.
+
+![nx-ai-after-workspace-structure2.avif](/blog/images/articles/nx-ai-after-workspace-structure2.avif)
+
+**So what changed?** Let's break it down.
+
+{% toc /%}
+
+## Monorepos Break Down Barriers
+
+When we (at Nx) [work with large enterprises](/enterprise), we often see patterns that lead to inefficiencies:
+
+- **Siloed knowledge** – Developers only have visibility into the areas they actively work on. Without a broader view, duplication increases, communication slows down, and collaboration suffers.
+- **Fragmentation** – Code is spread across multiple repositories with little integration. LLMs don't automatically understand how different projects connect or who owns what.
+- **Lack of integration** – Many productivity bottlenecks come from friction at integration points between teams.
+
+LLMs face the same challenges. They operate on a small scope, usually a few files at a time, but **lack architectural awareness**. They don't know how projects relate to each other, where the integration points are, or which team owns a given project.
+
+Monorepos solve visibility and fragmentation issues by consolidating related projects into a single repository. This gives teams a shared view, removes communication barriers, reduces duplication, and improves collaboration.
+
+**The same visibility that helps developers also helps an LLM.** Think about it: when you open your monorepo in VSCode or Cursor, you can see multiple related projects in one place. That's very different from working across scattered repositories.
+
+The problem? Even though your entire codebase is accessible, an LLM still only sees files and their contents. It doesn't understand which project a file belongs to or how that project interacts with others. It simply lacks that knowledge.
+
+This is where Nx comes in.
+
+## Nx Understands Your Monorepo
+
+Monorepos don't come for free. While they improve visibility and collaboration, they introduce scaling challenges. This is where tools like Nx step in, helping you get the benefits of a monorepo while managing the complexity that comes with it.
+
+Over the years, we've built features like [Nx Replay](/ci/features/remote-cache) and [Nx Agents](/ci/features/distribute-task-execution) to keep CI fast, while [conformance rules](/nx-enterprise/powerpack/conformance), [ownership](/nx-enterprise/powerpack/owners), and [local repository automation](/extending-nx/intro/getting-started) help manage and scale a monorepo in the long run.
+
+To power these features, **Nx collects metadata about your workspace**, understanding relationships between projects, ownership, technology types, available tasks, and more. The [Nx daemon](/concepts/nx-daemon) runs in the background, keeping this metadata up to date and making sure Nx operates efficiently.
+
+**Nx understands project relationships down to the file level**, tracking dependencies. For example, in the image below, `src/app/app.tsx` imports a component from `@aishop/feat-create-order`, and Nx knows exactly how these projects connect.
+
+![nx-ai-project-relationships.avif](/blog/images/articles/nx-ai-project-relationships.avif)
+
+**Nx also tracks available targets for each project**. If you're using [Code Owners](/nx-enterprise/powerpack/owners), it **knows who owns what within your monorepo**.
+
+![nx-ai-project-detail-view.avif](/blog/images/articles/nx-ai-project-detail-view.avif)
+
+It **identifies relevant files for each target** based on the input and output properties defined in the [cache configuration](/features/cache-task-results#finetune-caching-with-inputs-and-outputs).
+
+![nx-ai-cache-inputs.avif](/blog/images/articles/nx-ai-cache-inputs.avif)
+
+Nx also knows about **project tags, helping classify domains, project types, or any other custom attributes** you've applied.
+
+![nx-ai-project-tags.avif](/blog/images/articles/nx-ai-project-tags.avif)
+
+Nx plugins come with **[code generators](/features/generate-code)** that can scaffold entire projects. These generators have well-defined [schemas](https://github.com/nrwl/nx/blob/804df721a729da41d804c57a829828c96d265d79/packages/js/src/generators/library/schema.json) that describe the available properties, their descriptions, and which ones are required. This structured metadata makes them an ideal data source for LLMs, allowing them to provide more accurate and meaningful suggestions when interacting with your monorepo.
+
+![nx-ai-generator-schema.avif](/blog/images/articles/nx-ai-generator-schema.avif)
+
+These are just some examples of the metadata Nx maintains about your monorepo.
+
+Beyond that, the [Nx documentation already includes an AI-powered chat](/ai-chat), and its data can be injected directly into your LLM conversations as well.
+
+![nx-ai-docs-assistant.avif](/blog/images/articles/nx-ai-docs-assistant.avif)
+
+## Nx Makes Your LLM Way Smarter
+
+All of this data is a goldmine for enhancing your LLM. Luckily we're kinda obsessed with good DX which is why we had an editor for a long time: [Nx Console](/getting-started/editor-setup).
+
+While you could build your own chat-based LLM integration, the best approach is to make it work where developers already spend their time: inside the editor. Nx Console is the perfect fit for this. It already enhances your monorepo workflow by providing IntelliSense, running code generators, and [integrating with CI](/blog/nx-cloud-pipelines-come-to-nx-console). Now, we've taken it a step further.
+
+We extended Nx Console with an integration for Copilot that preprocesses Nx metadata and provides the LLM with details about:
+
+- The workspace structure, including applications and libraries.
+- How projects are connected.
+- A project's technology stack.
+- Tasks and which files are relevant for each task (e.g., spec files for test runs).
+- Categorization via tags and dependency rules.
+- Project ownership information.
+- …
+
+The result: **your LLM just got significantly smarter**, moving beyond basic file-level reasoning to understanding your workspace at an architectural level.
+
+Let's go through some concrete examples. You can try these yourself by [installing Nx Console](/getting-started/editor-setup) or updating to the latest version.
+
+Here, we ask Copilot about projects, their dependencies, and ownership details:
+
+![nx-ai-example-project-data.avif](/blog/images/articles/nx-ai-example-project-data.avif)
+
+We can also go deeper, asking where to best implement certain types of functionality:
+
+![nx-ai-example-data-access-feature.avif](/blog/images/articles/nx-ai-example-data-access-feature.avif)
+
+In a larger enterprise, this also means you can ask about who to talk to when implementing or planning a new feature. Thanks to Nx metadata, the LLM understands ownership:
+
+![nx-ai-example-ownership.avif](/blog/images/articles/nx-ai-example-ownership.avif)
+
+And since we made the LLM aware of [Nx generators](/features/generate-code), we can ask it to help set up a new project. Notice how it not only suggests the correct command but also places the new project in the `packages/products` subfolder. We even added action buttons to either run the command immediately or open it in [Nx Console's generator UI](/recipes/nx-console/console-generate-command).
+
+![nx-ai-example-generate-code.avif](/blog/images/articles/nx-ai-example-generate-code.avif)
+
+Beyond that, since we also feed documentation data into the LLM, it can now answer questions about Nx itself:
+
+![nx-ai-example-cache-config.avif](/blog/images/articles/nx-ai-example-cache-config.avif)
+
+## Nx Monorepos Are AI Future-Proof
+
+Right now, most LLM editor extensions operate at the file level, unless you manually feed them additional context. But this is going to change. LLMs will continue to improve, and most importantly, their context windows will grow.
+
+That's why **we strongly believe monorepos are AI future-proof**. They provide a consolidated view of multiple projects, and when enhanced with Nx metadata, they allow an LLM to reason at a higher architectural level. Instead of just answering file-specific questions, it can assist with broader development workflows, project structure, and cross-project interactions.
+
+And this is just the beginning. While Nx already understands your local monorepo, [Nx Cloud](/nx-cloud) holds valuable CI-related data, tracking which tasks take the longest, where failures are most common, identifying flaky tasks, and even mapping project relationships beyond a single monorepo. Combining local workspace metadata with Nx Cloud insights creates an even richer foundation for LLMs, unlocking more meaningful suggestions and optimizations.
+
+## Try It Out Yourself
+
+If you want to test this out, [create a new Nx workspace](/getting-started/intro#try-nx-yourself) and make sure you have [Nx Console](/getting-started/editor-setup) installed or updated to the latest version.
+
+> If you already have an existing NPM/Yarn/PNPM workspace, you can add Nx with `nx init`. Check out [our free course](/courses/pnpm-nx-next) to learn more.
+
+While Nx Console is also available for WebStorm, the AI-powered extensions currently only work with VSCode and Copilot.
+
+---
+
+Learn more:
+
+- 🧠 [Nx Docs](/getting-started/intro)
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-02-21-using-apollo-graphql-with-react-in-an-nx-workspace.md

@@ -0,0 +1,719 @@
+---
+title: 'Using Apollo GraphQL in an Nx Workspace'
+slug: 'using-apollo-graphql-in-an-nx-workspace'
+authors: ['Philip Fulcher']
+cover_image: '/blog/images/2025-02-21/header.avif'
+tags: [nx]
+description: 'Learn how to create an Nx workspace that provides a GraphQL API via Apollo Server, a React frontend, and code generated by GraphQL Codegen to save time on development.'
+---
+
+Because of the Nx's robust support for a diverse ecosystem of JavaScript development, it enables you to build your entire full-stack application in a single repo. This allows you to share code and interfaces between your frontend and backend and acts as a multiplier on your development velocity.
+
+[GraphQL](https://graphql.org/) is a query language for your API. Because of its typed schema definition, it’s a great candidate for defining the contract between your API and its consumers. By using smart tools to generate code based on that schema, you can save yourself a lot of time and enforce better cooperation between your frontend and backend.
+
+In this article, you will build a simple GraphQL API that tracks some information about Lego sets. You’ll create this API using Apollo Server, and it will be consumed by a React application. You’ll have this all inside of an Nx Workspace in a single repository.
+
+In this article, you’ll learn how to:
+
+- Create an Nx workspace for both frontend and backend applications
+- Create a GraphQL API using [Apollo Server](https://www.apollographql.com/docs/apollo-server)
+- Generate frontend code and backend resolver types based on your GraphQL schema using [GraphQL Codegen](https://the-guild.dev/graphql/codegen)
+- Create a [React](https://react.dev/) application to consume your GraphQL API
+
+{% callout type="note" title="Minimal configuration" %}
+When given the option to enable another tool, like linting or testing, we're going to decline. This keeps this article focussed on GraphQL instead of having lint and test configs in the example. As you progress, feel free to enable these additional options if you'd like, especially if you're adding to an existing workspace that has those tools enabled.
+{% /callout %}
+
+An example repo with all the work you’ll be doing here can be found in [our Nx Recipes repo](https://github.com/nrwl/nx-recipes/tree/main/apollo-graphql)
+
+## Create a new workspace
+
+Start by creating an Nx workspace:
+
+```shell
+npx create-nx-workspace@latest --preset=node-monorepo nx-apollo
+```
+
+When prompted, answer the prompts as follows:
+
+```shell
+❯ npx create-nx-workspace@latest --preset node nx-apollo
+
+ NX   Let's create a new workspace [https://nx.dev/getting-started/intro]
+
+✔ Application name · api
+✔ What framework should be used? · none
+✔ Would you like to generate a Dockerfile? [https://docs.docker.com/] · No
+✔ Which CI provider would you like to use? · skip
+✔ Would you like remote caching to make your build faster? · skip
+```
+
+## Create GraphQL schema and project
+
+We want to generate model types from our schema that can be used by other projects in our workspace, so we'll start by creating a new project:
+
+```shell
+npx nx g @nx/js:library --directory=libs/models-graphql models-graphql
+```
+
+When prompted, answer the prompts as follows:
+
+```shell
+❯ npx nx g @nx/js:library --directory=libs/models-graphql models-graphql
+
+ NX  Generating @nx/js:library
+
+✔ Which bundler would you like to use to build the library? Choose 'none' to skip build setup. · none
+✔ Which linter would you like to use? · none
+✔ Which unit test runner would you like to use? · none
+```
+
+{% callout type="note" title="Why do I need a separate project?" %}
+When you have your GraphQL schema and generated models in a separate project, other projects can depend on it. This ensures that all projects are using the same version of the schema and models. This exemplifies the "modulith" structure for monorepos. [Read more](/blog/virtuous-cycle-of-workspace-structure)
+{% /callout %}
+
+You need a GraphQL schema to create the API, so write a very simple one with a single query and a single mutation. Create a file named `schema.graphql` in the new `models-graphql` project:
+
+```graphql {% fileName="libs/models-graphql/src/lib/schema.graphql" %}
+type Set {
+  id: Int!
+  name: String
+  year: Int
+  numParts: Int
+}
+
+type Query {
+  allSets: [Set]
+}
+
+type Mutation {
+  addSet(name: String, year: String, numParts: Int): Set
+}
+```
+
+To start generating our models from this schema, we'll use [GraphQl Codegen](https://the-guild.dev/graphql/codegen). Install the packages needed:
+
+```shell
+npm install -D @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-resolvers @graphql-codegen/typescript-react-apollo
+```
+
+GraphQL Codegen is controlled by a configuration file named `codegen.ts` in each project that needs it. Create one for `models-graphql`:
+
+```typescript {% fileName="libs/models-graphql/codegen.ts" %}
+import type { CodegenConfig } from '@graphql-codegen/cli';
+
+const config: CodegenConfig = {
+  schema: 'libs/models-graphql/src/lib/schema.graphql',
+  generates: {
+    'libs/models-graphql/src/lib/__generated__/models.ts': {
+      plugins: ['typescript'],
+      config: {
+        avoidOptionals: true,
+      },
+    },
+  },
+};
+export default config;
+```
+
+To run GraphqlQL Codegen, we need a target added to our project. Add this to the `project.json` for `models-graphql`:
+
+```json {% fileName="libs/models-graphql/project.json" %}
+"targets": {
+    "codegen": {
+      "command": "npx graphql-codegen --config {projectRoot}/codegen.ts"
+    }
+}
+```
+
+Run the `codegen` task to generate our new models:
+
+```shell
+npx nx codegen models-graphql
+```
+
+You should see the new models created in the `__generated__` directory in `models-graphql`. To use them outside the project, export them from the `index.ts`:
+
+```typescript {% fileName="libs/models-graphql/src/index.ts" %}
+export * from './lib/__generated__/models';
+```
+
+## Create GraphQL API
+
+Use Apollo Server to create your GraphQL api. Start by installing the GraphQL modules needed for Apollo
+
+```shell
+npm install @apollo/server graphql
+```
+
+The workspace was generated with a Node application for us, but we need to make some small changes to support ESM for Apollo Server. First, change these compiler options in `tsconfig.app.json`:
+
+```json {% fileName="apps/api/tsconfig.app.json" %}
+  "compilerOptions": {
+    "lib": ["es2020"],
+    "target": "es2020",
+    "module": "esnext",
+    "moduleResolution": "node",
+    "esModuleInterop": true,
+    ...
+  }
+```
+
+And change the `build` target config in `project.json`:
+
+```json {% fileName="apps/api/project.json" %}
+"targets": {
+  "build": {
+    ...
+    "options": {
+      ...
+      "format": ["esm"]
+    }
+  }
+}
+```
+
+GraphQl Codegen has already created our models for our GraphQL schema, but it can also generate the resolver types we'll want to implement in Apollo Server. Like before, create a `codegen.ts` in the `api` application:
+
+```typescript {% fileName="apps/api/codegen.ts" %}
+import type { CodegenConfig } from '@graphql-codegen/cli';
+
+const config: CodegenConfig = {
+  schema: 'libs/models-graphql/src/lib/schema.graphql',
+  generates: {
+    'apps/api/src/__generated__/resolvers.ts': {
+      plugins: ['add', 'typescript-resolvers'],
+      config: {
+        useIndexSignature: true,
+        content: 'import * as types from "@nx-apollo/models-graphql"',
+        namespacedImportName: 'types',
+      },
+    },
+  },
+};
+export default config;
+```
+
+And add the task to our targets:
+
+```json {% fileName="apps/api/project.json" %}
+  "targets": {
+    "codegen": {
+      "command": "npx graphql-codegen --config {projectRoot}/codegen.ts"
+    }
+}
+```
+
+And run the task:
+
+```shell
+npx nx codegen api
+```
+
+And now there should be resolver types in the `__generated__` directory. We're ready to put create our Apollo Server application. Replace the contents of `main.ts` with this:
+
+```typescript {% fileName="apps/api/src/main.ts" %}
+import { ApolloServer } from '@apollo/server';
+import { startStandaloneServer } from '@apollo/server/standalone';
+import { Set } from '@nx-apollo/models-graphql';
+import { readFileSync } from 'fs';
+import { join } from 'path';
+import { Resolvers } from './__generated__/resolvers';
+
+// Note: this uses a path relative to the project's
+// root directory, which is the current working directory
+// if the server is executed using `npm run`.
+const typeDefs = readFileSync(
+  join('libs/models-graphql/src/lib', 'schema.graphql'),
+  { encoding: 'utf-8' }
+);
+
+const sets: Set[] = [
+  {
+    id: 1,
+    name: 'Voltron',
+    numParts: 2300,
+    year: '2019',
+  },
+  {
+    id: 2,
+    name: 'Ship in a Bottle',
+    numParts: 900,
+    year: '2019',
+  },
+];
+
+// Resolvers define how to fetch the types defined in your schema.
+// This resolver retrieves books from the "books" array above.
+const resolvers: Resolvers = {
+  Query: {
+    allSets: () => sets,
+  },
+  Mutation: {
+    addSet: (parent, args) => {
+      const newSet = {
+        id: sets.length + 1,
+        name: args.name,
+        year: args.year,
+        numParts: +args.numParts,
+      };
+
+      sets.push(newSet);
+
+      return newSet;
+    },
+  },
+};
+
+// The ApolloServer constructor requires two parameters: your schema
+// definition and your set of resolvers.
+const server = new ApolloServer({
+  typeDefs,
+  resolvers,
+});
+
+// Passing an ApolloServer instance to the `startStandaloneServer` function:
+//  1. creates an Express app
+//  2. installs your ApolloServer instance as middleware
+//  3. prepares your app to handle incoming requests
+const { url } = await startStandaloneServer(server, {
+  listen: { port: 4000 },
+});
+
+console.log(`🚀  Server ready at: ${url}`);
+```
+
+This is already enough to see some progress when you run the `api` application.
+
+```shell
+npx nx serve api
+```
+
+When the application is running, bring up the GraphQL Playground in your browser at [http://localhost:4000/](http://localhost:4000/)
+
+Here you can inspect your GraphQL schema as well as submit queries and mutations.
+
+This is a very simple resolver that holds data in memory. It returns the current contents of the sets array for the `allSets` query and allows users to add a new set using the `addSet` mutation. Add this resolver to the providers array in your app module:
+
+Go back to your GraphQL Playground and see if your queries return any data now. Try a query and a mutation:
+
+```graphql
+query allSets {
+  allSets {
+    id
+    name
+    numParts
+  }
+}
+
+mutation addSet {
+  addSet(name: "My New Set", numParts: 200, year: "2020") {
+    id
+  }
+}
+```
+
+Now that the API is working, you’re ready to build a frontend to access this.
+
+## Add React frontend
+
+Start by adding a React app to your workspace using the `@nx/react` plugin:
+
+```shell
+npx nx add @nx/react
+```
+
+Create the React app using the generator:
+
+```shell
+npx nx g @nx/react:app --directory=apps/frontend frontend
+```
+
+When prompted, answer the prompts as follows:
+
+```shell
+❯ npx nx g @nx/react:app --directory=apps/frontend frontend
+
+ NX  Generating @nx/react:application
+
+✔ Which stylesheet format would you like to use? · tailwind
+✔ Would you like to add React Router to this application? (y/N) · false
+✔ Which bundler do you want to use to build the application? · vite
+✔ Which linter would you like to use? · none
+✔ What unit test runner should be used? · none
+✔ Which E2E test runner would you like to use? · none
+```
+
+We use Tailwind styles here for convenience. It will allow us to add some simple styles to our app without adding CSS files and importing them.
+
+The Apollo client makes it easy to consume your GraphQL API. Install the client:
+
+```shell
+npm install @apollo/client
+```
+
+Modify your `app.tsx` to provide the Apollo Client:
+
+```typescript {% fileName="apps/frontend/src/main.tsx" %}
+import { StrictMode } from 'react';
+import * as ReactDOM from 'react-dom/client';
+import App from './app/app';
+import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client';
+
+const root = ReactDOM.createRoot(
+  document.getElementById('root') as HTMLElement
+);
+
+const client = new ApolloClient({
+  uri: 'http://localhost:4000/graphql',
+  cache: new InMemoryCache(),
+});
+
+root.render(
+  <StrictMode>
+    <ApolloProvider client={client}>
+      <App />
+    </ApolloProvider>
+  </StrictMode>
+);
+```
+
+## Create React library
+
+Nx helps you break down your code into well-organized libraries for consumption by apps, so create a couple of React libraries to organize your work. Create a `data-access` library that handles communication with the backend and a `feature-sets` library that includes container components for displaying the Lego set data. In a real app, you might also create a `ui` library that includes reusable presentational components, but that is not part of this example. For more information on how to organize your React monorepo using Nx, read our book _Effective React Development with Nx_ by registering [here](https://go.nx.dev/react-book)
+
+To create the described project, run this command:
+
+```shell
+npx nx g @nx/react:lib --directory=libs/feature-sets feature-sets
+```
+
+When prompted, answer the prompts as follows:
+
+```shell
+npx nx g @nx/react:lib --directory=libs/feature-sets feature-sets
+
+ NX  Generating @nx/react:library
+
+✔ Which bundler would you like to use to build the library? Choose 'none' to skip build setup. · none
+✔ What unit test runner should be used? · none
+```
+
+## Setup React Code Generation
+
+A tool called GraphQL Codegen makes the development of your feature library faster.
+
+You need to create some GraphQL queries and mutations for the frontend to consume. Create a file named `operations.graphql` in the projects:
+
+```graphql {% fileName="libs/feature-sets/src/lib/operations.graphql" %}
+mutation addSet($name: String!, $year: String!, $numParts: Int!) {
+  addSet(name: $name, year: $year, numParts: $numParts) {
+    id
+    name
+    numParts
+    year
+  }
+}
+
+query setList {
+  allSets {
+    id
+    name
+    numParts
+    year
+  }
+}
+```
+
+Once again create a `codegen.ts` for the project:
+
+```typescript {% fileName="libs/feature-sets/codegen.ts" %}
+import { CodegenConfig } from '@graphql-codegen/cli';
+
+const config: CodegenConfig = {
+  schema: 'libs/models-graphql/src/lib/schema.graphql',
+  documents: ['libs/feature-sets/src/**/*.graphql'],
+  generates: {
+    'libs/feature-sets/src/lib/__generated__/operations.ts': {
+      plugins: ['add', 'typescript-operations', 'typescript-react-apollo'],
+      config: {
+        useIndexSignature: true,
+        content: 'import * as types from "@nx-apollo/models-graphql"',
+        namespacedImportName: 'types',
+      },
+    },
+  },
+  ignoreNoDocuments: true,
+};
+
+export default config;
+```
+
+This configuration grabs all of your GraphQL files and generates all the needed types and services to consume the API.
+
+Add a new task in `project.json` to run this code generator:
+
+```json {% fileName="libs/feature-sets/project.json" %}
+  "targets": {
+    "codegen": {
+      "command": "npx graphql-codegen --config {projectRoot}/codegen.ts"
+    }
+}
+```
+
+Now you can run that task using the Nx CLI:
+
+```shell
+npx nx codegen feature-sets
+```
+
+You should now have a folder called `__generated__` in your `feature-sets` library with a file named `operations.ts`. It contains typing information about the GraphQL schema and the operations you defined. It even has some hooks that make consuming this API superfast.
+
+## Create React components
+
+You now have everything needed to start building your React components. Create two components: a list of Lego sets and a form to add a Lego set. Use Nx generators to scaffold these:
+
+```shell
+npx nx generate @nx/react:component libs/feature-sets/src/lib/add-set-form
+```
+
+```shell
+npx nx generate @nx/react:component libs/feature-sets/src/lib/set-list
+```
+
+When prompted, answer the prompts as follows:
+
+```shell
+❯ npx nx generate @nx/react:component libs/feature-sets/src/lib/add-set-form
+
+ NX  Generating @nx/react:component
+
+✔ Should this component be exported in the project? (y/N) · false
+```
+
+In the `SetList` component, add the following:
+
+```tsx {% fileName="libs/feature-sets/src/lib/set-list.tsx" %}
+import { useSetListQuery } from './__generated__/operations';
+
+export function SetList() {
+  const { loading, data } = useSetListQuery();
+
+  return loading ? (
+    <p>Loading ...</p>
+  ) : (
+    <ul className="mx-6 w-full list-none">
+      {data &&
+        data.allSets?.map(({ id, name, numParts, year }) => (
+          <li className="p-2 even:bg-slate-200">
+            {year} - <strong>{name}</strong> ({numParts} parts)
+          </li>
+        ))}
+    </ul>
+  );
+}
+
+export default SetList;
+```
+
+Notice how `useSetListQuery` is imported from the data-access library. This is a hook generated by GraphQL Codegen that provides the results of the `SetList` query. This entire pipeline is type-safe, using the types generated by GraphQL Codegen.
+
+In the `AddSetForm` component, add the following:
+
+```tsx {% fileName="libs/feature-sets/src/lib/add-set-form.tsx" %}
+import { useRef } from 'react';
+import { useAddSetMutation } from './__generated__/operations';
+
+export function AddSetForm() {
+  const formRef = useRef<HTMLFormElement>(null);
+  const [addSet] = useAddSetMutation({
+    refetchQueries: ['setList'],
+  });
+
+  const handleSubmit = (formData: FormData) => {
+    const name = formData.get('name')?.toString();
+    const year = formData.get('year')?.toString();
+    const numParts = parseInt(formData.get('numParts')?.toString() || '0', 10);
+
+    if (name && year && numParts > 0) {
+      addSet({ variables: { name, year, numParts } });
+    }
+    formRef.current?.reset();
+  };
+
+  return (
+    <form
+      ref={formRef}
+      action={handleSubmit}
+      className="mx-6 max-w-60 border border-slate-200 p-6"
+    >
+      <label
+        htmlFor="name"
+        className="block text-sm/6 font-medium text-gray-900"
+      >
+        Name
+      </label>
+      <div className="mt-2">
+        <input
+          id="name"
+          name="name"
+          type="text"
+          className="block w-full rounded-md bg-white px-3 py-1.5 text-base text-gray-900 outline outline-1 -outline-offset-1 outline-gray-300 placeholder:text-gray-400 focus:outline focus:outline-2 focus:-outline-offset-2 focus:outline-indigo-600 sm:text-sm/6"
+        />
+      </div>
+
+      <label
+        htmlFor="name"
+        className="mt-2 block text-sm/6 font-medium text-gray-900"
+      >
+        Year
+      </label>
+      <div className="mt-2">
+        <input
+          id="year"
+          name="year"
+          type="text"
+          className="block w-full rounded-md bg-white px-3 py-1.5 text-base text-gray-900 outline outline-1 -outline-offset-1 outline-gray-300 placeholder:text-gray-400 focus:outline focus:outline-2 focus:-outline-offset-2 focus:outline-indigo-600 sm:text-sm/6"
+        />
+      </div>
+
+      <label
+        htmlFor="name"
+        className="mt-2 block text-sm/6 font-medium text-gray-900"
+      >
+        Number of Parts
+      </label>
+      <div className="mt-2">
+        <input
+          id="numParts"
+          name="numParts"
+          type="number"
+          className="block w-full rounded-md bg-white px-3 py-1.5 text-base text-gray-900 outline outline-1 -outline-offset-1 outline-gray-300 placeholder:text-gray-400 focus:outline focus:outline-2 focus:-outline-offset-2 focus:outline-indigo-600 sm:text-sm/6"
+        />
+      </div>
+
+      <button
+        type="submit"
+        className="mt-6 rounded-md bg-indigo-600 px-2.5 py-1.5 text-sm font-semibold text-white shadow-sm hover:bg-indigo-500 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-indigo-600"
+      >
+        Create new set
+      </button>
+    </form>
+  );
+}
+
+export default AddSetForm;
+```
+
+Again, notice that the component imports hooks, queries, and typing information from our generated code to accomplish this.
+
+## Integrate components into the app
+
+Final step: bring those new components into `FeatureSets` component:
+
+```tsx {% fileName="libs/feature-sets/src/lib/feature-sets.tsx" %}
+import AddSetForm from './add-set-form';
+import SetList from './set-list';
+
+export function FeatureSets() {
+  return (
+    <div className="flex">
+      <AddSetForm></AddSetForm>
+      <SetList></SetList>
+    </div>
+  );
+}
+
+export default FeatureSets;
+```
+
+And bring that component into your app:
+
+```tsx {% fileName="apps/frontend/src/app/app.tsx" %}
+import { FeatureSets } from '@nx-apollo/feature-sets';
+
+export function App() {
+  return (
+    <div>
+      <h1 className="my-6 text-center text-2xl font-bold">My Lego Sets</h1>
+      <FeatureSets></FeatureSets>
+    </div>
+  );
+}
+
+export default App;
+```
+
+If your API isn’t running already, go ahead and start it:
+
+```shell
+npx nx serve api
+```
+
+And now start your React app in a separate terminal:
+
+```shell
+npx nx serve frontend
+```
+
+Browse to [http://localhost:4200](http://localhost:4200) and see the results of your work!
+
+## Extend `codegen` configuration
+
+The configuration for the `codegen` targets is a good start, but it's currently lacking two things:
+
+1. [Caching](/features/cache-task-results)
+2. [Dependent tasks](/concepts/task-pipeline-configuration)
+
+Without caching enabled, `codegen` tasks will be run every time, regardless if they need to be or not. And without dependent tasks configured, we can't be sure that `codegen` is run any time our generated code depends on the generated code in another project. IOn our example, the generated code in both `api` and `feature-sets` rely on the models generated in `models-graphql`. If we make changes to the schema in `models-graph` and then run `codegen` on `api`, our models will be out-of-sync and lead to errors.
+
+Let's fix both of these problems with a target default for `codegen`. In `nx.json`, add this:
+
+```json {% fileName="nx.json" %}
+  "targetDefaults": {
+  ...
+  "codegen": {
+      "cache": true,
+      "outputs": ["{projectRoot}/src/__generated__"],
+      "inputs": ["{workspaceRoot}/libs/models-graphql/src/lib/schema.graphql","{projectRoot}/**/*.graphql"],
+      "dependsOn": ["^codegen"]
+    }
+  }
+```
+
+Now try running `codegen` for `api` to see that `codegen` for `models-graphql` is run first:
+
+```shell
+❯ npx nx codegen api
+
+   ✔  1/1 dependent project tasks succeeded [0 read from cache]
+
+   Hint: you can run the command with --verbose to see the full dependent project outputs
+
+—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
+
+
+> nx run api:codegen
+
+> npx graphql-codegen --config apps/api/codegen.ts
+
+✔ Parse Configuration
+✔ Generate outputs
+
+—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
+
+ NX   Successfully ran target codegen for project api and 1 task it depends on (2s)
+
+```
+
+Try running the command again, and you'll see that the results are pulled from the cache, and the task ends immediately.
+
+## Further Reading
+
+- [Apollo Server](https://www.apollographql.com/docs/apollo-server)
+- [Apollo React Client](https://www.apollographql.com/docs/react/)
+- [GraphQL Codegen](https://the-guild.dev/graphql/codegen)
+- 🧠 [Nx Docs](/getting-started/intro)
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-02-26-react-development-for-2025.md

@@ -0,0 +1,19 @@
+---
+title: "React Development for 2025"
+description: "In this webinar, we’ll dive into building modern React applications using platform-native tools like NPM workspaces and TypeScript project references.
+Learn how Nx improves the developer experience all while letting you ship your React apps faster. We’ll explore features like project references, how they work, and why they can significantly improve the performance of large React and TypeScript monorepos, both locally and on CI."
+date: 2025-02-26
+slug: 'react-development-for-2025'
+authors: ['Juri Strumpflohner']
+tags: [webinar]
+cover_image: /blog/images/2025-02-26/Feb-Webinar-Card.png
+status: Past - Gated
+registrationUrl: https://go.nx.dev/feb2025-webinar
+---
+
+Presented by Juri Strumpflohner
+
+In this webinar, we’ll dive into building modern React applications using platform-native tools like NPM workspaces and TypeScript project references.
+Learn how Nx improves the developer experience all while letting you ship your React apps faster. We’ll explore features like project references, how they work, and why they can significantly improve the performance of large React and TypeScript monorepos, both locally and on CI.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/feb2025-webinar" description="Sign up to gain access" /%}

docs/blog/2025-03-06-making-cursor-smarter.md

@@ -0,0 +1,152 @@
+---
+title: 'Making Cursor Smarter with an MCP Server For Nx Monorepos'
+slug: nx-made-cursor-smarter
+authors: ['Juri Strumpflohner', 'Max Kless']
+tags: ['nx']
+cover_image: /blog/images/articles/cursor-nx-mcp-heroimg.jpg
+description: 'Learn how Nx enhances Cursor IDE with a dedicated MCP server, providing AI assistants with rich monorepo metadata for smarter code assistance.'
+youtubeUrl: https://youtu.be/V2W94Sq_v6A
+pinned: true
+---
+
+{% callout type="deepdive" title="Series: Making your LLM smarter" expanded=true %}
+
+- [Nx Just Made Your LLM Way Smarter](/blog/nx-just-made-your-llm-smarter)
+- **Making Cursor Smarter with an MCP Server For Nx Monorepos**
+- [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)
+
+{% /callout %}
+
+A couple of weeks ago, we [announced how Nx makes your LLM smarter](/blog/nx-just-made-your-llm-smarter) by providing rich metadata about your monorepo structure, project relationships, and architectural context. This enhancement was initially available through GitHub Copilot in VSCode, but now we're taking it a step further by implementing the Model Context Protocol (MCP) for Cursor, making your AI assistant even more powerful.
+
+{% call-to-action title="Learn more about Nx and AI" url="https://go.nx.dev/march2025-webinar" description="LLM-focused Webinar on March 19th" /%}
+
+{% toc /%}
+
+## What is the Model Context Protocol (MCP)?
+
+The Model Context Protocol is an open standard - pioneered by [Anthropic](https://www.anthropic.com/) - that enables AI models to interact with your development environment in a more structured and powerful way. It provides a standardized interface for tools and resources that can be used by AI assistants to better understand and interact with your codebase.
+
+![mcp-architecture.avif](/blog/images/articles/mcp-architecture.avif)
+
+_(Source: [Official MCP documentation](https://modelcontextprotocol.io))_
+
+According to the [MCP documentation](https://modelcontextprotocol.io/introduction), it's designed to:
+
+- Provide structured access to development tools and resources
+- Enable AI models to take actions in your development environment
+- Create a consistent interface for different AI assistants
+- Allow for better context management and tool selection
+
+This protocol is particularly powerful for monorepo development because it allows AI assistants to understand not just individual files, but the entire workspace structure, project relationships, and available tools. When combined with Nx's rich metadata about your monorepo, it creates an incredibly powerful development experience.
+
+The advantage of MCP is that it can become a standard. In fact, more and more libraries provide implementations (e.g. [Spring AI's MCP integration](https://docs.spring.io/spring-ai/reference/api/mcp/mcp-overview.html)).
+
+We're leveraging this by exposing such an MCP from our Nx Language server that comes with Nx Console so Cursor and other MCP compatible clients can automatically hook into the data Nx has about your workspace.
+
+## How to enable it in your Cursor IDE
+
+Getting started with Nx's MCP integration in Cursor is straightforward. Here's what you need to do:
+
+**Install Nx Console** in your Cursor IDE by following our [editor setup guide](/getting-started/editor-setup).
+
+Once installed, Cursor will automatically detect Nx Console and prompt you to configure the MCP server. You'll see a notification like this:
+
+![cursor-nx-notification.avif](/blog/images/articles/cursor-nx-notification.avif)
+
+**Click on the notification** to open Cursor's settings. The Nx Console notification conveniently provides a direct link to the MCP settings:
+
+![cursor-nx-enable-mcp.avif](/blog/images/articles/cursor-nx-enable-mcp.avif)
+
+In the settings, you'll see the Nx Console MCP server listed as "Disabled". **Click on it to enable it**:
+
+![Cursor MCP settings screen showing the disabled Nx Console MCP server](/blog/images/articles/mcp-cursor-disabled.avif)
+
+Once enabled, you'll see the server status change:
+
+![Cursor MCP setting screen showing the enabled Nx MCP server](/blog/images/articles/cursor-mcp-server-config.avif)
+
+If this is your first MCP installation, you'll notice a new `.cursor/mcp.json` file in your workspace. This file contains your MCP configuration:
+
+![Cursor MCP configuration](/blog/images/articles/cursor-nx-mcp-configuration.avif)
+
+Share this configuration with your team to ensure consistent settings or add it to `.gitignore` if you prefer to keep your local configuration private.
+
+That's it! Your Cursor IDE is now configured to use Nx's MCP integration. For more details about the available features and capabilities, check out our [AI enhancement documentation](/features/enhance-AI).
+
+{% callout type="note" title="Manual Setup" %}
+If you've missed the notification, you can always run the `nx.configureMcpServer` command via the command prompt (`Ctrl/Cmd` + `Shift` + `P`) and install the MCP server that way.
+{% /callout %}
+
+## How it works
+
+The Nx MCP integration is built on top of the official [Model Context Protocol TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk). When you enable the integration, we automatically spin up a local MCP server that communicates with Cursor using Server-Sent Events (SSE). This server runs on a random available port on your localhost, ensuring it doesn't conflict with other services.
+
+![Cursor MCP Architecture Diagram](/blog/images/articles/mcp-nx-architecture.avif)
+
+The MCP server is configured through the `.cursor/mcp.json` file, which is automatically created in your workspace as mentioned in the previous section. Nx Console will automatically read the port specified there and spin up a matching MCP server.
+You can always view and modify the configuration through `Cursor Settings -> MCP`.
+
+### Available Tools
+
+While the Model Context Protocol defines various functionalities (tools, resources, roots, and sampling), support in popular clients like Cursor or Claude Desktop is limited. For now, we've focused on providing a set of essential tools that leverage Nx's rich metadata:
+
+- `nx_workspace`: Provides an annotated representation of your Nx configuration and project graph
+- `nx_project_details`: Returns comprehensive configuration for any specific Nx project
+- `nx_docs`: Retrieves relevant documentation sections based on your queries
+- `nx_generators`: Lists all available code generators in your workspace
+- `nx_generator_schema`: Provides detailed schema information for specific generators
+- `nx_visualize_graph`: Opens interactive project or task graph visualizations directly in your IDE
+
+### Data Flow
+
+Behind the scenes, we use the Nx Language Server (`nxls`) that comes as part of the [Nx Console extension](/getting-started/editor-setup) to gather workspace information. Each tool request triggers a specific data flow:
+
+1. The tool receives your query
+2. `nxls` retrieves relevant workspace information from your Nx workspace
+3. We transform this data into a format optimized for LLM consumption
+4. The transformed data is enriched with natural language descriptions
+5. The result is passed back to the AI assistant
+
+For example, when handling project graph queries, we transform the raw graph data into a more structured format that includes explanations about project relationships and dependencies. You can see this transformation in action in our [project graph transformation code](https://github.com/nrwl/nx-console/blob/9a0425d8c0ae74d326bdd030e8793f2c4d0161e9/libs/shared/llm-context/src/lib/project-graph.ts#L5).
+
+### IDE Integration
+
+The MCP's true potential lies in its deep integration with your IDE. Right now, it can trigger these actions directly in your IDE:
+
+- Visualize the project graph focused on a specific project
+- Visualize the task graph for a specific project and target
+
+This is just the beginning. We plan to expand these capabilities in future releases and would love to hear your feedback and ideas on what you'd like to see.
+
+### Using MCP Outside Cursor
+
+If you want to use our MCP integration with other tools that support the protocol (like Claude Desktop, Cline, Windsurf and more), you can run it in `stdio` mode. This allows direct communication between the client and server process. Follow the instructions in the [nx-mcp npm package documentation](https://www.npmjs.com/package/nx-mcp?activeTab=readme) to set this up.
+
+## Let's see it in action
+
+The [Youtube video]() above showcases the below example queries, showing how Cursor leverages the different exposed Nx MCP tools to get more information to correctly take action.
+
+- If I change the public API of feat-product-detail, which other projects might be affected by that change?
+- Use Nx to generate a new React library for handling past orders.
+- Can you configure Nx release for the packages of this workspace? Just update nx.json with the necessary configuration. Use conventional commits as the versioning strategy. Also feel free to use the Nx docs to pull more info on how to configure it.
+
+## Wrapping up
+
+This is just our very first version of developing an MCP server. The protocol is evolving as we speak and getting more powerful by implementing new possibilities for enriching your LLM queries with more contextual data.
+
+But already these first interactions show how much more helpful and precise the answers become, making Cursor specifically a lot more useful.
+
+We **want your feedback though!** Reach out on our socials ([Twitter/X](https://x.com/NxDevTools), [Bluesky](https://bsky.app/profile/nx.dev) and [LinkedIn](https://www.linkedin.com/company/nrwl/)) or hop into our [weekly office hours on Discord](http://go.nx.dev/office-hours).
+
+Stay tuned for more updates on this MCP integration as well as enhancements on the [VSCode Copilot front](/blog/nx-just-made-your-llm-smarter).
+
+---
+
+Learn more:
+
+- 🧠 [Nx AI Docs](/features/enhance-AI)
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-03-07-nx-update-20-5.md

@@ -0,0 +1,108 @@
+---
+title: 'Nx Update: 20.5'
+slug: nx-update-20-5
+authors: [Philip Fulcher]
+tags: [nx, release]
+cover_image: /blog/images/2025-03-07/header.png
+description: Discover the latest in Nx 20.5, featuring TypeScript project references improvements, migration docs, and tool updates like Angular 19.2, React 19, and Vite 6.
+youtubeUrl: https://youtu.be/IujhR3-Iidk
+---
+
+Time moves fast, and so do Nx releases. Let’s catch up with the latest development on Nx since our [last release post for 20.3](/blog/nx-update-20-3#rfc-for-infinite-tasks).
+
+{% toc /%}
+
+## LLM improvements galore
+
+We think that monorepos are the solution to better AI-assisted development, and we’re doing the work to support that. We’ve recently released updates that enhance the LLM experience for both [Copilot](/blog/nx-just-made-your-llm-smarter) and [Cursor](/blog/nx-made-cursor-smarter).
+
+AI-powered coding assistants can edit files, but they're blind to the bigger picture – they don't understand how your entire codebase fits together. Nx changes that. With full visibility into your monorepo's project relationships, dependencies, and ownership, Nx enables your LLM to move beyond local file changes by providing this essential monorepo context.
+
+Take each of these for a spin and then [sign up for our webinar](/blog/are-monorepos-the-answer-to-better-aiassisted-development) on Nx and AI-assisted development.
+
+{% youtube src="https://www.youtube.com/watch?v=V2W94Sq_v6A" /%}
+
+## TypeScript project references improvements
+
+ICYMI, we announced a [new experience for TypeScript monorepos](/blog/new-nx-experience-for-typescript-monorepos) in January. The new setup is [faster, more efficient in memory use](/blog/new-nx-experience-for-typescript-monorepos#key-highlight-performance), and fixes common issues with TypeScript editor support for large monorepos. Since then, we’ve steadily improved this experience with many performance and quality-of-life improvements.
+
+One of the significant improvements is that you can now run tasks with a partial match of the project name rather than needing to use the full name every time. Say you have these projects:
+
+```text
+@org/foo
+@org/bar
+```
+
+You can run the `lint` task for `@org/foo` with `nx lint foo` rather than `nx build @org/foo` every time. A keystroke saved is time saved. 🧠
+
+By default, Nx will use the `name` property from the `package.json` for a project to determine its name. For more flexibility, you can also define a name as part of the `nx` properties:
+
+```jsx
+{
+  "name": "@org/foo",
+  "nx": {
+	"name": "foo"
+  }
+}
+```
+
+We have also made projects inferred by `@nx/js` more efficient by eliminating the duplicate typechecks that were occurring. Previously, when `@nx/js` inferred tasks in a workspace using TypeScript project references, buildable libraries would have both a `build` and `typecheck` target inferred. However, since typechecking occurs as part of `build`, this resulted in typechecking being run twice. Now, buildable projects will only have the `build` target, saving time.
+
+[See more details on how `@nx/js` infers tasks](/nx-api/js#how-nxjs-infers-tasks)
+
+{% youtube src="https://www.youtube.com/watch?v=O2xBQJMTs9E" /%}
+
+## Migration docs
+
+When `nx migrate` is run, Nx determines what migrations need to be run, but it hasn't been easy for users to understand what the migrations do. The first step we're taking to address this is providing migrations docs for each plugin, going back to version 20 of Nx. [See the Angular plugin migration for an example](/nx-api/angular/migrations).
+
+Additionally, when running migrations, the terminal will provide links for each migration with richer information about what is actually happening. This is just our first step in addressing confusion during migrations, keep an eye out for more development here.
+
+## ESM support for eslint config
+
+`@nx/eslint` now uses ESM for configuration by default. This means that new workspaces will use ESM. Existing workspaces will continue to use CommonJS. We don’t currently have a migration path between CommonJS and ESM because of the possibility to break something in your lint rules. Both CommonJS and ESM will be supported for the near future.
+
+## React 19 support for new workspaces
+
+New Nx workspaces now default to React 19. Note that due to the extent of breaking changes coming with React 19, we will not be providing an automated migration to React 19 via [**`nx migrate`**](/nx-api/nx/documents/migrate). If you’re ready to make this migration on your own, [see our docs about using the new `reactCompiler`](/recipes/react/react-compiler#react-compiler-with-nx)
+
+## Angular 19.2 support
+
+`@nx/angular` now supports up to Angular 19.2 Time to give their new experimental [Resources API](https://angular.dev/guide/signals/resource) a try! If you’re not quite ready to upgrade your version of Angular, remember that you can migrate to the latest Nx while keeping your current version of Angular using the `--interactive` flag during migration. [See our docs for more details](/recipes/tips-n-tricks/advanced-update#choosing-optional-package-updates-to-apply).
+
+## Vite 6 + Vitest 3 support
+
+`@nx/vite` now supports [Vite 6](https://vite.dev/blog/announcing-vite6) and [Vitest 3](https://vitest.dev/blog/vitest-3.html). This allows you to use the latest features in Vite like the [experimental Environment API](https://main.vite.dev/guide/api-environment) and brings us up-to-date with the latest in the Vite ecosystem!
+
+## Update on Infinite Tasks/Continuous Tasks
+
+In our [20.3 release post](/blog/nx-update-20-3#rfc-for-infinite-tasks), we introduced an RFC for “Infinite Tasks” (now called [Continuous Tasks](https://github.com/nrwl/nx/discussions/29025)). Nx will add the concept of **Continuous tasks** which Nx will orchestrate as part of the task graph. This will allow for tasks to depend on other running tasks in addition how it already allows depending on other completed tasks. This will allow for better support of long-running tasks like backend servers for frontend applications that depend on them, or tools that run in a watch mode. We’ve been hard at work implementing this feature, and you can look forward to a beta version before the release of Nx 21.
+
+## Fixes and improvements
+
+As always, there are many fixes and improvements being added to Nx every day like:
+
+- Calculating project graph speed has been significantly improved
+- Improved stability of the daemon
+
+Be sure to check out the [full release notes](https://github.com/nrwl/nx/releases/tag/20.5.0) for all the details.
+
+## Automatically Update Nx
+
+As always - updating Nx and its plugins is easy as we ship an [automated migration command](https://www.notion.so/features/automate-updating-dependencies).
+
+```bash
+npx nx migrate latest
+```
+
+After updating your dependencies, run any necessary migrations.
+
+```bash
+npx nx migrate --run-migrations
+```
+
+## Learn more
+
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-03-17-modern-angular-testing-with-nx.md

@@ -0,0 +1,395 @@
+---
+title: 'Modern Angular Testing with Nx'
+slug: modern-angular-testing-with-nx
+authors: ['Jack Hsu']
+tags: ['angular', 'nx']
+cover_image: /blog/images/2025-03-17/modern-angular-testing.png
+description: 'Learn how Nx enhances Angular testing by integrating modern tools like Playwright and Vitest, improving test speed, reliability, and CI scalability.'
+---
+
+{% callout type="deepdive" title="Angular Week Series" expanded=true %}
+
+This article is part of the Angular Week series:
+
+- **Modern Angular Testing with Nx**
+- [Angular Architecture Guide To Building Maintainable Applications at Scale](/blog/architecting-angular-applications)
+- [Using Rspack with Angular](/blog/using-rspack-with-angular)
+- [Enterprise Patterns](/blog/enterprise-angular-book)
+
+{% /callout %}
+
+Testing is a crucial part of any application to ensure correctness and guard against regression, and Angular is no exception. Here at Nx, we're big fans of Angular, and we think that we can drastically improve the unit testing and end-to-end (E2E) experience for Angular developers.
+
+Modern tools have evolved to make testing faster, more reliable, and developer-friendly. The Angular team has recognized this shift in the testing landscape. They've officially announced that [Protractor is in maintenance mode](https://blog.angular.dev/the-state-of-end-to-end-testing-with-angular-d175f751cb9c) and recommend using modern alternatives like Playwright or Cypress. Similarly, while Karma is still supported, the team [acknowledges the benefits of modern test runners](https://blog.angular.dev/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca) like Jest and Vitest, especially in terms of performance and developer experience.
+
+In this post, we'll explore how the Nx unlocks modern testing tools for Angular developers, and how Nx can help your CI scale as your team and codebase grow.
+
+## **Effortless E2E Testing at Scale**
+
+New Nx Angular workspaces come with Playwright as the E2E testing framework by default.
+
+```shell
+npx create-nx-workspace@latest --preset=angular-monorepo --appName=my-app
+```
+
+You can use Cypress by passing the `--e2eTestRunner=cypress` option. We will use Playwright for this example, but the benefits that Nx brings apply to both frameworks.
+
+Once you have the workspace created, you can see the E2E tests in action by running the following:
+
+```shell
+npx nx e2e my-app-e2e
+```
+
+This command runs `playwright test` underneath the hood. This is just standard tooling, and there is nothing Nx-specific about the tests. Nx comes into play with the `@nx/playwright` plugin, as you see inside your `nx.json` file. The `@nx/playwright` plugin does a few things.
+
+First, it makes the `e2e` command cacheable, so running it again without changes source files nor test files will replay the command from cache.
+
+```shell
+npx nx e2e my-app-e2e
+```
+
+You should see a message as follows the second time:
+
+```{% command="npx nx e2e my-app-e2e" %}
+NX  Successfully ran target e2e for project my-app-e2e (154ms)
+
+Nx read the output from the cache instead of running the command for 1 out of 1 tasks.
+```
+
+This is a powerful feature, especially when used in conjunction with [Remote Caching](/ci/features/remote-cache) (i.e. Nx Replay).
+
+How does Nx understand when a task can be read from cache? Well, the `@nx/playwright` also autoconfigures task inputs for you. So, unless a relevant file is changed, the task can be read from cache. That means updates to `README.md` will replay E2E tests from cache rather than running the expensive task.
+
+Another thing that Nx handles automatically for you is restoring outputs from cache. You'll notice that an HTML report is generated in the `dist/.playwright` folder.
+
+```
+dist/.playwright/apps/my-app-e2e
+├── playwright-report
+│  └── index.html
+└── test-output
+```
+
+You can remove this folder, and when Nx replays the task from cache, the test artifacts will be restored.
+
+```
+rm -rf dist
+npx nx e2e my-app-e2e
+tree dist/.playwright/apps/my-app-e2e
+```
+
+You should see the exact same output in `dist` even though the Playwright tests didn't actually run.
+
+To see how Nx configures your project, you can use `nx show project`.
+
+```shell
+npx nx show project my-app-e2e
+npx nx show project my-app
+```
+
+![Nx Cloud Result](/blog/images/2025-03-17/Screenshot_2025-03-05_at_10.44.52_AM.png)
+
+We also recommend that you install the Nx Console extension for VSCode, Cursor, and IntelliJ. It seamlessly integrates the [Project Details View](/recipes/nx-console/console-project-details) with your editor. To install it visit the Marketplace pages:
+
+- [VSCode extension](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
+- [IntelliJ plugin](https://plugins.jetbrains.com/plugin/21060-nx-console)
+
+Okay, the caching is already great on its own, but Nx has another very powerful feature to help you scale your CI.
+
+### **Automatic E2E Test Distribution**
+
+As workspaces grow, they often run into CI scaling issues that are hard to solve. E2E tests are often the main culprit of CI slowness, as a test suite can take several hours to run in large workspaces. This is just the reality for many teams, where you need the large test suites to ensure quality, but it's impossible to iterate quickly when each CI run takes hours.
+
+Fortunately, Nx has a solution that does not require complicated pipeline files or a whole team of infrastructure engineers to keep CI running smoothly. That solution is [Automatic Test Splitting](/ci/features/split-e2e-tasks) (or Nx Atomizer).
+
+If you view the `my-app-e2e` project (`npx nx show project my-app-e2e`), you will notice that there is an `e2e-ci` target, with additional targets created for each test file. This is the task splitting feature that `@nx/playwright` enables. Whereas the `e2e` target runs the full Playwright suite, the `e2e-ci` task runs additional tasks created from test files.
+
+When run on a single machine, `e2e-ci` will be slower because it starts multiple Playwright processes, which is why we only allow it to run through distribution. To [enable distribution](/ci/features/split-e2e-tasks#enable-automated-e2e-task-splitting), you must connect your workspace to [Nx Cloud](/nx-cloud). This is easily done with the `connect` command.
+
+```shell
+npx nx connect
+```
+
+Follow the onboarding steps and you should be connected within five minutes. For more information, check out our [GitHub Actions Tutorial](/ci/intro/tutorials/github-actions) or our [guides](/ci/recipes/set-up) for all supported CI providers (GitHub, GitLab, Azure, etc.).
+
+Now, let's take a look at a concrete example to get an idea of how much time-saving you can unlock with Nx Atomizer. I created [this repo](https://github.com/jaysoo/angular-testing-demo) that contains a simple Angular application and a UI package. It also has 40 Playwright test files.
+
+```
+apps/demo-e2e/src
+├── example-1.spec.ts
+├── example-2.spec.ts
+├── example-3.spec.ts
+├── ...
+└── example-40.spec.ts
+```
+
+Where each file uses `page.waitForTimeout` to artificially simulate run-running tests.
+
+```ts
+import { test, expect } from '@playwright/test';
+
+test('example 1 - test 1', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(3000);
+  expect(page.url()).toBe(page.url());
+});
+
+test('example 1 - test 2', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(3000);
+  expect(page.url()).toBe(page.url());
+});
+
+// ...
+
+test('example 1 - test 10', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(3000);
+  expect(page.url()).toBe(page.url());
+});
+```
+
+Using this [workflow file](https://github.com/jaysoo/angular-testing-demo/blob/main/.github/workflows/ci.yml) for GitHub Actions, we see that running unit tests and E2E tests take roughly 23 minutes in total.
+
+- CI without distribution: [https://github.com/jaysoo/angular-testing-demo/actions/runs/13677108651](https://github.com/jaysoo/angular-testing-demo/actions/runs/13677108651)
+
+In the [`feat/nx-cloud/setup`](https://github.com/jaysoo/angular-testing-demo/tree/feat/nx-cloud/setup) branch and PR, you can see that the [workflow file](https://github.com/jaysoo/angular-testing-demo/blob/feat/nx-cloud/setup/.github/workflows/ci.yml) is updated to enable distribution via Nx Agents.
+
+```yaml
+name: CI
+# ...
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      # ...
+      - run: npx nx-cloud start-ci-run --distribute-on="8 linux-medium-js" --stop-agents-after="e2e-ci"
+      # ...
+      - run: npx nx affected -t test e2e-ci
+```
+
+With distribution enabled, the total CI time went from 23 minutes to 6 minutes, which is over 70% reduction in total duration.
+
+- CI with distribution: [https://github.com/jaysoo/angular-testing-demo/actions/runs/13677116398](https://github.com/jaysoo/angular-testing-demo/actions/runs/13677116398)
+
+You can see that the CI pipeline distributes individual test files on multiple agents.
+
+![Nx Cloud In Progress](/blog/images/2025-03-17/Screenshot_2025-03-05_at_8.32.11_AM.png)
+
+That is significant time-saving! As your codebase grows, you have the option to increase distribution by changing the `--distribute-on` option to ensure that CI still runs fast.
+
+```yaml
+# Use 12 agents
+npx nx-cloud start-ci-run --distribute-on="12 linux-medium-js" --stop-agents-after="e2e-ci"
+```
+
+### Dynamic Agent Allocation
+
+You can even [dynamically allocate agents](/ci/features/dynamic-agents#dynamically-allocate-agents) depending on how big the changeset is. To do this, add an YAML file as follows:
+
+```yaml
+# .nx/workflows/distribution-config.yaml
+distribute-on:
+  small-changeset: 3 linux-medium-js
+  medium-changeset: 8 linux-medium-js
+  large-changeset: 12 linux-medium-js
+```
+
+Then, use that file in the `--distribute-on` option.
+
+```yaml
+npx nx-cloud start-ci-run --distribute-on=".nx/workflows/distribution-config.yaml" --stop-agents-after="e2e-ci"
+```
+
+### Flakiness Detection and Automatic Re-runs
+
+One last thing I want to mention, is that Nx can also help with flaky tests. Nx Cloud can reliably detect flaky tests and automatically re-run them. See the documentation on the [Re-run Flaky Tests](/ci/features/flaky-tasks) for more detail.
+
+All of this power comes at very little complexity and maintenance burden. Nx allows you to declaratively describe what you want to run, and how you want to distribute tasks, and we do all the heavy lifting for you.
+
+As we've seen, Nx is the easiest way for you to scale your E2E tests as your team and codebase grow, without dealing with complicated CI pipelines yourself. CI times can be drastically cut down by more than 70%, as seen in the example above. This enables teams to move faster and deliver value without being slowed down by CI.
+
+Next, let's take a look at how Nx helps with modernizing unit tests.
+
+## **Modern Unit Testing: Beyond Karma**
+
+While Angular CLI traditionally uses [Karma for unit testing](https://angular.dev/guide/testing/test-environment), Nx enables you to leverage more modern testing frameworks like [Vitest](https://vitest.dev/) and [Jest](https://jestjs.io/). The Angular team has been [exploring modern alternatives to Karma](https://blog.angular.dev/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca), recognizing the benefits these tools bring. Let's explore why this matters by comparing Vitest with Karma. Many of these benefits also apply to Jest, which the Angular CLI team has plans to officially support. There are currently no plan for Angular CLI to support Vitest.
+
+### **Why Choose Vitest over Karma?**
+
+The benefits of modern test runners like Vitest are well-documented in the [official Vitest documentation](https://vitest.dev/guide/why.html) and the [Angular blog](https://blog.angular.dev/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca). Here's why they're a compelling choice:
+
+### **Performance Features**
+
+- **Native ESM Support**: Tests run directly without bundling, unlike Karma
+- **Parallel Test Execution**: Tests run concurrently by default
+- **Efficient Resource Usage**: Modern architecture reduces memory usage
+- **Watch Mode with HMR**: Near-instant feedback during development
+
+### **Developer Experience**
+
+- **Better Debugging**: Improved error messages and stack traces
+- **Rich Plugin Ecosystem**: Wide range of tools and extensions
+- **Snapshot Testing**: Easily test UI components
+- **Modern API**: Intuitive, promise-based test writing
+- **Active Community**: Regular updates and improvements
+
+While actual performance gains vary by project size, teams consistently report faster test execution and improved developer experience when switching from Karma to modern test runners. This improvement in speed is can be largely attributed to not relying on real browsers and running tests in a simulated environment using pure-JavaScript DOM implementations such as `jsdom`.
+
+### **Setting Up Modern Unit Tests**
+
+Setting up Vitest for your Angular project with Nx is straightforward:
+
+```bash
+# Add the Vite plugin
+npx nx add @nx/vite
+
+# Configure Vitest for a project
+npx nx g @nx/vite:vitest
+```
+
+This should generate a Vitest configuration file like the following:
+
+```tsx
+// vite.config.mts
+/// <reference types='vitest' />
+import { defineConfig } from 'vite';
+import angular from '@analogjs/vite-plugin-angular';
+
+export default defineConfig({
+  plugins: [angular()],
+  test: {
+    watch: false,
+    globals: true,
+    environment: 'jsdom',
+    include: ['src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
+    setupFiles: ['src/test-setup.ts'],
+    reporters: ['default'],
+    coverage: {
+      reportsDirectory: './coverage/my-app',
+      provider: 'v8',
+    },
+  },
+});
+```
+
+Now, you can run your unit tests through Vitest:
+
+```shell
+npx nx test my-app --watch
+```
+
+![Vitest Output](/blog/images/2025-03-17/Screenshot_2025-03-05_at_1.14.58_PM.png)
+
+Note, that you may have a conflicting `test` target, which can be resolved by removing or renaming the old target in `project.json`:
+
+```json
+{
+  "targets": {
+    "karma:test": {
+      "executor": "@angular-devkit/build-angular:karma",
+      "options": {
+        "polyfills": ["zone.js", "zone.js/testing"],
+        "tsConfig": "tsconfig.spec.json",
+        "assets": [
+          {
+            "glob": "**/*",
+            "input": "public"
+          }
+        ],
+        "styles": ["src/styles.css"],
+        "scripts": []
+      }
+    }
+  }
+}
+```
+
+Big shout-out to Brandon Roberts and the Analog team for bringing [Angular-support to Vitest](https://analogjs.org/docs/features/testing/vitest).
+
+Try it out yourself by cloning the example repo:
+
+```shell
+# Set up
+git clone https://github.com/jaysoo/angular-testing-demo.git
+cd angular-testing-demo
+npm install
+
+# Run test for each project
+npx nx test demo
+npx nx test ui
+
+# Run in interactive mode (try updating files to see how fast HMR is)
+npx nx test ui --watch
+
+# Run all tests
+npx nx run-many -t test
+```
+
+The improvements for local development is night and day. Receive instant feedback when you run in watch mode, leverage modern [debugging tools integration](https://vitest.dev/guide/debugging), better error messages and stack traces, and more. CI is also improved by reducing flakiness and inconsistencies across environments, by not relying on real browsers.
+
+### Generate New Projects with Vitest
+
+The application and library generators that come with `@nx/angular` both support using Vitest as the unit test runner.
+
+```shell
+npx nx g @nx/angular:app apps/demo --unitTestRunner=vitest
+npx nx g @nx/angular:lib packages/ui --unitTestRunner=vitest
+```
+
+Note that Jest is also supported if that is preferred.
+
+```shell
+npx nx g @nx/angular:app apps/demo --unitTestRunner=jest
+npx nx g @nx/angular:lib packages/ui --unitTestRunner=jest
+```
+
+This means you can easily create new projects and be productive immediately.
+
+## Getting Started with Nx
+
+Now that you’re convinced to give Nx a try, let's go over a few ways to install Nx to your workspace.
+
+For a new workspaces, which is great to get started with Nx for the first time, use the `create-nx-workspace` command.
+
+```shell
+npx create-nx-workspace@latest --preset=angular-monorepo --appName=my-app
+```
+
+Follow, the prompts and you're good to go!
+
+For existing Angular CLI projects, you can run `nx init` inside the workspace. This will keep the file structure as is and minimally add Nx to the workspace.
+
+```shell
+ng new my-app
+cd my-app
+npx nx@latest init
+```
+
+Alternatively, you can convert your project into a monorepo using the `--integrated` flag. A monorepo gives you the ability to integrate more projects to it, such as other webapps or backends.
+
+```shell
+ng new my-app
+cd my-app
+npx nx@latest init --integrated
+```
+
+Run a few Nx commands to try it out!
+
+```shell
+npx nx show project my-app
+npx nx graph
+npx nx serve my-app
+npx nx test my-app
+```
+
+For more information, check out our [Getting Started](/getting-started/intro) docs.
+
+## **Conclusion**
+
+Modern testing tools have evolved significantly, offering better developer experience and faster execution times. By leveraging Nx's capabilities with Playwright for E2E testing and modern frameworks like Vitest for unit testing, you can create a more efficient and enjoyable testing workflow for your Angular teams.
+
+CI reliability and duration are improved through:
+
+- Automatic and effortless E2E test distribution
+- Flaky task detection and automatic retries
+- Faster and more consistent unit tests through modern tools like Vitest

docs/blog/2025-03-18-architecting-angular-applications.md

@@ -0,0 +1,550 @@
+---
+title: 'Angular Architecture Guide To Building Maintainable Applications at Scale'
+slug: architecting-angular-applications
+authors: ['Juri Strumpflohner']
+tags: ['nx']
+description: 'Learn how to build scalable Angular applications using domain-driven design, clear boundaries, and Nx tooling for better maintainability and team collaboration.'
+cover_image: /blog/images/articles/architecting-angular-apps-bg.jpg
+---
+
+{% callout type="deepdive" title="Angular Week Series" expanded=true %}
+
+This article is part of the Angular Week series:
+
+- [Modern Angular Testing with Nx](/blog/modern-angular-testing-with-nx)
+- **Angular Architecture Guide To Building Maintainable Applications at Scale**
+- [Using Rspack with Angular](/blog/using-rspack-with-angular)
+- [Enterprise Patterns](/blog/enterprise-angular-book)
+
+{% /callout %}
+
+Software Architecture consists of a variety of aspects that need to be considered. One key aspect though is to maximize the ability to remain flexible and adaptable to new customer requirements. Maybe you've already come across the "Project Paradox":
+
+![Project Paradox](/blog/images/articles/project-paradox.avif)
+
+A good software architecture helps mitigate the Project Paradox by enabling reversible decisions, progressive evolution, and delaying commitments until more knowledge is available. This can be achieved by aiming for a modular design that facilitates encapsulation, allowing incremental changes, and decoupling dependencies with clearly defined boundaries.
+
+In this article we focus mostly on:
+
+- how to implement a scalable architecture, not only at runtime, but at development time
+- how to structure your codebase and establish boundaries
+- how to encode and automate best practices to ensure their longevity
+
+{% toc /%}
+
+## Pizza-boxes, Onions and Hexagons - How to organize code
+
+Probably the simplest and most widespread (and probably most straightforward) approach for separating different aspects of an application is the **layered architecture** (in Italy we call them Pizza-box architecture).
+
+![layered-architecture.avif](/blog/images/articles/layered-architecture.avif)
+
+If you ever looked into software architecture and structuring of projects, this is probably what you've come across. There are variations of this such as the hexagonal and onion architecture, which differ mostly in how dependencies are wired up.
+The common denominator of these architectures (often also denoted as **horizontal approaches**) is that they are mostly focused on dividing the system based on technical responsibilities.
+
+On the other hand, **vertical architecture approaches** organize the application into functional segments or domains focusing on the business capabilities. This is a common approach in microservices architectures.
+
+![Possible domain architecture for our example application](/blog/images/articles/domain-driven-architecture.avif)
+
+## Breaking up the Monolith - How to identify where boundaries are
+
+{% video-player src="/documentation/blog/media/layered-to-domain-areas.mp4" alt="Moving from a layered architecture to domain oriented" showDescription=true showControls=false autoPlay=true loop=true /%}
+
+Instead of organizing code by technical types (components, services, directives) we want to structure our codebase around business domains. Good candidates for domains are areas that:
+
+- have distinct business capabilities (e.g. in the example of an online shop: orders, products, payments)
+- reflect team structure within the organization; domain boundaries often mirror organizational structure (Conway's Law)
+- can evolve independently from each other, at different speeds
+- have clear responsibilities and boundaries
+
+To use the example of an e-commerce application, we might have:
+
+- Products: Product catalog, inventory, categorization
+- Orders: Order processing, history, fulfillment
+- Checkout: Payment processing, cart management
+- User Management: Authentication, profiles, preferences
+- Shipping & Logistics: Delivery options, tracking, address management
+
+All of these need to work together for fulfilling the business requirements, but they can evolve independently and responsibilities can clearly be associated. In general, start broad and then refine over time as you gain more insights.
+
+Having such boundaries clearly separated not only helps with the longer-term maintainability of the application, but also helps assign teams and minimizes cross-team dependencies.
+
+## Start Small, Grow as you Need It
+
+A common mistake is to think too much about the ideal end goal and prepare things "just in case". Yep, over-engineering. Exactly, you might not need a monorepo (at least not yet). However, you want to make sure to not add roadblocks in your way.
+
+A lot of our Angular users don't necessarily start to use Nx because they need a monorepo, but because they want to be able to modularize their monolithic codebase. Hetzner Cloud - one of [our customers](/customers) - is a good example for that. Their main goal for initially adopting Nx was to [break apart their monolith](/blog/hetzner-cloud-success-story).
+
+If you want to start building a single Angular application with Nx, you can use the `--preset=angular-standalone` flag:
+
+```shell
+npx create-nx-workspace myshop --preset=angular-standalone
+```
+
+This creates a new Angular workspace (not a monorepo) with a single application located in the `src` folder.
+
+```text
+└─ myshop
+   ├─ e2e
+   │  ├─ ...
+   │  ├─ playwright.config.ts
+   │  └─ tsconfig.json
+   ├─ public/
+   ├─ src
+   │  ├─ app
+   │  │  ├─ ...
+   │  │  ├─ app.component.ts
+   │  │  ├─ app.config.ts
+   │  │  └─ app.routes.ts
+   │  ├─ index.html
+   │  ├─ ...
+   │  └─ main.ts
+   ├─ eslint.config.mjs
+   ├─ jest.config.ts
+   ├─ jest.preset.js
+   ├─ nx.json
+   ├─ project.json
+   ├─ tsconfig.app.json
+   ├─ tsconfig.editor.json
+   ├─ tsconfig.json
+   └─ tsconfig.spec.json
+```
+
+It uses Nx for running and building your project. Nx relies on the Angular Devkit builders but might also add in its own to fill in gaps (e.g. adding Jest/Vitest support). Have a look at the `project.json`:
+
+```json {% fileName="project.json" %}
+{
+  "name": "myshop",
+  "sourceRoot": "./src",
+  "targets": {
+    "build": {
+      "executor": "@angular-devkit/build-angular:browser",
+      "outputs": ["{options.outputPath}"],
+      "options": {
+        "outputPath": "dist/myshop",
+        "index": "./src/index.html",
+        "main": "./src/main.ts",
+        ...
+      },
+      "configurations": {...},
+      "defaultConfiguration": "production"
+    },
+    "serve": {
+      "executor": "@angular-devkit/build-angular:dev-server",
+      ...
+    },
+    ...
+    "lint": {
+      "executor": "@nx/eslint:lint",
+      "options": {
+        "lintFilePatterns": ["./src"]
+      }
+    },
+    "test": {
+      "executor": "@nx/jest:jest",
+      "outputs": ["{workspaceRoot}/coverage/{projectName}"],
+      "options": {
+        "jestConfig": "jest.config.ts"
+      }
+    },
+    "serve-static": {
+      "executor": "@nx/web:file-server",
+      "options": {
+        "buildTarget": "myshop:build",
+        "port": 4200,
+        "spa": true
+      }
+    }
+  }
+}
+```
+
+If you have an existing Angular CLI project, you can also [add Nx support to it](/recipes/angular/migration/angular) by running:
+
+```shell
+npx nx init
+```
+
+If you already know you want to go straight to an Nx monorepo, you can add the `--integrated` flag to the `nx init` command.
+
+## Modularize your Code into Projects Following Your Domain Areas
+
+When starting with Angular, you might structure your application like this:
+
+```text
+src/
+├── app/
+│   ├── auth/          # Authentication feature
+│   ├── products/      # Product management feature
+│   ├── cart/          # Shopping cart feature
+│   └── checkout/      # Checkout feature
+├── assets/
+└── styles/
+```
+
+This feature-based organization is already an improvement over the traditional "type-based" structure (where code is organized by technical type like components/, services/, etc.). However, it still has limitations:
+
+- Boundaries are purely folder-based with no real enforcement
+- Easy to create unwanted dependencies between features
+- Hard to maintain as the application grows
+- No clear rules about what can depend on what
+
+Instead of relying on folder-based separation, we can create dedicated projects (also called libraries) for different parts of our application. Looking at our workspace structure, we have organized our code into domain-specific projects:
+
+```text
+myshop/
+├── src/               # Main application
+└── packages/          # Library projects
+    ├── products/      # Product domain
+    ├── orders/        # Order management
+    ├── checkout/      # Checkout process
+    ├── user-management/
+    ├── shipping-logistics/
+    └── ...
+```
+
+These projects aren't necessarily meant to be published as npm packages - their main purpose is to create clear boundaries in your codebase. The application still builds everything together, but the project structure helps maintain clear separation of concerns.
+
+As domains grow more complex, you might want to split them further into more specialized libraries. For example, our products domain is organized as:
+
+```text
+packages/products/
+├── data-access/               # API and state management
+├── feat-product-list/         # Product listing feature
+├── feat-product-detail/       # Product detail feature
+├── feat-product-reviews/      # Product reviews feature
+├── ui-product-card/           # Reusable product card component
+└── ui-product-carousel/       # Product carousel component
+```
+
+This structure follows a pattern where each domain can have:
+
+- **Feature libraries** (`feat-*`): Implement specific business features or pages
+- **UI libraries** (`ui-*`): Contain presentational components
+- **Data-access libraries**: Handle API communication and state management
+
+Since this is a standalone application (not a monorepo), we use TypeScript path mappings to link these projects together. In our `tsconfig.base.json`, you can see how each project is mapped:
+
+```json {% fileName="tsconfig.base.json" %}
+{
+  "compilerOptions": {
+    "paths": {
+      "@myshop/products-data-access": [
+        "packages/products/data-access/src/index.ts"
+      ],
+      "@myshop/products-feat-product-list": [
+        "packages/products/feat-product-list/src/index.ts"
+      ],
+      "@myshop/products-ui-product-card": [
+        "packages/products/ui-product-card/src/index.ts"
+      ],
+      ...
+    }
+  }
+}
+```
+
+These mappings allow you to have clear imports in your code:
+
+```typescript
+// Clear imports showing the domain and type of code you're using
+import { ProductListComponent } from '@myshop/products-feat-product-list';
+import { ProductCardComponent } from '@myshop/products-ui-product-card';
+import { ProductService } from '@myshop/products-data-access';
+```
+
+This makes it immediately obvious:
+
+1. Which domain the code belongs to (`products`)
+2. What type of code it is (`feat-*`, `ui-*`, `data-access`)
+3. What specific feature or component you're importing
+
+## The Application is Your Linking and Deployment Container
+
+![Distribution of apps and libs in an Nx workspace](/blog/images/articles/nx-app-libs-distribution.avif)
+
+In a well-modularized architecture, your application shell should be surprisingly thin. Think of your main application as primarily a composition layer: it imports and coordinates the various domain libraries but contains minimal logic itself.
+
+The ideal application structure has:
+
+- **Thin application shell** - Contains mainly routing configuration, bootstrap logic, and layout composition
+- **Domain libraries** - All business logic, UI components, and data access code
+
+At the Angular router level you then import the various feature libraries:
+
+```typescript
+...
+export const appRoutes: Route[] = [
+  {
+    path: 'products',
+    loadComponent: () =>
+      import('@myshop/products-feat-product-list').then(
+        (m) => m.ProductsFeatProductListComponent
+      ),
+  },
+  {
+    path: 'product/:id',
+    loadComponent: () =>
+      import('@myshop/products-feat-product-detail').then(
+        (m) => m.ProductsFeatProductDetailComponent
+      ),
+  },
+  {
+    path: 'reviews',
+    loadComponent: () =>
+      import('@myshop/products-feat-product-reviews').then(
+        (m) => m.ProductsFeatProductReviewsComponent
+      ),
+  },
+  {
+    path: 'orders',
+    loadComponent: () =>
+      import('@myshop/orders-feat-order-history').then(
+        (m) => m.OrdersFeatOrderHistoryComponent
+      ),
+  },
+  {
+    path: 'create-order',
+    loadComponent: () =>
+      import('@myshop/orders-feat-create-order').then(
+        (m) => m.OrdersFeatCreateOrderComponent
+      ),
+  },
+  {
+    path: 'checkout',
+    loadComponent: () =>
+      import('@myshop/checkout-feat-checkout-flow').then(
+        (m) => m.CheckoutFeatCheckoutFlowComponent
+      ),
+  },
+  ...
+  {
+    path: '',
+    redirectTo: 'products',
+    pathMatch: 'full',
+  },
+];
+```
+
+> This routing configuration is just an example to convey the idea. You can go even further by having the top level domain-entry routing at the application and then domain specific routing is added by the various domain libraries themselves.
+
+When building, Nx compiles all the imported libraries together with your application code, creating a single deployable bundle. The libraries themselves don't produce deployable artifacts, they are implementation details that are consumed by the application.
+
+This pattern makes it much easier to move features between applications later if needed, as your business logic isn't tied to any specific application shell. It also provides a clear mental model: applications are for deployment, libraries are for code organization and reuse.
+
+## When to Create a New Library
+
+There is really no correct or wrong answer here. You should not just go and create a library for each component. That's probably too much. It really depends on how closely related various components or use cases are.
+
+Let's have a look at our current product domain example:
+
+```text
+packages/products/
+├── data-access/               # API and state management
+├── feat-product-list/         # Product listing feature
+├── feat-product-detail/       # Product detail feature
+├── feat-product-reviews/      # Product reviews feature
+├── ui-product-card/           # Reusable product card component
+└── ui-product-carousel/       # Product carousel component
+```
+
+We could easily just have a single `feat-product-list` which contains both, the list as well as detail view navigation because they might be closely connected. Similarly we could group `ui-product-card` and `ui-product-carousel` into a single `ui-product` library.
+
+A good rule of thumb is to understand and see how often various parts change over time. As your application grows, watch for these signs that your library boundaries might need adjustment:
+
+- **Frequent Cross-Library Changes** - You consistently need to modify multiple libraries for a single feature change
+- **Circular Dependencies** - Libraries depend on each other in ways that create circular references
+- **Unclear Ownership** - Multiple teams frequently need to coordinate to modify the same library
+- **Complex Dependencies** - Simple features require importing from many different libraries or domains
+- **Excessive Shared Code** - You find yourself duplicating types and utilities across domains
+
+Remember that library boundaries aren't set in stone - they should evolve with your application. Start with broader boundaries and refine them as you gain insights into how your code changes together.
+
+## Guard Your Boundaries - Automatically Enforcing Clear Dependencies
+
+Once you've established your domain boundaries and architectural layers, you need to ensure they remain intact as your codebase grows. Nx provides powerful tools to enforce these boundaries through module boundary rules that can be configured in your ESLint configuration.
+
+In our example, we use a dual-tagging approach:
+
+1. **Scope tags** (`scope:<name>`): These reflect our domain boundaries, representing different business capabilities like `products`, `orders`, `checkout` etc. They encode our vertical slicing approach.
+2. **Type tags** (`type:<name>`): These represent our horizontal architectural layers such as `feature`, `ui`, `data-access`, and `util`.
+
+Here's how the rules are configured:
+
+```typescript
+// Type-based rules
+{
+  sourceTag: 'type:feature',
+  onlyDependOnLibsWithTags: ['type:feature', 'type:ui', 'type:data-access']
+},
+{
+  sourceTag: 'type:ui',
+  onlyDependOnLibsWithTags: ['type:ui', 'type:util', 'type:data-access']
+},
+
+// Domain-based rules
+{
+  sourceTag: 'scope:orders',
+  onlyDependOnLibsWithTags: ['scope:orders', 'scope:products', 'scope:shared']
+},
+{
+  sourceTag: 'scope:products',
+  onlyDependOnLibsWithTags: ['scope:products', 'scope:shared']
+}
+```
+
+The rules enforce a clear dependency structure:
+
+- **Type rules** ensure architectural layering. For instance, UI components can only depend on other UI components, utilities, and data-access libraries. This prevents circular dependencies and maintains a clean architecture.
+- **Domain rules** control which domains can talk to each other. For example, the `orders` domain can depend on `products` (since orders contain products), but `products` cannot depend on `orders`.
+- Every domain can depend on `shared` code, but `shared` code can only depend on other shared code, preventing it from becoming a source of circular dependencies.
+
+These rules are enforced at build time through ESLint. If a developer tries to import from a forbidden domain or layer, they'll receive an immediate error, helping maintain the architectural integrity of your application. This allows you to get feedback as early as possible when you run your PR checks on CI.
+
+Note that this tagging structure is just a suggestion - you can adapt it to your specific needs. The key is to have clear, enforceable boundaries that reflect both your technical architecture and your business domains.
+
+Read more about [Nx boundary rules in our documentation](/features/enforce-module-boundaries).
+
+## Automate Your Standards
+
+As your workspace grows, it becomes increasingly important to automate and enforce your team's standards and best practices.
+
+The key to successful automation is finding the right balance. Start with automating the most common patterns that need standardization, and gradually add more automation as patterns emerge. Focus on the standards that provide the most value to your team. These automation capabilities are really here to ensure that your team's standards are not just documented but actively enforced through tooling, making it easier for developers to do the right thing by default.
+
+Nx provides powerful mechanisms to achieve this.
+
+### Custom Generators for Consistent Code Generation
+
+Nx is extensible. As such it allows you to create custom code generators that you can use to encode your organization's standards and best practices.
+
+The generator itself is just a function that manipulates files:
+
+```typescript
+import { Tree, formatFiles } from '@nx/devkit';
+
+export default async function (tree: Tree, schema: any) {
+  // Add your generator logic here
+  // For example, create files, modify configurations, etc.
+
+  await formatFiles(tree);
+}
+```
+
+Your team can then run these generators through the Nx CLI (via the `nx generate ...` command) or [Nx Console](/getting-started/editor-setup):
+
+For more detailed information about creating custom generators, including how to add options, create files, and modify existing ones, check out the [Local Generators documentation](/extending-nx/recipes/local-generators).
+
+### Leverage Nx Console AI Integration
+
+If you use [Nx Console](/getting-started/editor-setup), Nx's editor extension for VSCode and IntelliJ, then you should already have the latest AI capabilities enabled.
+
+Nx Console [just got some enhancements](/blog/nx-made-cursor-smarter) with the goal of providing contextual information to editor integrated LLMs such as Copilot and Cursor. By providing Nx workspace metadata to these models they are able to provide much more valuable, context specific information and perform actions via the Nx CLI.
+
+You can find more detailed information [in our documentation](/features/enhance-AI) about how to enable and use the capabilities.
+
+## Single-app vs Multiple App Deployment
+
+Until now we didn't really talk about a monorepo at all. We have a single Angular application and modularized its features into dedicated projects. The projects themselves are really just to encapsulate their logic and structure our application. While we could make them buildable by themselves (mostly for leveraging speed gains from incremental building) most of them do not have build targets. You can test and lint them independently but with a standalone Angular application, all your features are bundled and deployed together as a single unit.
+
+While this approach is simple and works well for smaller applications, there are several scenarios where you might want to split your application:
+
+- **Different scaling requirements**: Your customer-facing store might need high availability and scalability to handle thousands of concurrent users, while your admin interface serves a much smaller number of internal users
+- **Resource optimization**: Not all users need all features. For example, administrative features like inventory management are only needed by staff members
+- **Independent deployment cycles**: Different parts of your application might need to evolve at different speeds. Your admin interface might need frequent updates for internal tools, while your customer-facing store remains more stable
+- **Security considerations**: Keeping administrative features in a separate application can reduce the attack surface of your customer-facing application
+
+As your application grows, you might want to split it into multiple applications - perhaps separating your customer-facing storefront from your administrative interface. The first step is to convert your standalone application into a monorepo structure. Nx comes with a `convert-to-monorepo` command to do exactly that:
+
+```shell
+nx g convert-to-monorepo
+```
+
+This command moves your existing application into an `apps` directory and adjusts any configuration that needs to be adjusted for supporting multiple side-by-side applications in a monorepo setup.
+
+> Note: If you're looking for a NPM/Yarn/PNPM workspaces based monorepo setup, then make sure to read our article about the [New Nx Experience for TypeScript Monorepos](/blog/new-nx-experience-for-typescript-monorepos).
+
+### Creating Multiple Applications
+
+Once you have a monorepo structure, you can create additional applications that share code with your original app. For example, you might want to create an admin application:
+
+```shell
+nx g @nx/angular:app admin
+```
+
+Now you can move administrative features (like inventory management) to the new admin app by importing libraries relevant to the new app (such as for example the inventory management libraries).
+
+Here's what the new structure could look like:
+
+```text
+myshop/
+├── apps/
+│   ├── shop/          # Customer-facing storefront (high availability needed)
+│   └── admin/         # Administrative interface (internal users only)
+└── packages/
+    ├── products/      # Shared product domain
+    ├── orders/        # Shared order management
+    ├── checkout/      # Shop-specific checkout process
+    └── shared/        # Common utilities and components
+```
+
+You can see how the already modular structure allows you to adjust your application structure and re-link some of the packages into the new application. Something that would have otherwise been a major undertaking.
+
+Similarly to how we now have two applications that can be deployed and scaled independently, we could go even further and convert it into a microfrontend approach. But more on that in another article.
+
+## Scaling Development
+
+Obviously as your codebase keeps growing you need to have the tooling support that helps keep it sustainable. In particular CI might become a concern as the number of projects grows. For that purpose Nx has several features to keep your CI fast and efficient:
+
+- **[Remote Caching (Nx Replay)](/ci/features/remote-cache)** ensures your code is never rebuilt or retested unnecessarily.
+- **[Distributed Task Execution (Nx Agents)](/ci/features/distribute-task-execution)** intelligently allocates tasks across multiple machines.
+- **[Atomizer](/ci/features/split-e2e-tasks)** helps manage growing test suites by automatically splitting them into more fine-grained runs and by leveraging Nx Agents to parallelize them across machines.
+- **[Flaky Task Detection](/ci/features/flaky-tasks)** identifies flaky tasks (often automated unit or e2e tests) and re-runs them automatically for you.
+
+One of the key advantages of using Nx is that it's not limited to just Angular either. As your application grows, you might need to:
+
+- Add a documentation site using static site generators like [Analog](https://analogjs.org/)
+- Create landing pages with Next.js or Astro
+- Build backend services with NestJS or Express
+- Add specialized tools for specific business needs
+
+Nx supports all these scenarios while maintaining the ability to share code between different technologies. For example, you could:
+
+```text
+myshop/
+├── apps/
+│   ├── shop/          # Main Angular application
+│   ├── admin/         # Angular admin interface
+│   ├── docs/          # Analog documentation site
+│   ├── landing/       # Next.js marketing site
+│   └── api/          # NestJS backend
+└── packages/
+    ├── products/     # Shared product domain (used by both front and backend)
+    ├── orders/       # Shared order management
+    └── shared/       # Common utilities and types
+```
+
+The modular structure we established earlier makes it easy to share types and interfaces between frontend and backend and reuse business logic across different applications.
+
+## Wrapping up
+
+Building maintainable Angular applications at scale requires thoughtful architecture decisions and proper tooling support. We've covered several key aspects:
+
+1. **Domain-Driven Structure**: Moving from traditional layered architectures to organizing code around business domains creates clearer boundaries and better maintainability.
+
+2. **Incremental Adoption**: Starting small with a standalone application and growing into a more complex structure as needed, rather than over-engineering from the start.
+
+3. **Clear Boundaries**: Using projects/libraries to create explicit boundaries between different parts of your application, with automated enforcement through module boundary rules.
+
+4. **Automation & Standards**: Leveraging custom generators and AI-enhanced tooling to maintain consistency and best practices across your codebase.
+
+5. **Scalability Options**: Understanding when and how to evolve from a single application to multiple applications or even microfrontends, while maintaining code sharing and reusability.
+
+Remember that architecture is not a one-time decision but an evolving process - start with clear boundaries and good practices, then adapt as your application and team's needs grow. The key to success lies in having the proper tooling and automation in place to support you as your application grows.
+
+---
+
+Learn more:
+
+- 🧠 [Nx AI Docs](/features/enhance-AI)
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-03-19-are-monorepos-the-answer-to-better-aiassisted-development.md

@@ -0,0 +1,20 @@
+---
+title: 'Are Monorepos the Answer to Better AI-Assisted Development?'
+description: 'In this webinar, Nx CTO Victor Savkin and Senior Engineer Max Kless will break down **why monorepos are inherently more AI-friendly**, giving LLMs the full context they need to generate more accurate, actionable insights. You’ll also learn how Nx provides deep architectural awareness, making AI tools smarter and more effective.'
+date: 2025-03-06
+slug: 'are-monorepos-the-answer-to-better-aiassisted-development'
+authors: ['Victor Savkin', 'Max Kless']
+tags: [webinar]
+cover_image: /blog/images/2025-03-19/March-2025-Webinar-card.png
+time: 1pm EDT/5pm UTC
+status: Past - Gated
+registrationUrl: https://go.nx.dev/march2025-webinar
+---
+
+**Mar 19, 2025 - 1pm EDT/5pm UTC**
+
+Presented by Victor Savkin and Max Kless
+
+In this webinar, Nx CTO Victor Savkin and Senior Engineer Max Kless will break down **why monorepos are inherently more AI-friendly**, giving LLMs the full context they need to generate more accurate, actionable insights. You’ll also learn how Nx provides deep architectural awareness, making AI tools smarter and more effective.
+
+{% call-to-action title="Download the recording" url="https://go.nx.dev/march2025-webinar" description="Sign up to gain access" /%}

docs/blog/2025-03-19-using-angular-with-rspack.md

@@ -0,0 +1,237 @@
+---
+title: 'Using Rspack with Angular'
+date: 2025-03-19
+slug: using-rspack-with-angular
+authors: [Colum Ferry]
+tags: [angular, webpack, rspack, nx]
+cover_image: /blog/images/2025-03-19/rspack.avif
+description: Learn about how and why to use Rspack with Angular thanks to Nx's efforts for supporting Rspack for Angular.
+---
+
+{% callout type="deepdive" title="Angular Week Series" expanded=true %}
+
+This article is part of the Angular Week series:
+
+- [Modern Angular Testing with Nx](/blog/modern-angular-testing-with-nx)
+- [Angular Architecture Guide To Building Maintainable Applications at Scale](/blog/architecting-angular-applications)
+- **Using Rspack with Angular**
+- [Enterprise Patterns](/blog/enterprise-angular-book)
+
+{% /callout %}
+
+Configuring your build tooling for [Angular](https://angular.dev) applications has always been a lesser concern for most Angular developers due to the abstractions that Angular created called `builders`. The underlying implementation details were hidden from the developer who only needed to run either `ng build` or `nx build`.  
+Despite this, most Angular developers knew that it was originally [Webpack](https://webpack.js.org/) that was used to build their applications. This was a great solution at the time and it was even possible to extend their builds by leveraging custom webpack configurations and plugins.
+
+Over time, as applications grew in size and complexity, it became clear that the inherit slowness with Webpack build speeds was becoming more and more of an issue for Angular developers.
+
+The Angular Team decided to address this issue by creating a new build pipeline that leveraged [Esbuild](https://esbuild.github.io/).
+
+> Esbuild brought much-needed performance improvements to Angular builds, but existing Webpack-based applications were left with either a difficult migration path or no clear upgrade strategy.
+
+To this day, many existing Angular applications still rely on Webpack because they cannot readily replace their Webpack configurations and plugins with equivalent Esbuild plugins. Thus, they are continuing to fight with slow builds reducing their productivity.
+
+## What about Rspack?
+
+[Rspack](https://rspack.dev) is a high performance JavaScript bundler written in Rust. It offers strong compatibility with the Webpack ecosystem, allowing for almost seamless replacement of webpack, and provides lightning fast build speeds.
+
+Because it supports the existing Webpack ecosystem, it provides an answer to teams that maintain Angular applications using Webpack and want to migrate to a faster build pipeline.
+
+However, it is crucial to understand that Rspack is not _completely_ compatible with the Webpack ecosystem with some slight nuances and low-level api differences that prevent certain plugins and loaders from working out of the box.
+
+One such example is the `AngularIvyPlugin` which is a Webpack plugin that is used to support Angular's Ivy compiler. Therefore, it was not possible to simply drop in Rpsack and expect it to work with Angular applications.
+Many people have tried to get Rspack working with Angular, but it has proven to be a challenge, with partial support and partial success being reported in the past but with a lot of limitations or actual performance degradations over the Webpack approach.
+
+Previous attempts to get Rspack working with Angular focused on porting the Webpack-specific plugins, loaders and configurations to Rspack, either as-is or by reproducing them. This approach was never fully successful.
+
+Instead, a new approach was needed to support Rspack with Angular. A closer examination of how Angular compiles and bundles the application was required.
+
+## Introducing Angular Rspack
+
+![Angular Rspack Logo](/blog/images/2025-03-19/angular-rspack-logo-small.avif)
+
+Angular Rspack started in September 2024 after I spent way too long investigating and researching how exactly Angular compiles and bundles for both their Webpack support and Esbuild support.
+
+Something that I kept coming back to was that any Rspack solution that relied too much on Angular's Webpack support had the chance of being dropped by the Angular team as they continue to build out incredible new features with Esbuild. Instead, I decided that replicating and utilizing the abstractions the Angular team provided for their Esbuild support had a much stronger chance of longevity.
+
+But before we dive into the technical details, I am excited to announce that Angular Rspack is now being maintained by the Nx team and is available for use with Nx. This means that you can now use Rspack with Angular and Nx and enjoy the benefits of both.  
+The new package is called [@nx/angular-rspack](https://www.npmjs.com/package/@nx/angular-rspack) and it is available on npm while the repository has been moved to [nrwl/angular-rspack](https://github.com/nrwl/angular-rspack).
+
+Nx already supports and integrates with a wide variety of build tooling across the ecosystem - filling in the gaps where developer experience (DX) needs to be improved - which makes Nx the perfect fit for continuing to maintain and build out Angular Rspack.
+
+The support is still currently experimental, however, it is in a state that may be sufficient for your current needs. We invite you to try it out and to let us know if you run into issues by raising issues on the [angular-rspack repo](https://github.com/nrwl/angular-rspack/issues/new).
+
+There are some limitations and missing features that are currently being worked on and on the roadmap to support. They have been listed at the bottom of this article.
+
+## Migrating from Angular Webpack to Angular Rspack
+
+To make the migration process as smooth as possible, a new generator has been added to the `@nx/angular` package called `convert-to-rspack` which will help you migrate your Angular applications from Webpack to Rspack.
+
+The steps are very simple:
+
+1. Run `nx migrate latest` to update your workspace to the latest version of Nx.
+2. Run `nx g @nx/angular:convert-to-rspack` to migrate your Angular application to Rspack.
+
+There is also a [guide in our documentation](/recipes/angular/rspack/migrate-from-webpack) that walks you through the process step-by-step.
+Even if you're currently using the Angular CLI, it's as simple as first running `npx nx init` in your workspace and then running `npx nx g convert-to-rspack`.
+
+## Using Angular Rspack
+
+You'll notice that after migrating to Angular Rspack your `build` and `serve` targets have been removed from your project, and are instead [inferred](/concepts/inferred-tasks) by the `@nx/rspack/plugin`.
+In addition, a new `rspack.config.ts` file has been created in your project which looks something like this:
+
+```ts
+import { createConfig } from '@nx/angular-rspack';
+export default createConfig(
+  {
+    options: {
+      root: __dirname,
+      outputPath: {
+        base: '../../dist/apps/app',
+      },
+      index: './src/index.html',
+      browser: './src/main.ts',
+      polyfills: ['zone.js'],
+      tsConfig: './tsconfig.app.json',
+      assets: [
+        './src/favicon.ico',
+        './src/assets',
+        {
+          input: './public',
+          glob: '**/*',
+        },
+      ],
+      styles: ['./src/styles.scss'],
+      scripts: [],
+    },
+  },
+  {
+    production: {
+      options: {
+        outputPath: {
+          base: '../../dist/apps/app-prod',
+        },
+        index: './src/index.prod.html',
+        browser: './src/main.prod.ts',
+        tsConfig: './tsconfig.prod.json',
+      },
+    },
+  }
+);
+```
+
+{% callout type="deepdive" title="createConfig Information" %}
+The `createConfig` function is used to create an Rspack configuration object setup for Angular applications.
+You can read more about it [here](/nx-api/angular-rspack/documents/create-config).
+{% /callout %}
+
+### Building and Serving your Application
+
+You can now run `nx build app` and `nx serve app` to build and serve your application via Rspack.
+
+```{% command="nx build app" %}
+> nx run app:build
+
+> rspack build --node-env=production
+
+●  ━━━━━━━━━━━━━━━━━━━━━━━━━ (100%) emitting after emit                                               browser:
+
+
+  browser compiled successfully in 2.32 s
+```
+
+```{% command="nx serve app" %}
+> nx run app:serve
+
+> rspack serve --node-env=development
+
+<i> [webpack-dev-server] [HPM] Proxy created: /api  -> http://localhost:3000
+<i> [webpack-dev-server] Project is running at:
+<i> [webpack-dev-server] Loopback: http://127.0.0.1:8080/
+<i> [webpack-dev-server] Content not from webpack is served from '/Users/columferry/dev/nrwl/issues/rspack-angular/ng-rspack/e2e/fixtures/rspack-csr-css/public' directory
+<i> [webpack-dev-server] 404s will fallback to '/index.html'
+Listening on port: 8080
+●  ━━━━━━━━━━━━━━━━━━━━━━━━━ (100%) emitting after emit                                               browser:
+  browser compiled successfully in 2.33 s
+```
+
+### Using a configuration
+
+To run the build with the `production` configuration:
+
+```bash
+NGRS_CONFIG=production nx build app
+```
+
+`NGRS_CONFIG` is an environment variable that you can use to specify which configuration to use. If the environment variable is not set, the `production` configuration is used by default.
+
+## Creating a new Angular Rspack application
+
+We currently do not have a generator for creating a new Angular Rspack application, but we will soon and it will be available under a `--bundler=rspack` option on the `@nx/angular:application` generator.
+
+However, you can still create a new Angular Rspack application by running the following commands:
+
+```shell
+nx g @nx/angular:application myapp --bundler=webpack
+nx g @nx/angular:convert-to-rspack myapp
+```
+
+## Benchmarks
+
+![Benchmarks](/blog/images/2025-03-19/bundler-build-times.avif)
+
+Below is a table of benchmarks for the different bundlers available, run against an application consisting of ~800 lazy loaded routes with ~10 components each - totaling ~8000 components.
+
+**System Info**
+
+- MacBook Pro (macOS 15.3.1)
+- Processor: M2 Max
+- Memory: 96 GB
+- `@nx/angular-rspack` version: 20.6.2
+- Angular version: ~19.2.0
+
+| Build/Bundler | Prod SSR (s) | Prod (s) | Dev (s) |
+| ------------- | ------------ | -------- | ------- |
+| Webpack       | 198.614      | 154.339  | 159.436 |
+| esbuild       | 23.701       | 19.569   | 15.358  |
+| Rsbuild       | 23.949       | 20.490   | 18.209  |
+| Rspack        | 30.589       | 19.269   | 19.940  |
+
+> You can find the benchmarks and run them yourself: [https://github.com/nrwl/ng-bundler-benchmark](https://github.com/nrwl/ng-bundler-benchmark)
+
+As can be seen by the benchmarks above, Rspack is significantly faster than Webpack and very close to Esbuild.
+
+Given that the primary goal for Angular Rspack is to provide a faster build system for Angular Webpack applications while supporting their existing Webpack configurations and plugins, we are confident that Angular Rspack will be a great choice for teams that want to migrate to a faster build system.
+
+## Known Limitations and Missing Features
+
+The following are known limitations and missing features of Angular Rspack:
+
+- Static Site Generation (SSG) is not supported.
+- Angular's built-in support for Internationalization (i18n) is not supported.
+- Server Routing is not supported - still experimental in Angular currently.
+- App Engine APIs are not supported - still experimental in Angular currently.
+- Optimization is not currently 1:1 with Angular's optimization - however, there are still great optimizations that are made.
+  - Styles optimization for `inline-critical` and `remove-special-comments` are not yet implemented.
+  - Inlining of fonts is not yet implemented.
+- Web Workers are not fully supported.
+- Hot Module Replacement (HMR) is partially supported.
+
+If you have any other missing features or limitations, please [let us know](https://github.com/nrwl/angular-rspack/issues/new).
+
+## What's Next?
+
+We are actively working on improving the experience, stability and performance of Angular Rspack. Our next steps will revolve around getting to feature parity with Angular's build system - addressing the items listed above to achieve this.
+
+The `@nx/angular` plugin will also be updated to support generating new Angular Rspack applications as well as supporting Rspack Module Federation with Angular.
+
+Exciting times ahead! You can follow our progress by starring the [Angular Rspack repository](https://github.com/nrwl/angular-rspack) and following us on [X](https://X.com/nxdevtools).
+
+## Further Reading
+
+- [Nx Angular Rspack](/recipes/angular/rspack/introduction)
+- [Angular](https://angular.dev)
+- [Rspack](https://rspack.dev)
+- 🧠 [Nx Docs](/getting-started/intro)
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)

docs/blog/2025-03-20-enterprise-angular-book.md

@@ -0,0 +1,26 @@
+---
+title: 'Enterprise Angular Monorepo Patterns'
+date: 2025-03-20
+slug: enterprise-angular-book
+authors: [Mike Hartington]
+tags: [angular, nx, architecture]
+cover_image: /blog/images/2025-03-20/book-relaunch.avif
+description: Get the latest version of the Enterprise Angular Monorepo patterns book.
+---
+
+{% callout type="deepdive" title="Angular Week Series" expanded=true %}
+
+This article is part of the Angular Week series:
+
+- [Modern Angular Testing with Nx](/blog/modern-angular-testing-with-nx)
+- [Angular Architecture Guide To Building Maintainable Applications at Scale](/blog/architecting-angular-applications)
+- [Using Rspack with Angular](/blog/using-rspack-with-angular)
+- **Enterprise Patterns**
+
+{% /callout %}
+
+Building applications is often a challenge when you're working as an enterprise developer. But thankfully, Nx can help teams keep on the happy path when building for these challenging environments. We've had a book available since 2018 to help teams follow established patterns and ensure high quality code, however 2018 was quite a long time ago. Times have changed and so has the best practices for building Angular applications.
+
+As part of our Week of Angular, I'm thrilled to share that we've revised our book "Enterprise Angular Monorepo Patterns" and have updated it for 2025!
+
+If you'd like to get your copy of the book, be sure to [check it out](https://go.nx.dev/angular-patterns-ebook) and download your free copy!

docs/blog/2025-03-31-custom-runners-and-self-hosted-caching.md

@@ -0,0 +1,73 @@
+---
+title: 'Custom Task Runners and Self-Hosted Caching Changes'
+slug: custom-runners-and-self-hosted-caching
+authors: [Victor Savkin]
+description: 'Learn about free plugins for self-hosting your cache, a new Open API RFC and hooks for the task lifecycle as well as the commitment to open source and improved community collaboration.'
+tags: [nx]
+cover_image: /blog/images/articles/bg-self-hosted-caching-article.jpg
+---
+
+**TL;DR:** **Nx remains free for everyone who chooses to self-host their own cache**. There will be two ways to self-host:
+
+1. **Maximum independence and control:** An OpenAPI specification so you can run your own cache server implementation on your own terms.
+2. **Maximum convenience:** Free plugins for each major cloud storage provider (and arbitrary file system storage), all maintained by us.
+
+These options will be released before Nx 21.
+
+---
+
+**So, what happened?**
+
+In September 2024, we announced that custom task runners would be deprecated and would reach end-of-life in April 2025. This announcement is consistent with how we typically design and ship. We create a draft proposal (for example, a new API) that doesn't affect anyone immediately and give ourselves 6 to 12 months to gather feedback from the community, with real teams. After which, once it becomes stable, we finalize the design. I strongly believe in designing-while-doing and we've found that continuous-thinking-without-doing re-enforces ivory tower solutions.
+
+In this instance, we did not spend enough time engaging with the community on a couple key concerns. Our communication around this situation also fell short and I sincerely apologize for the confusion and concern this caused. I will outline the feedback we heard below and explain what we're improving to ensure this does not happen again.
+
+## **1. "We don't want open source capabilities to be taken away."**
+
+While we're still deprecating the older custom task runners API, our mistake was in not providing one-for-one replacement. To address this, we are introducing new APIs to replace the old one — **fully supporting everything the previous implementation offered, including free self-hosted caching.**
+
+### Self-Hosted Cache API RFC
+
+We have [published a new RFC](https://github.com/nrwl/nx/discussions/30548) detailing a custom self-hosted cache based on an OpenAPI specification. This will be available before Nx 21, ensuring a smooth migration path for those who are looking for full control.
+
+### New preTasksExecution and postTasksExecution API
+
+Some teams used custom task runners for non-cache-related workflows, and removing them created gaps in functionality. We have released open-source preTasksExecution and postTasksExecution hooks to provide the same capabilities in a more composable way. More details [in our docs](/extending-nx/recipes/task-running-lifecycle). We also [added detailed instructions to migrate to this new API](/deprecated/custom-tasks-runner#the-pretasksexecution-and-posttasksexecution-hooks) if you've been using custom task runners for such use cases in the past.
+
+We worked closely with large teams that have advanced use cases to ensure they can still accomplish everything they did before.
+
+{% callout title="A Clear Commitment Moving Forward" type="info" %}
+
+Our commitment is that **no major open-source feature or API will be replaced with a non-open-source alternative.** Some features will inevitably become obsolete over time, but when that happens, we will provide clear deprecation notices and migration strategies. Nx will continue to evolve, but removing an old API will never be a means to move users toward a paid feature.
+
+We will keep developing Nx Cloud and other premium offerings for teams that need enterprise-scale solutions, but we remain focused on a strong open-source foundation that allows teams to use and scale Nx without requiring paid features.
+
+Nx open-source remains a primary focus for us as a company.
+
+{% /callout %}
+
+### **@nx/s3, @nx/gcp, @nx/azure… and related packages are free for everyone**
+
+In addition to updating the API, we believe the first-party packages we offer are the best option for most organizations using self-hosted cache today – **so we've made them free for everyone**. The activation is simple and can be done in the CLI. _Full refunds will be issued to anyone who paid for these packages during this transition._
+
+> **Why is there an activation process?** It simply helps us better understand our users as we continue to improve our tools. You can also use the OpenAPI specification to run your own cache – for complete independence.
+
+## 2. "We want more input into the roadmap."
+
+We recognize that some of these changes felt abrupt. To address that, we've put the following measures in place to improve how we involve the community in major decisions:
+
+- **New RFC Process:** We've started putting all major API changes through an RFC process before being finalized:
+  - [**RFC: Nx Custom Self-Hosted Remote Cache**](https://github.com/nrwl/nx/discussions/30548)
+  - [**RFC: Linking Packages with Workspaces**](https://github.com/nrwl/nx/discussions/29099) (new [TypeScript Setup](/blog/new-nx-experience-for-typescript-monorepos))
+  - [**RFC: Infinite Tasks**](https://github.com/nrwl/nx/discussions/29025)
+- **Regular Office Hours:** A space for open discussions, where we share updates and answer questions. Join us [here](http://go.nx.dev/office-hours)!
+- **Published Roadmaps:** More transparency on what's coming next. View [current roadmap](https://github.com/nrwl/nx/discussions/28731).
+- **Closer Collaboration with Nx Champions and teams:** This new approach – and even this post – were shaped through dozens of conversations with [**Nx Champions**](/community) and many teams. We will continue to do so to minimize future blindspots.
+
+### **Moving Forward**
+
+The community's enthusiasm is what makes Nx successful, and we're very grateful for it. Good developer tools aren't built in isolation; they come from working together, listening, and refining as we go. The conversations we had over the past few months have helped us shape a better solution – one that works for more teams while keeping Nx fast and powerful.
+
+A huge thank you to everyone who shared their thoughts and helped push Nx forward - we wouldn't be where we are without you!
+
+- Victor Savkin and the Nx Team

docs/blog/2025-04-10-exploring-nx-console-with-mcp.md

@@ -0,0 +1,105 @@
+---
+title: 'Vibe Exploring a Codebase with LLMs'
+slug: vibe-exploring-a-codebase
+authors: ['Juri Strumpflohner']
+tags: ['nx', 'nx-console', 'ai']
+cover_image: /blog/images/articles/bg-vibe-querying-codebase.avif
+description: 'A walkthrough of using the Nx MCP integration in Cursor to navigate and understand the Nx Console codebase, demonstrating how AI assistance simplifies development tasks.'
+youtubeUrl: https://youtu.be/WUm61cDH8C8
+---
+
+[Nx Console](/getting-started/editor-setup) is our IDE extension for VSCode, Cursor, IntelliJ IDEA and other Jetbrains IDEs. It integrates deeply with Nx workspaces. Recently, we've also added features to [enhance your LLM assistant](/features/enhance-AI) with rich context about your monorepo, which is particularly valuable for exploring large codebases. Our Model Context Protocol (MCP) integration specifically improves the AI's reasoning capabilities in these complex environments. Read more in the [announcement blog post](/blog/nx-made-cursor-smarter).
+
+While often associated with code generation, LLMs are **incredibly powerful for exploration and understanding complex codebases**. Imagine onboarding a new developer onto a large project – an LLM armed with workspace context could significantly speed up their learning process.
+
+I recently experienced this firsthand as I needed to test an upcoming PR for Nx Console itself. Having not touched the packaging part of the codebase for a while, I wasn't sure about the current structure or how to generate the `.vsix` package for local testing. Instead of manually digging through files, I decided to leverage Nx Console's own LLM integration within the Nx Console codebase (pure inception!). I used it to query the structure and figure out the necessary build commands.
+
+Let's see how that went.
+
+{% toc /%}
+
+## Setting up the Nx MCP
+
+First, you need to ensure the Model Context Protocol (MCP) integration is set up, which allows Cursor to understand your Nx workspace. This starts with having the [Nx Console](/getting-started/editor-setup) extension installed, as it provides the necessary MCP server.
+
+When you start Cursor (version 0.46 or newer) in an Nx workspace with Nx Console present, it should automatically detect the server and prompt you via a notification to enable the "Nx Enhancement" agent. Clicking the notification is the easiest way, but you can also manually trigger the setup using the `nx.configureMcpServer` command from the command palette (`Ctrl/Cmd + Shift + P`).
+
+Finally, verify that the "Nx Console MCP" server is listed and enabled within Cursor's settings (`Cursor -> Settings -> Cursor Settings -> MCP`). This step confirms that Cursor is connected to the local MCP server provided by Nx Console. Once enabled, the AI assistant gains access to a powerful set of tools, allowing it to query detailed information about your Nx workspace structure, project configurations, and task dependencies.
+
+![Making sure the Nx MCP is registered in Cursor settings](/blog/images/articles/cursor-mcp-registered.avif)
+
+The [docs have all the details](/features/enhance-AI) if you need more infos.
+
+## Figuring out the Build Process
+
+My goal was to build the VS Code extension package (`.vsix` file) so I could install and test it locally. I wasn't sure about the exact command.
+
+**Query:** "What command can I use to build the VS Code extension so I can try it out locally?"
+
+Initially, the assistant might search for generic build scripts. However, thanks to the `nx_workspace` tool provided by the MCP, it quickly identifies the project as an Nx workspace.
+
+![MCP identifying Nx workspace and project structure](/blog/images/articles/mcp-identifying-nx-workspace.avif)
+
+It accesses the workspace details and finds the `project.json` for the VS Code extension project (likely located under an `apps` directory). Within this file, it discovers the available targets, including `build` and `package`.
+
+**Query:** "What is the difference between the `build` and `package` command? I want to get an extension VSIX file that I can install. Which one should I use?"
+
+The assistant, using the `nx_project_details` tool, examines the configuration for both targets. It determines that the `package` target is the one that produces the `.vsix` file needed for installation, while `build` likely just compiles the code.
+
+## Understanding Task Dependencies
+
+A common question when dealing with [build pipelines](/features/run-tasks#defining-a-task-pipeline) is whether prerequisite steps need to be run manually.
+
+**Query:** "When I run the package command, do I need to run build beforehand?"
+
+This is where the Nx MCP integration truly shines. Nx allows defining dependencies between tasks. The assistant analyzes the project configuration again.
+
+**Query:** "Where is that dependency between the `package` and `build` command defined?"
+
+It reads the `project.json` for the VS Code project, specifically looking at the `package` target:
+
+```json
+// Example structure within project.json (apps/vscode/project.json)
+{
+  // ... other config ...
+  "targets": {
+    "build": {
+      // build configuration
+    },
+    "package": {
+      "executor": "nx:run-commands",
+      "options": {
+        "commands": ["node ./tools/scripts/vscode-vsce.js"]
+      },
+      "dependsOn": [
+        "build" // <-- Here's the dependency!
+        "^build"
+      ]
+    }
+    // ... other targets ...
+  }
+}
+```
+
+The assistant points out the `dependsOn` array within the `package` target configuration. This explicitly tells Nx to run the `build` target before executing the `package` command.
+
+This **understanding comes directly from the structured data provided by the MCP server about the Nx workspace's configuration and task graph**. Without the MCP, the AI would lack the context of Nx's task dependency system.
+
+## Wrapping Up
+
+Much of the buzz around LLMs focuses on code generation (a major use case, for sure) or even the more extreme "vibe coding". However, as this walkthrough demonstrates, using LLMs for **exploring and understanding large codebases** is an incredibly valuable application, especially within an Nx monorepo enhanced with our MCP integration.
+
+Think about navigating an unfamiliar project: you can ask the AI where specific functionality is located, how different parts are connected, or where new code should ideally be placed. This can help accelerate the onboarding process for new team members.
+
+We're really just getting started with Nx's LLM integration. Keep an eye on our social channels ([@nxdevtools on X/Twitter](https://x.com/nxdevtools), [@nx.dev on Bluesky](https://bsky.app/profile/nx.dev), and our [Nx YouTube channel](https://www.youtube.com/@nxdevtools)) where we regularly share showcases and announce new features – we're releasing improvements almost weekly!
+
+---
+
+Learn more:
+
+- 🧠 [Nx AI Docs](/features/enhance-AI)
+- 📖 [Making Cursor Smarter with an MCP Server For Nx Monorepos](/blog/nx-made-cursor-smarter)
+- 👩‍💻 [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)

docs/blog/2025-04-14-scaffold-angular-rspack-applications.md

@@ -0,0 +1,139 @@
+---
+title: 'Scaffolding New Apps With Angular Rspack'
+date: 2025-04-15
+slug: scaffold-angular-rspack-applications
+authors: [Colum Ferry]
+tags: [angular, webpack, rspack, nx]
+cover_image: /blog/images/2025-04-14/scaffold-angular-rspack-applications.avif
+description: Learn about how to scaffold a new Angular Rspack application with Nx.
+---
+
+It is not uncommon to see [Angular](https://angular.dev) applications that rely on a custom [Webpack](https://webpack.js.org) configuration - especially in enterprise settings. These applications rely heavily on the extensibility offered by Webpack via its Plugin and Loader ecosystem.
+
+However, building Angular applications with Webpack has historically been slow. In fact, slow builds with Webpack is something that even the wider JavaScript Ecosystem has come to expect. The result? Many new bundler options have been created to tackle the issue. Vite, Rollup, Rolldown, Esbuild, Turbopack and more.
+
+The frustration over build performance became so great that the Angular team decided to switch to [Esbuild](https://esbuild.github.io) which has offered an incredible improvement on build speed.
+
+The problem with Esbuild – and with the other bundler options listed above – stems from the _reason_ teams needed custom Webpack configurations in the first place. The extensibility.
+
+While most of the bundler options that are available today offer some kind of API to extend the build process, the ability to replicate the functionality of certain Webpack plugins and loaders is either impossible or would involve a large effort to build a homebrewed solution that would need to be maintained internally over time.
+
+That is, until [ByteDance](https://bytedance.com/en) released [Rspack](https://rspack.dev).
+
+## Rspack
+
+![Rspack Logo](/blog/images/2025-04-14/rspack-logo.avif)
+
+Rspack is a high performance JavaScript bundler written in Rust. It offers strong compatibility with the Webpack ecosystem, allowing for near-seamless replacement of Webpack, while providing lightning fast build speeds.
+
+That sounds compelling enough as it is, especially for anyone that is currently using Webpack to build their applications. You can see from the benchmark results below just _how much_ faster than Webpack it really is. You can view the benchmark details [here](https://github.com/rspack-contrib/build-tools-performance).
+
+![Rspack Benchmarks](/blog/images/2025-04-14/rspack-benchmarks.png)
+
+Docusaurus has even [reported that switching to Rspack has resulted in a 2x-4x faster production build](https://docusaurus.io/blog/releases/3.6#docusaurus-faster)!
+
+However, Angular’s Webpack build pipeline proved to be an issue. It had not been possible to use Rspack as a drop-in replacement for Angular applications.
+
+Which is why [Angular Rspack](/recipes/angular/rspack/introduction) was created.
+
+## Angular Rspack
+
+![Angular Rspack Logo](/blog/images/2025-03-19/angular-rspack-logo-small.avif)
+
+Angular Rspack provides Rspack Plugins and Loaders that makes it possible to build Angular applications with Rspack.
+
+{% callout type="note" title="Learn More" %}
+
+You can learn more about Angular Rspack from the resources below:
+
+- [Angular Rspack - Introduction](/recipes/angular/rspack/introduction)
+- [Using Rspack with Angular](/blog/using-rspack-with-angular)
+
+{% /callout %}
+
+At the time of writing, Angular still supports building applications with Webpack alongside Esbuild. However, they are two different build pipelines.
+
+Therefore, if the Angular team were to **drop support for Webpack** and remove the code from the Angular Devkit packages entirely, **Angular Rspack will continue to operate**.
+
+- By using Rspack the majority of Plugins and Loaders used by Angular applications with custom Webpack Configurations will continue to be supported
+- It does not rely on Angular’s Webpack build pipeline directly. Instead it uses the abstractions in place for the Esbuild pipeline.
+
+From the benchmark results below, you can see the vast improvement using Angular Rspack has over sticking with Webpack. You can view the benchmark details [here](https://github.com/nrwl/ng-bundler-benchmark).
+
+![Angular Rspack Benchmarks](/blog/images/2025-03-19/bundler-build-times.avif)
+
+You can see that the results from Rspack are comparable to the results provided by Angular’s Esbuild build pipeline.
+
+That said, it is worth noting that there are still currently some [known limitations and missing features](/recipes/angular/rspack/introduction#known-limitations-and-missing-features).
+
+## Why Choose Rspack for New Projects?
+
+Given the results above, it’s clear that migrating Angular Webpack applications to Rspack can lead to significant time savings — reducing CI durations and boosting overall developer productivity.
+
+But at this point, you might be asking _why_ you should start a new Angular project with **Rspack** instead of **Esbuild**, especially considering that benchmarks show Esbuild is still slightly faster when building Angular apps.
+
+Here’s why Rspack is often the better choice for new projects:
+
+- **Speed** – While Esbuild may still win out slightly in raw benchmarks, Rspack delivers massive speed improvements over traditional Webpack — especially in large projects or CI environments. It’s fast enough to feel like a completely different experience for developers used to legacy builds.
+- **Extensibility** – Rspack provides a much more extensible architecture than Esbuild. This allows teams to customize and fine-tune their build processes far more effectively. For projects that have complex build requirements or need to integrate custom tooling, this flexibility is a major advantage.
+- **Compatibility** – Rspack is designed to be highly compatible with the existing Webpack ecosystem. This means many plugins and loaders that teams already rely on can continue to work with minimal or no changes. It eases the migration path and preserves your existing investment in tooling and configuration.
+- **Micro-frontend support** – If you're building applications that rely heavily on **[Module Federation](https://module-federation.io)**, Rspack is the clear winner. Its compatibility and support for advanced use cases in micro-frontends are significantly more mature than what's possible with Esbuild.
+- **Chunking control** – Esbuild has a long-standing [issue](https://github.com/angular/angular-cli/issues/27715) with generating an excessive number of chunks, offering very limited control over how chunking is performed. This can cause performance issues in certain scenarios. In contrast, Rspack offers fine-grained chunking strategies that let teams precisely shape how their bundles are produced.
+
+These advantages make Rspack not just a performance play, but a more adaptable and production-ready solution for modern Angular projects.
+
+## How to Scaffold a New Angular Rspack Project?
+
+Nx provides two methods for creating a new Angular Rspack project, one for existing Nx Workspaces and one for new Workspaces.
+
+### New Workspaces
+
+To create a new Nx Workspace with an Angular Rspack project run the following command and select the options listed below:
+
+```{% command="npx create-nx-workspace myorg" path="~/" %}
+
+NX   Let's create a new workspace [[https://nx.dev/getting-started/intro](https://nx.dev/getting-started/intro)]
+
+✔ Which stack do you want to use? · angular
+✔ Integrated monorepo, or standalone project? · integrated
+✔ Application name · myorg
+✔ Which bundler would you like to use? · rspack
+✔ Default stylesheet format · css
+✔ Do you want to enable Server-Side Rendering (SSR)? · No
+✔ Which unit test runner would you like to use? · vitest
+✔ Test runner to use for end to end (E2E) tests · playwright
+✔ Which CI provider would you like to use? · skip
+✔ Would you like remote caching to make your build faster? · skip
+
+NX   Creating your v20.8.0 workspace.
+
+```
+
+### Existing Workspaces
+
+In existing Nx Workspaces, ensure you are on Nx version `20.8.0` or greater and simply run:
+
+```
+
+npx nx g @nx/angular:app myapp --bundler=rspack
+
+```
+
+### Converting an Existing Angular Webpack Application
+
+If you have an existing Angular Webpack application you can easily migrate it to use Angular Rspack by using the `@nx/angular:convert-to-rspack` generator. The [Migrate Angular with Webpack to Rspack](/recipes/angular/rspack/migrate-from-webpack) guide explains more on this.
+
+## Future Work
+
+It’s been great to see the progress on Angular Rspack so far, but it’s not done yet. We’ll be working on making it closer to feature parity with the Angular CLI by addressing:
+
+- Internationalization (i18n) support
+- Static Site Generation (SSG) support
+- and more!
+
+Stay tuned to our socials to stay up to date on the latest Angular Rspack news!
+
+- 🧠 [**Nx Docs**](/getting-started/intro)
+- 👩‍💻 [**Nx GitHub**](https://github.com/nrwl/nx)
+- 💬 [**Nx Official Discord Server**](https://go.nx.dev/community)
+- 📹 [**Nx Youtube Channel**](https://www.youtube.com/@nxdevtools)

docs/blog/2025-04-15-nx-mcp-vscode-copilot.md

@@ -0,0 +1,126 @@
+---
+title: 'Nx MCP Now Available for VS Code Copilot'
+slug: nx-mcp-vscode-copilot
+authors: ['Juri Strumpflohner']
+tags: ['nx', 'nx-console', 'ai']
+cover_image: /blog/images/articles/bg-copilot-nx-mcp.avif
+description: 'Learn how to enhance VS Code Copilot with Nx MCP integration, providing rich monorepo context for smarter AI assistance.'
+youtubeUrl: https://youtu.be/dRQq_B1HSLA
+---
+
+{% callout type="deepdive" title="Series: Making your LLM smarter" expanded=true %}
+
+- [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**
+- [Nx and AI: Why They Work so Well Together](/blog/nx-and-ai-why-they-work-together)
+
+{% /callout %}
+
+Back in [February we shipped the first version of Nx Console with AI features](/blog/nx-just-made-your-llm-smarter), directly integrating with GitHub Copilot's APIs to provide rich monorepo context. Now, VS Code has finally adopted the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction), and we've adapted our Cursor-based MCP implementation to work with all MCP clients, including Copilot. This integration makes your AI assistant even more powerful by providing rich context about your Nx workspace. Let's see how to set it up and what it can do for you.
+
+{% toc /%}
+
+## Setting up MCP in VS Code
+
+Getting started with Nx's MCP integration in VS Code is straightforward:
+
+1. **Install Nx Console** from the VS Code marketplace if you haven't already.
+2. Once installed, VS Code will show a notification to "Improve Copilot agent with Nx-specific context"
+3. Click "Yes" to automatically configure the Nx MCP server in your `.vscode/mcp.json` file
+
+![VS Code showing the Nx MCP installation prompt](/blog/images/articles/copilot-mcp-install.avif)
+
+{% callout type="note" title="Missed the notification?" %}
+If you missed the notification, you can always run the `nx.configureMcpServer` command from the command palette (`Ctrl/Cmd + Shift + P`).
+{% /callout %}
+
+VS Code will automatically start the MCP server when needed during your interactions with the LLM. You can verify the installation by checking your VS Code settings, where you should see the Nx MCP server listed along with its available tools.
+
+## Why Use Nx MCP in Your Monorepo?
+
+While VS Code and Copilot can already gather information from your monorepo context, Nx MCP provides several advantages:
+
+1. **Efficient Data Access**: Instead of analyzing numerous files to infer relationships, Nx MCP provides direct access to pre-computed metadata about your workspace.
+2. **Rich Project Context**: Nx maintains detailed information about:
+   - Project relationships and dependencies
+   - Project tags and categorization
+   - Available tasks and their configurations
+   - Code ownership
+   - And more...
+
+This information is already maintained by Nx for optimizing your monorepo, and the Nx MCP makes it now available to your AI assistant as well. Most importantly, this enables Copilot to move beyond simple file-level understanding to gain more of an **architectural awareness of your workspace**. Instead of just seeing individual files and their contents, it now understands the broader context: how projects are connected, where integration points exist, which teams own what, and how changes might impact the broader system. This architectural awareness is particularly powerful in a monorepo setting, where understanding these relationships is crucial for making informed development decisions.
+
+## Nx MCP in Action
+
+Let's look at some practical examples of how Nx MCP enhances your AI assistant's capabilities:
+
+### Understanding Project Relationships
+
+You can ask questions about project dependencies and get accurate answers based on the actual project graph:
+
+```typescript
+// Example query:
+'Use the provided Nx MCP tools to figure out which order projects
+are related to the data-access-order project';
+```
+
+The AI will use the `nx_workspace` tool to analyze project relationships and can even visualize them using the `nx_visualize_graph` tool, showing both direct dependencies and upstream projects.
+
+### Smart Code Generation
+
+While LLMs can generate code on their own, Nx MCP provides a powerful combination of predictable code generation through Nx generators and AI-driven customization:
+
+```typescript
+// Example query:
+"Create a new feature library in packages/order/feat-cancel-order.
+Make it a React library and link it to the data-access-order project.
+Don't use a bundler or generate components."
+```
+
+The AI will:
+
+1. Use `nx_generators` to identify available generators
+2. Execute the React library generator with precise options
+3. Set up proper project tags and dependencies
+
+### Documentation-Aware Configuration
+
+To prevent hallucination and ensure up-to-date information, Nx MCP provides access to the current Nx documentation:
+
+```typescript
+// Example query:
+'Add a task pipeline in nx.json that runs the build of all downstream projects before the dev command';
+```
+
+The AI will:
+
+1. Query the Nx docs for task pipeline configuration
+2. Update `nx.json` with the correct syntax
+3. Configure the dependencies accurately
+
+## Beyond File-Level Thinking
+
+This integration isn't just about fancy AI features - it's about making your existing editor experience more productive by integrating AI capabilities where they actually make sense. Instead of jumping on the AI hype train, we're focusing on exposing Nx's deep understanding of your workspace directly in your editor through tools like Copilot. This enables:
+
+- More precise and contextual suggestions
+- Architecture-aware refactoring
+- Better understanding of project boundaries and relationships
+- Improved onboarding assistance for new team members
+
+We're actively developing this integration and would love to hear your feedback! If you have ideas about what you'd like to see or how we can make this more useful for your workflow, reach out to us on [Twitter/X](https://x.com/NxDevTools), [Bluesky](https://bsky.app/profile/nx.dev), [LinkedIn](https://www.linkedin.com/company/nrwl/), or join our [weekly office hours on Discord](http://go.nx.dev/office-hours).
+
+Also, subscribe to our [YouTube channel](https://www.youtube.com/@nxdevtools) for upcoming feature announcements and demonstrations.
+
+Want to try it out? Install [Nx Console from the VS Code marketplace](/getting-started/editor-setup) and follow the MCP setup prompts to get started.
+
+---
+
+Learn more:
+
+- 🧠 [Nx AI Docs](/features/enhance-AI)
+- 📖 [Making Cursor Smarter with MCP](/blog/nx-made-cursor-smarter)
+- 👩‍💻 [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)

docs/blog/2025-04-15-test-splitting-techniques.md

@@ -0,0 +1,162 @@
+---
+title: '3 Test Splitting Techniques that Cut E2E Times up to 90%'
+slug: test-splitting-techniques
+authors: [Miroslav Jonaš]
+description: "Learn the techniques for optimizing CI by splitting long-running tests, using sharding, Atomizer, and manual E2E project splitting, all enhanced by Nx Cloud's distributed task execution for improved stability and performance."
+tags: [nx, architecture]
+cover_image: /blog/images/articles/bg-test-splitting-techniques.avif
+---
+
+> "There's nothing worse than waiting for a build to complete, or those e2e tests to run. With Nx Cloud, our development team has saved over 104 hours, almost cutting our build times in half. The installation is seamless and the results are immediate. It's nice to have a tool that passively saves so much development time." - Director of Software Development, enterprise digital marketing firm
+
+One of the most impactful core features of Nx is the affected graph. The affected graph helps us to skip unnecessary work and focus only on the things that have been changed, speeding our CI and helping us ship features and hotfixes faster.
+
+However, long-running tasks, especially End-to-End (E2E) tests, can become a significant bottleneck and prevent getting the code changes out faster. This is particularly true for monolithic projects, but also in cases when there is a single large E2E project that covers the entire scope of the application. In these scenarios, the full benefits of an affected graph cannot be realized.
+
+In this guide, we'll explore three techniques to speed up your CI by splitting these lengthy test tasks.
+
+## Built-in Test Sharding
+
+One of the simplest ways to split long-running tests is by using built-in test sharding features available in popular testing frameworks like **Jest** and **Playwright**. These tools allow you to divide your test suite into multiple shards that can be executed in parallel, reducing the perceived test execution time.
+
+In **Jest** we can utilize the new `--shard` option to split your test suite. The example below shows splitting into 4 shards.
+
+```shell
+nx affected -t test -- --shard=1/4
+nx affected -t test -- --shard=2/4
+nx affected -t test -- --shard=3/4
+nx affected -t test -- --shard=4/4
+```
+
+**Playwright** also supports the `--shard` option:
+
+```shell
+nx affected -t e2e -- --shard=1/4
+nx affected -t e2e -- --shard=2/4
+nx affected -t e2e -- --shard=3/4
+nx affected -t e2e -- --shard=4/4
+```
+
+Now that we have our tests sharded, we can distribute the test load and achieve faster feedback. But what about the test runners that don't support sharding?
+
+## Nx Atomizer
+
+For more granular control over test distribution, Nx offers the [Atomizer](/ci/features/split-e2e-tasks). This feature allows you to split tasks per file. Splitting then further allows us to distribute long-running tasks across a larger number of agents, providing detailed insights into flaky tests and enabling automatic re-runs. If one of the flaky tests fails, we will still cache the results of all the other task slices and can even have a successful run if the flaky test re-run succeeded.
+
+![The `nx-e2e` task atomized to 13 e2e sub-tasks](/blog/images/articles/atomized-nx-e2e-ci.avif)
+
+With Atomizer, you can achieve a higher level of parallelism and ensure that only the necessary tests are executed, further optimizing your CI pipeline.
+
+To enable the Atomizer, we need to use supported inferred plugins or create our own.
+
+```json {% fileName="nx.json" %}
+{
+  // ...
+  "plugins": {
+    {
+      "plugin": "@nx/cypress/plugin",
+      "options": {
+        "targetName": "e2e",
+        "ciTargetName": "e2e-ci",
+      }
+    },
+    {
+      "plugin": "@nx/playwright/plugin",
+      "options": {
+        "targetName": "e2e",
+        "ciTargetName": "e2e-ci"
+      }
+    },
+    {
+      "plugin": "@nx/jest/plugin",
+      "options": {
+        "targetName": "test",
+        "ciTargetName": "test-ci",
+      }
+    },
+    {
+      "plugin": "@nx/gradle",
+      "options": {
+        "classesTargetName": "classes",
+        "buildTargetName": "build",
+        "testTargetName": "test",
+        "ciTargetName": "test-ci"
+      }
+    }
+  }
+}
+```
+
+The `test-ci` and `e2e-ci` targets will automatically be split into the following format:
+
+- `e2e-ci--path/to/test/file`
+- `test-ci--path/to/test/file`
+
+Or more generically:
+
+- `{ciTargetName}--{path/to/test/file}`
+
+You can find more information on how to configure the Atomizer on the respective [Jest](/nx-api/jest#splitting-e2e-tests), [Cypress](/nx-api/cypress#nxcypress-configuration), [Playwright](/nx-api/playwright#nxplaywright-configuration), [Gradle](/nx-api/gradle/documents/overview#nxgradle-configuration) or follow [this recipe](/extending-nx/recipes/project-graph-plugins) to create your own inferred plugin.
+
+## Manual E2E Project Splitting
+
+In addition to automated splitting like sharding or atomization, manually splitting E2E projects into scopes can provide additional significant performance benefits.
+
+Let's look at the simplified graph below:
+![Nx graph with single application, e2e project and several libraries](/blog/images/articles/single-e2e-project.avif)
+
+Our E2E project contains tests for each of the application features - products, orders and checkout. Any change made in the graph will cause all our E2E tests to be re-run. Even if we only modified `products`, we will still re-run the tests for `orders` and `checkout`. Although the Atomizer will help us split that work per file and distribute it, we will still end up running unnecessary work.
+
+By defining scopes that implicitly depend on feature libraries rather than the entire application, you can ensure that only relevant tests are run when changes are made.
+
+- **Scope Definition**: Break down your E2E tests into smaller, focused scopes.
+- **Dependency Management**: Ensure that scopes depend on specific feature libraries, reducing unnecessary test execution.
+
+![Nx graph with several e2e applications depending on different scopes of the application](/blog/images/articles/manually-split-e2e-projects.avif)
+
+This approach offers both speed of distribution and caching efficiency. Every time the application is affected, we will only run the small subset of sanity smoke tests to ensure the application still runs, but specific features will only be tested if the relevant feature library has been modified or affected and skipped otherwise.
+
+The tricky part comes from the fact that our split E2E applications still depend on the full application being served. But using the combination of `implicitDependencies` and `dependsOn` we can ensure that the application is running for our E2E tests without explicitly depending on it.
+
+```json {% fileName="libs/checkout-e2e/project.json" %}
+{
+  ...
+  "implicitDependencies": ["checkout"],
+  "targets": {
+    "e2e": {
+      "dependsOn": ["^build", { "target": "build", "projects": "app" }]
+    }
+  }
+}
+```
+
+When we look at the graph, we will only see an edge from `checkout-e2e` to `checkout`, but having an explicit `dependsOn` `app:build` ensures that the build of the application was successful and the distributed agent running our E2E task has app's build cache replayed.
+
+As of Nx version `20.8.0` you can now combine manual splitting with the Atomizer. In order to split atomized projects, we will have to override their `dependsOn` property to target also `app:build`:
+
+```json {% fileName="libs/checkout-e2e/project.json" %}
+{
+  ...
+  "implicitDependencies": ["checkout"],
+  "targets": {
+    "e2e": {
+      "dependsOn": ["^build", { "target": "build", "projects": "app" }]
+    },
+    "e2e-ci--**/**": {
+      "dependsOn": ["^build", { "target": "build", "projects": "app" }]
+    }
+  }
+}
+```
+
+This small improvement gives us best of both worlds - using the Atomizer to automatically split long running tasks into smaller chunks and using manual splitting to skip entire work if dependencies haven't change.
+
+## Conclusion
+
+By implementing these techniques — the built-in test sharding, Nx Atomizer, and manual E2E project splitting — you can significantly cut down CI time. That means fewer bottlenecks, less time waiting on pipelines, and more time spent delivering features, fixing bugs, and improving the product. When CI runs faster, teams can iterate quickly, merge with confidence, and ship value to users without the drag of slow test cycles.
+
+Faster CI is just the beginning. When combined with Nx Cloud's distributed task execution, these strategies not only bring stability and improved performance but also offer better developer ergonomics and a comprehensive overview of your testing processes. This powerful combination allows your team to ship with greater confidence.
+
+Give these techniques a try and see the difference for yourself.
+
+{% 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." /%}

docs/blog/2025-04-17-nx-and-ai-why-they-work-together.md

@@ -0,0 +1,190 @@
+---
+title: 'Nx and AI - Why They Work so Well Together'
+slug: nx-and-ai-why-they-work-together
+authors: ['Victor Savkin']
+tags: ['nx', 'ai', 'monorepo']
+cover_image: /blog/images/articles/bg-nx-and-ai-powered-dev.avif
+description: 'Explore how Nx monorepos amplify AI benefits by providing complete context and consistent tooling, creating a growing competitive advantage for enterprise development.'
+---
+
+{% callout type="deepdive" title="Series: Making your LLM smarter" expanded=true %}
+
+- [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**
+
+{% /callout %}
+
+**TLDR:**
+
+1. **Monorepos Amplify AI Benefits**: Monorepos inherently enhance the utility of coding assistants by providing complete context, creating a growing competitive advantage.
+2. **Consistency is Key**: The primary challenge with AI coding assistants is maintaining consistency and reliability. This affects both AI and human developers' future effectiveness, but can be mitigated with Nx capabilities.
+3. **Integrated Tooling**: Tools connecting CI, editors, and coding assistants create powerful development workflows.
+4. **Mitigated Downsides**: Traditional monorepo disadvantages (like the necessity for large-scale code changes) can be effectively addressed with agentic AI.
+5. **Cross-Repository Context**: Benefits extend beyond single repositories to connected repositories using Nx Cloud Polygraph.
+
+{% toc /%}
+
+{% call-to-action title="Are Monorepos the Answer to Better AI-Assisted Development?" url="https://go.nx.dev/april2025-webinar" description="Upcoming webinar: save your spot" /%}
+
+## It's All About Context
+
+> _"Context is worth 80 IQ points." — Alan Kay_
+
+Why do tools like Bolt.new work so well for streamers and indie developers bootstrapping new projects but not so much for enterprise developers that work on an existing large codebase? The answer is context. With Bolt, an LLM can access the entire context of a smaller repo, making local changes with short-term considerations.
+
+Enterprise systems present a different challenge:
+
+- Highly complex and interdependent
+- Built by hundreds of engineers over many years
+- Often spread across hundreds of repositories
+- Integrated with numerous external systems
+
+In these environments, **LLMs lack the necessary context to make changes that account for all considerations**. Like human developers, LLMs struggle with complex systems, but unlike humans, they don't have tacit knowledge from wikis, meetings, or informal conversations. As a result, they only see a small fraction of the system.
+
+![LLMs with limited context can only see a small fraction of the system](/blog/images/articles/nx-ai-limited-context-problem.avif)
+
+LLMs rely entirely on provided context. Because monorepos consolidate all code in one place, they fundamentally improve contextual access. However, **raw code access isn't enough. It's analogous to navigating a city using only street view.** This makes it unlikely to pick optimal routes.
+
+![Navigating code with raw access only is like using street view without a map](/blog/images/articles/nx-ai-street-view-problem.avif)
+
+**What's needed is a "map" of your codebase and organization. Nx via its plugins builds this "map".** It includes:
+
+1. High-level repository structure
+2. System architecture
+3. Organizational structure and ownership
+4. Information about used tools, frameworks, their versions and dependencies
+5. CI information (frequency, failures)
+
+This information is used to make CI execution fast, to ensure boundaries, and now **Nx provides this information to [coding assistants through MCP servers](/features/enhance-AI), enabling LLMs to answer questions like**:
+
+- "Who should I consult about creating a new bank library for overdraft payments?"
+- "Create a library using the bank team's best practices."
+- "Identify and suggest fixes for circular dependencies."
+- "Which shared libraries does the overdraft library depend on? Which teams own them?"
+- "Which projects owned by my team fail frequently in CI? Which ones affect other teams' work?"
+
+![Nx provides a 30,000-foot view map of your entire system](/blog/images/articles/nx-ai-map-view-visualization.avif)
+
+With this map, Nx provides a "30,000-foot view" of the entire system (architecture, organization, CI). Coding assistants are able to read relevant files and see the 0-foot view. This combination creates very powerful interactions.
+
+But we are working on providing a "10,000-foot view" by compressing relevant content about projects and project clusters in the repository. Another way to think of this is **"d.ts" files for AI coding assistants**. With this, your coding assistant is able to jump between different abstraction levels to get relevant information.
+
+![Different abstraction levels help AI understand your codebase better](/blog/images/articles/nx-ai-abstraction-levels.avif)
+
+## Beyond Speed: Writing Correct and Consistent Code
+
+> _"It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward." — Chinese Proverb_
+
+Research shows enterprise developers commit only 20-30 lines of code daily. The bottleneck isn't coding speed but determining the correct approach to minimize technical debt and long-term impact.
+
+Enterprise developers spend 90%+ of their time not actively writing code. **LLMs excel at generating code, and if that's what they are used for, they can only help with that 10% of the development process.**
+
+To realize substantial gains we need to:
+
+1. Enable LLMs to help with the 90% by providing better context (see section above)
+2. Ensure generated code is correct, consistent with the organization's best practices, and doesn't introduce technical debt
+
+Without these considerations, you might be 5x more productive in the first month but progressively slower throughout the year due to accumulated technical debt. So you might not even break even.
+
+### Consistency Through Best Practices and Metadata
+
+One way to minimize technical debt is by codifying and reusing best practices:
+
+**Human Approach**:
+
+- Senior developers examine feature libraries from the bank team
+- They identify common patterns and create a local plugin with a generator
+- They teach other developers about the new generator
+
+**LLM Approach**:
+
+- Developers ask LLM powered by Nx to extract common patterns from all bank libraries
+- LLM creates a local plugin with a generator for bank libraries
+- Developer refines the generator
+- Another developer requests a new bank feature library
+- LLM finds and runs the new generator in dry-run mode for confirmation
+- LLM can open a generator UI for parameter tweaking
+- Developer selects parameters and generates code
+- LLM picks it up and offers additional customization
+
+You don't have to create libraries reflecting organization's best practices. Nx plugins come with many generators.
+
+The reason why this approach works with Nx is that everything in Nx (including [its generators](/features/generate-code)) comes with a lot of static metadata. Traditionally this metadata was used to power the terminal UI, graphic UI, docs and more. Turns out it's also extremely useful for LLMs. **With this metadata they know all the inputs into each generator and what each of them does. But it gets better! Nx's virtual file system lets LLMs run the generators in dry run mode to get the generator outputs.** With this, LLMs can derive which generators work well with which parameters. **Additional metadata specifically designed for LLMs is being added.**
+
+LLMs excel at impressive demonstrations but struggle with consistency and correctness. This is why they work better for new applications where correctness is loosely defined and consistency is not important. Being able to access a large library of annotated generators helps LLMs reduce variability of what they generate, which improves consistency and quality. They use a generator and make some small modifications on top instead of trying to author everything from scratch.
+
+### Migrations
+
+[Nx Migrations](/features/automate-updating-dependencies) are special generators that update codebases to use newer tool versions and new APIs. AI agents can enhance this process with specialized metadata for validation and fixes.
+
+### Human in the Loop
+
+Human oversight remains crucial as AI is good at being "almost correct." Having a human in the loop, especially for high-impact operations, helps with the need to correct what LLMs generate. Nx offers a tool that lets LLMs open the generator UI and allows the developer to customize and preview what will be generated.
+
+## The Integrated Development Advantage: Multiplying AI's Power
+
+> _"The whole is greater than the sum of its parts." — Aristotle_
+
+The utility of your coding assistant goes up significantly as the number of tools it can access increases, which includes the rest of your editor and IDE and your local tools. Nx has always believed in this, and that's why we always put so much effort into our VSCode and IntelliJ plugins. The bet paid off. With agentic AI being available, the value of those plugins is going up 10x.
+
+This is the sketch I drew a while back, and we have been moving toward this vision:
+
+![Integrated development tools and AI systems working together seamlessly](/blog/images/articles/nx-ai-integrated-tools-vision.avif)
+
+**These are some of the things Nx either already does or is about to do in the next couple of weeks:**
+
+1. Coding assistants can open and manipulate the [Nx project graph visualization](/features/explore-graph).
+2. Coding assistants are able to open the generation UI, prefill the right values.
+3. Coding assistants are able to fetch up-to-date docs to ensure they don't hallucinate.
+4. Coding assistants get notified about CI execution results while the CI is still running. The assistant gets relevant logs and files and is able to explain or fix the CI error and push changes before the CI execution even completes.
+5. Coding assistants will integrate with the new Nx interactive UI so they can see what the developer sees and are able to address issues while the Nx command is still running. **Tell the LLM to fix the error, and it will know what error you are looking at.**
+
+## From Pain Points to Power Moves
+
+> _"What was once impossible becomes merely difficult; what was difficult becomes easy; and what was easy becomes elegant." — Alan Kay_
+
+Monorepos offer many benefits but come with caveats. The main concern is managing large-scale changes across the repository, such as updating all applications to the latest React version.
+
+Nx has always addressed this with ["migrations" - specialized generators](/features/automate-updating-dependencies) optimized for such tasks. Typically, migrations handle 80% of the work, with the remaining 20% potentially taking weeks for a small team in large repos.
+
+This is precisely where agentic coding assistants excel. **By building on Nx's migration capabilities, AI increases completion from 80% to a much higher percentage, reducing effort from weeks to days or even hours.** What was difficult becomes easy.
+
+The ability to update all code simultaneously is also a significant benefit of monorepos. Small changes like renaming can be executed in a single step, eliminating entire classes of "breaking" changes. Your code is less defensive. This is a huge advantage preventing your code from becoming stale. It's a form of economy of scale, where you can make a code cleanup for a dozen applications in a time that is a tiny fraction of what it would have taken if they were in separate repos.
+
+**Agentic coding assistants significantly expand the range of "reliable transformations" that can be done quickly, turning what were before long refactorings into minutes-long tasks. With this, the delta between what you can do in a monorepo compared to a polyrepo gets substantially more significant.**
+
+## Repository Interconnectedness: Breaking Down the Final Silos
+
+> _"Silos create boundaries. Networks create possibilities." — Anonymous_
+
+This document was about Nx monorepos. But most organizations using Nx have dozens or hundreds of Nx repos and oftentimes hundreds or thousands of other repos as well. Because we recognize this reality, we built **Nx Polygraph** (available for [Nx Enterprise users](/enterprise)) which lets you connect multiple repositories into a federated meta-repo. With this, you will get some of the advantages outlined in this document in H1 2025.
+
+## The Long View: Designing for AI's Continued Evolution
+
+_"The path of technological progress is neither random nor accidental, but follows paths of least resistance toward inevitable destinations." — Kevin Kelly_
+
+Some might argue that coding assistants aren't that reliable now and perhaps some of the benefits aren't realizable. A lot of it is new ([VSCode MCP support is a few weeks old](/blog/nx-mcp-vscode-copilot)) so we are working hard to provide the necessary context to them, and not everything at this point is as good as it should be. What matters though is not the current state but the direction.
+
+**Many advantages are inherent to Nx's approach:**
+
+- Consolidating information
+- Providing a navigable "map" of the codebase
+- Using metadata-driven generators and migrations that are inherently LLM-friendly
+- Enabling large-scale transformations in a monorepo
+
+Although it's not entirely impossible, it is significantly harder to provide the same advantages in a polyrepo where information isn't consolidated, where there is no "map", where there is no codification of best practices, where cross-cutting code changes are effortful and non-atomic.
+
+**The trajectory is clear: monorepos with tools like Nx are positioned to leverage AI capabilities more effectively as the technology evolves.**
+
+---
+
+Learn more:
+
+- 🧠 [Nx AI Docs](/features/enhance-AI)
+- 📖 [Nx MCP Now Available for VS Code Copilot](/blog/nx-mcp-vscode-copilot)
+- 👩‍💻 [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)

docs/blog/2025-04-21-nx-cloud-update-april-2025.md

@@ -0,0 +1,100 @@
+---
+title: 'Nx Cloud Update - Assignment rules come out of beta and more!'
+slug: nx-cloud-update-april-2025
+authors: ['Philip Fulcher']
+tags: ['nx-cloud']
+cover_image: /blog/images/2025-04-21/header.avif
+description: 'Nx Cloud updates for April 2025 include assignment rules coming out of beta, CIPE filters, flaky retry configuration, and more!'
+youtubeUrl: https://youtu.be/mug02alT7rQ
+---
+
+We're rolling out updates to Nx Cloud constantly, so we wanted to bring you up to date with what we've been working on lately.
+
+{% toc /%}
+
+## Assignment Rules come out of beta
+
+In your CI pipeline, you've got some tasks of different sizes. Some tasks are quick, like linting or format checking, but you've got more resource-intensive tasks like building apps or running e2e suites. Your smaller tasks can run on a small agent with fewer CPU cores or less memory, but your larger tasks need a larger agent.
+
+But when you're spreading tasks across multiple agents, it's inefficient to increase the size of all the agents to accommodate your larger tasks. So ideally, you have smaller agents for small tasks and larger agents for your larger tasks. But how do you make sure tasks get assigned to the right agent?
+
+Many CI tools have ways of handling this, but we wanted to make things easier. That's why Nx Cloud now has [Assignment Rules](/ci/reference/assignment-rules). This configuration allows you to control which tasks are assigned to certain agents.
+
+Let's take a look at a quick example for [Nx Agents](/ci/features/distribute-task-execution):
+
+```yaml {% fileName=".nx/workflows/distribution-config.yaml" /%}
+# Create five agents using the `linux-medium-js` launch template and five agents using `linux-large-js`
+distribute-on:
+  default: 5 linux-medium-js, 5 linux-large-js
+
+assignment-rules:
+  # for our `app1` projects...
+  - projects:
+      - app1
+    # for targets beginning with "e2e-ci"...
+    targets:
+      - e2e-ci*
+    # and using the `production` configuration
+    configurations:
+      - production
+    # run matching tasks on a `linux-medium-js` agent with parallelism set to 5
+    run-on:
+      - agent: linux-medium-js
+        parallelism: 5
+
+  # for lint and build tasks on any project
+  - targets:
+      - lint
+      - build
+    # run matching tasks on a `linux-large-js` agent with parallelism set to 10
+    run-on:
+      - agent: linux-large-js
+        parallelism: 10
+```
+
+As you can see, there's a lot of flexibility in the configuration here to fine-tune your agent assignments.
+
+We're so excited about this feature that we've built it to work with both [Agents](/ci/features/distribute-task-execution) and [Manual DTE](/ci/recipes/dte/github-dte). So, no matter how you're distributing tasks using Nx Cloud, you can use this new feature! Be sure to [check the docs](/ci/reference/assignment-rules) for more details.
+
+We're also providing a new UI that tells you exactly what tasks are being run on which agents and the rules impacting them.
+
+![Screenshot of UI showing how assignment rules are affecting tasks](/blog/images/2025-04-21/assignment-rules-viz.avif)
+
+## Find your CIPEs with better filtering
+
+![Screenshot of UI showing filters for CIPEs view](/blog/images/2025-04-21/cipe-filters.avif)
+
+Having trouble finding a CI Pipeline Execution (CIPE)? We've added new filter options for the CIPEs list. You can now filter by committer, branch, or date range. You can even sort by duration to help find your longest CIPEs.
+
+## Control how flaky task retries work with your workspace
+
+![Screenshot of UI showing configuration options for flaky task retries](/blog/images/2025-04-21/flaky-retries.avif)
+
+Flaky retries are great at unblocking your CI pipelines by automatically retrying tasks that Nx Cloud detects as flaky. This means you spend less time re-running CI pipelines when you have a task that passes sometimes and fails other times. You now have more control over this process. You can fine-tune how Nx Cloud retries tasks, specify a time range when flakiness is determined, or even turn it off entirely. This helps optimize when tasks are retried so you can control resource use and CI cost.
+
+## Request access to protected views
+
+![Screenshot of UI showing an option to request access to a protected resource](/blog/images/2025-04-21/request-access.avif)
+
+Access control is important, but it can be time-consuming to give the right access to the right people. Now, users can request access with a simple button click, and an admin will be alerted to adjust their access. This automated process saves your team time by not having to send another email or submit a support ticket for access.
+
+## Nx Agents supports custom GitHub domains
+
+![Screenshot of UI showing how to use a custom GitHub URL for Nx Agents](/blog/images/2025-04-21/github-url.avif)
+
+Using GitHub Enterprise and having a custom URL? Nx Agents now works with these custom domains, check for the option to override your domain during setup.
+
+{% call-to-action title="Not using Nx Cloud yet?" url="https://cloud.nx.app/get-started/?utm_source=nx-dev" icon="nxcloud" description="Get started now for free!" /%}
+
+---
+
+## Learn more
+
+- [Nx Cloud Docs](/ci)
+- [Nx Docs](/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools)
+- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](/nx-cloud)

docs/blog/2025-04-30-are-monorepos-the-answer-to-better-aiassisted-development.md

@@ -0,0 +1,20 @@
+---
+title: 'Are Monorepos the Answer to Better AI-Assisted Development?'
+description: 'In this webinar, Nx CTO Victor Savkin and Senior Engineer Max Kless will break down **why monorepos are inherently more AI-friendly**, giving LLMs the full context they need to generate more accurate, actionable insights. You’ll also learn how Nx provides deep architectural awareness, making AI tools smarter and more effective.'
+date: 2025-04-16
+slug: 'are-monorepos-the-answer-to-better-aiassisted-development'
+authors: ['Victor Savkin', 'Max Kless']
+tags: [webinar]
+cover_image: /blog/images/2025-04-30/April-2025-Webinar-Card.png
+time: 10:30am ET/2:30pm UTC
+status: Upcoming
+registrationUrl: https://go.nx.dev/april2025-webinar
+---
+
+**Apr 30, 2025 - 10:30am ET/2:30pm UTC**
+
+Presented by Victor Savkin and Max Kless
+
+In this webinar, Nx CTO Victor Savkin and Senior Engineer Max Kless will break down **why monorepos are inherently more AI-friendly**, giving LLMs the full context they need to generate more accurate, actionable insights. You’ll also learn how Nx provides deep architectural awareness, making AI tools smarter and more effective.
+
+{% call-to-action title="Register today!" url="https://go.nx.dev/april2025-webinar" description="Save your spot" /%}

docs/blog/authors.json

@@ -141,5 +141,23 @@
     "image": "/blog/images/Nicolas Beaussart.jpeg",
     "twitter": "beaussan",
     "github": "beaussan"
+  },
+  {
+    "name": "Nicole Oliver",
+    "image": "/blog/images/Nicole Oliver.jpeg",
+    "twitter": "nixcodes",
+    "github": "nixallover"
+  },
+  {
+    "name": "Rareș Matei",
+    "image": "/blog/images/Rareș Matei.jpeg",
+    "twitter": "__rares",
+    "github": "rarmatei"
+  },
+  {
+    "name": "James Henry",
+    "image": "/blog/images/James Henry.jpeg",
+    "twitter": "MrJamesHenry",
+    "github": "JamesHenry"
   }
 ]