fix(core): retry interrupted errors when writing to stdout (#23359)

<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->

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

## Current Behavior
<!-- This is the behavior we have today -->

## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->

## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->

Fixes #

(cherry picked from commit 1acbc7e555)

.circleci/config.yml

@@ -69,50 +69,6 @@ commands:
             - ~/.pnpm-store
             - ~/.cache/Cypress
             - node_modules
-  install-sdkman:
-    description: Install SDKMAN
-    steps:
-      - restore_cache:
-          name: Restore SDKMAN executable and binaries from cache
-          keys:
-            - sdkman-cli-{{ arch }}-v2
-      - run:
-          name: Installing SDKMAN
-          command: |
-            if [ ! -d ~/.sdkman ]
-            then
-              curl -s "https://get.sdkman.io?rcupdate=false" | bash
-              sed -i -e 's/sdkman_auto_answer=false/sdkman_auto_answer=true/g' ~/.sdkman/etc/config
-            fi
-            echo -e '\nsource "/home/circleci/.sdkman/bin/sdkman-init.sh"' >> $BASH_ENV
-            source $BASH_ENV
-            sdk version
-      - save_cache:
-          name: Save SDKMAN executable and binaries to cache
-          key: sdkman-cli-{{ arch }}-v2
-          paths:
-            - ~/.sdkman
-  install-gradle:
-    description: Install gradle
-    parameters:
-      gradle-version:
-        type: string
-        default: ''
-    steps:
-      - restore_cache:
-          name: Restore Gradle binary from cache
-          keys:
-            - gradle-cli-{{ arch }}-v1
-      - run:
-          name: Installing Gradle
-          command: |
-            sdk install gradle << parameters.gradle-version >>
-            gradle --version
-      - save_cache:
-          name: Save Gradle binary to cache
-          key: gradle-cli-{{ arch }}-v1
-          paths:
-            - ~/.sdkman/candidates/gradle/
 # -------------------------
 #          JOBS
 # -------------------------
@@ -140,10 +96,6 @@ jobs:
             sudo apt-get update
             sudo apt-get install -y ca-certificates lsof
       - browser-tools/install-chrome
-      - browser-tools/install-chromedriver
-      - install-sdkman
-      - install-gradle:
-          gradle-version: '8.5'
       - run-pnpm-install:
           os: linux
       - run:

.eslintrc.base.json

@@ -1,35 +0,0 @@
-{
-  "root": true,
-  "ignorePatterns": ["**/*"],
-  "plugins": ["@nx"],
-  "overrides": [
-    {
-      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
-      "rules": {
-        "@nx/enforce-module-boundaries": [
-          "error",
-          {
-            "enforceBuildableLibDependency": true,
-            "allow": [],
-            "depConstraints": [
-              {
-                "sourceTag": "*",
-                "onlyDependOnLibsWithTags": ["*"]
-              }
-            ]
-          }
-        ]
-      }
-    },
-    {
-      "files": ["*.ts", "*.tsx"],
-      "extends": ["plugin:@nx/typescript"],
-      "rules": {}
-    },
-    {
-      "files": ["*.js", "*.jsx"],
-      "extends": ["plugin:@nx/javascript"],
-      "rules": {}
-    }
-  ]
-}

.github/workflows/e2e-matrix.yml

@@ -55,6 +55,11 @@ jobs:
           path: '**/node_modules'
           key: ${{ runner.os }}-modules-${{ matrix.node_version }}-${{ github.run_id }}
 
+      - name: Ensure Python setuptools Installed on Macos
+        if: ${{ matrix.os == 'macos-latest' }}
+        id: brew-install-python-setuptools
+        run: brew install python-setuptools
+
       - name: Install packages
         if: steps.cache-modules.outputs.cache-hit != 'true'
         run: pnpm install --frozen-lockfile
@@ -403,7 +408,7 @@ jobs:
         timeout-minutes: 15
 
   process-result:
-    if: ${{ always() }}
+    if: ${{ always() && github.repository_owner == 'nrwl' }}
     runs-on: ubuntu-latest
     needs: e2e
     outputs:

.github/workflows/schedule-stale.yml

@@ -4,7 +4,7 @@ on:
 
 name: Stale Bot workflow
 
-permissions: {}
+permissions: { }
 
 jobs:
   build:
@@ -16,163 +16,96 @@ jobs:
     name: stale
     runs-on: ubuntu-latest
     steps:
+      # This handles issues that need more info
       - name: stale-more-info-needed
         id: stale-more-info-needed
-        uses: actions/stale@v3.0.13
+        uses: actions/stale@v9.0.0
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 14
-          days-before-close: 14
+          days-before-stale: 7
+          days-before-close: 21
           stale-issue-label: "stale"
           operations-per-run: 300
           remove-stale-when-updated: true
           only-labels: "blocked: more info needed"
           stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
+            This issue has been automatically marked as stale because more information has not been provided within 7 days.
+            It will be closed in 21 days if no information is provided.
+            If information has been provided, please reply to keep it active.
             Thanks for being a part of the Nx community! 🙏
 
+      # This handles PRs that need to be rebased
       - name: stale-needs-rebase
         id: stale-needs-rebase
-        uses: actions/stale@v3.0.13
+        uses: actions/stale@v9.0.0
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 14
-          days-before-close: 14
+          days-before-stale: 7
+          days-before-close: 21
           stale-issue-label: "stale"
           operations-per-run: 300
           remove-stale-when-updated: true
           only-labels: "blocked: needs rebased"
           stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
+            This PR has been automatically marked as stale because it has not been rebased in 7 days.
+            It will be closed in 21 days if it is not rebased.
+            If the PR has been rebased or you are working on rebasing it, please reply to keep it active.
+            If you do not have time, please let us know and we can rebase it.
             Thanks for being a part of the Nx community! 🙏
 
+      # This handles issues that do not have a repro
       - name: stale-repro-needed
         id: stale-repro-needed
-        uses: actions/stale@v3.0.13
+        uses: actions/stale@v9.0.0
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 14
-          days-before-close: 14
+          days-before-stale: 7
+          days-before-close: 21
           stale-issue-label: "stale"
           operations-per-run: 300
           remove-stale-when-updated: true
           only-labels: "blocked: repro needed"
           stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
+            This issue has been automatically marked as stale because no reproduction was provided within 7 days.
+            Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue.
+            Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues.
+            This issue will be closed in 21 days if a reproduction is not provided.
+            If a reproduction has been provided, please reply to keep it active.
             Thanks for being a part of the Nx community! 🙏
 
       - name: stale-retry-with-latest
         id: stale-retry-with-latest
-        uses: actions/stale@v3.0.13
+        uses: actions/stale@v9.0.0
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 14
-          days-before-close: 14
+          days-before-stale: 7
+          days-before-close: 21
           stale-issue-label: "stale"
           operations-per-run: 300
           remove-stale-when-updated: true
           only-labels: "blocked: retry with latest"
           stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
+            This issue has been automatically marked as stale because no results of retrying on the latest version of Nx was provided within 7 days.
+            It will be closed in 21 days if no results are provided.
+            If the issue is still present, please reply to keep it active.
+            If the issue was not present, please close this issue.
             Thanks for being a part of the Nx community! 🙏
 
 
+      # This handles issues are really old and were made with a previous major
       - name: stale-bug
         id: stale-bug
-        uses: actions/stale@v3.0.13
+        uses: actions/stale@v9.0.0
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
           days-before-stale: 180
-          days-before-close: 14
+          days-before-close: 21
           stale-issue-label: "stale"
           operations-per-run: 300
           remove-stale-when-updated: true
-          only-labels: "type: bug"
           stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
-            Thanks for being a part of the Nx community! 🙏
-
-      - name: stale-cleanup
-        id: stale-cleanup
-        uses: actions/stale@v3.0.13
-        with:
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 180
-          days-before-close: 14
-          stale-issue-label: "stale"
-          operations-per-run: 300
-          remove-stale-when-updated: true
-          only-labels: "type: cleanup"
-          stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
-            Thanks for being a part of the Nx community! 🙏
-
-      - name: stale-docs
-        id: stale-docs
-        uses: actions/stale@v3.0.13
-        with:
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 180
-          days-before-close: 14
-          stale-issue-label: "stale"
-          operations-per-run: 300
-          remove-stale-when-updated: true
-          only-labels: "type: docs"
-          stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
-            Thanks for being a part of the Nx community! 🙏
-
-      - name: stale-enhancement
-        id: stale-enhancement
-        uses: actions/stale@v3.0.13
-        with:
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 250
-          days-before-close: 14
-          stale-issue-label: "stale"
-          operations-per-run: 300
-          remove-stale-when-updated: true
-          only-labels: "type: enhancement"
-          stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
-            Thanks for being a part of the Nx community! 🙏
-
-      - name: stale-feature
-        id: stale-feature
-        uses: actions/stale@v3.0.13
-        with:
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 250
-          days-before-close: 14
-          stale-issue-label: "stale"
-          operations-per-run: 300
-          remove-stale-when-updated: true
-          only-labels: "type: feature"
-          stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
-            Thanks for being a part of the Nx community! 🙏
-
-      - name: stale-question
-        id: stale-question
-        uses: actions/stale@v3.0.13
-        with:
-          repo-token: ${{ secrets.GITHUB_TOKEN }}
-          days-before-stale: 45
-          days-before-close: 14
-          stale-issue-label: "stale"
-          operations-per-run: 300
-          remove-stale-when-updated: true
-          only-labels: "type: question / discussion"
-          stale-issue-message: |
-            This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
-            If we missed this issue please reply to keep it active.
+            This issue has been automatically marked as stale because it hasn't had any activity for 6 months.
+            Many things may have changed within this time. The issue may have already been fixed or it may not be relevant anymore.
+            If at this point, this is still an issue, please respond with updated information.
+            It will be closed in 21 days if no further activity occurs.
             Thanks for being a part of the Nx community! 🙏

.nx/workflows/agents.yaml

@@ -21,8 +21,6 @@ launch-templates:
             ~/.cache/Cypress
             ~/.cache/ms-playwright
             ~/.pnpm-store
-            ~/.sdkman
-            ~/.sdkman/candidates/gradle
           BASE_BRANCH: 'master'
       - name: Install e2e deps
         script: |
@@ -57,18 +55,3 @@ launch-templates:
 
       - name: Install zip and unzip
         script: sudo apt-get -yqq install zip unzip
-
-      - name: Install SDKMAN and gradle
-        script: |
-          if [ ! -d $HOME/.sdkman ]
-          then
-            curl -s "https://get.sdkman.io" | bash
-            source "$HOME/.sdkman/bin/sdkman-init.sh"
-          fi
-          sdk version
-          if [ ! -d $HOME/.sdkman/candidates/gradle/8.5 ]
-          then
-            sdk install gradle 8.5
-          fi
-          gradle --version
-          echo "PATH=$HOME/.sdkman/candidates/gradle/8.5/bin:$PATH" >> $NX_CLOUD_ENV

community/approved-plugins.json

@@ -29,6 +29,11 @@
     "description": "Nx plugin integrations with Vite.",
     "url": "https://nx-plugins.netlify.app/"
   },
+  {
+    "name": "nx-serverless-cdk",
+    "description": "Create CDK applications and construct libraries. Test and debug infrastructure code and AWS Lambda functions locally.",
+    "url": "https://github.com/castleadmin/nx-plugins/tree/main/nx-serverless-cdk/plugin"
+  },
   {
     "name": "@ago-dev/nx-aws-cdk-v2",
     "description": "An nx plugin for the aws-cdk v2.",
@@ -473,5 +478,10 @@
     "name": "@getlarge/nx-heroku",
     "description": "Plugin to deploy and promote Nx apps on Heroku",
     "url": "https://github.com/getlarge/nx-heroku"
+  },
+  {
+    "name": "@huge-nx/conventions",
+    "description": "Plugin to generate and manage Nx workspaces by adhering to established workspace conventions.",
+    "url": "https://github.com/jogelin/huge-nx"
   }
 ]

docs/blog/2023-04-19-nx-cloud-3.md

@@ -0,0 +1,121 @@
+---
+title: Nx Cloud 3.0 — Faster Cache, More Powerful DTE, Better Ergonomics
+authors: [Juri Strumpflohner]
+cover_image: '/blog/images/2023-04-19/featured_img.webp'
+tags: [nx, nx-cloud]
+---
+
+It has been almost 2 years since we released [Nx Cloud 2.0](https://nx.app/). Since then, it has saved over 400 years of computation by leveraging its distributed caching and task execution. And we keep adding 8 years every single week. Not only does this tremendously [impact our environment](https://dev.to/nx/helping-the-environment-by-saving-two-centuries-of-compute-time-4nep), but it also helps developers be more productive and companies save money.
+
+In the last couple of months we have quadrupled the team and have done some amazing things. And we have some big plans for what is coming next. Here’s all you need to know!
+
+**Table of Contents**
+
+- [New, Streamlined UI](#new-streamlined-ui)
+- [Prefetching and Faster Cache Uploading](#prefetching-and-faster-cache-uploading)
+- [DTE Just got Better](#dte-just-got-better)
+- [Direct Integration With GitHub, GitLab and Bitbucket](#direct-integration-with-github-gitlab-and-bitbucket)
+- [Enterprise Support](#enterprise-support)
+- [New, Simplified Plans and Pricing Model](#new-simplified-plans-and-pricing-model)
+- [Coming Next](#coming-next)
+- [Learn more](#learn-more)
+
+**Prefer a Video? We’ve got you Covered!**
+
+{% youtube src="https://www.youtube.com/embed/cG2hEI5L3qI?si=9frDSD8_HK1iTNEi" /%}
+
+## New, Streamlined UI
+
+This latest release of Nx Cloud comes with a new, streamlined design that offers users a more modern and visually appealing experience. This includes the main [Nx Cloud website](https://nx.app/), where we improved our messaging, including interactive visualizations to better explain some core concepts around remote caching and distributed task execution.
+
+![](/blog/images/2023-04-19/bodyimg1.webp)
+
+The Nx Cloud application — showing your runs, cache saved, and stats — also got a significant overhaul, making the UI more lightweight and easier to parse.
+
+![](/blog/images/2023-04-19/bodyimg2.webp)
+
+More UI-related updates and improvements are already underway.
+
+## Prefetching and Faster Cache Uploading
+
+![](/blog/images/2023-04-19/bodyimg3.webp)
+
+At Nx, we are performance addicts! Especially when it comes to local development, every millisecond counts! In the latest update of the Nx CLI, we added the ability to **offload some of the remote cache management to the [Nx Daemon](/concepts/nx-daemon)**. As a result you no longer have to wait for the cache to upload. This saves valuable time, allowing the command to complete instantly and immediately providing you with the necessary link.
+We also **prefetch cache results in the background** to have them ready when needed.
+
+Both optimizations can save seconds.
+
+## DTE Just got Better
+
+![](/blog/images/2023-04-19/bodyimg4.webp)
+
+[Distributed Task Execution (short DTE)](/ci/features/distribute-task-execution) is a core part of what makes Nx Cloud stand out compared to other solutions. And we made some significant improvements to both the ergonomics and speed.
+
+**Identify failed tasks early** — You can now view information about the in-progress DTEs, allowing you to quickly identify and address any failed functions without waiting for the command to complete.
+
+**Simplified CI setup** — We simplified the setup process for most CI systems, eliminating the need to pass environment variables manually. Instead, everything is automatically derived from the context.
+
+**Improved performance and efficiency** — Nx Cloud now intelligently figures out which tasks will be cache hits before sending them to agents. Rather it can directly send them to the main job, reducing unnecessary round trips and drastically speeding up CI runs.
+
+**Efficient agent management** — We have introduced a new command, `npx nx-cloud start-ci-run –stop-agents-after=e2e`, that allows you to notify Nx Cloud when specific commands, such as long-running e2e tasks, have started. This helps Nx Cloud proactively identify and shut down agents that will not be needed, improving compute efficiency.
+
+**Reduce fix costs** — Even though cache hits are basically free, spinning processes still have fixed costs. We fixed that (see what I did there) by leveraging a new Nx feature that allows to have a long-running process on an agent to which we can arbitrarily feed new tasks. This removed the DTE overheads and also improved the predictability of runs.
+
+## Direct Integration With GitHub, GitLab and Bitbucket
+
+Our GitHub integration has been enhanced. Now, the list of runs is updated in real-time as soon as they are created or their status changes, providing developers with up-to-date information directly on GitHub.
+
+![](/blog/images/2023-04-19/bodyimg5.webp)
+
+In addition to the GitHub, we expanded our Nx Cloud live status updates to work on GitLab and BitBucket.
+
+![](/blog/images/2023-04-19/bodyimg6.webp)
+
+## Enterprise Support
+
+![](/blog/images/2023-04-19/bodyimg7.webp)
+
+We have extensive experience working with Fortune 500 companies, helping them scale their development using monorepos. This has given us valuable insight into the unique security requirements of these companies. Our [Enterprise plan](/enterprise) reflects that allowing organizations to have a **fully self-contained version of Nx Cloud** that can be **hosted on their own servers** and comes with dedicated support from the Nx and Nx Cloud core team.
+
+We’ve recently made a couple of improvements to our enterprise offering.
+
+- **Helm Charts** — We added a **Helm chart** to simplify the process of deploying Nx Cloud to on-premises infrastructure, allowing organizations to quickly set up and manage their own instance of Nx Cloud within their secure environment.
+- **Stability improvements** — We significantly reworked our on-premises solution to be identical to our SaaS deployment. This revamp resulted in a more robust and reliable on-premises deployment of Nx Cloud, ensuring enterprise-grade performance and reliability.
+- **SSO** — We now support AWS Identity and Access Management (IAM) for seamless integration with existing AWS environments and the SAML protocol for a more flexible single sign-on integration across various providers. This enables organizations to leverage their existing identity management systems for authentication and authorization.
+
+Learn more at [enterprise](/enterprise).
+
+## New, Simplified Plans and Pricing Model
+
+Nx Cloud has evolved a lot since we first released it in 2020, and is changing even more in 2023. To better adapt to Nx Cloud being a critical CI tool, we changed our pricing model to be more consistent and predictable for CI workloads.
+
+Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](https://nx.app/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
+
+![](/blog/images/2023-04-19/bodyimg8.webp)
+
+Our Free plan allows one administrator and up to 300 CI pipeline executions per month. Our Pro plan allows more administrators, and uncapped CI pipeline executions, with a flat fee and incremental charges per 100 CI pipeline executions. The OSS plan comes with unlimited CI pipeline executions. Nx has been open source from the beginning and we care a lot about that ecosystem. So this is our contribution to help OSS projects and make their CI pipeline executions faster.
+
+Finally, the **Enterprise plan** is for companies that want full control over where their data is hosted, get hands-on, dedicated support from the Nx & Nx Cloud team, and enterprise features such as SSO & SAML-based authentication support.
+
+All these changes should allow developers to choose the plan that best suits their needs and budget more easily, ensuring a seamless and transparent experience regarding pricing and subscription management.
+
+Learn more at [https://nx.app/pricing](https://nx.app/pricing).
+
+## Coming Next
+
+We’ve got some big plans for Nx Cloud. You really want to write your CI script by focusing on what you want to achieve rather than thinking about making it fast. We’re going to make this happen!
+
+The current Distributed Task Execution (DTE) already goes a long way, but you still have to provision the agents by yourself. Providing the correct number of agents is crucial for maximizing efficiency and reducing idle time. And it is not even a static number but might depend on the actual run itself. Nx has extensive knowledge about the structure of the workspace and according tasks. We want to leverage that information. Imagine a setup where you have a roughly 20 line CI config for a repo with hundreds of developers and Nx Cloud automatically determines for each run the ideal number of agents required, provisions them, distributes all tasks efficiently and then disposes all agents again. All fully automatically. And it will be fast. To the point where you wouldn’t even need your Jenkins, CircleCI etc at all.
+
+In addition, we are actively exploring ways to provide advanced analytics for your workspace, including insights into the frequency and duration of specific tasks. This valuable information can help identify large tasks that could benefit from being broken down into smaller ones, leveraging caching and other speed improvements to optimize performance. Stay tuned for more to come!
+
+---
+
+## Learn more
+
+- [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](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)

docs/blog/2023-06-29-nx-console-gets-lit.md

@@ -0,0 +1,337 @@
+---
+title: Nx Console gets Lit
+authors: [Max Kless]
+cover_image: '/blog/images/2023-06-29/featured_img.webp'
+tags: [nx, nx-console]
+---
+
+Over the last few weeks, we rebuilt one of Nx Console’s most liked features from the ground up: The Generate UI. It looks better, loads faster, and preliminary research shows using it makes you happier, too ;)
+
+You can use it today by installing the latest version of Nx Console for VSCode and JetBrains IDEs! 🎉🎉🎉
+
+- [Nx Console on the VSCode Marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
+- [Nx Console on the JetBrains Marketplace](https://plugins.jetbrains.com/plugin/21060-nx-console)
+
+If you’re curious to learn more about the rewrite and the motivations behind it, this is the blog post for you! We’ll touch on these topics and more:
+
+- Why did we choose to rewrite?
+- What’s Lit and why did we use it over Angular?
+- How did the rewrite go and what Lit features were important for us?
+- What does the performance look like before and after?
+
+{% youtube src="https://www.youtube.com/embed/p455D4W7330?si=FRbiKJhGxT8dYzf9" /%}
+
+## Background: Why Migrate from Angular to Lit?
+
+### A Short History of Nx Console
+
+Let’s go back in time: Nx Console has been around for a while. [It first launched in 2018](https://blog.nrwl.io/announcing-the-first-stable-release-of-angular-console-the-ui-for-the-angular-cli-bb19093a92d4?source=friends_link&sk=d955094b2cb872a130b47c8040ec820e) — then called Angular Console — as a standalone Electron app which let you run Angular schematics and builders from a graphical interface. Of course, it was built with Angular and looked something like this:
+
+![Screenshot of the original Angular Console electron app](/blog/images/2023-06-29/bodyimg1.webp)
+
+In 2019, [it was ported to a VSCode extension](https://blog.nrwl.io/brand-new-ui-custom-vscode-task-support-more-in-angular-console-9-0-5e4d3a109fb9?source=friends_link&sk=47fd72d5700b4cb3de09e559c5524ce5) with the now familiar UI and support for the standalone app was dropped.
+
+In 2020, support for the entire Nx ecosystem was added, it was renamed to Nx Console and an amazing transformation began: Today, Nx Console is much more than just a single form — it tightly integrates Nx into your IDE, gives you the overview of your projects that you need and puts your task-running just a click away.
+
+### Rewriting in Lit
+
+This evolution brought significant improvements to the usability of Nx Console and the value we could provide to developers, but not without presenting its own set of challenges. Inevitably, the codebase grew complex and convoluted over time — the context in which it ran changed, the scope of the product changed, yet the technology remained the same. Adding small features or fixing bugs became increasingly time consuming, and every PR compounded the problem.
+
+The UI looked somewhat outdated and had been built with only VSCode in mind — which became painfully obvious when support for JetBrains IDEs was added. While the web-based nature of the Generate UI allowed us to reuse the code in the new environment, the design looked out of place.
+
+In addition, we started questioning our usage of Angular. Angular is a great framework for building web apps, and in the original context of Angular Console, it made a lot of sense: A tool built by and for Angular engineers — of course it’s written in Angular. But things changed, and Angular started to feel overkill for what we needed. Angular has a huge number of features right out of the box. But for our simple form, we didn’t need routing, http requests or modules to organize our code. The amount of boilerplate and overhead Angular introduces is significant.
+
+So, ultimately, **we decided to pull the plug and rewrite the entire thing in [Lit](https://lit.dev/).**
+
+Lit is a lightweight framework built on top of web components and “adds just what you need to be happy and productive: reactivity, declarative templates and a handful of thoughtful features to reduce boilerplate and make your job easier” (taken from their docs). We had used it before to [build the Nx Cloud view](https://blog.nrwl.io/nx-console-meets-nx-cloud-d45dc099dc5d?source=friends_link&sk=90215eb316ef332c1324f2d50cd3ad85) and were happy with the simple setup and great DX. So the decision to reuse it here was an easy one, since it allowed us to reuse code, build tooling and expertise. The rewrite also gave us the opportunity to improve the design for both supported IDEs and give the entire UI a clean, new coat of paint.
+
+![Screenshot of the reworked generate ui](/blog/images/2023-06-29/bodyimg2.webp)
+
+Before I dive deeper into specifics, let’s have a look at the general architecture of Nx Console first.
+
+## Nx Console Architectural Overview
+
+Nx Console is composed of 3 core parts:
+
+- The **nxls** is a language server based on the [Language Server Protocol (LSP)](https://microsoft.github.io/language-server-protocol/) and acts as the “brain” of Nx Console. It analyzes your Nx workspace and provides information on it, including code completion and more.
+- The **Generate UI** is the form-based view for running Nx generators.
+- The **platform-specific wrappers**. These are written in Typescript and Kotlin and connect the rest of Nx Console to IDE-specific APIs. Having the other parts separate greatly reduces the amount of duplicated code we have to write in order to support multiple IDEs
+
+This architecture’s modularity meant we could quickly switch out the Generate UI for a new version without significantly impacting the rest of the codebase — only the parts that actually render the UI and communicate with it had to be adjusted slightly. It also allowed us to ensure backward compatibility: the old generate UI is still available via a feature toggle in the settings.
+
+If you want to dive deeper, there are many more resources on the architecture of Nx Console and how it’s built:
+
+- [In-depth blog post about expanding to JetBrains IDEs](https://blog.nrwl.io/expanding-nx-console-to-jetbrains-ides-8a5b80fff2d7?source=friends_link&sk=967080ea30bdbf9f8132f098a2cdd188)
+- [Accompanying Youtube video by Zack DeRose](https://www.youtube.com/watch?v=xUTm6GDqwJM)
+- [The Power of Nx Console — talk by Jon Cammisuli](https://www.youtube.com/watch?v=3C_9g9kt2KM)
+
+## Migrating to Lit: Step by Step
+
+To rebuild our UI, we first needed a new Lit app to work on. While there’s no native Nx plugin for Lit, generating the code we need was still very straightforward:
+
+`nx generate @nx/web:app --name generate-ui-v2`
+
+This generates an entire project for us, with a `tsconfig.json`, `index.html`, `main.ts`, and a `project.json`, where our Nx-specific config lives.
+
+I also installed a couple of dependencies:
+
+- The `@nx/esbuild` plugin because I like fast build times 🏎️
+- TailwindCSS because I don’t like writing CSS 🤫
+- `@vscode/webview-ui-toolkit` because it does all of the VSCode work for me 🤖
+
+This is really where Nx shines, because it allows you to take these tools and quickly patch them together and build a pipeline that does exactly what you need. And it also allows you to think about your workspace visually. This is what this is what my task graph for building the Lit app ultimately looks like:
+
+![Nx task graph for building the Lit webview](/blog/images/2023-06-29/bodyimg3.webp)
+
+You can see three build steps:
+
+- `generate-ui-v2:_build` uses esbuild to bundle my Lit components written in Typescript and spits out a `main.js` file
+- `generate-ui-v2:extract-dependencies` copies the third party assets we need into the dist folder. Right now it’s just codicons `.css` and `.ttf` files.
+- `generate-ui-v2:build` finally runs tailwind over the bundled code. This could also be done with `postCss` or a custom `esbuild` plugin but running tailwind directly is the easier, so why complicate things?
+
+> 💡 There are different ways to generate this visualisation for your own workspaces:
+>
+> - In VSCode, use the Nx Project View or the `Nx: Focus task in Graph` action
+> - In JetBrains IDEs, use the Nx Toolwindow or context menus
+> - In the command line, run `nx build {{your project}} --graph`
+
+In the bigger context of Nx Console, here’s what happens when you build the VSCode extension:
+
+![Nx task graph for building the VSCode extension](/blog/images/2023-06-29/bodyimg4.webp)
+
+You can see that we’re still building both the new & old generate UI as well as the Nxls and the Nx Cloud webview before combining them all into one VSCode extension artifact.
+
+### Building the Form
+
+Lit is a very small library that provides useful abstractions over browser-native features like web components and messages. Here’s what a simple Lit component, written with Typescript, looks like:
+
+```ts {% fileName="main.ts" %}
+@customElement('root-element')
+export class Root extends LitElement {
+  render() {
+    return html`<p>Hello World</p>`;
+  }
+}
+```
+
+```html {% fileName="index.html" %}
+<!DOCTYPE html>
+<html lang="en">
+  <body>
+    <script type="module" src="main.js"></script>
+    <root-element></root-element>
+  </body>
+</html>
+```
+
+If you need to pass information up the DOM, you use normal events and you can set properties to send information to descendants. Check out the [Lit Docs](https://lit.dev/docs/components/rendering/) to learn more about how the render() method works, how to leverage reactivity, the shadow DOM and so much more.
+
+> 💡 All code samples in this section have been adapted for brevity and clarity. So you won’t find this exact code anywhere, but it demonstrates the concepts well.
+
+### Communicating with the IDE — using Reactive Controllers
+
+To communicate with the host IDE, we were able to reuse almost all the logic from the previous UI (for more details, see [Communicating with IntelliJ](https://blog.nrwl.io/expanding-nx-console-to-jetbrains-ides-8a5b80fff2d7?source=friends_link&sk=967080ea30bdbf9f8132f098a2cdd188#d151) from the last blog post). Instead of a service that exposes observables that our component can consume, we used a [Reactive Controller](https://lit.dev/docs/composition/controllers/). Controllers are a neat feature of Lit — they hook into a component and can request DOM updates on their behalf. This eliminates the need for observable streams and subscriptions while keeping the communication code self-contained. Look at this example:
+
+```ts {% fileName="main.ts" %}
+@customElement('root-element')
+export class Root extends LitElement {
+  icc: IdeCommunicationController;
+
+  constructor() {
+    super();
+    this.icc = new IdeCommunicationController(this);
+  }
+  render() {
+    return html`${JSON.stringify(this.icc.generatorSchema)}`;
+  }
+}
+```
+
+```ts {% fileName="ide-communication-controller.ts" %}
+// ide-communication-controller.ts
+export class IdeCommunicationController implements ReactiveController {
+  generatorSchema: GeneratorSchema | undefined;
+  constructor(private host: ReactiveControllerHost) {}
+  // ...
+  private handleMessageFromIde(message: InputMessage) {
+    // ...
+    this.generatorSchema = message.payload;
+    this.host.requestUpdate();
+  }
+}
+```
+
+You can see that `root-element` can really just deal with rendering the form contents, delegating communicating with the IDE and when to update the DOM to the controller.
+
+### Rendering the form fields — using Mixins
+
+The core part of the UI is the form. We built all kinds of inputs: text fields, checkboxes, (multi-) select boxes and array fields. While those each have unique implementations, displaying them is also going to take a lot of repeated code. Every fields needs a label and description. Every field needs to know about its validation state, how dispatch change events and what aria attributes to set. In order to keep this code clean and DRY, we used [Class Mixins](https://lit.dev/docs/composition/mixins/). Mixins aren’t really a Lit-specific feature, but I don’t see them used much in other frameworks. A mixin is essentially a factory that takes a class and returns another, modified class. Check out this example:
+
+```ts {% fileName="field-mixin.ts" %}
+const Field = (superClass) =>
+  class extends superClass {
+    // we can define (reactive) properties that every field is going to need
+    @property()
+    option: Option;
+    protected get fieldId(): string {
+      return `${this.option.name}-field`;
+    }
+
+    // we can define methods that should be available to all fields
+    dispatchValue(value: string) {
+      // ...
+    }
+  };
+```
+
+```ts {% fileName="field-wrapper-mixin.ts" %}
+const FieldWrapper = (superClass) =>
+  class extends superClass {
+    // we can define a render() method so that fields are all rendered the same
+    protected render() {
+      return html` <label for="${this.fieldId}">${this.option.name}</label>
+        <p>${this.option.description}</p>
+        ${this.renderField()}`;
+    }
+  };
+```
+
+```ts {% fileName="input-field.ts" %}
+@customElement('input-field')
+export class InputField extends FieldWrapper(Field(LitElement)) {
+  renderField() {
+    return html` <input
+      id="${this.fieldId}"
+      @input="${(e) => this.dispatchValue(e.target.value)}"
+    />`;
+  }
+}
+```
+
+You can see that each component and mixin deals with a specific subset of the overall logic, keeping our code cleanly separated and reusable. A checkbox, for example, is a special case because it’s layout on the page is slightly different — no problem, we simply wrote a CheckboxWrapper with some modifications without having to worry about changing the checkbox logic itself.
+
+> 💡 Properly typing mixins is complicated so I left that part out. Refer to [Mixins in Typescript](https://lit.dev/docs/composition/mixins/#mixins-in-typescript) to learn more or [check out our source code on GitHub](https://github.com/nrwl/nx-console).
+
+### Injecting Services & Data — Lit Context
+
+If you’re coming from the Angular world, you probably appreciate the great dependency injection (DI) mechanism they have. You can centrally define some services and reuse them across your app, without thinking about passing on props from component to component — the DI system takes care of it. Lit provides something similar via the []`@lit-labs/context`](https://lit.dev/docs/data/context/) package. It’s based on the [Context Community Protocol](https://github.com/webcomponents-cg/community-protocols/blob/main/proposals/context.md) and similar to React’s context API.
+
+Under the hood, it still works with normal browser events, but it abstracts it away from you so you can easily share data and services across your app.
+
+The Generate UI is rendered in both VSCode and JetBrains IDEs. In order to look appropriate, components need to know which environment they’re in and adjust styling accordingly. Instead of passing this information from component to component, we can make it available contextually! And with a proper mixin, reading the editor context only has to be implemented once, too.
+
+Have a look at the following example:
+
+```ts {% fileName="editor-context.ts" %}
+export const editorContext = createContext<'vscode' | 'intellij'>(
+  Symbol('editor')
+);
+
+const EditorContext = (superClass) =>
+  class extends superClass {
+    @consume({ context: editorContext })
+    @state()
+    editor: 'vscode' | 'intellij';
+  };
+```
+
+```ts {% fileName="ide-communication-controller.ts" %}
+export class IdeCommunicationController implements ReactiveController {
+  // ...
+  constructor(private host: ReactiveElement) {
+    const editor = isVscode() ? 'vscode' : 'intellij';
+    // provide the context to all DOM children of the host element
+    new ContextProvider(host, {
+      context: editorContext,
+      initialValue: editor,
+    });
+  }
+}
+```
+
+```ts {% fileName="some-component.ts" %}
+@customElement('some-component')
+export class SomeComponent extends EditorContext(LitElement) {
+  render() {
+    return html`<p>I am rendered in ${this.editor}</p>`;
+  }
+}
+```
+
+### VSCode Webview UI Toolkit
+
+As we mentioned above, a big part of why we rewrote the UI is that it looked quite out of place in JetBrains IDEs. It was still useful, of course, but it’s important to make sure the form _feels_ right.
+
+In VSCode, this is very easy to achieve, thanks to the [VSCode Webview UI Toolkit](https://github.com/microsoft/vscode-webview-ui-toolkit). It’s a set of web components, provided by Microsoft, that are designed to look good and be used in VSCode webviews.
+
+![Sample image of the VSCode Webview UI Toolkit showing the different components it provides](/blog/images/2023-06-29/bodyimg5.webp)
+
+Using it, you get the native look, a11y, and theme-aware styling for free! Thanks to everyone who built it, it’s a huge help!
+
+### E2E Testing with Cypress
+
+One big upside of using a webview is the huge Javascript ecosystem is available to you! To make sure that no regressions are introduced later on, we use [Cypress](https://www.cypress.io/). We can mock the editor communication and provide different schemas, make sure the form is rendered correctly and the right messages are sent back to the IDE.
+
+While there’s no particular Lit integration for Cypress, the tool itself is framework agnostic so it still works perfectly fine. Using the [`@nx/cypress`](/nx-api/cypress) executors did most of the work for us so setup was pretty quick too.
+
+### Results: Comparing Performance
+
+There’s a number of different aspects to performance we can compare between the two implementations. The biggest one by far is not really quantifiable: The maintainability and looks of the new UI. In my opinion, it looks a lot fresher and more native in both environments. We got rid of a lot of legacy code and the new version is easier to reason about and work with.
+But there are thing we _can_ measure, so let’s talk numbers!
+
+### Startup Time
+
+It takes time to bootstrap a large framework like Angular, so skipping that, the UI should load quicker than before.
+
+We measured the median time it took to render all options of the `@nx/angular:application` generator in both VSCode and IntelliJ. You can see that the results are pretty clear-cut, even though they are not hugely impactful.
+
+Old UI (Angular)New UI (Lit)SpeedupVSCode65 ms39 ms~ 1.7xIntelliJ189 ms122 ms~ 1.5x
+
+### Bundle Size
+
+As mentioned earlier, Angular comes with a lot more features out-of-the-box than Lit, so it would make sense that the built bundle will be bigger.
+
+We were able to reduce the bundle size (w/o compression) from about 733 kB to 282 kB, which comes out to about a 2,6x decrease. Unlike a website, where the bundle needs to be shipped to users when they load a page, Nx Console users only need to download it once when installing the plugin. This means we’re not affected by network speeds after installation, which makes the bundle size less critical.
+
+> 💡 Because of a misconfiguration from a few Angular versions ago, the bundle size that we reported in:
+
+{% tweet url="https://twitter.com/MaxKless/status/1671095858182381569" /%}
+
+was overly bloated. We corrected it, but Lit still came out ahead in terms of size and rendering times.
+
+### Build Time
+
+While it might not be important to users of Nx Console, the time it takes to build the project makes a difference to us developers.
+
+Since Lit is just javascript files that don’t require a custom compiler or build tooling, we decided to use [`esbuild`](https://esbuild.github.io/) (via `@nx/esbuild`), which is written in Go and extremely fast. On the other hand, the old UI used the `@angular-builders/custom-webpack:browser` builder, which uses webpack under the hood.
+
+We went from about 3.5 seconds to less than 2 seconds of build time, which is less of an improvement than we expected. Since we also have to run tailwind over our files, some of that additional `esbuild` speed seems to be relativized.
+
+## Looking Ahead
+
+Rebuilding the UI has paved the road to reduce a lot of the maintenance burden of Nx Console. It will allow us to move even quicker on building new features to provide the best developer experience possible for you.
+
+Specifically, the updated architecture enabled us to build a (still secret and WIP) plugin feature for Nx Console. Just like Nx, there are always going to be things that are unique to your workspace. We want to make it easy for you to extend and modify Nx Console in ways that help you make the most of using it.
+
+So keep your eyes peeled for announcements and let us know via GitHub or Twitter if you have any ideas! We’d love to chat.
+
+## One more thing!
+
+Nx Console is a tool by developers for developers and there’s one thing we love — keyboard shortcuts. So of course we had to build some in. In addition to being keyboard-friendly and tabbable, you can do the following:
+
+- `Cmd/Ctrl + Enter` to run the generator
+- `Cmd/Ctrl + Shift + Enter` to start a dry run
+- `Cmd/Ctrl + Shift + S` to focus the search bar and look for a specific option. Just `tab` to get back to the form
+
+If the prettier UI and better performance haven’t convinced you, this surely will! 😉
+
+---
+
+## Learn more
+
+- [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](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)

docs/blog/2023-08-15-qwikify-your-dev.md

@@ -5,7 +5,7 @@ cover_image: '/blog/images/2023-08-15/featured_img.png'
 tags: [nx, changelog, release]
 ---
 
-In the ever-evolving web development landscape, efficiency and modularity have become paramount. This is where [Nx](https://nx.dev) and [Qwik](https://qwik.dev/) come into play.
+In the ever-evolving web development landscape, efficiency and modularity have become paramount. This is where [Nx]() and [Qwik](https://qwik.dev/) come into play.
 
 Qwik is a modern web framework that focuses on application performance by reducing the amount of JavaScript that needs to be shipped to the browser. You can learn more about how Qwik achieves this with [Resumability in their docs](https://qwik.dev/docs/concepts/resumable/).
 

docs/blog/2023-10-13-nx-conf-2023-recap.md

@@ -0,0 +1,497 @@
+---
+title: Nx Conf 2023 — Recap
+authors: [Juri Strumpflohner]
+cover_image: '/blog/images/2023-10-13/featured_img.webp'
+tags: [nx, nx-conf]
+---
+
+The 3rd edition of [Nx Conf](/conf), this year live from New York City. If you missed the talks, no worries, we’ve got you covered. This article does a brief recap of all the presentations and has links to the individual recordings and slides.
+
+{% youtube src="https://www.youtube.com/embed/P_W8MwX25a0?si=gpjul3hdqmOiBdev" /%}
+
+## Keynote
+
+**Speaker:** [Juri Strumpflohner](https://twitter.com/juristr) & [Victor Savkin](https://twitter.com/victorsavkin)
+
+{% youtube src="https://www.youtube.com/watch?v=WSqivWlEDFw" /%}
+
+Juri Strumpflohner (me 😅) opens the keynote. He focuses on the Nx ecosystem, how it is [much more than monorepos](/getting-started/why-nx) by helping you integrate your framework of choice (whether that is Angular, React, or Vue) with tooling such as ESLint, Playwright, Cypress, Webpack, ESBuild, Vite etc.
+
+![](/blog/images/2023-10-13/bodyimg1.webp)
+
+Such integration capabilities really help push the developer productivity, whether that’s in single-project workspaces or monorepos.
+Juri also dives deeper into efforts from the team to provide high quality educational content around Nx and its capabilities. The [Nx docs](/getting-started/intro) have been restructured to follow the [Diataxis](https://diataxis.fr/) framework, dividing content into into learning-, task-, understanding- and information-oriented sections.
+
+![](/blog/images/2023-10-13/bodyimg2.webp)
+
+This makes it easier to find keep the content organized and focused and makes it easier for the reader to choose between solution-oriented [recipes](/recipes) vs learning-oriented [tutorials](/getting-started/tutorials).
+
+The Nx team not only produces written content, but also video content mainly on the [Nx YouTube Channel](https://www.youtube.com/@nxdevtools). Juri shows some of the growth stats, with the channel now having more than 14k subscribers and around 3.7k hours of watch time per month. The channel serves mostly short-form videos about new releases, highlighting new features as well as longer-form tutorial videos.
+
+The Nx Community also got a special place in the keynote. Juri highlighted in particular the transition from the “Nrwl Community Slack” to the new “Nx Community” on Discord.
+
+![](/blog/images/2023-10-13/bodyimg3.webp)
+
+Discord is built for managing communities and will open up a series of features to come. Things like a built-in forum to ask questions, the ability to highlight Nx events (e.g. the Nx live stream) and having powerful automation and moderation tools. Since the launch a couple of weeks ago, already 1500+ members have signed up. If you didn’t sign up yet, go to [https://go.nx.dev/community](https://go.nx.dev/community).
+Juri also highlighted the [Nx Champions](/community) program that got launched this year which helps with efforts to grow the Nx community. The program features members that stood out in the Nx community by helping support others, producing content or speaking at conferences about Nx and related tech.
+
+Finally there were also two **announcements**:
+
+- the Nx team decided to move off Medium for a better publishing experience but mainly also to avoid the paywall, something that the team has no control over. The new blog is currently being built and will be hosted at [blog](/blog). This also allows to better resurface information by being able to integrate blog articles into the Nx docs search and make them also accessible to the Nx AI Assistant which was the 2nd announcement.
+- the **Nx AI Assistant** is an experiment the team is running to use AI to improve discoverability on the Nx docs. The ChatGPT powered assistant allows to ask natural language questions and responds based on the Nx docs training data, also including links to the sources. Try it out at [ai-chat](/ai-chat) and use the feedback thumbs-up/down buttons to help improve it over time 🙏.
+
+Also, Nx is open source: [https://github.com/nrwl/nx](https://github.com/nrwl/nx). Contribute! And while you’re there, don’t forget to give us a star 😃.
+
+**Victor Savkin** began the second segment of the keynote discussing the hidden expenses that often plague large teams.
+
+![](/blog/images/2023-10-13/bodyimg4.webp)
+
+He emphasized that as an organization grows, so does the supporting work. This isn’t limited to just communication and management. Every artifact, be it code, process, or otherwise, needs to be assimilated into the broader context. This supporting work becomes intricate and demanding. He pointed out that the remote work trend, while it started with a lot of momentum, struggles in larger corporations because it demands even more coordination and effort. In contrast, smaller entities often outshine their larger counterparts due to the reduced overhead of supporting work.
+
+One of Victor’s main points was the potential of software developers. Given the right tools and environment, they can achieve remarkable feats. CI is one such tool.
+
+![](/blog/images/2023-10-13/bodyimg5.webp)
+
+The state of CI configuration, Victor explained, is essentially a meticulous blueprint of tasks for the CI tool. This blueprint defines everything from the number of machines to their precise roles. Historically, these processes were performed manually, with individuals running test cases and subsequently approving or rejecting them.
+
+However, scaling CI is a challenge. In larger workspace, up to 50 agents is pretty common, all requiring careful coordination and configuration to ensure tasks run in the correct order.
+
+![](/blog/images/2023-10-13/bodyimg6.webp)
+
+This might be manageable in a static repository setup, but monorepos introduce an added layer of complexity. Here, static “CI recipes” just won’t cut it. The result is either an overuse of computational resources, leading to waste of money, or a painfully slow CI.
+
+Victor critiqued that most current CI setups are:
+
+- Oriented towards machines
+- Low-level in their configuration
+- Maintenance-heavy
+- Detached from developer intentions
+- Challenging to implement with monorepos
+
+The big question: how can we revolutionize CI? Victor then showcased a demo workspace and highlights where the complexity of setting up CI comes from:
+
+![](/blog/images/2023-10-13/bodyimg7.webp)
+
+Even running e2e tests on CI requires:
+
+- Building the application to be tested to produce an artifact
+- That usually requires first building all libraries the app depends on, in the correct order
+- Once all libraries are built, the application itself can be build
+- Finally e2e can be run on the application artifact
+
+Notice, since we want to do this as fast as possible, we want to parallelize these operations across machines. This involves also taking care of transferring build artifacts between them.
+
+This is where **Nx Cloud Workflows** shines. It enables developers to draft CI configurations at a far more abstract level. Instead of delving into the minutiae of tasks, developers specify **what** commands to execute, with the **how** being implicitly managed by Nx Cloud.
+
+```yaml
+env:
+  NODE_OPTIONS: '--max_old_space_size=4096'
+setup:
+  - name: Git Checkout
+    uses: 'nx-cloud-steps/checkout'
+  - name: Npm Install
+    uses: 'nx-cloud-steps/npm-install'
+steps:
+  - name: CI Checks
+    parallel-scripts: |
+      nx affected -t build e2e --parallel=1
+      nx affected -t test lint --parallel=3
+```
+
+This elevated abstraction is possible because Nx Cloud & Nx are intimately familiar with the workspace, understanding the interdependencies between projects and tasks.
+
+![](/blog/images/2023-10-13/bodyimg8.webp)
+
+Beyond simplifying CI configurations, Nx Cloud Workflows helps optimize computational resource use. Agents are instantiated dynamically based on the project’s requirements.
+
+![](/blog/images/2023-10-13/bodyimg9.webp)
+
+Victor highlighted that most current CI setups:
+
+- Consistently utilize a predetermined number of agents, irrespective of the actual needs of the PR
+- Possess non-reusable agents since each is tailored to a specific task, like building or testing
+- Struggle with granular retries
+
+As a metaphor Victor mentions that **Nx Cloud Workflows is to CI what S3 is to file uploads.**
+
+![](/blog/images/2023-10-13/bodyimg10.webp)
+
+Sounds interesting? Watch the entire talk below:
+
+{% youtube src="https://www.youtube.com/watch?v=WSqivWlEDFw" /%}
+
+## Nx Cloud Workflows: Next-Gen CI with First-Class Monorepo Support
+
+**Speaker:** Simon Critchley
+[Slides](https://docs.google.com/presentation/d/18EHfZ4UUtnAlzl15Ul_GPsr5lxNFtEEFPuT1uvxIEAk/edit?usp=sharing)
+
+{% youtube src="https://youtu.be/JG1FWfZFByM?si=pNQNCLsbn5U0uSFB" /%}
+
+Simon Critchley (Senior Software Architect at Nx) dives into the more technical details of the newly announced **Nx Cloud Workflows** (which is in private beta as of this writing).
+
+![](/blog/images/2023-10-13/bodyimg11.webp)
+
+Apart from the distributed caching, Nx Cloud already offers [DTE (Distributed Task Execution)](/ci/features/distribute-task-execution), which is a mechanism to seamlessly distribute tasks across various machines to achieve a high degree of parallelism. Up until now it was on you to configure your existing CI in a way to provision machines (agents) to Nx Cloud DTE. This required some fine-tuning to understand the best level of parallelism given the underlying monorepo and tasks that need to be run. If you have too many machines, it’ll be wasteful, if you have to few your CI will be slower.
+
+Nx Cloud Workflow is an advancement of the DTE mechanism, where machines can be automatically provisioned and scaled based on the tasks that need to be run. Essentially it is a replacement for your existing CI but way smarter because it is able to leverage the knowledge it has about the Nx workspace, historical data and can thus do a series of optimizations. Traditional CI systems are running low-level commands on machines. Nx Cloud Workflows is task oriented instead: you tell it to run builds, tests, e2e, linting on the affected projects of the Nx workspace and it figures out how to split them up into fine-grained tasks and then distributes them among dynamically provisioned agents.
+
+From a developer’s perspective, Nx Cloud Workflows are written in Yaml (or alternatively in JSON which is handy if you need to generate them). The format is very similar to existing CI providers to make sure the knowledge you have easily transfers. If you want an example, we’re dog-fooding Nx Cloud Workflows on the Nx repo (note the config will change as the product progresses): [https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml](https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml)
+
+Simon then dives way deeper into the underlying architecture. In particular, how scheduling in Kubernetes works, which is used at the infrastructure level for Nx Cloud Workflows.
+
+![](/blog/images/2023-10-13/bodyimg12.webp)
+
+Workflow scheduling is handled by Kubernetes, specifically through a “Workflow Controller” that interacts with the K8s API Server and triggers Kubernetes Pods. Each Pod contains a Workflow executor and sidecar containers. All containers in the Nx Cloud workflow share a workspace volume for collaborative access. This allows for interesting optimizations in terms of sharing `node_modules` and restoring cache results.
+
+![](/blog/images/2023-10-13/bodyimg13.webp)
+
+The Workflow executor, written in Go, is responsible for receiving and executing workflow steps, capturing output, buffering logs, and communicating with the Workflow Controller. It also exposes its own grpc API for distributed locking, file system cache operations, and setting output parameters for each step, ensuring efficient workflow execution.
+
+Nx Cloud Workflow is in its early development phase. The Kubernetes scheduler supports Docker based executors (basically any Docker image can be used as build image).
+
+![](/blog/images/2023-10-13/bodyimg14.webp)
+
+Windows, macOS and Linux is currently in development which will use a Cloud VM scheduler on the cloud of your choice.
+
+## United by Nxcellent DX
+
+**Speaker:** [Michael Hladky](https://twitter.com/Michael_Hladky)
+[Slides](https://docs.google.com/presentation/d/1F6_x3Jiu_3b9tZpxQnCrU60Eb1FhYR8E5jVnb1t7DjA/edit?usp=sharing)
+
+{% youtube src="https://youtu.be/i0UdoImryJQ?si=a5lx6VnS__qhiyex" /%}
+
+Michael talks about how to leverage Nx to migrate multiple repositories into a monorepo to streamline development and increase developer productivity. He goes through
+
+- how a project gets started
+- how to prep moving to a monorepo from a polyrepo situation
+- how to do the move in parallel
+- how to measure the progress
+
+The project usually starts with an architectural audit. That involves a detailed analysis of the underlying codebase, also including an executive summary for non technical folks. Once the audit is done, the actual move is planned and prepared. A part of that is to define “Nx migration goals”, like
+
+- Single Version Policy
+- Improved Maintenance
+- Shared Infrastructure
+- Shared Architecture
+- Efficient Task Runs
+- Frictionless Code-Sharing
+- Frequent Deployments
+- Decouple Deployment
+
+To prioritize which ones to address first, Michael uses the following metaphor:
+
+![](/blog/images/2023-10-13/bodyimg15.webp)
+
+The important part here is to understand why “apples get bad” in the first place. Is it the harvesting process?
+
+Once the priorities are defined and roadmap laid out, the goal is to **move in parallel.**
+As part of that move the following gets produced:
+
+- Migration Guide
+- Training Program
+- Communication Strategy
+- Impact Measurement
+
+The migration guide defines where to start, what the company goals are, how the deliveries will be integrated into the existing process and how the interaction with the various teams will happen.
+
+The training program is there to tackle the bottleneck of missing knowledge, right from the beginning. Each stage of the process will have a different training content and collect feedback.
+
+Finally the impact measurement; Nx Cloud already has graphs to measure how much time got saved in CI due to the improvements made. Michael mentions they go further, also measuring communication and productivity.
+
+An interesting part is also how they perform the repository synching (from polyrepo to monorepo). They leverage an Nx plugin that
+
+- contains shared build logic
+- has rules to run that produce actionable feedback about what is needed to sync/align the polyrepo repository s.t. it can be merged into the monorepo
+- it also allows to track progress and produce according reporting of where the company is at
+
+Sounds interesting? Watch the full talk below:
+
+{% youtube src="https://www.youtube.com/watch?v=i0UdoImryJQ" /%}
+
+## Redefining Projects with Nx: A Dive into the New Inference API
+
+**Speaker:** [Craigory Coppola](https://twitter.com/enderagent)
+[Slides](https://craigory.dev/presentations/view/nx-conf-2023-inference/#1)
+
+Demo Repo:
+{% github-repository url="https://github.com/AgentEnder/inference-demo" /%}
+
+{% youtube src="https://www.youtube.com/watch?v=bnjOu7iOrMg" /%}
+
+Craigory did a deep dive into the new Nx inference API. This is particularly interesting if you’re developing [Nx plugins](/extending-nx/intro/getting-started) or if you have leverage/build some more advanced automation for your Nx workspace.
+
+What is project inference:
+
+- how Nx reads your project configuration
+- introduced between v13.3 and v14
+- initially to support package-based monorepos which use package.json scripts rather than `project.json`. Generalizing the project config reading mechanism also allowed to define an API that community plugins can leverage and which allows to integrate even languages outside the JS ecosystem into Nx (e.g. where projects are just defined differently, such as .Net, Java, Python,..)
+
+Inference API v1
+
+- `projectFilePatterns` - identify files that represent the root of a project
+- `registerProjectTargets` - takes a project file and converts to a list of targets that Nx knows how to run
+
+Shortcomings have been
+
+- strict 1–1 mapping between project files and projects
+- the logic of finding proj files and targets had to be decoupled which introduced potential failure points
+- no way to add dynamic metadata to a project
+
+Project graph API v2
+
+- `createNodes` - finds graph nodes based on files on disk
+- `createDependencies` - finds edges to be added to the graph
+
+Still 2 parts, but there’s no overlap between these two and they have very specific purposes.
+
+`createNodes` is a tuple composed of:
+
+- `projectFilePattern`
+- `CreateNodesFunction` It can return a map of projects and external nodes, so there's no more the shortcoming of a 1-1 as it was in v1 API. With this new setup multiple plugins might detect the same project. Nx merges the configuration that has been identified. Kinda what happens right now if you mix `package.json` and `project.json` targets in an Nx workspace.
+
+Craigory demos the inference API by building a spell checking plugin for Nx.
+
+`createDependencies` replaces `processProjectGraph`. It is more constrained but mainly because things like adding nodes should be done in a different function now (e.g. `createNodes`). This has also advantages for Nx itself, as it knows all nodes will have been created after the `createNodes` has terminated.
+
+This API is still marked as experimental, next steps will be
+
+- mark as stable
+- remove v1 API after deprecation period
+- plugin authors should start looking into the new API, provide feedback and think about migration scenarios
+
+## Package-based to Integrated: One Small Step or One Giant Leap?
+
+**Speaker:** [Isaac Mann](https://twitter.com/MannIsaac)
+[Slides](https://drive.google.com/file/d/1V1ocFIjYkRrcNXWuvUK1T8dQEceDcjvw/view?pli=1)
+
+Repo:
+{% github-repository url="https://github.com/isaacplmann/space-station-tracker/tree/final" /%}
+
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=nY0_o7zWBLM" /%}
+
+Isaac initiated his talk by drawing an analogy between software development and the moon landing. While Neil Armstrong is often singularly celebrated for setting foot on the moon, Isaac emphasized that the monumental achievement was the collective effort of countless individuals on the ground crew, from engineers to support staff.
+
+> Isaac: Nx wants to be that indispensable ground support crew for developers, allowing them to push the boundaries of software development.
+
+Currently, Nx offers support for two predominant monorepo styles: package-based and integrated.
+
+### Package-based Monorepos:
+
+- These are tailored for flexibility and innovation.
+- Packages within this setup can have diverse configurations.
+- Every package boasts its individual node_modules and dependencies.
+- Crucially, each can be upgraded independently, offering a high degree of autonomy.
+
+### Integrated Monorepos:
+
+- These are structured to prioritize consistency and maintainability.
+- Updates within this framework are automated, and the setup adheres to a single-version policy.
+
+Isaac then drew parallels between the Apollo program and the package-based mindset. The Apollo missions were evolutionary in nature, constantly pushing the envelope and embracing innovation with each successive mission. However, this trailblazing approach wasn’t without its perils, as evidenced by tragic accidents. This experimental approach was feasible because the core team, responsible for creating the setup, remained consistent throughout the project’s duration.
+
+In contrast, Isaac likened the International Space Station (ISS) to the integrated mindset. The ISS epitomizes the challenges of coordination, given its international collaboration involving numerous countries. Emphasizing longevity, the ISS necessitates that every new crew member be proficient in operating its intricate machinery.
+
+Shifting gears, Isaac delved into a hands-on demonstration. He outlined the process of transitioning from a package-based monorepo to an integrated one, including demoing:
+
+- Initializing Nx with `nx init`.
+- Establishing new projects to facilitate type sharing across applications.
+- Harnessing the power of the Nx graph visualization to navigate and understand the project structure.
+- Employing the module boundary rule, ensuring constraints are maintained in the revamped structure.
+- Devising a novel Nx generator, streamlining the process of setting up new libraries within the workspace.
+- Finally, he showcased the seamless upgrade mechanism, ensuring the workspace is always aligned with the latest version.
+
+## Nx’t Level Publishing
+
+**Speaker:** [James Henry](https://twitter.com/MrJamesHenry)
+[Slides](https://main--idyllic-dieffenbachia-3699ec.netlify.app/1)
+
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=p5qW5-2nKqI" /%}
+
+James Henry unveils the new versioning and publishing functionality that is now built into Nx itself.
+
+Nx has always given you the building blocks to do integrate the versioning and publishing; you could easily use Lerna with Nx, or changesets, release-it as well as a series of Nx Community plugins
+The nx core team decided to go into this problem space and provide an opinionated approach that is easy to use within existing Nx workspaces; something that works and scales; also something that works outside the JS ecosystem which Nx can also be used with
+
+New command `nx release`
+
+- `nx release version` to determine and apply version updates
+- `nx release` changelog generate a CHANGELOG.md file and optional GitHub releases based on git commits
+- `nx release` publish takes a newly versioned project and publishes them to a remote registry (e.g. NPM)
+
+This new command is not tight to `package.json` files but is general purpose; clearly publishing JS/TS packages is the main use case right now in Nx
+Important to note that all the existing plugins are still valid and will still be going forward.
+
+James goes forward demoing how `nx release` works in a simple NPM package: [jump directly into the video](https://www.youtube.com/watch?si=xoIW0Q-mQWTGgrek&t=411&v=p5qW5-2nKqI&feature=youtu.be).
+
+Nx release can be added to any npm package. All that’s needed is the `nx` and `@nx/js` package and a `nx: {}` node in the `package.json`.
+
+Nx release has a dry-run mode; `nx release version --dry-run`. This will output a diff of what version would be created and on which `package.json` files (if there are multiple).
+The same mechanism also works for the `changelog` command, e.g. `nx release changelog --dry-run`. In addition to just dry-run, the `changelog` command also has an `--interactive` mode that allows to get the generated changelog in an interactive editor where you can adjust and add extra stuff.
+
+James then moves on to show how the release process works in a monorepo scenario using pnpm workspaces, where there are multiple NPM packages that need to be published: [jump to the video](https://www.youtube.com/watch?si=BvFvRQjgtwOxu-Dv&t=777&v=p5qW5-2nKqI&feature=youtu.be).
+
+The monorepo has a `pkg-a` and `pkg-b` where there's a relationship between them as follows: `pkg-a --> pkg-b`.
+If the `version` command is used in such scenario, it will also be applied to the dependent packages (`pkg-b`) since Nx knows about the dependencies via the project graph.
+A nice feature is also that the changelog will...
+
+- automatically group first by type (e.g. features grouped together, fixes etc)
+- within each type grouping it will be grouped by scope such as pkg-a etc which will be alphabetized
+- if there’s a fix on the entire repo that’ll come first before the per-package changes
+
+`nx release changelog --create-release=github` allows to also automatically push the changelog to a Github release.
+
+When running `nx release publish`, Nx also takes into account the right order of how the packages should go on NPM. Like if there's a relationship `pkg-a --> pkg-b`, Nx automatically detects such dependency and will go and publish pkg-b first and then `pkg-a` which depends on it. That to make sure that even if there's a network error in between packages, you'd still not break anything.
+
+Future roadmap:
+
+- ability to customize how the release works by defining it in `nx.json`
+- “release groups” will allow to group packages and define whether versions should be in sync or versioned independently; filter by projects, or even just publish a subset of projects of a workspace
+- publishing also automatically takes into account the provenance data on NPM
+
+## Lightning Talk: What if your stories were — already — your e2e tests?
+
+**Speaker:** [Katerina Skroumpelou](https://twitter.com/psybercity)
+[Slides](https://drive.google.com/file/d/1XY8tefqqcM4k4swNPhlSrJiKxurMGiup/view)
+
+Repo
+{% github-repository url="https://github.com/mandarini/storybook-play" /%}
+
+[Live Demo](https://storybook-play.vercel.app/?path=/story/app--primary)
+
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=SWlvsDNXCsQ" /%}
+
+Katerina starts by introducing the concept of UI testing for error detection, usability verification, regression prevention but also for validating the user journey and making sure the software is reliability.
+
+Nx had support to use Storybook for doing component-level tests, both using a Cypress e2e setup as well as Cypress component tests. This is where Nx would fill in to launch Storybook to render a single component and then launch Cypress and run dedicated tests against that served component.
+Meanwhile Storybook has introduced so-called [Interaction Tests](https://storybook.js.org/docs/writing-tests/interaction-testing) which allow you to do something similar.
+
+You can read more on [our docs](https://storybook.js.org/docs/writing-tests/interaction-testing). Or check out our corresponding video on Youtube:
+{% youtube src="https://www.youtube.com/watch?v=SaHoUx-TUs8" /%}
+
+## Lightning Talk: Nx Cloud Demo
+
+**Speaker:** [Johanna Pearce](https://twitter.com/jhannapearce)
+
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=xc6fJpwk4Lo" /%}
+
+Johanna gives us a tour through the Nx Cloud UI. So there’s not much to say other than [go watch the talk](https://www.youtube.com/watch?v=xc6fJpwk4Lo&feature=youtu.be) :)
+
+## From DIY to DTE — An Enterprise Experience
+
+**Speaker:** Adrian Baran
+[Slides](https://docs.google.com/presentation/d/1LPgCuYoVEIJqqhk8TLq4RAcHrJ5phJuiHHEGA3y_aws/edit?pli=1#slide=id.g25ac4b0c8f6_0_72)
+{% youtube src="https://www.youtube.com/watch?v=MsUN0wQHPAs" /%}
+
+Adrian Baran, a Senior Software Engineer at Cisco, embarked on his talk by presenting the status quo of their monorepo which encompasses approximately 150 projects at the start of the experiment.
+
+![](/blog/images/2023-10-13/bodyimg16.webp)
+
+Their CI workflow is powered by CircleCI. For the purpose of clarity, Adrian zoomed in on the frequently executed tasks: `build`, `lint`, and `test`. To execute these tasks, they leverage the [Nx affected](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) command to avoid running all commands on all projects.
+
+![](/blog/images/2023-10-13/bodyimg17.webp)
+
+Despite that, on average CI runs on PRs still lingered around the 1-hour mark. The immediate remedy? Harnessing CircleCI to parallelize tasks across multiple machines, while continuing to utilize Nx affected. Adrian wrote about that journey in a blog post last year, titled [Nx Affected + CircleCI Parallelism = Faster CI/CD Pipelines](https://medium.com/@abaran30/nx-affected-circleci-parallelism-faster-ci-cd-pipelines-b4edc4caaaac).
+
+They ended up with a loooot of parallelism:
+
+![](/blog/images/2023-10-13/bodyimg18.webp)
+
+The outcome was promising though — they witnessed a significant reduction, approximately 75%, in execution time, even in scenarios where all projects were influenced by a PR. Done, right?
+
+However, as their monorepo burgeoned to encompass 400+ projects, the DIY solution began to show its limitations. The incessant parallelization implied the addition of more agents, leading to escalating costs. Furthermore, they observed considerable variability in task durations.
+
+![](/blog/images/2023-10-13/bodyimg19.webp)
+
+Their workaround was to manually allocate specific tasks to distinct agents. This method in addition to capping on a max number of agents helped keep costs under control, but regrettably, it also compromised performance due to the lowered parallelism.
+
+This is when Cisco looked into running an [Nx Enterprise](/enterprise) pilot, specifically with the goal of adopting [DTE](/ci/features/distribute-task-execution). In the 2nd part of the talk, Adrian outlined their journey of setting up DTE, starting with the generation of the initial CI setup:
+
+```shell
+nx g @nx/workspace:ci-workflow --ci=circleci
+```
+
+They tuned the generated configuration, but failed to get it properly running, many of the issues leading to resource exhaustion. As a result, they went the route of going on a 1–1 mapping setup between DIY and DTE. That made sure the DTE setup was as close as possible and allowed for a gradual transition approach, which proved invaluable, allowing them to maintain stability whilst progressively migrating to DTE.
+
+The comparative analysis of their DIY solution versus DTE revealed roughly equivalent performance metrics. However, the DTE framework shone in its simplicity, maintainability, and resource efficiency, achieving similar outcomes with a 75% reduction in resource utilization.
+
+![](/blog/images/2023-10-13/bodyimg20.webp)
+
+### Adrian’s Key Insights:
+
+- DTE setup warrants a dual-pronged strategy: an immediate plan for initiation and a long-term vision for transition. Notably, Nx DTE supports incremental adoption.
+- Patience is paramount during the tuning phase to determine the optimal number of agents.
+- While results might vary, Adrian humorously assures that one can always bank on the Nx team for support. 😅
+
+## Vanquishing Deployment Dragons with Nx wizardry
+
+**Speaker:** [Miroslav Jonas](https://twitter.com/meeroslav)
+[Slides](https://speakerdeck.com/meeroslav/vanquishing-deployment-dragons-with-nx-wizardry)
+
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=jGF8vo2ChfI" /%}
+
+There’s not much to say here. Lean back and [immerse yourself into the world of dragons and wizards.](https://www.youtube.com/watch?v=jGF8vo2ChfI)
+
+## Optimizing your OSS infrastructure with Nx Plugins
+
+**Speaker:** [Brandon Roberts](https://twitter.com/brandontroberts)
+[Slides](https://github.com/brandonroberts/nx-conf-2023/blob/main/nx-oss-infrastructure.pdf)
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=bNuXH25CTO0" /%}
+
+Brandon discussed his work on the open-source tool [Analog](https://analogjs.org/) and how Nx Plugins are crucial to its development.
+
+He introduced Analog, shedding light on its foundational ecosystem and the its core features.
+
+![](/blog/images/2023-10-13/bodyimg21.webp)
+
+Nx plays a crucial role in helping integrate and maintain these different tools:
+
+![](/blog/images/2023-10-13/bodyimg22.webp)
+
+How? Brandon dives straight into it by explaining how Nx plugins in particular can be useful, explaining:
+
+- features of Nx plugins such as generators, executors, automated migrations, presets and how to use them just locally to automate your workspace
+- how to create a new plugin
+- the anatomy of a generator and how they can be useful in scaffolding new setups, but also integrating technology, like adding tRPC to your stack, etc.
+- similarly Nx executors provide a thin abstraction layer over the actual commands, allowing the plugin developer to update the underlying tooling without necessarily disrupting the end user
+- most importantly allowing to write automatic migrations he can leverage with Analog, like running `nx migrate @analogjs/platform@latest` to update a given workspace automatically to the latest version, across potentially breaking changes
+
+Brandon highlighted a pivotal aspect for OSS package/framework authors: the power to not just assimilate into pre-existing Nx workspaces via custom Nx plugins but also to steer the entire workspace setup process. This is particularly beneficial when tailored setups specific to individual use cases are required. By leveraging an [Nx preset](/extending-nx/recipes/create-preset), one can achieve this tailored configuration. Brandon also touched upon the possibility of advancing further by constructing an [install package](/extending-nx/recipes/create-install-package) through Nx.
+
+## Level Up Your Productivity with Nx Console
+
+**Speaker:** [Jonathan Cammisuli](https://twitter.com/jcammisuli) & [Max Kless](https://twitter.com/MaxKless)
+[Slides](https://github.com/Cammisuli/nx-conf-2023/tree/main/tools/presentation)
+
+Watch on YouTube:
+{% youtube src="https://www.youtube.com/watch?v=TTjVcWCdwVY" /%}
+
+Jon and Max are the masterminds behind [Nx Console](/getting-started/editor-setup#integrate-with-editors), the Nx IDE extension for Code and JetBrains.
+
+They mention the release of the JetBrains IDE support earlier this year and give a big shoutout to [Issam](https://github.com/iguissouma) who was the original author of the Nx Console Webstorm community plugin and who helped a lot with the official Nx Console version for JetBrains IDE.
+
+Jon and Max demo the new IntelliJ version of Nx console and how it properly integrates as well as how they wrote the new UI completely from the ground up [using Lit](/blog/2023-06-29-nx-console-gets-lit).
+
+Clearly they did not spare showing off the awesome new graph capabilities built into Nx Console that allow you to directly navigate to files.
+
+![](/blog/images/2023-10-13/bodyimg23.webp)
+
+## That’s a wrap
+
+If you enjoyed these, [subscribe to our YouTube channel](https://www.youtube.com/@nxdevtools) where we keep releasing educational content and fun videos.
+
+---
+
+## Learn more
+
+- [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](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)

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

@@ -46,7 +46,7 @@ And you’ll have access to Nx generators so that you can generate Vue applicati
 
 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](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial).
+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
 
@@ -141,7 +141,7 @@ Finally, generators will now factory in your current working directory, so you c
 
 ## The NEW Nx AI ChatBot
 
-We’ve added a new AI ChatBot to our docs site. You can access it now at [https://nx.dev/ai-chat](https://nx.dev/ai-chat).
+We’ve added a new AI ChatBot to our docs site. You can access it now at [https://nx.dev/ai-chat](/ai-chat).
 
 ![](/blog/images/2023-10-20/bodyimg4.gif)
 
@@ -170,9 +170,9 @@ We’ve also removed the need to specify `cacheableOperations` at the task-runne
 }
 ```
 
-If you use the `nx migrate` command, all updates will be handled for you using the `targetDefaults` in your `nx.json` file. [More in the docs.](https://nx.dev/features/cache-task-results)
+If you use the `nx migrate` command, all updates will be handled for you using the `targetDefaults` in your `nx.json` file. [More in the docs.](/features/cache-task-results)
 
-We’ve been working hard at reducing and simplifying all the configuration required for your Nx workspaces. Checkout our latest guide on how to [Reduce Repetitive Configuration](https://nx.dev/recipes/running-tasks/reduce-repetitive-configuration) for more, and stay tuned as we’ve got new efforts underway to make this simplification even more appealing!
+We’ve been working hard at reducing and simplifying all the configuration required for your Nx workspaces. Checkout our latest guide on how to [Reduce Repetitive Configuration](/recipes/running-tasks/reduce-repetitive-configuration) for more, and stay tuned as we’ve got new efforts underway to make this simplification even more appealing!
 
 ## Nx Repo Dog-Fooding Nx Workflows
 
@@ -226,15 +226,15 @@ In Nx 17, we removed any remaining traces of `tslint` from our linter package, s
 
 As we solidify this command, we intend to bring robust support for various versioning and publishing strategies, as well as built-in support for publishing packages or modules to a variety of languages, registries, and platforms.
 
-For more [checkout our API docs](https://nx.dev/nx-api/nx/documents/release), and be sure to catch James Henry’s announcement of this new command at [Nx Conf](https://dev.to/nx/nx-conf-2023-recap-53ep):
+For more [checkout our API docs](/nx-api/nx/documents/release), and be sure to catch James Henry’s announcement of this new command at [Nx Conf](https://dev.to/nx/nx-conf-2023-recap-53ep):
 
 {% youtube src="https://www.youtube.com/embed/p5qW5-2nKqI?si=FzpGMJwPVINc1hgL" /%}
 
 ## Experimental: Nx Project Inference API v2
 
-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](https://nx.dev/extending-nx/recipes/project-graph-plugins).
+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](https://nx.dev/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](/getting-started/tutorials/vue-standalone-tutorial).
 
 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.
 
@@ -244,7 +244,7 @@ For most developers, the main thing you need to know is that plugins may now add
 > nx show project <project_name>
 ```
 
-For plugin authors, check out the [v2 documentation](https://nx.dev/extending-nx/recipes/project-graph-plugins) to see how you can take advantage of the new API to deliver a better experience to your users.
+For plugin authors, check out the [v2 documentation](/extending-nx/recipes/project-graph-plugins) to see how you can take advantage of the new API to deliver a better experience to your users.
 
 ## 20k Github Stars!!
 
@@ -254,7 +254,7 @@ Nx is SOOO CLOSE to 20,000 stars on github! If Nx has been helpful to you, [plea
 
 ## How to Update Nx
 
-Nx is known to [help you automatically migrate](https://nx.dev/features/automate-updating-dependencies) to the new version (including potentially breaking changes). To update simply run:
+Nx is known to [help you automatically migrate](/features/automate-updating-dependencies) to the new version (including potentially breaking changes). To update simply run:
 
 ```shell
 > npx nx migrate latest
@@ -274,7 +274,7 @@ That’s all for now folks! We’re just starting up a new iteration of developm
 
 ## Learn more
 
-- [Nx Docs](https://nx.dev/getting-started/intro)
+- [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)

docs/blog/2023-11-22-unit-testing-expo.md

@@ -0,0 +1,335 @@
+---
+title: Unit Testing Expo Apps With Jest
+authors: [Emily Xiong]
+cover_image: '/blog/images/2023-11-22/featured_img.webp'
+tags: [nx, unit testing]
+---
+
+In my latest [blog](https://dev.to/nx/step-by-step-guide-to-creating-an-expo-monorepo-with-nx-3b17), I successfully navigated through the steps of setting up an Expo Monorepo with [Nx](). The next challenge? Testing! This blog dives into:
+
+- Crafting effective unit tests for Expo components utilizing Jest
+- Addressing common issues encountered during unit testing
+
+Repo:
+{% github-repository url="https://github.com/xiongemi/nx-expo-monorepo" /%}
+
+## Stacks
+
+Here’s my setup
+
+- Testing framework: [jest](https://jestjs.io/)
+- Testing library: [@testing-library/react-native](https://callstack.github.io/react-native-testing-library/)
+- Jest Preset: [jest-expo](https://www.npmjs.com/package/jest-expo)
+
+## Writing and Running Unit Tests
+
+When you use Nx, it not only configures and sets up Jest, but also creates a default unit test for every expo component that is being generated. Here’s what that looks like:
+
+```typescript
+import { render } from '@testing-library/react-native';
+import React from 'react';
+
+import Loading from './loading';
+
+describe('Loading', () => {
+  it('should render successfully', () => {
+    const { root } = render(<Loading />);
+    expect(root).toBeTruthy();
+  });
+});
+```
+
+To run all unit tests for a given project, use:
+
+```shell
+npx nx test <project-name>
+```
+
+Here’s the output of running this for my example app:
+
+![terminal output](/blog/images/2023-11-22/bodyimg1.webp)
+
+When it comes to writing tests, the [React Native Testing Library](https://callstack.github.io/react-native-testing-library/docs/api-queries) is a game-changer for writing cleaner unit tests in React Native applications. Its intuitive query API simplifies the process of selecting elements within your components, making it straightforward to write more maintainable and readable tests. You mark elements with a `testID`
+
+```html
+<Headline testID="title">{film.title}</Headline>
+```
+
+Then in the test file, you can use the function `getByTestId` to query `testID`:
+
+```typescript
+const { getByTestId } = render(<your component>);
+expect(getByTestId('title')).toHaveTextContent(...);
+```
+
+You can find more options for querying elements on the official React Native Testing Library docs: [https://callstack.github.io/react-native-testing-library/docs/api-queries](https://callstack.github.io/react-native-testing-library/docs/api-queries).
+
+## Troubleshooting Common Issues When Writing Tests
+
+However, unit tests do not always pass. Here are some common errors I ran into and how to resolve them.
+
+### **Error: AsyncStorage is null.**
+
+I am using the library `@react-native-async-storage/async-storage`, and I got the below error when running unit testing:
+
+```shell
+ \[@RNC/AsyncStorage\]: NativeModule: AsyncStorage is null.
+
+    To fix this issue try these steps:
+
+      • Rebuild and restart the app.
+
+      • Run the packager with \`--reset-cache\` flag.
+
+      • If you are using CocoaPods on iOS, run \`pod install\` in the \`ios\` directory and then rebuild and re-run the app.
+
+      • If this happens while testing with Jest, check out docs how to integrate AsyncStorage with it: https://react-native-async-storage.github.io/async-storage/docs/advanced/jest
+
+    If none of these fix the issue, please open an issue on the Github repository: https://github.com/react-native-async-storage/async-storage/issues
+
+       5 | import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
+       6 | import { Platform } from 'react-native';
+    >  7 | import AsyncStorage from '@react-native-async-storage/async-storage';
+```
+
+The issue is that `@react-native-async-storage/async-storage` library can only be used in `NativeModule`. Since unit testing with Jest only tests JS/TS file logic, I need to mock this library.
+
+In the app’s test-setup.ts file, add the below lines:
+
+```typescript
+jest.mock('@react-native-async-storage/async-storage', () =>
+  require('@react-native-async-storage/async-storage/jest/async-storage-mock')
+);
+```
+
+## Error: Could not find “store”
+
+I am using Redux for state management, and I got this error for my stateful components:
+
+```
+Could not find "store" in the context of "Connect(Bookmarks)". Either wrap the root component in a <Provider>, or pass a custom React context provider to <Provider> and the corresponding React context consumer to Connect(Bookmarks) in connect options.
+```
+
+To fix this, the simple way is to mock a redux store. I need to install [redux-mock-store](https://github.com/reduxjs/redux-mock-store) and its typing:
+
+{% tabs %}
+{% tab label="npm" %}
+
+```shell
+npm install redux-mock-store @types/redux-mock-store --save-dev
+```
+
+{% /tab %}
+
+{% tab label="yarn" %}
+
+```shell
+yarn add redux-mock-store @types/redux-mock-store --dev
+```
+
+{% /tab %}
+{% /tabs %}
+
+Then I can create a mock store using this library like the below code:
+
+```typescript
+import configureStore, { MockStoreEnhanced } from 'redux-mock-store';
+
+  const mockStore = configureStore<any>(\[\]);
+
+  let store: MockStoreEnhanced<any>;
+
+  beforeEach(() => {
+    store = mockStore({});
+    store.dispatch = jest.fn();
+  });
+```
+
+For example, one of my stateful components’ unit test will become:
+
+```typescript
+import React from 'react';
+import { render } from '@testing-library/react-native';
+import { Provider } from 'react-redux';
+import configureStore, { MockStoreEnhanced } from 'redux-mock-store';
+import { RootState, initialRootState } from '@nx-expo-monorepo/states/cat';
+
+import Bookmarks from './bookmarks';
+
+describe('Bookmarks', () => {
+  const mockStore = configureStore<RootState>(\[\]);
+
+  let store: MockStoreEnhanced<RootState>;
+
+  beforeEach(() => {
+    store = mockStore(initialRootState);
+    store.dispatch = jest.fn();
+  });
+
+  it('should render successfully', () => {
+    const { container } = render(
+      <Provider store={store}>
+        <Bookmarks />
+      </Provider>
+    );
+    expect(container).toBeTruthy();
+  });
+});
+```
+
+The above code will apply the initial redux state to my components.
+
+### Error: No QueryClient set
+
+Because I use [TanStack Query](https://tanstack.com/query/latest) , when I run unit tests, I have this error:
+
+```
+No QueryClient set, use QueryClientProvider to set one
+```
+
+This error occurred because I used `useQuery` from `@tanstack/react-query` in my component; however, in this unit test, the context of this hook is not provided.
+
+To solve this, I can just mock the `useQuery` function:
+
+```typescript
+import * as ReactQuery from '@tanstack/react-query';
+
+jest.spyOn(ReactQuery, 'useQuery').mockImplementation(
+  jest.fn().mockReturnValue({
+    data: 'random cat fact',
+    isLoading: false,
+    isSuccess: true,
+    refetch: jest.fn(),
+    isFetching: false,
+    isError: false,
+  })
+);
+```
+
+### Error: Couldn’t find a navigation object
+
+If you use `@react-navigation` library for navigation, and inside your component, there are hooks from this library like `useNavigation` and `useRoute`, you are likely to get this error:
+
+```
+Couldn't find a navigation object. Is your component inside NavigationContainer?
+```
+
+The fix this, I need to mock the `@react-nativgation/native` library. In the app’s test-setup.ts file, I need to add:
+
+```typescript
+jest.mock('@react-navigation/native', () => {
+  return {
+    useNavigation: () => ({
+      navigate: jest.fn(),
+      dispatch: jest.fn(),
+      setOptions: jest.fn(),
+    }),
+    useRoute: () => ({
+      params: {
+        id: '123',
+      },
+    }),
+  };
+});
+```
+
+### SyntaxError: Unexpected token ‘export’
+
+I got this error when using a library with ECMAScript Module (ESM), such as `[udid](https://github.com/uuidjs/uuid)`:
+
+```
+ /Users/emilyxiong/Code/nx-expo-monorepo/node\_modules/uuid/dist/esm-browser/index.js:1
+    ({"Object.<anonymous>":function(module,exports,require,\_\_dirname,\_\_filename,jest){export { default as v1 } from './v1.js';
+                                                                                      ^^^^^^
+
+    SyntaxError: Unexpected token 'export'
+
+       5 | import { connect } from 'react-redux';
+       6 | import 'react-native-get-random-values';
+    >  7 | import { v4 as uuidv4 } from 'uuid';
+```
+
+Jest does not work with ESM out of the box. The simple solution is to map this library to the CommonJS version of this library.
+
+In the app’s `jest.config.ts`, there should be an option called `moduleNameMapper`. The library I used is called `uuid`, so I need to add the map `uuid: require.resolve(‘uuid’)` under `moduleNameMapper`. So when the code encounters imports from `uuid` library, it will resolve the CommonJS version of it:
+
+```typescript
+module.exports = {
+  moduleNameMapper: {
+    uuid: require.resolve('uuid'),
+  },
+};
+```
+
+Alternatively, I can also mock this library in the test files:
+
+```typescript
+import { v4 as uuidv4 } from 'uuid';
+
+jest.mock('uuid', () => {
+  return {
+    v4: jest.fn(() => 1),
+  };
+});
+```
+
+## Error: Jest encountered an unexpected token
+
+I got this error when I was importing from a library such as [react-native-vector-icons](https://github.com/oblador/react-native-vector-icons):
+
+```
+ console.error
+      Jest encountered an unexpected token
+
+      Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.
+
+      Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.
+
+      By default "node\_modules" folder is ignored by transformers.
+
+      Here's what you can do:
+       • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
+       • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
+       • To have some of your "node\_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
+       • If you need a custom transformation specify a "transform" option in your config.
+       • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.
+
+      You'll find more details and examples of these config options in the docs:
+      https://jestjs.io/docs/configuration
+      For information about custom transformations, see:
+      https://jestjs.io/docs/code-transformation
+```
+
+To fix this, add this library name to `transformIgnorePatterns` in the app's jest.config.ts.
+
+What is `transformIgnorePatterns`? The `transformIgnorePatterns` allows developers to specify which files shall be transformed by Babel. `transformIgnorePatterns` is an array of regexp pattern strings that should be matched against all source file paths before the transformation. If the file path matches any patterns, it will not be transformed by Babel.
+
+By default, Jest will ignore all the files under node_modules and only transform the files under the project’s src.
+
+However, some libraries such as `react-native-paper` or `react-native-svg`, the library files are in `.ts` or `.tsx`. These files are not compiled to `js`. So I need to add these libraries' names to `transformIgnorePatterns`, so these libraries will be transformed by Babel along with my project. source file. The default generated `jest.config.js` already has:
+
+```
+transformIgnorePatterns: \[
+    'node\_modules/(?!((jest-)?react-native|@react-native(-community)?)|expo(nent)?|@expo(nent)?/.\*|@expo-google-fonts/.\*|react-navigation|@react-navigation/.\*|@unimodules/.\*|unimodules|sentry-expo|native-base|react-native-svg)',
+\]
+```
+
+If I have an error related to a library with an unexpected token, I need to check whether they are compiled or not.
+
+- If this library source files are already transformed to `.js`, then its name should match regex, so it would be ignored, so it will NOT be transformed.
+- If this library source files are NOT transformed to `.js` (e.g. still in `.ts` or `.tsx`), then its name should NOT match regex, so it will be transformed.
+
+## Summary
+
+Here are some common errors that I will probably run into while doing unit testing. The solution to most problems is to find a way to mock a library that is not relevant to my component logic.
+
+With Nx, you do not need to explicitly install any testing library, so you can dive right in and focus on writing the tests rather than spending time on setup.
+
+## Learn more
+
+- [Add Cypress, Playwright, and Storybook to Nx Expo Apps](https://medium.com/@emilyxiong/add-cypress-playwright-and-storybook-to-nx-expo-apps-1d3e409ce834)
+- 🧠 [Nx Docs](/getting-started/intro)
+- 👩‍💻 [Nx GitHub](https://github.com/nrwl/nx)
+- 💬 [Nx Community Discord](/community)
+- 📹 [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- 🚀 [Speed up your CI](https://nx.app/)

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

@@ -31,7 +31,7 @@ It is that time again: getting flooded by Year of Review blog posts. We did it l
 
 ## Top 10 Nx Highlights of 2023
 
-We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: [https://nx.dev/changelog](https://nx.dev/changelog) or check out our [Dev.to collection](https://dev.to/nx).
+We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: [https://nx.dev/changelog](/changelog) or check out our [Dev.to collection](https://dev.to/nx).
 
 We've picked out 10 highlights for you.
 
@@ -45,7 +45,7 @@ Following this, we revamped the TypeScript dependency resolution, observing an a
 
 {% tweet url="https://twitter.com/juristr/status/1726977598218199302" /%}
 
-Such enhancements are especially crucial for the efficient [project graph calculation](https://nx.dev/features/explore-graph). As we continue to evolve Nx, Rust will play a key role in optimizing performance-critical components. This strategic use of Rust complements our ongoing commitment to TypeScript, ensuring Nx remains as extensible and powerful as ever.
+Such enhancements are especially crucial for the efficient [project graph calculation](/features/explore-graph). As we continue to evolve Nx, Rust will play a key role in optimizing performance-critical components. This strategic use of Rust complements our ongoing commitment to TypeScript, ensuring Nx remains as extensible and powerful as ever.
 
 ### First Class Vite Support
 
@@ -55,7 +55,7 @@ Our collaboration with our friends in the Vite core team has been incredibly fru
 
 ![](/blog/images/2023-12-28/bodyimg1.webp)
 
-We also built some powerful code generators that not only facilitate a seamless [transition from Webpack to Vite](https://nx.dev/nx-api/vite/generators/configuration#nxviteconfiguration) but also pave the way for an effortless [migration from a CRA-based setup](https://nx.dev/recipes/adopting-nx/adding-to-existing-project) to a modern Nx + Vite based workspace. To see this process in action, [check out this short video](https://www.youtube.com/watch?v=zvYb7XCLQzU).
+We also built some powerful code generators that not only facilitate a seamless [transition from Webpack to Vite](/nx-api/vite/generators/configuration#nxviteconfiguration) but also pave the way for an effortless [migration from a CRA-based setup](/recipes/adopting-nx/adding-to-existing-project) to a modern Nx + Vite based workspace. To see this process in action, [check out this short video](https://www.youtube.com/watch?v=zvYb7XCLQzU).
 
 [AnalogJS](https://analogjs.org/) — the fullstack Angular meta-framework which also heavily builds on top of Vite — is using the `@nx/vite` plugin to power its Angular and Nx based workspaces.
 
@@ -65,7 +65,7 @@ We also spoke at both editions of [ViteConf](https://viteconf.org/23/). If you
 
 Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we’ll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like [release-it](https://github.com/release-it/release-it), [changesets](https://github.com/changesets/changesets), or custom Node scripts, similar to our approach in the Nx repository.
 
-However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we’ve introduced [the “nx release” command](https://nx.dev/features/manage-releases), a solution designed to seamlessly integrate these processes into the Nx workflow.
+However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we’ve introduced [the “nx release” command](/features/manage-releases), a solution designed to seamlessly integrate these processes into the Nx workflow.
 
 James Henry gave a deep dive talk of an early version of it at this year’s Nx Conf:
 
@@ -76,7 +76,7 @@ Since its introduction, the “nx release” feature has significantly evolved,
 - Versioning packages offering support for both independent and “locked” versioning strategies.
 - Releasing packages in the correct sequence, ensuring dependency integrity.
 
-Beyond these core functionalities, the feature also includes a robust grouping mechanism, supports semantic versioning, and changelog generation. Additionally, it provides various release targets, such as GitHub and NPM. For those having special requirements, the [programmatic API](https://nx.dev/features/manage-releases#using-the-programmatic-api-for-nx-release) offers maximum flexibility.
+Beyond these core functionalities, the feature also includes a robust grouping mechanism, supports semantic versioning, and changelog generation. Additionally, it provides various release targets, such as GitHub and NPM. For those having special requirements, the [programmatic API](/features/manage-releases#using-the-programmatic-api-for-nx-release) offers maximum flexibility.
 
 ### Improved Node Backend Development: Fastify and Docker
 
@@ -192,7 +192,7 @@ Here’s a video that walks you through:
 
 {% youtube src="https://www.youtube.com/embed/Vy4d0-SF5cY?si=mHatqRPRqHAK0X9o" /%}
 
-But we wouldn’t be talking about Nx if we didn’t also look into speeding up TypeScript compilation for large monorepos. We called it “[batch mode](https://nx.dev/showcase/benchmarks/tsc-batch-mode)”. When enabling batch mode, Nx leverages the underlying [project graph](https://nx.dev/features/explore-graph) to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to [our benchmarks](https://github.com/nrwl/large-ts-monorepo), batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.
+But we wouldn’t be talking about Nx if we didn’t also look into speeding up TypeScript compilation for large monorepos. We called it “[batch mode](/showcase/benchmarks/tsc-batch-mode)”. When enabling batch mode, Nx leverages the underlying [project graph](/features/explore-graph) to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to [our benchmarks](https://github.com/nrwl/large-ts-monorepo), batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.
 
 ![](/blog/images/2023-12-28/bodyimg3.gif)
 
@@ -218,17 +218,17 @@ And you’ll then have access to Nx generators so you can create Vue application
 
 ![](/blog/images/2023-12-28/bodyimg6.gif)
 
-Checkout out our [Vue standalone tutorial](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial) for more, as well as our [Vue API docs](https://nx.dev/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 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!
 
 ### Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
 
-Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of [community plugin contributions](https://nx.dev/plugin-registry). Furthermore, Nx’s adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.
+Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of [community plugin contributions](/plugin-registry). Furthermore, Nx’s adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.
 
 In 2023 we kept improving Nx’s extensibility, unifying the Nx plugin development model and how you develop workspace-local automations. You can now scaffold a new plugin into your Nx workspace and run it right away which makes it an interesting approach to automate your monorepo.
 
 {% youtube src="https://www.youtube.com/embed/myqfGDWC2go?si=q6_9JReS1nF8d3pZ" /%}
 
-When creating automations with Nx you cannot just enhance existing Nx workspaces, but also develop a complete [Nx preset](https://nx.dev/extending-nx/recipes/create-preset) that controls the entire appearance of an Nx workspace. Basically your own, personalized `create-nx-workspace`. You can publish and then use your preset like:
+When creating automations with Nx you cannot just enhance existing Nx workspaces, but also develop a complete [Nx preset](/extending-nx/recipes/create-preset) that controls the entire appearance of an Nx workspace. Basically your own, personalized `create-nx-workspace`. You can publish and then use your preset like:
 
 ```shell
 npx create-nx-workspace myrepo --preset=@yourpkg/nx-preset
@@ -250,7 +250,7 @@ Simply put, Module Federation allows a Javascript application running in a brows
 
 This is an exciting development as it allows a paradigm shift in how you can architect, build, and deploy Javascript applications! And this is especially exciting for monorepo fans, as Nx has best-in-class support for module federation that makes a Module Federation approach easy to adopt and simple to understand!
 
-Currently, our `@nx/angular` and `@nx/react` plugins both have generators to [create a “host” application](https://nx.dev/recipes/module-federation/create-a-host) that will load and consume federated modules from [“remote” applications](https://nx.dev/recipes/module-federation/create-a-remote), which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:
+Currently, our `@nx/angular` and `@nx/react` plugins both have generators to [create a “host” application](/recipes/module-federation/create-a-host) that will load and consume federated modules from [“remote” applications](/recipes/module-federation/create-a-remote), which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:
 
 ```shell
 nx serve host-application --devRemotes=remote-application
@@ -258,9 +258,9 @@ nx serve host-application --devRemotes=remote-application
 
 Where in the example above your host application is named “host-application” and a remote application that you want live updates on as you’re developing is named “remote-application”.
 
-Throughout 2023, we’ve continued to increase Nx’s support and general dev experience around Module Federation, including [adding a generator to federate an existing module](https://nx.dev/recipes/module-federation/federate-a-module), improving the local developer experience by improving local webserver performance, and introducing the concept of [Dynamic Module Federation](https://nx.dev/recipes/angular/dynamic-module-federation-with-angular#advanced-angular-micro-frontends-with-dynamic-module-federation) which will allow you to dynamically specify the location of your remote applications via a “module-federation.manifest.json” file!
+Throughout 2023, we’ve continued to increase Nx’s support and general dev experience around Module Federation, including [adding a generator to federate an existing module](/recipes/module-federation/federate-a-module), improving the local developer experience by improving local webserver performance, and introducing the concept of [Dynamic Module Federation](/recipes/angular/dynamic-module-federation-with-angular#advanced-angular-micro-frontends-with-dynamic-module-federation) which will allow you to dynamically specify the location of your remote applications via a “module-federation.manifest.json” file!
 
-At Nx, we’re excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx’s CI capabilities, in particular allowing for [much shorter build times](https://nx.dev/concepts/module-federation/faster-builds-with-module-federation#faster-builds-with-module-federation) especially for larger Angular applications.
+At Nx, we’re excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx’s CI capabilities, in particular allowing for [much shorter build times](/concepts/module-federation/faster-builds-with-module-federation#faster-builds-with-module-federation) especially for larger Angular applications.
 
 ## Many OSS repos adopt Nx
 
@@ -281,11 +281,11 @@ I picked out some of the more well-known OSS repos that started using Nx this ye
 
 [**RxJS**](https://github.com/ReactiveX/rxjs) — The library for reactive programming in JavaScript. It is widely popular, with over 40 million downloads/week on NPM. RxJS only recently adopted Nx, not only leveraging speed improvements via caching, but also leveraging Nx’s latest `nx release` feature to publish packages to NPM.
 
-[**AnalogJS**](https://analogjs.org/) — Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses [Nx’s DevKit](https://nx.dev/extending-nx/intro/getting-started) to create tools that work great in both Nx and Angular CLI workspaces.
+[**AnalogJS**](https://analogjs.org/) — Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses [Nx’s DevKit](/extending-nx/intro/getting-started) to create tools that work great in both Nx and Angular CLI workspaces.
 
-[**Qwikifier**](https://github.com/qwikifiers/qwik-nx) — The Qwikifiers community built a dedicated Nx plugin to combine the power of Qwik and Nx. Their repo is a great example of building Nx plugins and [using Nx to build your own CLI](https://nx.dev/extending-nx/recipes/create-install-package).
+[**Qwikifier**](https://github.com/qwikifiers/qwik-nx) — The Qwikifiers community built a dedicated Nx plugin to combine the power of Qwik and Nx. Their repo is a great example of building Nx plugins and [using Nx to build your own CLI](/extending-nx/recipes/create-install-package).
 
-[**Builder.io Mitosis**](https://github.com/BuilderIO/mitosis) — [BuilderIO](https://www.builder.io/) has an ambitious compiler project that allows you to write a component once and then compile it to different frameworks. Check out their [mind-blowing demo page](https://mitosis.builder.io/?outputTab=G4VwpkA%3D). They adopted Nx to [coordinate task dependencies](https://nx.dev/concepts/task-pipeline-configuration) and speed up their CI builds.
+[**Builder.io Mitosis**](https://github.com/BuilderIO/mitosis) — [BuilderIO](https://www.builder.io/) has an ambitious compiler project that allows you to write a component once and then compile it to different frameworks. Check out their [mind-blowing demo page](https://mitosis.builder.io/?outputTab=G4VwpkA%3D). They adopted Nx to [coordinate task dependencies](/concepts/task-pipeline-configuration) and speed up their CI builds.
 
 [**Ghost**](https://github.com/TryGhost/Ghost) — Are you into blogging? You might want to look at [Ghost](https://ghost.org/). They were using Lerna in the past and migrated to a fully Nx-powered workspace.
 
@@ -293,13 +293,13 @@ And these are just some of them that joined in 2023. If I missed some cool ones
 
 ## Nx Community
 
-Nx has a huge community! We’re lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or [creating awesome plugins](https://nx.dev/plugin-registry).
+Nx has a huge community! We’re lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or [creating awesome plugins](/plugin-registry).
 
-**Nx Champions** — This year we finally launched which we had planned for a long time. Our [Nx Champions](https://nx.dev/community) program.
+**Nx Champions** — This year we finally launched which we had planned for a long time. Our [Nx Champions](/community) program.
 
 ![](/blog/images/2023-12-28/bodyimg7.webp)
 
-These are individuals who stood out for their contributions and passion for helping within the Nx community. We wanted to build a more connected relationship with these folks and have a channel to gather more direct feedback as well. Get to know [all of our champions](https://nx.dev/community).
+These are individuals who stood out for their contributions and passion for helping within the Nx community. We wanted to build a more connected relationship with these folks and have a channel to gather more direct feedback as well. Get to know [all of our champions](/community).
 
 **New Discord server** — Around September we also switched over from our previous Nx Slack community to a brand new [**Nx community Discord**](https://go.nx.dev/community), which is already 2,600 members and counting. Discord is popular among OSS communities and allows new folks to join easily. In addition, we now have a dedicated forum integrated, as well as a couple of useful automations. More coming next year!
 
@@ -309,16 +309,16 @@ Make sure [you join](https://go.nx.dev/community)!
 
 Our [Youtube channel](https://www.youtube.com/@nxdevtools) has grown to over 15k subscribers and peaks of 65k views a month. We love to provide educational video content, so make sure to subscribe! It got a little silent towards the end of the year, but we’ve been working a lot behind the scenes. So stay tuned!
 
-We also poured a lot of [effort into the docs](https://nx.dev/getting-started/intro). We restructured them following the [Diataxis](https://diataxis.fr/) to make pages less overwhelming and more structured based on their type of content. You’ll find
+We also poured a lot of [effort into the docs](/getting-started/intro). We restructured them following the [Diataxis](https://diataxis.fr/) to make pages less overwhelming and more structured based on their type of content. You’ll find
 
-- [**Concept docs**](https://nx.dev/concepts) — which explain some of the inner workings and mental model behind certain features. Like [how caching works](https://nx.dev/concepts/how-caching-works).
-- [**Recipes**](https://nx.dev/recipes) — which are solution oriented. You already know how to cook, we provide the exact recipe for it.
-- [**Tutorials**](https://nx.dev/getting-started/tutorials) — for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
-- [**Reference**](https://nx.dev/reference) and [**API docs**](https://nx.dev/nx-api) — pure, raw and to the point.
+- [**Concept docs**](/concepts) — which explain some of the inner workings and mental model behind certain features. Like [how caching works](/concepts/how-caching-works).
+- [**Recipes**](/recipes) — which are solution oriented. You already know how to cook, we provide the exact recipe for it.
+- [**Tutorials**](/getting-started/tutorials) — for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
+- [**Reference**](/reference) and [**API docs**](/nx-api) — pure, raw and to the point.
 
-We created a brand new [“Why Nx”](https://nx.dev/getting-started/why-nx) page explaining the overall architecture of Nx including a [brand new video](https://www.youtube.com/watch?v=-_4WMl-Fn0w) giving you a holistic overview of what Nx is capable of.
+We created a brand new [“Why Nx”](/getting-started/why-nx) page explaining the overall architecture of Nx including a [brand new video](https://www.youtube.com/watch?v=-_4WMl-Fn0w) giving you a holistic overview of what Nx is capable of.
 
-We also refreshed our [entry pages](https://nx.dev/getting-started/intro), including dedicated examples of using Nx with popular stacks:
+We also refreshed our [entry pages](/getting-started/intro), including dedicated examples of using Nx with popular stacks:
 
 ![Examples include Express, Vue, Next, Nuxt, Rract Native, Rust, Go, Storybook, and more.](/blog/images/2023-12-28/bodyimg8.webp)
 
@@ -328,19 +328,19 @@ You can also browse them in the [nx-recipes](https://github.com/nrwl/nx-recipes)
 
 {% tweet url="https://twitter.com/juristr/status/1726977598218199302" /%}
 
-And obviously, we jumped on the AI train as well. A couple of months ago, we added the [Nx Assistant](https://nx.dev/ai-chat). A ChatGPT-powered interface trained on our docs. [Katerina](https://twitter.com/psybercity) wrote about it [on our blog](https://blog.nrwl.io/nx-docs-ai-assistant-433d238e45d4). 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 on our docs. [Katerina](https://twitter.com/psybercity) wrote about it [on our blog](https://blog.nrwl.io/nx-docs-ai-assistant-433d238e45d4). 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
 
-Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx’s robust tooling, and later, when the need arises, seamlessly [migrate to a monorepo](https://nx.dev/recipes/tips-n-tricks/standalone-to-integrated).
+Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx’s robust tooling, and later, when the need arises, seamlessly [migrate to a monorepo](/recipes/tips-n-tricks/standalone-to-integrated).
 
 However, Nx’s true strength becomes most apparent at scale, typically within a monorepo setup. We wanted to capture it in our new tagline: **Smart Monorepos — Fast CI**.
 
 {% twitter url="https://twitter.com/juristr/status/1734558895547568634" /%}
 
-Setting up an efficient and maintainable CI process for monorepos can be a complex task, so we’ve also made it a focal point in our new tagline. Nx expands beyond the local development experience, helping you set up an efficient CI process. We’re publicly launching [Nx Agents](https://nx.dev/ci/features/distribute-task-execution) to add seamless distribution to your CI pipeline, and more are coming in 2024.
+Setting up an efficient and maintainable CI process for monorepos can be a complex task, so we’ve also made it a focal point in our new tagline. Nx expands beyond the local development experience, helping you set up an efficient CI process. We’re publicly launching [Nx Agents](/ci/features/distribute-task-execution) to add seamless distribution to your CI pipeline, and more are coming in 2024.
 
-As part of that, we also restructured our docs to have a section entirely dedicated to CI: [https://nx.dev/ci](https://nx.dev/ci/intro/ci-with-nx).
+As part of that, we also restructured our docs to have a section entirely dedicated to CI: [https://nx.dev/ci](/ci/intro/ci-with-nx).
 
 ## Nx Conf
 
@@ -360,8 +360,8 @@ Legacy CI systems are a performance and productivity bottleneck if you use a pow
 
 It has three components:
 
-- [**Nx Cach**](https://nx.dev/ci/features/remote-cache): Built-in local and remote caching to speed up your tasks and save you time and money. Available now.
-- [**Nx Agents**](https://nx.dev/ci/features/distribute-task-execution): A single line to enable distributed computation, across multiple machines. Fully managed agents, dynamically allocated based on PR size. Available early Feb.
+- [**Nx Cach**](/ci/features/remote-cache): Built-in local and remote caching to speed up your tasks and save you time and money. Available now.
+- [**Nx Agents**](/ci/features/distribute-task-execution): A single line to enable distributed computation, across multiple machines. Fully managed agents, dynamically allocated based on PR size. Available early Feb.
 - **Nx Workflows**: Next generation, fully managed CI solution with distribution at its core, designed from the ground up for monorepos. _Available later in 2024._
 
 Optimal parallelization and distribution, using the right numbers of agents for each PR, rerunning flaky tests, splitting and distributing large test suites, handling dependencies between tasks across machines — are just some of the things we can now handle automatically for you. Turn it on and enjoy the speed.
@@ -374,7 +374,7 @@ We took inspiration from VSCode. Any project you open in VSCode will work right
 
 The whole team is excited about it as the new experience feels much more elegant.
 
-As always, we try very hard not to break folks, so all your current workspaces will keep working, and we will [provide automatic migrations](https://nx.dev/features/automate-updating-dependencies) to bring you to this new way of using Nx.
+As always, we try very hard not to break folks, so all your current workspaces will keep working, and we will [provide automatic migrations](/features/automate-updating-dependencies) to bring you to this new way of using Nx.
 
 Exciting stuff! So keep an eye on our channels, and subscribe if you haven’t already ;)
 
@@ -382,7 +382,7 @@ Exciting stuff! So keep an eye on our channels, and subscribe if you haven’t a
 
 ## Learn more
 
-- [Nx Docs](https://nx.dev/getting-started/intro)
+- [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)

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

@@ -169,7 +169,7 @@ The spirit of this post is similar to Alan Kay's quote, "A change of perspective
 
 ---
 
-You can learn more about Nx Cloud on [nx.app](https://nx.app) and Nx open source on [nx.dev](https://nx.dev).
+You can learn more about Nx Cloud on [nx.app](https://nx.app) and Nx open source on [nx.dev]().
 
 **Nx Cloud Pro includes a 2-month free trial** that is definitely worth trying out if you're curious what Cloud Pro can do for your CI. You can try out Nx Agents, e2e test splitting, deflaking and more. [Learn more about Nx Cloud Pro.](https://nx.app/campaigns/pro)
 

docs/blog/2024-04-19-manage-your-gradle.md

@@ -25,7 +25,7 @@ This blog will show you:
 
 Before we start, let’s answer this question: what is Nx and why should we use it?
 
-From [nx.dev](https://nx.dev): “Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.” It sounds good, what benefits does it bring?
+From [nx.dev](): “Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.” It sounds good, what benefits does it bring?
 
 Nx adds the following features to your workspace:
 

docs/blog/2024-05-08-nx-19-release.md

@@ -0,0 +1,233 @@
+---
+title: Nx 19.0 Release!!
+authors: ['Zack DeRose']
+cover_image: '/blog/images/2024-05-08/nx-19-thumbnail.png'
+tags: [nx, release]
+---
+
+{% youtube
+src="https://youtu.be/U6eO8-w9DR0"
+title="Nx 19.0 Has Landed!!"
+width="100%" /%}
+
+Hey folks!
+
+It's been awhile since February, where in the midsts our big launch week, we launched Nx 18. Nx 18 introduced the biggest new enhancement to Nx to date: Project Crystal.
+
+[![Project Crystal](/blog/images/2024-02-05/featured_img.png)](/blog/2024-02-05-nx-18-project-crystal)
+
+You can read more on project crystal [here](/blog/2024-02-05-nx-18-project-crystal). The main thing to know though is that Project Crystal adjusts the idea of Nx plugins, so that the mere presence of the plugin in your Nx Workspace removes the need to maintain any configuration for most cases.
+
+Nx 18 was a significant departure for us in several ways - maybe the most noteworthy was that we broke our years-long cadence of releasing a new major version every 6 months.
+
+Nx 19 represents a return to form, matching the reliable 6-month schedule. Nx 19 is releasing now 6 months from when Nx 17 released, making Nx 18 a special case to match the impact that Project Crystal had on Nx as a whole.
+
+Here's the rundown of the major things we'll cover in this update:
+
+- [NEW PLUGIN: @nx/gradle](#new-plugin-nxgradle)
+- [Nx Atomizer Enhancements](#nx-atomizer-enhancements)
+- [Associated Technologies Added To Tasks](#associated-technologies-added-to-tasks)
+- [Generators to Convert to Project Crystal](#generators-to-convert-to-project-crystal)
+- [BREAKING CHANGE: Updating Bundled Environment Variables: `NX_` to `NX_PUBLIC_`](#breaking-change-updating-bundled-environment-variables-to)
+- [General Crystal Polishing](#general-crystal-polishing)
+- [Nx Cloud Updates!](#nx-cloud-updates)
+- [More Miscellaneous Updates!](#more-miscellaneous-updates)
+- [New Conference: Monorepo World 2024](#new-conference-monorepo-world-2024)
+- [Wrapping Up, And A Heartfelt Thank You](#wrapping-up-and-a-heartfelt-thank-you)
+- [Learn More](#learn-more)
+
+## NEW PLUGIN: @nx/gradle
+
+[![NEW PLUGIN: @nx/gradle](/blog/images/2024-04-19/featured_img.png)](/blog/2024-04-19-manage-your-gradle)
+
+We've launched a new first-party plugin for Gradle!
+
+Emily, the engineer that worked on this effort, posted an entire article where you can find the full details [here](/blog/2024-04-19-manage-your-gradle).
+
+Thanks to the benefits of Project Crystal - which allows us to determine information to create Nx Tasks based on the way your Gradle projects are setup - by adding this plugin, it makes it easy to add Gradle into an existing workspace without needing any Nx-specific configuration.
+
+In addition, you can now find [a new tutorial on using Nx with Gradle](/getting-started/tutorials/gradle-tutorial) which will expand on the [Spring framework](https://spring.io/)'s tutorial for multi-module projects and show you how Nx further enhances the developer experience of that workspace. This tutorial takes you all the way through setting up your CI pipeline with Nx Cloud, so be sure to check it out!
+
+As an editorial note, this Gradle plugin is a big step for Nx, as it represents the first major step we're taking outside of the Javascript ecosystem. This has always been the goal: to robustly support monorepos and full-stack development, even across language and ecosystem barriers. We're using this Gradle plugin internally for our closed-sourced projects (in particular Nx Cloud) and in [Nx Console](https://github.com/nrwl/nx-console/blob/master/package.json#L74) and we're very proud of this plugin and all that it represents.
+
+## Nx Atomizer Enhancements
+
+The Nx Atomizer launched in Nx 18 with Project Crystal. Essentially, "Atomizer" is the name we use to describe how Nx will automatically shard your e2e tests in your CI pipelines via our first party plugins. You can find out more information in the video below:
+
+{% youtube
+src="https://youtu.be/0YxcxIR7QU0"
+title="10x Faster e2e Tests!"
+width="100%" /%}
+
+While the Atomizer was great for reducing the time of end-to-end tests in CI pipelines, one unfortunate trade-off of the Atomizer was that rather than having a single task to represent your end-to-end validation tasks, you instead had a collection of tasks. This tended to clutter up tools when viewing your Nx Tasks. It also wasn't very clear which tasks belonged to which group!
+
+We've addressed this in Nx 19 by introducing the concept of Task Grouping inside of our tooling.
+
+Now, when running the command:
+
+```shell
+nx show project nx-dev-e2e --web
+```
+
+You'll see the following in the project view:
+
+![Nx Show Project Web View](/blog/images/2024-05-08/grouping-web-view.webp)
+
+Notice how all tasks are now appropriately grouped in the `E2E (CI)` group!
+
+You can also find the same enhancements in Nx Cloud. Below is a view of all tasks in the [CI pipeline](https://staging.nx.app/runs/ctbAZfiLy3):
+
+[![Grouped e2e tests in Nx Cloud](/blog/images/2024-05-08/nx-cloud-atomizer-groupings.gif)](https://staging.nx.app/runs/ctbAZfiLy3)
+
+Notice how all e2e groups are collapsed by default to give a concise view, while allowing you to expand to see how each individual task is progressing!
+
+Project Crystal is gathering the information to group your tasks, so this is automatically inferred for you based on the actual contents of your workspace. You can see this information by running the command:
+
+```shell
+nx show project nx-dev-e2e --json | jq
+```
+
+![Show Project JSON view](/blog/images/2024-05-08/show-project-json.webp)
+
+All Nx Plugins that support this concept of "Atomization" will do this automatically for you, and if you are writing a custom plugin for your own tool or special use-case, you can implect this inferrence to group your targets in Nx and Nx Cloud tooling as well. We'll be adding more documentation on how to implement this in your own plugins in the future.
+
+## Associated Technologies Added To Tasks
+
+We've added icons for associated technologies on tasks in the project detail web view:
+
+![Technology icons in Project Detail View](/blog/images/2024-05-08/icon-in-project-detail-view.gif)
+
+And in Nx Cloud:
+
+![Technology icons in Nx Cloud](/blog/images/2024-05-08/nx-cloud-icons.gif)
+
+This will help easily identify at-a-glance the technology your tasks are associated with. All this is supported out of the box by our plugins and you should see this as soon as updating to Nx 19.
+
+To see how we support this new feature, checkout the json view of our project again:
+
+```shell
+nx show project e2e-angular --json | jq
+```
+
+![Highlighting target metadata](/blog/images/2024-05-08/highlight-target-metadata.webp)
+
+## Generators to Convert to Project Crystal
+
+As part of Nx 19, we've included generators to our Playwright, Cypress, and ESLint plugins to allow you to easily convert your projects to opt into Project Crystal features!
+
+To convert your workspace, you can use the command:
+
+```shell
+nx generate convert-to-inferred
+```
+
+Before running this command you could expect your project detail view to look like this:
+
+```shell
+nx show project my-react-app-e2e --web
+```
+
+![Before Conversion](/blog/images/2024-05-08/before-conversion.webp)
+
+And after running the generator, you can expect your project detail view to look like this:
+
+![After Conversion](/blog/images/2024-05-08/after-conversion.webp)
+
+Notice that in addition to reducing the configuration in your `project.json` file, this generator will also turn on the Nx Atomizer for your Cypress and Playwright projects, so Nx will allow sharding for your end-to-end tasks in CI based on the tests present in your workspace going forward. Note that Nx Agents are very highly highly encouraged as a way of taking advantage of this sharding capability.
+
+As a note, if you cannot see `e2e-ci` tasks after converting your cypress projects, you can [take a closer look here](/nx-api/cypress/documents/overview#splitting-e2e-tasks-by-file) at how to configure them correctly.
+
+## BREAKING CHANGE: Updating Bundled Environment Variables: `NX_` to `NX_PUBLIC_`
+
+An important update for folks using environment variables in their builds!
+
+Previously, when building your projects in an Nx workspace, our builds were setup to include any environment variables prefixed with `NX_` and include them in the built artifact so they would be accessible there. This is often used for setting things like urls for different versions of external services to hit - for example, sending requests to your local development server while developing, but pointing to the production service for your production build.
+
+Going forward, these environment variables will need to be prefixed with `NX_PUBLIC_`. This is a security consideration - by requiring a more specific prefix we're making sure that no secrets end up in your production builds unintentionally!
+
+Because of the nature of this change we will NOT be providing an automatic migration. So be sure to manually update any environment variables that you want bundled into your builds from `NX_` to `NX_PUBLIC_`.
+
+## General Crystal Polishing
+
+Along with the features above (many of which further build upon Nx Project Crystal), we've done quite a bit since Nx 18 to polish the features that we introduced with Project Crystal.
+
+Since Nx 18 release, we also started using Project Crystal inside of the Nx repo itself (as well as in Nx Console and in our closed-source monorepo as well). This has allowed us to find many improvements we can make, as well as issues we can fix.
+
+You can find a full list of fixes and features applied in this major release [here](https://github.com/nrwl/nx/releases/tag/19.0.0).
+
+[![Changelog for Nx 19](/blog/images/2024-05-08/fixes.gif)](https://github.com/nrwl/nx/releases/tag/19.0.0)
+
+With Project Crystal landed now, we're also adjusting our priorities to place a higher importance on stability. You should see this reflected in Nx 19.
+
+As a note, we had noticed an increase in the rate of Github issues since Nx 18 launched. Previously, we had not allocated enough time to handling these issues. To address this, our team is going to be doubling the amount of time focusing on maintainence.
+
+In addition - we are adding more process to make the triage of these issues more efficient. Github issues will now be assigned directly to specific members of the Nx Core Team. The main intention of this change is to increase the efficiency of the time that we do spend on addressing issues.
+
+## Nx Cloud Updates!
+
+[![The Nx Cloud Dashboard](/blog/images/2024-05-08/nx-cloud-dashboard.webp)](https://nx.app/#deep-understanding)
+
+We've got some cool stats to share from our users regarding the benefits of [Nx Cloud](https://nx.app), our premium CI service. The three areas we've identified as the critical aspects of a CI provider are: speed, cost, and reliablity. In these areas we've seen:
+
+- **speed**: Reported 30% - 70% faster CI
+- **cost**: Reported 40% - 75% reduction in CI costs
+- **reliability**: Nx Cloud's automatic detection and retrying of flaky tests makes the issue of flaky tests largely go away entirely. You can read more on [our thoughts on reliability here](/blog/2024-03-21-reliable-ci).
+
+In February, we launched two big enhancements to Nx Cloud: the [Atomizer](/ci/features/split-e2e-tasks) and [Nx Agents](https://nx.app/products/agents#content).
+
+Since then, the Atomizer has received a nice UI update (as we had seen earlier):
+
+[![Grouped e2e tests in Nx Cloud](/blog/images/2024-05-08/nx-cloud-atomizer-groupings.gif)](https://staging.nx.app/runs/ctbAZfiLy3)
+
+Since February, we also revamped our task distribution algorithms. This has resulted in a 5-20% (depending on the repo) increase in both speed and cost efficiency for our users.
+
+If you are interested in trying Nx Cloud, go to [https://nx.app](https://nx.app).
+
+## More Miscellaneous updates!
+
+We've been updating our docs site. We've tweeked the search to make it more helpful, updated navigation, and as you can tell since you're reading it, we've moved our blog to [nx.dev/blog](blog) as well.
+
+We've also added a page for [Nx Enterprise](/enterprise):
+
+[![Nx Enterprise Site](/blog/images/2024-05-08/nx-enterprise-site.webp)](/enterprise)
+
+And! We've revamped our newsletter, written by our CTO, Victor Savkin. [Subscribe here](https://go.nx.dev/nx-newsletter) to start receiving it!
+
+## NEW CONFERENCE: Monorepo World 2024
+
+[![NEW CONFERENCE: Monorepo World 2024](/blog/images/2024-05-08/welcome-to-monorepo-world-2024.webp)](https://monorepo.tools/conf)
+
+We've got a new conference coming up: [Monorepo World 2024](https://monorepo.tools/conf)!
+
+This conference will cover all things dealing with monorepos, and we're excited to host it at the Computer History Museum in Mountain View, California this October 7th!
+
+You can [reserve your tickets now](https://ti.to/nx-conf/monorepoworld2024)! In person tickets start at $300 a piece for Early Bird (open until May 31), and online attendance is free.
+
+The [Call for Speakers](https://sessionize.com/monorepo-world) is open now, and will close on June 20, 2024.
+
+We'll be excited to see y'all there!
+
+## Wrapping Up, And A Heartfelt Thank You
+
+That's it for now!
+
+I did want to take a moment to give a heartfelt thank you to everyone out there. If you weren't aware, I had something of a [personal tragedy](https://twitter.com/zackderose/status/1759695615573864758) in February, not long after our big launch week.
+
+[![My Sadie.](/blog/images/2024-05-08/sadie.webp)](https://twitter.com/zackderose/status/1759695615573864758)
+
+For me, this blogpost represents the beginning of my return to Nx, and to the larger dev community.
+
+To everyone out there - your kindness and care meant more to me than you could know. I intend to return that the positivity and care you invested in me in those dark days back as best I can. So here's looking forward to hard work, more releases, and better days to come.
+
+With Many Thanks,
+
+Zack
+
+## Learn more
+
+- [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](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)

docs/blog/authors.json

@@ -0,0 +1,50 @@
+[
+  {
+    "name": "Juri Strumpflohner",
+    "image": "/blog/images/Juri Strumpfloner.jpeg",
+    "twitter": "juristr",
+    "github": "juristr"
+  },
+  {
+    "name": "Colum Ferry",
+    "image": "/blog/images/Colum Ferry.jpeg",
+    "twitter": "FerryColum",
+    "github": "Coly010"
+  },
+  {
+    "name": "Emily Xiong",
+    "image": "/blog/images/Emily Xiong.jpeg",
+    "twitter": "xiongemily",
+    "github": "xiongemi"
+  },
+  {
+    "name": "Isaac Mann",
+    "image": "/blog/images/Isaac Mann.jpeg",
+    "twitter": "mannisaac",
+    "github": "isaacplmann"
+  },
+  {
+    "name": "Katerina Skroumpelou",
+    "image": "/blog/images/Katerina Skroumpelou.jpeg",
+    "twitter": "psybercity",
+    "github": "mandarini"
+  },
+  {
+    "name": "Max Kless",
+    "image": "/blog/images/Max Kless.jpeg",
+    "twitter": "MaxKless",
+    "github": "MaxKless"
+  },
+  {
+    "name": "Victor Savkin",
+    "image": "/blog/images/Victor Savkin.jpeg",
+    "twitter": "victorsavkin",
+    "github": "vsavkin"
+  },
+  {
+    "name": "Zack DeRose",
+    "image": "/blog/images/Zack DeRose.jpeg",
+    "twitter": "zackderose",
+    "github": "ZackDeRose"
+  }
+]

docs/changelog/18_0_0.md

@@ -1,6 +1,6 @@
 # Nx 18
 
-We were so excited about the features in Nx 18 that we created a whole [Launch Nx Week](https://nx.dev/launch-nx) to share our excitement with you. During the launch week, we made the following announcements:
+We were so excited about the features in Nx 18 that we created a whole [Launch Nx Week](/launch-nx) to share our excitement with you. During the launch week, we made the following announcements:
 
 - [Project Crystal](https://blog.nrwl.io/what-if-nx-plugins-were-more-like-vscode-extensions-dcdad140ae09?source=friends_link&sk=ade76fe8d50d44aafb4d4d89ab882e24&__hstc=221401095.5d21139e33f975ecef01c1783a7523db.1673975383152.1708023233215.1708026196201.468&__hssc=221401095.2.1708026196201&__hsfp=589919331) allows you to use inferred tasks
 - A new [`@nx/nuxt`](https://blog.nrwl.io/introducing-nx-nuxt-enhanced-nuxt-js-support-in-nx-01eac78034fc?source=friends_link&sk=91582cdbd0719dc23375338ad92afa9b&__hstc=221401095.5d21139e33f975ecef01c1783a7523db.1673975383152.1708023233215.1708026196201.468&__hssc=221401095.2.1708026196201&__hsfp=589919331) plugin is available

docs/changelog/19_0_0.md

@@ -0,0 +1,27 @@
+# Nx 19
+
+Nx 19.0 has landed, and it's ALL about reinforcing 💎Project Crystal💎!!!
+
+Catch the details in this [blog post](/blog/2024-05-08-nx-19-release) and watch the video below:
+
+{% youtube
+src="https://youtu.be/U6eO8-w9DR0"
+title="Nx 19.0 Has Landed!!"
+/%}
+
+## Features
+
+{% cards cols="2" %}
+{% card title="NEW PLUGIN: @nx/gradle" type="document" url="/blog/2024-05-08-nx-19-release#new-plugin-nxgradle" /%}
+{% card title="Nx Atomizer Enhancements" type="document" url="/blog/2024-05-08-nx-19-release#nx-atomizer-enhancements" /%}
+{% card title="Associated Technologies Added To Tasks" type="document" url="/blog/2024-05-08-nx-19-release##associated-technologies-added-to-tasks" /%}
+{% card title="Generators to Migrate to Project Crystal" type="document" url="/blog/2024-05-08-nx-19-release#generators-to-migrate-to-project-crystal" /%}
+{% card title="General Crystal Polishing" type="document" url="/blog/2024-05-08-nx-19-release#general-crystal-polishing" /%}
+{% card title="Nx Cloud Updates!" type="document" url="/blog/2024-05-08-nx-19-release#nx-cloud-updates" /%}
+{% card title="More Miscellaneous Updates!" type="document" url="/blog/2024-05-08-nx-19-release#more-miscellaneous-updates" /%}
+{% card title="NEW CONFERENCE: Monorepo World 2024" type="document" url="/blog/2024-05-08-nx-19-release#new-conference-monorepo-world-2024" /%}
+{% /cards %}
+
+## Breaking Changes
+
+[Updating Bundled Environment Variables: `NX_` to `NX_PUBLIC_`](/blog/2024-05-08-nx-19-release#breaking-change-updating-bundled-environment-variables-to)

docs/generated/cli/show.md

@@ -145,6 +145,12 @@ Type: `string`
 
 Show only projects that match a given pattern.
 
+##### sep
+
+Type: `string`
+
+Outputs projects with the specified seperator
+
 ##### type
 
 Type: `string`
@@ -199,6 +205,12 @@ Type: `boolean`
 
 Show help
 
+##### open
+
+Type: `boolean`
+
+Set to false to prevent the browser from opening when using --web
+
 ##### projectName
 
 Type: `string`

docs/generated/devkit/NxPluginV1.md

@@ -4,13 +4,13 @@
 
 **`Deprecated`**
 
-Use [NxPluginV2](../../devkit/documents/NxPluginV2) instead. This will be removed in Nx 19
+Use [NxPluginV2](../../devkit/documents/NxPluginV2) instead. This will be removed in Nx 20
 
 #### Type declaration
 
 | Name                      | Type                                                                            | Description                                                                                                                                                                                              |
 | :------------------------ | :------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `name`                    | `string`                                                                        | -                                                                                                                                                                                                        |
-| `processProjectGraph?`    | `ProjectGraphProcessor`                                                         | **`Deprecated`** Use [CreateNodes](../../devkit/documents/CreateNodes) and [CreateDependencies](../../devkit/documents/CreateDependencies) instead. This will be removed in Nx 19                        |
-| `projectFilePatterns?`    | `string`[]                                                                      | A glob pattern to search for non-standard project files. @example: ["*.csproj", "pom.xml"] **`Deprecated`** Use [CreateNodes](../../devkit/documents/CreateNodes) instead. This will be removed in Nx 19 |
-| `registerProjectTargets?` | [`ProjectTargetConfigurator`](../../devkit/documents/ProjectTargetConfigurator) | **`Deprecated`** Add targets to the projects inside of [CreateNodes](../../devkit/documents/CreateNodes) instead. This will be removed in Nx 19                                                          |
+| `processProjectGraph?`    | `ProjectGraphProcessor`                                                         | **`Deprecated`** Use [CreateNodes](../../devkit/documents/CreateNodes) and [CreateDependencies](../../devkit/documents/CreateDependencies) instead. This will be removed in Nx 20                        |
+| `projectFilePatterns?`    | `string`[]                                                                      | A glob pattern to search for non-standard project files. @example: ["*.csproj", "pom.xml"] **`Deprecated`** Use [CreateNodes](../../devkit/documents/CreateNodes) instead. This will be removed in Nx 20 |
+| `registerProjectTargets?` | [`ProjectTargetConfigurator`](../../devkit/documents/ProjectTargetConfigurator) | **`Deprecated`** Add targets to the projects inside of [CreateNodes](../../devkit/documents/CreateNodes) instead. This will be removed in Nx 20                                                          |

docs/generated/devkit/ProjectGraphBuilder.md

@@ -4,7 +4,7 @@ A class which builds up a project graph
 
 **`Deprecated`**
 
-The ProjectGraphProcessor has been deprecated. Use a [CreateNodes](../../devkit/documents/CreateNodes) and/or a [CreateDependencies](../../devkit/documents/CreateDependencies) instead. This will be removed in Nx 19.
+The ProjectGraphProcessor has been deprecated. Use a [CreateNodes](../../devkit/documents/CreateNodes) and/or a [CreateDependencies](../../devkit/documents/CreateDependencies) instead. This will be removed in Nx 20.
 
 ## Table of contents
 

docs/generated/devkit/ProjectGraphProcessorContext.md

@@ -4,7 +4,7 @@ Additional information to be used to process a project graph
 
 **`Deprecated`**
 
-The ProjectGraphProcessor is deprecated. This will be removed in Nx 19.
+The ProjectGraphProcessor is deprecated. This will be removed in Nx 20.
 
 ## Table of contents
 

docs/generated/devkit/ProjectTargetConfigurator.md

@@ -4,7 +4,7 @@
 
 **`Deprecated`**
 
-Add targets to the projects in a [CreateNodes](../../devkit/documents/CreateNodes) function instead. This will be removed in Nx 19
+Add targets to the projects in a [CreateNodes](../../devkit/documents/CreateNodes) function instead. This will be removed in Nx 20
 
 #### Type declaration
 

docs/generated/devkit/getOutputsForTargetAndConfiguration.md

@@ -15,7 +15,7 @@
 
 **`Deprecated`**
 
-Pass the target and overrides instead. This will be removed in v19.
+Pass the target and overrides instead. This will be removed in v20.
 
 ▸ **getOutputsForTargetAndConfiguration**(`target`, `overrides`, `node`): `string`[]
 

docs/generated/manifests/menus.json

@@ -93,6 +93,14 @@
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
+              },
+              {
+                "name": "Gradle Monorepo",
+                "path": "/getting-started/tutorials/gradle-tutorial",
+                "id": "gradle-tutorial",
+                "isExternal": false,
+                "children": [],
+                "disableCollapsible": false
               }
             ],
             "disableCollapsible": false
@@ -185,6 +193,14 @@
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
+          },
+          {
+            "name": "Gradle Monorepo",
+            "path": "/getting-started/tutorials/gradle-tutorial",
+            "id": "gradle-tutorial",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
           }
         ],
         "disableCollapsible": false
@@ -238,106 +254,9 @@
         "disableCollapsible": false
       },
       {
-        "name": "Core Tutorial",
-        "path": "/core-tutorial",
-        "id": "core-tutorial",
-        "isExternal": false,
-        "children": [
-          {
-            "name": "1 - Create Blog",
-            "path": "/core-tutorial/01-create-blog",
-            "id": "01-create-blog",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "2 - Create CLI",
-            "path": "/core-tutorial/02-create-cli",
-            "id": "02-create-cli",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "3 - Share Assets",
-            "path": "/core-tutorial/03-share-assets",
-            "id": "03-share-assets",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "4 - Build Affected Projects",
-            "path": "/core-tutorial/04-build-affected-projects",
-            "id": "04-build-affected-projects",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "5 - Automatically Detect Dependencies",
-            "path": "/core-tutorial/05-auto-detect-dependencies",
-            "id": "05-auto-detect-dependencies",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "6 - Summary",
-            "path": "/core-tutorial/06-summary",
-            "id": "06-summary",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          }
-        ],
-        "disableCollapsible": false
-      },
-      {
-        "name": "1 - Create Blog",
-        "path": "/core-tutorial/01-create-blog",
-        "id": "01-create-blog",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "2 - Create CLI",
-        "path": "/core-tutorial/02-create-cli",
-        "id": "02-create-cli",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "3 - Share Assets",
-        "path": "/core-tutorial/03-share-assets",
-        "id": "03-share-assets",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "4 - Build Affected Projects",
-        "path": "/core-tutorial/04-build-affected-projects",
-        "id": "04-build-affected-projects",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "5 - Automatically Detect Dependencies",
-        "path": "/core-tutorial/05-auto-detect-dependencies",
-        "id": "05-auto-detect-dependencies",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "6 - Summary",
-        "path": "/core-tutorial/06-summary",
-        "id": "06-summary",
+        "name": "Gradle Monorepo",
+        "path": "/getting-started/tutorials/gradle-tutorial",
+        "id": "gradle-tutorial",
         "isExternal": false,
         "children": [],
         "disableCollapsible": false
@@ -719,6 +638,30 @@
             "children": [],
             "disableCollapsible": false
           },
+          {
+            "name": "Nx Daemon",
+            "path": "/concepts/nx-daemon",
+            "id": "nx-daemon",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
+          {
+            "name": "Nx and Turborepo",
+            "path": "/concepts/turbo-and-nx",
+            "id": "turbo-and-nx",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
+          {
+            "name": "Buildable and Publishable Libraries",
+            "path": "/concepts/buildable-and-publishable-libraries",
+            "id": "buildable-and-publishable-libraries",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
           {
             "name": "Module Federation",
             "path": "/concepts/module-federation",
@@ -761,14 +704,22 @@
             "disableCollapsible": false
           },
           {
-            "name": "More Concepts",
-            "path": "/concepts/more-concepts",
-            "id": "more-concepts",
+            "name": "Organizational Decisions",
+            "path": "/concepts/decisions",
+            "id": "decisions",
             "isExternal": false,
             "children": [
+              {
+                "name": "Overview",
+                "path": "/concepts/decisions/overview",
+                "id": "overview",
+                "isExternal": false,
+                "children": [],
+                "disableCollapsible": false
+              },
               {
                 "name": "Monorepos",
-                "path": "/concepts/more-concepts/why-monorepos",
+                "path": "/concepts/decisions/why-monorepos",
                 "id": "why-monorepos",
                 "isExternal": false,
                 "children": [],
@@ -776,72 +727,40 @@
               },
               {
                 "name": "Dependency Management",
-                "path": "/concepts/more-concepts/dependency-management",
+                "path": "/concepts/decisions/dependency-management",
                 "id": "dependency-management",
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
               },
               {
-                "name": "Code Sharing",
-                "path": "/concepts/more-concepts/code-sharing",
-                "id": "code-sharing",
+                "name": "Code Ownership",
+                "path": "/concepts/decisions/code-ownership",
+                "id": "code-ownership",
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
               },
               {
-                "name": "Nx Daemon",
-                "path": "/concepts/more-concepts/nx-daemon",
-                "id": "nx-daemon",
+                "name": "Project Size",
+                "path": "/concepts/decisions/project-size",
+                "id": "project-size",
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
               },
               {
-                "name": "Nx and Turborepo",
-                "path": "/concepts/more-concepts/turbo-and-nx",
-                "id": "turbo-and-nx",
+                "name": "Project Dependency Rules",
+                "path": "/concepts/decisions/project-dependency-rules",
+                "id": "project-dependency-rules",
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
               },
               {
-                "name": "Applications and Libraries",
-                "path": "/concepts/more-concepts/applications-and-libraries",
-                "id": "applications-and-libraries",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
-              {
-                "name": "When to Create a New Library",
-                "path": "/concepts/more-concepts/creating-libraries",
-                "id": "creating-libraries",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
-              {
-                "name": "Library Types",
-                "path": "/concepts/more-concepts/library-types",
-                "id": "library-types",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
-              {
-                "name": "Grouping Libraries",
-                "path": "/concepts/more-concepts/grouping-libraries",
-                "id": "grouping-libraries",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
-              {
-                "name": "Buildable and Publishable Libraries",
-                "path": "/concepts/more-concepts/buildable-and-publishable-libraries",
-                "id": "buildable-and-publishable-libraries",
+                "name": "Folder Structure",
+                "path": "/concepts/decisions/folder-structure",
+                "id": "folder-structure",
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
@@ -916,6 +835,30 @@
         "children": [],
         "disableCollapsible": false
       },
+      {
+        "name": "Nx Daemon",
+        "path": "/concepts/nx-daemon",
+        "id": "nx-daemon",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
+      {
+        "name": "Nx and Turborepo",
+        "path": "/concepts/turbo-and-nx",
+        "id": "turbo-and-nx",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
+      {
+        "name": "Buildable and Publishable Libraries",
+        "path": "/concepts/buildable-and-publishable-libraries",
+        "id": "buildable-and-publishable-libraries",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
       {
         "name": "Module Federation",
         "path": "/concepts/module-federation",
@@ -990,14 +933,22 @@
         "disableCollapsible": false
       },
       {
-        "name": "More Concepts",
-        "path": "/concepts/more-concepts",
-        "id": "more-concepts",
+        "name": "Organizational Decisions",
+        "path": "/concepts/decisions",
+        "id": "decisions",
         "isExternal": false,
         "children": [
+          {
+            "name": "Overview",
+            "path": "/concepts/decisions/overview",
+            "id": "overview",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
           {
             "name": "Monorepos",
-            "path": "/concepts/more-concepts/why-monorepos",
+            "path": "/concepts/decisions/why-monorepos",
             "id": "why-monorepos",
             "isExternal": false,
             "children": [],
@@ -1005,72 +956,40 @@
           },
           {
             "name": "Dependency Management",
-            "path": "/concepts/more-concepts/dependency-management",
+            "path": "/concepts/decisions/dependency-management",
             "id": "dependency-management",
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
           },
           {
-            "name": "Code Sharing",
-            "path": "/concepts/more-concepts/code-sharing",
-            "id": "code-sharing",
+            "name": "Code Ownership",
+            "path": "/concepts/decisions/code-ownership",
+            "id": "code-ownership",
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
           },
           {
-            "name": "Nx Daemon",
-            "path": "/concepts/more-concepts/nx-daemon",
-            "id": "nx-daemon",
+            "name": "Project Size",
+            "path": "/concepts/decisions/project-size",
+            "id": "project-size",
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
           },
           {
-            "name": "Nx and Turborepo",
-            "path": "/concepts/more-concepts/turbo-and-nx",
-            "id": "turbo-and-nx",
+            "name": "Project Dependency Rules",
+            "path": "/concepts/decisions/project-dependency-rules",
+            "id": "project-dependency-rules",
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
           },
           {
-            "name": "Applications and Libraries",
-            "path": "/concepts/more-concepts/applications-and-libraries",
-            "id": "applications-and-libraries",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "When to Create a New Library",
-            "path": "/concepts/more-concepts/creating-libraries",
-            "id": "creating-libraries",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "Library Types",
-            "path": "/concepts/more-concepts/library-types",
-            "id": "library-types",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "Grouping Libraries",
-            "path": "/concepts/more-concepts/grouping-libraries",
-            "id": "grouping-libraries",
-            "isExternal": false,
-            "children": [],
-            "disableCollapsible": false
-          },
-          {
-            "name": "Buildable and Publishable Libraries",
-            "path": "/concepts/more-concepts/buildable-and-publishable-libraries",
-            "id": "buildable-and-publishable-libraries",
+            "name": "Folder Structure",
+            "path": "/concepts/decisions/folder-structure",
+            "id": "folder-structure",
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
@@ -1078,9 +997,17 @@
         ],
         "disableCollapsible": false
       },
+      {
+        "name": "Overview",
+        "path": "/concepts/decisions/overview",
+        "id": "overview",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
       {
         "name": "Monorepos",
-        "path": "/concepts/more-concepts/why-monorepos",
+        "path": "/concepts/decisions/why-monorepos",
         "id": "why-monorepos",
         "isExternal": false,
         "children": [],
@@ -1088,72 +1015,40 @@
       },
       {
         "name": "Dependency Management",
-        "path": "/concepts/more-concepts/dependency-management",
+        "path": "/concepts/decisions/dependency-management",
         "id": "dependency-management",
         "isExternal": false,
         "children": [],
         "disableCollapsible": false
       },
       {
-        "name": "Code Sharing",
-        "path": "/concepts/more-concepts/code-sharing",
-        "id": "code-sharing",
+        "name": "Code Ownership",
+        "path": "/concepts/decisions/code-ownership",
+        "id": "code-ownership",
         "isExternal": false,
         "children": [],
         "disableCollapsible": false
       },
       {
-        "name": "Nx Daemon",
-        "path": "/concepts/more-concepts/nx-daemon",
-        "id": "nx-daemon",
+        "name": "Project Size",
+        "path": "/concepts/decisions/project-size",
+        "id": "project-size",
         "isExternal": false,
         "children": [],
         "disableCollapsible": false
       },
       {
-        "name": "Nx and Turborepo",
-        "path": "/concepts/more-concepts/turbo-and-nx",
-        "id": "turbo-and-nx",
+        "name": "Project Dependency Rules",
+        "path": "/concepts/decisions/project-dependency-rules",
+        "id": "project-dependency-rules",
         "isExternal": false,
         "children": [],
         "disableCollapsible": false
       },
       {
-        "name": "Applications and Libraries",
-        "path": "/concepts/more-concepts/applications-and-libraries",
-        "id": "applications-and-libraries",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "When to Create a New Library",
-        "path": "/concepts/more-concepts/creating-libraries",
-        "id": "creating-libraries",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "Library Types",
-        "path": "/concepts/more-concepts/library-types",
-        "id": "library-types",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "Grouping Libraries",
-        "path": "/concepts/more-concepts/grouping-libraries",
-        "id": "grouping-libraries",
-        "isExternal": false,
-        "children": [],
-        "disableCollapsible": false
-      },
-      {
-        "name": "Buildable and Publishable Libraries",
-        "path": "/concepts/more-concepts/buildable-and-publishable-libraries",
-        "id": "buildable-and-publishable-libraries",
+        "name": "Folder Structure",
+        "path": "/concepts/decisions/folder-structure",
+        "id": "folder-structure",
         "isExternal": false,
         "children": [],
         "disableCollapsible": false
@@ -2090,6 +1985,14 @@
                 "isExternal": false,
                 "children": [],
                 "disableCollapsible": false
+              },
+              {
+                "name": "Configure Changelog Format",
+                "path": "/recipes/nx-release/configure-changelog-format",
+                "id": "configure-changelog-format",
+                "isExternal": false,
+                "children": [],
+                "disableCollapsible": false
               }
             ],
             "disableCollapsible": false
@@ -3761,6 +3664,14 @@
             "isExternal": false,
             "children": [],
             "disableCollapsible": false
+          },
+          {
+            "name": "Configure Changelog Format",
+            "path": "/recipes/nx-release/configure-changelog-format",
+            "id": "configure-changelog-format",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
           }
         ],
         "disableCollapsible": false
@@ -3837,6 +3748,14 @@
         "children": [],
         "disableCollapsible": false
       },
+      {
+        "name": "Configure Changelog Format",
+        "path": "/recipes/nx-release/configure-changelog-format",
+        "id": "configure-changelog-format",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
       {
         "name": "Other",
         "path": "/recipes/other",
@@ -4579,6 +4498,22 @@
         "id": "deprecated",
         "isExternal": false,
         "children": [
+          {
+            "name": "affected:graph",
+            "path": "/deprecated/affected-graph",
+            "id": "affected-graph",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
+          {
+            "name": "print-affected",
+            "path": "/deprecated/print-affected",
+            "id": "print-affected",
+            "isExternal": false,
+            "children": [],
+            "disableCollapsible": false
+          },
           {
             "name": "workspace.json",
             "path": "/deprecated/workspace-json",
@@ -4662,6 +4597,22 @@
         ],
         "disableCollapsible": false
       },
+      {
+        "name": "affected:graph",
+        "path": "/deprecated/affected-graph",
+        "id": "affected-graph",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
+      {
+        "name": "print-affected",
+        "path": "/deprecated/print-affected",
+        "id": "print-affected",
+        "isExternal": false,
+        "children": [],
+        "disableCollapsible": false
+      },
       {
         "name": "workspace.json",
         "path": "/deprecated/workspace-json",
@@ -8354,22 +8305,6 @@
                 "children": [],
                 "disableCollapsible": false
               },
-              {
-                "name": "affected:graph",
-                "path": "/nx-api/nx/documents/affected-dep-graph",
-                "id": "affected-dep-graph",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
-              {
-                "name": "print-affected",
-                "path": "/nx-api/nx/documents/print-affected",
-                "id": "print-affected",
-                "isExternal": false,
-                "children": [],
-                "disableCollapsible": false
-              },
               {
                 "name": "format:check",
                 "path": "/nx-api/nx/documents/format-check",

docs/generated/manifests/nx-api.json

@@ -63,7 +63,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/ng-packagr-lite": {
-        "description": "Builds a library with support for incremental builds.\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nrwl/angular:package` executor but with some key differences:\n- It doesn't run `ngcc` automatically (`ngcc` needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2020 bundles.\n- It doesn't generate package exports in the `package.json`.",
+        "description": "Builds an Angular library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nx/angular:package` executor but with some key differences:\n- For supported Angular versions lower than v16, it doesn't run `ngcc` automatically (`ngcc` is no longer available from Angular v16 onwards, for lower versions, it needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2022 bundles (ESM2020 for supported Angular versions lower than v16).",
         "file": "generated/packages/angular/executors/ng-packagr-lite.json",
         "hidden": false,
         "name": "ng-packagr-lite",
@@ -72,7 +72,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/package": {
-        "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\nThis executor is similar to the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
+        "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\n\nThis executor is a drop-in replacement for the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
         "file": "generated/packages/angular/executors/package.json",
         "hidden": false,
         "name": "package",
@@ -81,7 +81,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/browser-esbuild": {
-        "description": "Builds your application with esbuild and adds support for incremental builds.",
+        "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/).",
         "file": "generated/packages/angular/executors/browser-esbuild.json",
         "hidden": false,
         "name": "browser-esbuild",
@@ -90,7 +90,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/module-federation-dev-server": {
-        "description": "The module-federation-dev-server executor is reserved exclusively for use with host Module Federation applications. It allows the user to specify which remote applications should be served with the host.",
+        "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) allowing to specify which remote applications should be served with the host.",
         "file": "generated/packages/angular/executors/module-federation-dev-server.json",
         "hidden": false,
         "name": "module-federation-dev-server",
@@ -99,7 +99,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/application": {
-        "description": "Builds an application with esbuild with support for incremental builds. _Note: this is only supported in Angular versions >= 17.0.0_.",
+        "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/) with integrated SSR and prerendering capabilities. _Note: this is only supported in Angular versions >= 17.0.0_.",
         "file": "generated/packages/angular/executors/application.json",
         "hidden": false,
         "name": "application",
@@ -117,7 +117,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/webpack-browser": {
-        "description": "The `webpack-browser` executor is very similar to the standard `browser` builder provided by the Angular Devkit. It allows you to build your Angular application to a build artifact that can be hosted online. There are some key differences:   \n- Supports Custom Webpack Configurations  \n- Supports Incremental Building",
+        "description": "Builds an Angular application using [webpack](https://webpack.js.org/).",
         "file": "generated/packages/angular/executors/webpack-browser.json",
         "hidden": false,
         "name": "webpack-browser",
@@ -126,7 +126,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/dev-server": {
-        "description": "Serves an Angular application using [Webpack](https://webpack.js.org/) when the build target is using a Webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an esbuild-based executor.",
+        "description": "Serves an Angular application using [webpack](https://webpack.js.org/) when the build target is using a webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an [esbuild](https://esbuild.github.io/)-based executor.",
         "file": "generated/packages/angular/executors/dev-server.json",
         "hidden": false,
         "name": "dev-server",
@@ -135,7 +135,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/webpack-server": {
-        "description": "The `webpack-server` executor is very similar to the standard `server` builder provided by the Angular Devkit. It is usually used in tandem with `@nrwl/angular:webpack-browser` when your Angular application uses a custom webpack configuration and NgUniversal for SSR.",
+        "description": "Builds a server Angular application using [webpack](https://webpack.js.org/). This executor is a drop-in replacement for the `@angular-devkit/build-angular:server` builder provided by the Angular CLI. It is usually used in tandem with the `@nx/angular:webpack-browser` executor when your Angular application uses a custom webpack configuration.",
         "file": "generated/packages/angular/executors/webpack-server.json",
         "hidden": false,
         "name": "webpack-server",
@@ -144,7 +144,7 @@
         "type": "executor"
       },
       "/nx-api/angular/executors/module-federation-dev-ssr": {
-        "description": "The module-federation-dev-ssr executor is reserved exclusively for use with host Module Federation applications that use SSR. It allows the user to specify which remote applications should be served with the host.",
+        "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) that use SSR allowing to specify which remote applications should be served with the host.",
         "file": "generated/packages/angular/executors/module-federation-dev-ssr.json",
         "hidden": false,
         "name": "module-federation-dev-ssr",
@@ -1778,28 +1778,6 @@
         "tags": ["run-tasks"],
         "originalFilePath": "generated/cli/affected"
       },
-      "/nx-api/nx/documents/affected-dep-graph": {
-        "id": "affected-dep-graph",
-        "name": "affected:graph",
-        "description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
-        "file": "generated/packages/nx/documents/affected-dep-graph",
-        "itemList": [],
-        "isExternal": false,
-        "path": "/nx-api/nx/documents/affected-dep-graph",
-        "tags": [],
-        "originalFilePath": "generated/cli/affected-graph"
-      },
-      "/nx-api/nx/documents/print-affected": {
-        "id": "print-affected",
-        "name": "print-affected",
-        "description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
-        "file": "generated/packages/nx/documents/print-affected",
-        "itemList": [],
-        "isExternal": false,
-        "path": "/nx-api/nx/documents/print-affected",
-        "tags": [],
-        "originalFilePath": "generated/cli/print-affected"
-      },
       "/nx-api/nx/documents/format-check": {
         "id": "format-check",
         "name": "format:check",
@@ -2863,7 +2841,7 @@
         "type": "generator"
       },
       "/nx-api/storybook/generators/cypress-project": {
-        "description": "Add cypress e2e app to test a UI library that is set up for Storybook.",
+        "description": "Add cypress E2E app to test a ui library that is set up for Storybook.",
         "file": "generated/packages/storybook/generators/cypress-project.json",
         "hidden": false,
         "name": "cypress-project",

docs/generated/manifests/tags.json

@@ -60,7 +60,7 @@
     },
     {
       "description": "",
-      "file": "shared/recipes/running-tasks/executors-and-configurations",
+      "file": "shared/concepts/executors-and-configurations",
       "id": "executors-and-configurations",
       "name": "Executors and Configurations",
       "path": "/concepts/executors-and-configurations"
@@ -392,31 +392,24 @@
     },
     {
       "description": "",
-      "file": "shared/workspace/applications-and-libraries",
-      "id": "applications-and-libraries",
-      "name": "Applications and Libraries",
-      "path": "/concepts/more-concepts/applications-and-libraries"
+      "file": "shared/concepts/decisions/project-size",
+      "id": "project-size",
+      "name": "Project Size",
+      "path": "/concepts/decisions/project-size"
     },
     {
       "description": "",
-      "file": "shared/workspace/creating-libraries",
-      "id": "creating-libraries",
-      "name": "When to Create a New Library",
-      "path": "/concepts/more-concepts/creating-libraries"
+      "file": "shared/concepts/decisions/project-dependency-rules",
+      "id": "project-dependency-rules",
+      "name": "Project Dependency Rules",
+      "path": "/concepts/decisions/project-dependency-rules"
     },
     {
       "description": "",
-      "file": "shared/workspace/library-types",
-      "id": "library-types",
-      "name": "Library Types",
-      "path": "/concepts/more-concepts/library-types"
-    },
-    {
-      "description": "",
-      "file": "shared/workspace/grouping-libraries",
-      "id": "grouping-libraries",
-      "name": "Grouping Libraries",
-      "path": "/concepts/more-concepts/grouping-libraries"
+      "file": "shared/concepts/decisions/folder-structure",
+      "id": "folder-structure",
+      "name": "Folder Structure",
+      "path": "/concepts/decisions/folder-structure"
     },
     {
       "description": "",
@@ -539,6 +532,13 @@
       "name": "Customize Conventional Commit Types",
       "path": "/recipes/nx-release/customize-conventional-commit-types"
     },
+    {
+      "description": "",
+      "file": "shared/recipes/nx-release/configure-changelog-format",
+      "id": "configure-changelog-format",
+      "name": "Configure Changelog Format",
+      "path": "/recipes/nx-release/configure-changelog-format"
+    },
     {
       "description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
       "file": "generated/packages/generated/packages/nx/documents/release",
@@ -550,7 +550,7 @@
   "intro": [
     {
       "description": "",
-      "file": "shared/mental-model",
+      "file": "shared/concepts/mental-model",
       "id": "mental-model",
       "name": "Mental Model",
       "path": "/concepts/mental-model"
@@ -566,7 +566,7 @@
   "inferred-tasks": [
     {
       "description": "",
-      "file": "shared/mental-model",
+      "file": "shared/concepts/mental-model",
       "id": "mental-model",
       "name": "Mental Model",
       "path": "/concepts/mental-model"
@@ -670,14 +670,14 @@
   "module-federation": [
     {
       "description": "",
-      "file": "shared/guides/module-federation/module-federation-and-nx",
+      "file": "shared/concepts/module-federation/module-federation-and-nx",
       "id": "module-federation-and-nx",
       "name": "Module Federation and Nx",
       "path": "/concepts/module-federation/module-federation-and-nx"
     },
     {
       "description": "",
-      "file": "shared/guides/module-federation/faster-builds",
+      "file": "shared/concepts/module-federation/faster-builds",
       "id": "faster-builds-with-module-federation",
       "name": "Faster Builds with Module Federation",
       "path": "/concepts/module-federation/faster-builds-with-module-federation"
@@ -698,7 +698,7 @@
     },
     {
       "description": "",
-      "file": "shared/guides/module-federation/dynamic-mfe-angular",
+      "file": "shared/recipes/module-federation/dynamic-mfe-angular",
       "id": "dynamic-module-federation-with-angular",
       "name": "Advanced Micro Frontends with Angular using Dynamic Federation",
       "path": "/recipes/angular/dynamic-module-federation-with-angular"
@@ -707,14 +707,14 @@
   "angular": [
     {
       "description": "",
-      "file": "shared/guides/module-federation/module-federation-and-nx",
+      "file": "shared/concepts/module-federation/module-federation-and-nx",
       "id": "module-federation-and-nx",
       "name": "Module Federation and Nx",
       "path": "/concepts/module-federation/module-federation-and-nx"
     },
     {
       "description": "",
-      "file": "shared/guides/module-federation/faster-builds",
+      "file": "shared/concepts/module-federation/faster-builds",
       "id": "faster-builds-with-module-federation",
       "name": "Faster Builds with Module Federation",
       "path": "/concepts/module-federation/faster-builds-with-module-federation"
@@ -728,7 +728,7 @@
     },
     {
       "description": "",
-      "file": "shared/guides/module-federation/dynamic-mfe-angular",
+      "file": "shared/recipes/module-federation/dynamic-mfe-angular",
       "id": "dynamic-module-federation-with-angular",
       "name": "Advanced Micro Frontends with Angular using Dynamic Federation",
       "path": "/recipes/angular/dynamic-module-federation-with-angular"
@@ -737,14 +737,14 @@
   "react": [
     {
       "description": "",
-      "file": "shared/guides/module-federation/module-federation-and-nx",
+      "file": "shared/concepts/module-federation/module-federation-and-nx",
       "id": "module-federation-and-nx",
       "name": "Module Federation and Nx",
       "path": "/concepts/module-federation/module-federation-and-nx"
     },
     {
       "description": "",
-      "file": "shared/guides/module-federation/faster-builds",
+      "file": "shared/concepts/module-federation/faster-builds",
       "id": "faster-builds-with-module-federation",
       "name": "Faster Builds with Module Federation",
       "path": "/concepts/module-federation/faster-builds-with-module-federation"

docs/generated/packages-metadata.json

@@ -58,7 +58,7 @@
         "type": "executor"
       },
       {
-        "description": "Builds a library with support for incremental builds.\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nrwl/angular:package` executor but with some key differences:\n- It doesn't run `ngcc` automatically (`ngcc` needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2020 bundles.\n- It doesn't generate package exports in the `package.json`.",
+        "description": "Builds an Angular library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nx/angular:package` executor but with some key differences:\n- For supported Angular versions lower than v16, it doesn't run `ngcc` automatically (`ngcc` is no longer available from Angular v16 onwards, for lower versions, it needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2022 bundles (ESM2020 for supported Angular versions lower than v16).",
         "file": "generated/packages/angular/executors/ng-packagr-lite.json",
         "hidden": false,
         "name": "ng-packagr-lite",
@@ -67,7 +67,7 @@
         "type": "executor"
       },
       {
-        "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\nThis executor is similar to the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
+        "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\n\nThis executor is a drop-in replacement for the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
         "file": "generated/packages/angular/executors/package.json",
         "hidden": false,
         "name": "package",
@@ -76,7 +76,7 @@
         "type": "executor"
       },
       {
-        "description": "Builds your application with esbuild and adds support for incremental builds.",
+        "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/).",
         "file": "generated/packages/angular/executors/browser-esbuild.json",
         "hidden": false,
         "name": "browser-esbuild",
@@ -85,7 +85,7 @@
         "type": "executor"
       },
       {
-        "description": "The module-federation-dev-server executor is reserved exclusively for use with host Module Federation applications. It allows the user to specify which remote applications should be served with the host.",
+        "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) allowing to specify which remote applications should be served with the host.",
         "file": "generated/packages/angular/executors/module-federation-dev-server.json",
         "hidden": false,
         "name": "module-federation-dev-server",
@@ -94,7 +94,7 @@
         "type": "executor"
       },
       {
-        "description": "Builds an application with esbuild with support for incremental builds. _Note: this is only supported in Angular versions >= 17.0.0_.",
+        "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/) with integrated SSR and prerendering capabilities. _Note: this is only supported in Angular versions >= 17.0.0_.",
         "file": "generated/packages/angular/executors/application.json",
         "hidden": false,
         "name": "application",
@@ -112,7 +112,7 @@
         "type": "executor"
       },
       {
-        "description": "The `webpack-browser` executor is very similar to the standard `browser` builder provided by the Angular Devkit. It allows you to build your Angular application to a build artifact that can be hosted online. There are some key differences:   \n- Supports Custom Webpack Configurations  \n- Supports Incremental Building",
+        "description": "Builds an Angular application using [webpack](https://webpack.js.org/).",
         "file": "generated/packages/angular/executors/webpack-browser.json",
         "hidden": false,
         "name": "webpack-browser",
@@ -121,7 +121,7 @@
         "type": "executor"
       },
       {
-        "description": "Serves an Angular application using [Webpack](https://webpack.js.org/) when the build target is using a Webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an esbuild-based executor.",
+        "description": "Serves an Angular application using [webpack](https://webpack.js.org/) when the build target is using a webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an [esbuild](https://esbuild.github.io/)-based executor.",
         "file": "generated/packages/angular/executors/dev-server.json",
         "hidden": false,
         "name": "dev-server",
@@ -130,7 +130,7 @@
         "type": "executor"
       },
       {
-        "description": "The `webpack-server` executor is very similar to the standard `server` builder provided by the Angular Devkit. It is usually used in tandem with `@nrwl/angular:webpack-browser` when your Angular application uses a custom webpack configuration and NgUniversal for SSR.",
+        "description": "Builds a server Angular application using [webpack](https://webpack.js.org/). This executor is a drop-in replacement for the `@angular-devkit/build-angular:server` builder provided by the Angular CLI. It is usually used in tandem with the `@nx/angular:webpack-browser` executor when your Angular application uses a custom webpack configuration.",
         "file": "generated/packages/angular/executors/webpack-server.json",
         "hidden": false,
         "name": "webpack-server",
@@ -139,7 +139,7 @@
         "type": "executor"
       },
       {
-        "description": "The module-federation-dev-ssr executor is reserved exclusively for use with host Module Federation applications that use SSR. It allows the user to specify which remote applications should be served with the host.",
+        "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) that use SSR allowing to specify which remote applications should be served with the host.",
         "file": "generated/packages/angular/executors/module-federation-dev-ssr.json",
         "hidden": false,
         "name": "module-federation-dev-ssr",
@@ -1757,28 +1757,6 @@
         "tags": ["run-tasks"],
         "originalFilePath": "generated/cli/affected"
       },
-      {
-        "id": "affected-dep-graph",
-        "name": "affected:graph",
-        "description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
-        "file": "generated/packages/nx/documents/affected-dep-graph",
-        "itemList": [],
-        "isExternal": false,
-        "path": "nx/documents/affected-dep-graph",
-        "tags": [],
-        "originalFilePath": "generated/cli/affected-graph"
-      },
-      {
-        "id": "print-affected",
-        "name": "print-affected",
-        "description": "The core Nx plugin contains the core functionality of Nx like the project graph, nx commands and task orchestration.",
-        "file": "generated/packages/nx/documents/print-affected",
-        "itemList": [],
-        "isExternal": false,
-        "path": "nx/documents/print-affected",
-        "tags": [],
-        "originalFilePath": "generated/cli/print-affected"
-      },
       {
         "id": "format-check",
         "name": "format:check",
@@ -2833,7 +2811,7 @@
         "type": "generator"
       },
       {
-        "description": "Add cypress e2e app to test a UI library that is set up for Storybook.",
+        "description": "Add cypress E2E app to test a ui library that is set up for Storybook.",
         "file": "generated/packages/storybook/generators/cypress-project.json",
         "hidden": false,
         "name": "cypress-project",

docs/generated/packages/angular/documents/overview.md

@@ -111,9 +111,9 @@ nx lint libName
 
 Read more about:
 
-- [Creating Libraries](/concepts/more-concepts/creating-libraries)
-- [Library Types](/concepts/more-concepts/library-types)
-- [Buildable and Publishable Libraries](/concepts/more-concepts/buildable-and-publishable-libraries)
+- [Creating Libraries](/concepts/decisions/project-size)
+- [Library Types](/concepts/decisions/project-dependency-rules)
+- [Buildable and Publishable Libraries](/concepts/buildable-and-publishable-libraries)
 
 ### Fallback to `@schematics/angular`
 

docs/generated/packages/angular/executors/application.json

@@ -4,8 +4,8 @@
   "schema": {
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Schema for Nx Application Executor",
-    "description": "Builds an application with esbuild with support for incremental builds. _Note: this is only supported in Angular versions >= 17.0.0_.",
-    "examplesFile": "The `@nx/angular:application` executor is very similar to the `@angular-devkit/build-angular:application` builder provided by the Angular CLI. It builds an Angular application using [esbuild](https://esbuild.github.io/) with integrated SSR and prerendering capabilities.\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:application` executor also supports the following:\n\n- Providing esbuild plugins\n- Providing a function to transform the application's `index.html` file\n- Incremental builds\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Providing esbuild plugins\" %}\n\nThe executor accepts a `plugins` option that allows you to provide esbuild plugins that will be used when building your application. It allows providing a path to a plugin file or an object with a `path` and `options` property to provide options to the plugin.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[\"8-16\"] %}\n{\n  ...\n  \"targets\": {\n    \"build\": {\n      \"executor\": \"@nx/angular:application\",\n      \"options\": {\n        ...\n        \"plugins\": [\n          \"apps/my-app/plugins/plugin1.js\",\n          {\n            \"path\": \"apps/my-app/plugins/plugin2.js\",\n            \"options\": {\n              \"someOption\": \"some value\"\n            }\n          }\n        ]\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin1.js\" %}\nconst plugin1 = {\n  name: 'plugin1',\n  setup(build) {\n    const options = build.initialOptions;\n    options.define.PLUGIN1_TEXT = '\"Value was provided at build time\"';\n  },\n};\n\nmodule.exports = plugin1;\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin2.js\" %}\nfunction plugin2({ someOption }) {\n  return {\n    name: 'plugin2',\n    setup(build) {\n      const options = build.initialOptions;\n      options.define.PLUGIN2_TEXT = JSON.stringify(someOption);\n    },\n  };\n}\n\nmodule.exports = plugin2;\n```\n\nAdditionally, we need to inform TypeScript of the defined variables to prevent type-checking errors during the build. We can achieve this by creating or updating a type definition file included in the TypeScript build process (e.g. `src/types.d.ts`) with the following content:\n\n```ts {% fileName=\"apps/my-app/src/types.d.ts\" %}\ndeclare const PLUGIN1_TEXT: number;\ndeclare const PLUGIN2_TEXT: string;\n```\n\n{% /tab %}\n\n{% tab label=\"Transforming the 'index.html' file\" %}\n\nThe executor accepts an `indexHtmlTransformer` option to provide a path to a file with a default export for a function that receives the application's `index.html` file contents and outputs the updated contents.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[8] %}\n{\n  ...\n  \"targets\": {\n    \"build\": {\n      \"executor\": \"@nx/angular:application\",\n      \"options\": {\n        ...\n        \"indexHtmlTransformer\": \"apps/my-app/index-html.transformer.ts\"\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/index-html.transformer.ts\" %}\nexport default function (indexContent: string) {\n  return indexContent.replace(\n    '<title>my-app</title>',\n    '<title>my-app (transformed)</title>'\n  );\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
+    "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/) with integrated SSR and prerendering capabilities. _Note: this is only supported in Angular versions >= 17.0.0_.",
+    "examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:application` builder provided by the Angular CLI. It builds an Angular application using [esbuild](https://esbuild.github.io/) with integrated SSR and prerendering capabilities.\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:application` executor also supports the following:\n\n- Providing esbuild plugins\n- Providing a function to transform the application's `index.html` file\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](https://nx.dev/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:application` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Vite when using the `@nx/angular:application` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Providing esbuild plugins\" %}\n\nThe executor accepts a `plugins` option that allows you to provide esbuild plugins that will be used when building your application. It allows providing a path to a plugin file or an object with a `path` and `options` property to provide options to the plugin.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[\"8-16\"] %}\n{\n  ...\n  \"targets\": {\n    \"build\": {\n      \"executor\": \"@nx/angular:application\",\n      \"options\": {\n        ...\n        \"plugins\": [\n          \"apps/my-app/plugins/plugin1.js\",\n          {\n            \"path\": \"apps/my-app/plugins/plugin2.js\",\n            \"options\": {\n              \"someOption\": \"some value\"\n            }\n          }\n        ]\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin1.js\" %}\nconst plugin1 = {\n  name: 'plugin1',\n  setup(build) {\n    const options = build.initialOptions;\n    options.define.PLUGIN1_TEXT = '\"Value was provided at build time\"';\n  },\n};\n\nmodule.exports = plugin1;\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin2.js\" %}\nfunction plugin2({ someOption }) {\n  return {\n    name: 'plugin2',\n    setup(build) {\n      const options = build.initialOptions;\n      options.define.PLUGIN2_TEXT = JSON.stringify(someOption);\n    },\n  };\n}\n\nmodule.exports = plugin2;\n```\n\nAdditionally, we need to inform TypeScript of the defined variables to prevent type-checking errors during the build. We can achieve this by creating or updating a type definition file included in the TypeScript build process (e.g. `src/types.d.ts`) with the following content:\n\n```ts {% fileName=\"apps/my-app/src/types.d.ts\" %}\ndeclare const PLUGIN1_TEXT: number;\ndeclare const PLUGIN2_TEXT: string;\n```\n\n{% /tab %}\n\n{% tab label=\"Transforming the 'index.html' file\" %}\n\nThe executor accepts an `indexHtmlTransformer` option to provide a path to a file with a default export for a function that receives the application's `index.html` file contents and outputs the updated contents.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[8] %}\n{\n  ...\n  \"targets\": {\n    \"build\": {\n      \"executor\": \"@nx/angular:application\",\n      \"options\": {\n        ...\n        \"indexHtmlTransformer\": \"apps/my-app/index-html.transformer.ts\"\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/index-html.transformer.ts\" %}\nexport default function (indexContent: string) {\n  return indexContent.replace(\n    '<title>my-app</title>',\n    '<title>my-app (transformed)</title>'\n  );\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
     "outputCapture": "direct-nodejs",
     "type": "object",
     "properties": {
@@ -739,7 +739,7 @@
     },
     "presets": []
   },
-  "description": "Builds an application with esbuild with support for incremental builds. _Note: this is only supported in Angular versions >= 17.0.0_.",
+  "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/) with integrated SSR and prerendering capabilities. _Note: this is only supported in Angular versions >= 17.0.0_.",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/executors/application/schema.json",

docs/generated/packages/angular/executors/browser-esbuild.json

@@ -4,8 +4,8 @@
   "schema": {
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Schema for Nx ESBuild Executor",
-    "description": "Nx ESBuild Executor supporting Incremental Builds.",
-    "examplesFile": "The `@nx/angular:browser-esbuild` executor is very similar to the `@angular-devkit/build-angular:browser-esbuild` builder provided by the Angular CLI. It builds an Angular application using [esbuild](https://esbuild.github.io/).\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:browser-esbuild` executor also supports the following:\n\n- Providing esbuild plugins\n- Incremental builds\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Providing esbuild plugins\" %}\n\nThe executor accepts a `plugins` option that allows you to provide esbuild plugins that will be used when building your application. It allows providing a path to a plugin file or an object with a `path` and `options` property to provide options to the plugin.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[\"8-16\"] %}\n{\n  ...\n  \"targets\": {\n    \"build\": {\n      \"executor\": \"@nx/angular:browser-esbuild\",\n      \"options\": {\n        ...\n        \"plugins\": [\n          \"apps/my-app/plugins/plugin1.js\",\n          {\n            \"path\": \"apps/my-app/plugins/plugin2.js\",\n            \"options\": {\n              \"someOption\": \"some value\"\n            }\n          }\n        ]\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin1.js\" %}\nconst plugin1 = {\n  name: 'plugin1',\n  setup(build) {\n    const options = build.initialOptions;\n    options.define.PLUGIN1_TEXT = '\"Value was provided at build time\"';\n  },\n};\n\nmodule.exports = plugin1;\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin2.js\" %}\nfunction plugin2({ someOption }) {\n  return {\n    name: 'plugin2',\n    setup(build) {\n      const options = build.initialOptions;\n      options.define.PLUGIN2_TEXT = JSON.stringify(someOption);\n    },\n  };\n}\n\nmodule.exports = plugin2;\n```\n\nAdditionally, we need to inform TypeScript of the defined variables to prevent type-checking errors during the build. We can achieve this by creating or updating a type definition file included in the TypeScript build process (e.g. `src/types.d.ts`) with the following content:\n\n```ts {% fileName=\"apps/my-app/src/types.d.ts\" %}\ndeclare const PLUGIN1_TEXT: number;\ndeclare const PLUGIN2_TEXT: string;\n```\n\n{% /tab %}\n{% /tabs %}\n",
+    "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/).",
+    "examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:browser-esbuild` builder provided by the Angular CLI. It builds an Angular application using esbuild.\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:browser-esbuild` executor also supports the following:\n\n- Providing esbuild plugins\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](https://nx.dev/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:browser-esbuild` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Vite when using the `@nx/angular:browser-esbuild` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Providing esbuild plugins\" %}\n\nThe executor accepts a `plugins` option that allows you to provide esbuild plugins that will be used when building your application. It allows providing a path to a plugin file or an object with a `path` and `options` property to provide options to the plugin.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[\"8-16\"] %}\n{\n  ...\n  \"targets\": {\n    \"build\": {\n      \"executor\": \"@nx/angular:browser-esbuild\",\n      \"options\": {\n        ...\n        \"plugins\": [\n          \"apps/my-app/plugins/plugin1.js\",\n          {\n            \"path\": \"apps/my-app/plugins/plugin2.js\",\n            \"options\": {\n              \"someOption\": \"some value\"\n            }\n          }\n        ]\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin1.js\" %}\nconst plugin1 = {\n  name: 'plugin1',\n  setup(build) {\n    const options = build.initialOptions;\n    options.define.PLUGIN1_TEXT = '\"Value was provided at build time\"';\n  },\n};\n\nmodule.exports = plugin1;\n```\n\n```ts {% fileName=\"apps/my-app/plugins/plugin2.js\" %}\nfunction plugin2({ someOption }) {\n  return {\n    name: 'plugin2',\n    setup(build) {\n      const options = build.initialOptions;\n      options.define.PLUGIN2_TEXT = JSON.stringify(someOption);\n    },\n  };\n}\n\nmodule.exports = plugin2;\n```\n\nAdditionally, we need to inform TypeScript of the defined variables to prevent type-checking errors during the build. We can achieve this by creating or updating a type definition file included in the TypeScript build process (e.g. `src/types.d.ts`) with the following content:\n\n```ts {% fileName=\"apps/my-app/src/types.d.ts\" %}\ndeclare const PLUGIN1_TEXT: number;\ndeclare const PLUGIN2_TEXT: string;\n```\n\n{% /tab %}\n{% /tabs %}\n",
     "outputCapture": "direct-nodejs",
     "type": "object",
     "properties": {
@@ -648,7 +648,7 @@
     },
     "presets": []
   },
-  "description": "Builds your application with esbuild and adds support for incremental builds.",
+  "description": "Builds an Angular application using [esbuild](https://esbuild.github.io/).",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/executors/browser-esbuild/schema.json",

docs/generated/packages/angular/executors/dev-server.json

@@ -6,8 +6,8 @@
     "outputCapture": "direct-nodejs",
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Schema for Webpack Dev Server",
-    "description": "Serves an Angular application using [Webpack](https://webpack.js.org/) when the build target is using a Webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an esbuild-based executor.",
-    "examplesFile": "The `@nx/angular:dev-server` executor is very similar to the `@angular-devkit/build-angular:dev-server` builder provided by the Angular CLI. In addition to the features provided by the Angular CLI builder, the `@nx/angular:dev-server` executor also supports the following:\n\n- Best integration for `@nx/angular:webpack-browser`, `@nx/angular:browser-esbuild` and `@nx/angular:application`\n- Providing HTTP request middleware functions when the build target is using an esbuild-based executor\n- Incremental builds\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom Webpack configuration\" %}\n\nThis executor should be used along with `@nx/angular:webpack-browser` to serve an application using a custom Webpack configuration.\n\nAdd the `serve` target using the `@nx/angular:dev-server` executor, set the `build` target executor as `@nx/angular:webpack-browser` and set the `customWebpackConfig` option as shown below:\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[2,\"5-7\",\"10-20\"] %}\n\"build\": {\n  \"executor\": \"@nx/angular:webpack-browser\",\n  \"options\": {\n    ...\n    \"customWebpackConfig\": {\n      \"path\": \"apps/my-app/webpack.config.js\"\n    }\n  }\n},\n\"serve\": {\n  \"executor\": \"@nx/angular:dev-server\",\n  \"configurations\": {\n    \"production\": {\n      \"buildTarget\": \"my-app:build:production\"\n    },\n    \"development\": {\n      \"buildTarget\": \"my-app:build:development\"\n    }\n  },\n  \"defaultConfiguration\": \"development\",\n}\n```\n\n```js {% fileName=\"apps/my-app/webpack.config.js\" %}\nmodule.exports = (config) => {\n  // update the config with your custom configuration\n\n  return config;\n};\n```\n\n{% /tab %}\n\n{% tab label=\"Providing HTTP request middleware function\" %}\n\n{% callout type=\"warning\" title=\"Overrides\" }\n\nAvailable for workspaces using Angular version 17.0.0 or greater and with `build` targets using an esbuild-based executor.\n\n{% /callout %}\n\nThe executor accepts an `esbuildMidleware` option that allows you to provide HTTP require middleware functions that will be used by the Vite development server.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[8] %}\n{\n  ...\n  \"targets\": {\n    \"serve\": {\n      \"executor\": \"@nx/angular:dev-server\",\n      \"options\": {\n        ...\n        \"esbuildMidleware\": [\"apps/my-app/hello-world.middleware.ts\"]\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/hello-world.middleware.ts\" %}\nimport type { IncomingMessage, ServerResponse } from 'node:http';\n\nconst helloWorldMiddleware = (\n  req: IncomingMessage,\n  res: ServerResponse,\n  next: (err?: unknown) => void\n) => {\n  if (req.url === '/hello-world') {\n    res.end('<h1>Hello World!</h1>');\n  } else {\n    next();\n  }\n};\n\nexport default helloWorldMiddleware;\n```\n\n{% /tab %}\n",
+    "description": "Serves an Angular application using [webpack](https://webpack.js.org/) when the build target is using a webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an [esbuild](https://esbuild.github.io/)-based executor.",
+    "examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:dev-server` builder provided by the Angular CLI. In addition to the features provided by the Angular CLI builder, the `@nx/angular:dev-server` executor also supports the following:\n\n- Serving applications with Vite when using the `@nx/angular:application` or `@nx/angular:browser-esbuild` executors to build them\n- Serving applications with webpack when using the `@nx/angular:webpack-browser` executor\n- Providing HTTP request middleware functions when the build target is using an esbuild-based executor\n- Incremental builds\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom webpack configuration\" %}\n\nThis executor should be used along with `@nx/angular:webpack-browser` to serve an application using a custom webpack configuration.\n\nAdd the `serve` target using the `@nx/angular:dev-server` executor, set the `build` target executor as `@nx/angular:webpack-browser` and set the `customWebpackConfig` option as shown below:\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[2,\"5-7\",\"10-20\"] %}\n\"build\": {\n  \"executor\": \"@nx/angular:webpack-browser\",\n  \"options\": {\n    ...\n    \"customWebpackConfig\": {\n      \"path\": \"apps/my-app/webpack.config.js\"\n    }\n  }\n},\n\"serve\": {\n  \"executor\": \"@nx/angular:dev-server\",\n  \"configurations\": {\n    \"production\": {\n      \"buildTarget\": \"my-app:build:production\"\n    },\n    \"development\": {\n      \"buildTarget\": \"my-app:build:development\"\n    }\n  },\n  \"defaultConfiguration\": \"development\",\n}\n```\n\n```js {% fileName=\"apps/my-app/webpack.config.js\" %}\nmodule.exports = (config) => {\n  // update the config with your custom configuration\n\n  return config;\n};\n```\n\n{% /tab %}\n\n{% tab label=\"Providing HTTP request middleware function\" %}\n\n{% callout type=\"warning\" title=\"Overrides\" }\n\nAvailable for workspaces using Angular version 17.0.0 or greater and with `build` targets using an esbuild-based executor.\n\n{% /callout %}\n\nThe executor accepts an `esbuildMidleware` option that allows you to provide HTTP require middleware functions that will be used by the Vite development server.\n\n```json {% fileName=\"apps/my-app/project.json\" highlightLines=[8] %}\n{\n  ...\n  \"targets\": {\n    \"serve\": {\n      \"executor\": \"@nx/angular:dev-server\",\n      \"options\": {\n        ...\n        \"esbuildMidleware\": [\"apps/my-app/hello-world.middleware.ts\"]\n      }\n    }\n    ...\n  }\n}\n```\n\n```ts {% fileName=\"apps/my-app/hello-world.middleware.ts\" %}\nimport type { IncomingMessage, ServerResponse } from 'node:http';\n\nconst helloWorldMiddleware = (\n  req: IncomingMessage,\n  res: ServerResponse,\n  next: (err?: unknown) => void\n) => {\n  if (req.url === '/hello-world') {\n    res.end('<h1>Hello World!</h1>');\n  } else {\n    next();\n  }\n};\n\nexport default helloWorldMiddleware;\n```\n\n{% /tab %}\n",
     "type": "object",
     "presets": [
       { "name": "Using a Different Port", "keys": ["buildTarget", "port"] }
@@ -17,7 +17,7 @@
         "type": "string",
         "description": "A browser builder target to serve in the format of `project:target[:configuration]`. Ignored if `buildTarget` is set.",
         "pattern": "^[^:\\s]+:[^:\\s]+(:[^\\s]+)?$",
-        "x-deprecated": "Use 'buildTarget' instead. It will be removed in Nx v19."
+        "x-deprecated": "Use 'buildTarget' instead. It will be removed in Nx v20."
       },
       "buildTarget": {
         "type": "string",
@@ -148,7 +148,7 @@
       { "required": ["browserTarget"] }
     ]
   },
-  "description": "Serves an Angular application using [Webpack](https://webpack.js.org/) when the build target is using a Webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an esbuild-based executor.",
+  "description": "Serves an Angular application using [webpack](https://webpack.js.org/) when the build target is using a webpack-based executor, or [Vite](https://vitejs.dev/) when the build target uses an [esbuild](https://esbuild.github.io/)-based executor.",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/builders/dev-server/schema.json",

docs/generated/packages/angular/executors/module-federation-dev-server.json

@@ -5,7 +5,7 @@
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Schema for Module Federation Dev Server",
     "outputCapture": "direct-nodejs",
-    "description": "The module-federation-dev-server executor is reserved exclusively for use with host Module Federation applications. It allows the user to specify which remote applications should be served with the host.",
+    "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) allowing to specify which remote applications should be served with the host.",
     "type": "object",
     "presets": [
       { "name": "Using a Different Port", "keys": ["buildTarget", "port"] }
@@ -15,7 +15,7 @@
         "type": "string",
         "description": "A browser builder target to serve in the format of `project:target[:configuration]`.",
         "pattern": "^[^:\\s]+:[^:\\s]+(:[^\\s]+)?$",
-        "x-deprecated": "Use 'buildTarget' instead. It will be removed in Nx v19."
+        "x-deprecated": "Use 'buildTarget' instead. It will be removed in Nx v20."
       },
       "buildTarget": {
         "type": "string",
@@ -149,7 +149,7 @@
     ],
     "examplesFile": "## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\nThe Module Federation Dev Server will serve a host application and find the remote applications associated with the host and serve them statically also.  \nSee an example set up of it below:\n\n```json\n{\n  \"serve\": {\n    \"executor\": \"@nx/angular:module-federation-dev-server\",\n    \"configurations\": {\n      \"production\": {\n        \"buildTarget\": \"host:build:production\"\n      },\n      \"development\": {\n        \"buildTarget\": \"host:build:development\"\n      }\n    },\n    \"defaultConfiguration\": \"development\",\n    \"options\": {\n      \"port\": 4200,\n      \"publicHost\": \"http://localhost:4200\"\n    }\n  }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Serve host with remotes that can be live reloaded\" %}\nThe Module Federation Dev Server will serve a host application and find the remote applications associated with the host and serve a set selection with live reloading enabled also.  \nSee an example set up of it below:\n\n```json\n{\n  \"serve-with-hmr-remotes\": {\n    \"executor\": \"@nx/angular:module-federation-dev-server\",\n    \"configurations\": {\n      \"production\": {\n        \"buildTarget\": \"host:build:production\"\n      },\n      \"development\": {\n        \"buildTarget\": \"host:build:development\"\n      }\n    },\n    \"defaultConfiguration\": \"development\",\n    \"options\": {\n      \"port\": 4200,\n      \"publicHost\": \"http://localhost:4200\",\n      \"devRemotes\": [\"remote1\", \"remote2\"]\n    }\n  }\n}\n```\n\n{% /tab %}\n\n{% /tabs %}\n"
   },
-  "description": "The module-federation-dev-server executor is reserved exclusively for use with host Module Federation applications. It allows the user to specify which remote applications should be served with the host.",
+  "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) allowing to specify which remote applications should be served with the host.",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/executors/module-federation-dev-server/schema.json",

docs/generated/packages/angular/executors/module-federation-dev-ssr.json

@@ -4,7 +4,7 @@
   "schema": {
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Module Federation SSR Dev Server Target",
-    "description": "SSR Dev Server target options for Module Federation host applications.",
+    "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) that use SSR allowing to specify which remote applications should be served with the host.",
     "type": "object",
     "properties": {
       "browserTarget": {
@@ -88,7 +88,7 @@
     "required": ["browserTarget", "serverTarget"],
     "presets": []
   },
-  "description": "The module-federation-dev-ssr executor is reserved exclusively for use with host Module Federation applications that use SSR. It allows the user to specify which remote applications should be served with the host.",
+  "description": "Serves host [Module Federation](https://module-federation.io/) applications ([webpack](https://webpack.js.org/)-based) that use SSR allowing to specify which remote applications should be served with the host.",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/builders/module-federation-dev-ssr/schema.json",

docs/generated/packages/angular/executors/ng-packagr-lite.json

@@ -6,7 +6,7 @@
     "outputCapture": "direct-nodejs",
     "$schema": "https://json-schema.org/schema",
     "title": "ng-packagr Target",
-    "description": "Builds a library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nx/angular:package` executor but with some key differences:\n- For supported Angular versions lower than v16, it doesn't run `ngcc` automatically (`ngcc` is no longer available from Angular v16 onwards, for lower versions, it needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2022 bundles (ESM2020 for supported Angular versions lower than v16).",
+    "description": "Builds an Angular library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nx/angular:package` executor but with some key differences:\n- For supported Angular versions lower than v16, it doesn't run `ngcc` automatically (`ngcc` is no longer available from Angular v16 onwards, for lower versions, it needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2022 bundles (ESM2020 for supported Angular versions lower than v16).",
     "cli": "nx",
     "type": "object",
     "presets": [
@@ -44,7 +44,7 @@
     "additionalProperties": false,
     "required": ["project"]
   },
-  "description": "Builds a library with support for incremental builds.\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nrwl/angular:package` executor but with some key differences:\n- It doesn't run `ngcc` automatically (`ngcc` needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2020 bundles.\n- It doesn't generate package exports in the `package.json`.",
+  "description": "Builds an Angular library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nx/angular:package` executor but with some key differences:\n- For supported Angular versions lower than v16, it doesn't run `ngcc` automatically (`ngcc` is no longer available from Angular v16 onwards, for lower versions, it needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2022 bundles (ESM2020 for supported Angular versions lower than v16).",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/executors/ng-packagr-lite/schema.json",

docs/generated/packages/angular/executors/package.json

@@ -6,7 +6,7 @@
     "outputCapture": "direct-nodejs",
     "$schema": "https://json-schema.org/schema",
     "title": "ng-packagr Target",
-    "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\n\nThis executor is similar to the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
+    "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\n\nThis executor is a drop-in replacement for the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
     "cli": "nx",
     "type": "object",
     "presets": [
@@ -53,7 +53,7 @@
       "project"
     ]
   },
-  "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\nThis executor is similar to the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
+  "description": "Builds and packages an Angular library producing an output following the Angular Package Format (APF) to be distributed as an NPM package.\n\nThis executor is a drop-in replacement for the `@angular-devkit/build-angular:ng-packagr` with additional support for incremental builds.",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/executors/package/schema.json",

docs/generated/packages/angular/executors/webpack-browser.json

@@ -6,8 +6,8 @@
     "outputCapture": "direct-nodejs",
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Schema for Webpack Browser",
-    "description": "The webpack-browser executor is very similar to the standard browser builder provided by the Angular Devkit. It allows you to build your Angular application to a build artifact that can be hosted online. There are some key differences:   \n- Supports Custom Webpack Configurations  \n- Supports Incremental Building",
-    "examplesFile": "##### Using a custom webpack configuration\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n    \"executor\": \"@nx/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"customWebpackConfig\": {\n          \"path\": \"apps/appName/webpack.config.js\"\n        }\n    }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n    \"executor\": \"@nx/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"buildLibsFromSource\": false\n    }\n}\n```\n",
+    "description": "Builds an Angular application using [webpack](https://webpack.js.org/).",
+    "examplesFile": "This executor is a drop-in replacement for the `@angular-devkit/build-angular:browser` builder provided by the Angular CLI. It builds an Angular application using [webpack](https://webpack.js.org/).\n\nIn addition to the features provided by the Angular CLI builder, the `@nx/angular:webpack-browser` executor also supports the following:\n\n- Providing a custom webpack configuration\n- Incremental builds\n\n{% callout type=\"check\" title=\"Dev Server\" %}\nThe [`@nx/angular:dev-server` executor](https://nx.dev/nx-api/angular/executors/dev-server) is required to serve your application when using the `@nx/angular:browser-esbuild` to build it. It is a drop-in replacement for the Angular CLI's `@angular-devkit/build-angular:dev-server` builder and ensures the application is correctly served with Vite when using the `@nx/angular:browser-esbuild` executor.\n{% /callout %}\n\n## Examples\n\n{% tabs %}\n{% tab label=\"Using a custom webpack configuration\" %}\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,\"8-10\"] %}\n{\n    ...\n    \"targets\": {\n        \"build\": {\n            \"executor\": \"@nx/angular:webpack-browser\",\n            \"options\": {\n                ...\n                \"customWebpackConfig\": {\n                  \"path\": \"apps/appName/webpack.config.js\"\n                }\n            }\n        },\n        ...\n    }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Incrementally Building your Application\" %}\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n{% callout type=\"note\" title=\"Performance\" %}\nThere may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n{% /callout %}\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```json {% fileName=\"project.json\" highlightLines=[5,8] %}\n{\n    ...\n    \"targets\": {\n        \"build\": {\n            \"executor\": \"@nx/angular:webpack-browser\",\n            \"options\": {\n                ...\n                \"buildLibsFromSource\": false\n            }\n        },\n        ...\n    }\n}\n```\n\n{% /tab %}\n{% /tabs %}\n",
     "type": "object",
     "presets": [
       {
@@ -689,7 +689,7 @@
       }
     }
   },
-  "description": "The `webpack-browser` executor is very similar to the standard `browser` builder provided by the Angular Devkit. It allows you to build your Angular application to a build artifact that can be hosted online. There are some key differences:   \n- Supports Custom Webpack Configurations  \n- Supports Incremental Building",
+  "description": "Builds an Angular application using [webpack](https://webpack.js.org/).",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/builders/webpack-browser/schema.json",

docs/generated/packages/angular/executors/webpack-server.json

@@ -6,7 +6,7 @@
     "outputCapture": "direct-nodejs",
     "$schema": "http://json-schema.org/draft-07/schema",
     "title": "Schema for Webpack Server",
-    "description": "The webpack-server executor is very similar to the standard server builder provided by the Angular Devkit. It is usually used in tandem with `@nx/angular:webpack-browser` when your Angular application uses a custom webpack configuration and NgUniversal for SSR.",
+    "description": "Builds a server Angular application using [webpack](https://webpack.js.org/). This executor is a drop-in replacement for the `@angular-devkit/build-angular:server` builder provided by the Angular CLI. It is usually used in tandem with the `@nx/angular:webpack-browser` executor when your Angular application uses a custom webpack configuration.",
     "type": "object",
     "properties": {
       "assets": {
@@ -369,7 +369,7 @@
     },
     "presets": []
   },
-  "description": "The `webpack-server` executor is very similar to the standard `server` builder provided by the Angular Devkit. It is usually used in tandem with `@nrwl/angular:webpack-browser` when your Angular application uses a custom webpack configuration and NgUniversal for SSR.",
+  "description": "Builds a server Angular application using [webpack](https://webpack.js.org/). This executor is a drop-in replacement for the `@angular-devkit/build-angular:server` builder provided by the Angular CLI. It is usually used in tandem with the `@nx/angular:webpack-browser` executor when your Angular application uses a custom webpack configuration.",
   "aliases": [],
   "hidden": false,
   "path": "/packages/angular/src/builders/webpack-server/schema.json",

docs/generated/packages/angular/generators/component.json

@@ -32,7 +32,7 @@
         "description": "The name of the project.",
         "$default": { "$source": "projectName" },
         "x-dropdown": "projects",
-        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. The project will be determined from the directory provided. It will be removed in Nx v19."
+        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. The project will be determined from the directory provided. It will be removed in Nx v20."
       },
       "prefix": {
         "type": "string",
@@ -96,7 +96,7 @@
         "type": "boolean",
         "description": "Create the new files at the top level of the current project.",
         "default": false,
-        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. It will be removed in Nx v19."
+        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. It will be removed in Nx v20."
       },
       "skipImport": {
         "type": "boolean",

docs/generated/packages/angular/generators/directive.json

@@ -32,7 +32,7 @@
         "description": "The name of the project.",
         "$default": { "$source": "projectName" },
         "x-dropdown": "projects",
-        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. The project will be determined from the directory provided. It will be removed in Nx v19."
+        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. The project will be determined from the directory provided. It will be removed in Nx v20."
       },
       "prefix": {
         "type": "string",
@@ -67,7 +67,7 @@
         "type": "boolean",
         "description": "When true (the default), creates the new files at the top level of the current project.",
         "default": true,
-        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. It will be removed in Nx v19."
+        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. It will be removed in Nx v20."
       },
       "module": {
         "type": "string",

docs/generated/packages/angular/generators/pipe.json

@@ -32,13 +32,13 @@
         "description": "The name of the project.",
         "$default": { "$source": "projectName" },
         "x-dropdown": "projects",
-        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. The project will be determined from the directory provided. It will be removed in Nx v19."
+        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. The project will be determined from the directory provided. It will be removed in Nx v20."
       },
       "flat": {
         "type": "boolean",
         "default": true,
         "description": "When true (the default) creates files at the top level of the project.",
-        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. It will be removed in Nx v19."
+        "x-deprecated": "Provide the `directory` option instead and use the `as-provided` format. It will be removed in Nx v20."
       },
       "skipTests": {
         "type": "boolean",