docs(nx-dev): diataxis restructure (#11649)

* docs(nxdev): restructure docs to diataxis style

* docs(nxdev): cleanup

* docs(nxdev): fix links

* chore(nxdev): format

* docs(nxdev): fix broken images

* docs(nxdev): fix links

* docs(nxdev): fix links

* docs(nxdev): fix links

* docs(nxdev): tweaks

* docs(nxdev): redirect rules

* docs(nxdev): fixes

docs/generated/cli/affected-apps.md

@@ -15,7 +15,7 @@ Print applications affected by changes
 nx affected:apps
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/affected-graph.md

@@ -13,7 +13,7 @@ Graph dependencies affected by changes
 nx affected:graph
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/affected-libs.md

@@ -15,7 +15,7 @@ Print libraries affected by changes
 nx affected:libs
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/affected.md

@@ -13,7 +13,7 @@ Run target for affected projects
 nx affected
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/connect-to-nx-cloud.md

@@ -13,7 +13,7 @@ Makes sure the workspace is connected to Nx Cloud
 nx connect-to-nx-cloud
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ## Options
 

docs/generated/cli/daemon.md

@@ -13,7 +13,7 @@ Prints information about the Nx Daemon process or starts a daemon process
 nx daemon
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ## Options
 

docs/generated/cli/format-check.md

@@ -13,7 +13,7 @@ Check for un-formatted files
 nx format:check
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ## Options
 

docs/generated/cli/format-write.md

@@ -13,7 +13,7 @@ Overwrite un-formatted files
 nx format:write
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ## Options
 

docs/generated/cli/generate.md

@@ -17,7 +17,7 @@ nx generate <collection:generator>
 nx g <generator>
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/graph.md

@@ -13,7 +13,7 @@ Graph dependencies within workspace
 nx graph
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/init.md

@@ -13,4 +13,4 @@ Adds nx.json file and installs nx if not installed already
 nx init
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.

docs/generated/cli/list.md

@@ -13,7 +13,7 @@ Lists installed plugins, capabilities of installed plugins and other available p
 nx list [plugin]
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/migrate.md

@@ -18,7 +18,7 @@ Creates a migrations file or runs migrations from the migrations file.
 nx migrate [packageAndVersion]
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/print-affected.md

@@ -13,7 +13,7 @@ Prints information about the projects and targets affected by changes
 nx print-affected
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/repair.md

@@ -13,7 +13,7 @@ Repair any configuration that is no longer supported by Nx.
 nx repair
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ## Options
 

docs/generated/cli/report.md

@@ -13,4 +13,4 @@ Reports useful version numbers to copy into the Nx issue template
 nx report
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.

docs/generated/cli/reset.md

@@ -13,4 +13,4 @@ Clears all the cached Nx artifacts and metadata about the workspace and shuts do
 nx reset
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.

docs/generated/cli/run-many.md

@@ -13,7 +13,7 @@ Run target for multiple listed projects
 nx run-many
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/run.md

@@ -13,7 +13,7 @@ Runs an Architect target with an optional custom builder configuration defined i
 nx run <target> [options]
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/generated/cli/workspace-generator.md

@@ -13,7 +13,7 @@ Runs a workspace generator from the tools/generators directory
 nx workspace-generator [name]
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ## Options
 

docs/generated/cli/workspace-lint.md

@@ -13,4 +13,4 @@ Lint nx specific workspace files (nx.json, workspace.json)
 nx workspace-lint [files..]
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.

docs/generated/packages/angular.json

@@ -11,7 +11,7 @@
       "id": "overview",
       "path": "/packages/angular",
       "file": "shared/angular-plugin",
-      "content": "![Angular logo](/shared/angular-logo.png)\n\nThe Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides:\n\n- Integration with libraries such as Storybook, Jest, Cypress, Karma, and Protractor.\n- Generators to help scaffold code quickly, including:\n  - Micro Frontends\n  - Libraries, both internal to your codebase and publishable to npm\n  - Upgrading AngularJS applications\n  - Single Component Application Modules (SCAMs)\n- NgRx helpers.\n- Utilities for automatic workspace refactoring.\n\n## Setting up the Angular plugin\n\nAdding the Angular plugin to an existing Nx workspace can be done with the following:\n\n```bash\nyarn add -D @nrwl/angular\n```\n\n```bash\nnpm install -D @nrwl/angular\n```\n\n## Using the Angular Plugin\n\n### Generating an application\n\nIt's straightforward to generate an Angular application:\n\n```bash\nnx g @nrwl/angular:app appName\n```\n\nBy default, the application will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n- Cypress as the E2E test runner.\n\nWe can then serve, build, test, lint, and run e2e tests on the application with the following commands:\n\n```bash\nnx serve appName\nnx build appName\nnx test appName\nnx lint appName\nnx e2e appName\n```\n\n### Generating a library\n\nGenerating an Angular library is very similar to generating an application:\n\n```bash\nnx g @nrwl/angular:lib libName\n```\n\nBy default, the library will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n\nWe can then test and lint the library with the following commands:\n\n```bash\nnx test libName\nnx lint libName\n```\n\nRead more about:\n\n- [Creating Libraries](/structure/creating-libraries)\n- [Library Types](/structure/library-types)\n- [Buildable and Publishable Libraries](/structure/buildable-and-publishable-libraries)\n\n## More Documentation\n\n- [Angular Nx Tutorial](/angular-tutorial/01-create-application)\n- [Setup Module Federation with Angular and Nx](/module-federation/faster-builds)\n- [Using NgRx](/guides/misc-ngrx)\n- [Using Data Persistence operators](/guides/misc-data-persistence)\n- [Upgrading an AngularJS application to Angular](/migration/migration-angularjs)\n- [Using Tailwind CSS with Angular projects](/guides/using-tailwind-css-with-angular-projects)\n"
+      "content": "![Angular logo](/shared/angular-logo.png)\n\nThe Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides:\n\n- Integration with libraries such as Storybook, Jest, Cypress, Karma, and Protractor.\n- Generators to help scaffold code quickly, including:\n  - Micro Frontends\n  - Libraries, both internal to your codebase and publishable to npm\n  - Upgrading AngularJS applications\n  - Single Component Application Modules (SCAMs)\n- NgRx helpers.\n- Utilities for automatic workspace refactoring.\n\n## Setting up the Angular plugin\n\nAdding the Angular plugin to an existing Nx workspace can be done with the following:\n\n```bash\nyarn add -D @nrwl/angular\n```\n\n```bash\nnpm install -D @nrwl/angular\n```\n\n## Using the Angular Plugin\n\n### Generating an application\n\nIt's straightforward to generate an Angular application:\n\n```bash\nnx g @nrwl/angular:app appName\n```\n\nBy default, the application will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n- Cypress as the E2E test runner.\n\nWe can then serve, build, test, lint, and run e2e tests on the application with the following commands:\n\n```bash\nnx serve appName\nnx build appName\nnx test appName\nnx lint appName\nnx e2e appName\n```\n\n### Generating a library\n\nGenerating an Angular library is very similar to generating an application:\n\n```bash\nnx g @nrwl/angular:lib libName\n```\n\nBy default, the library will be generated with:\n\n- ESLint as the linter.\n- Jest as the unit test runner.\n\nWe can then test and lint the library with the following commands:\n\n```bash\nnx test libName\nnx lint libName\n```\n\nRead more about:\n\n- [Creating Libraries](/more-concepts/creating-libraries)\n- [Library Types](/more-concepts/library-types)\n- [Buildable and Publishable Libraries](/more-concepts/buildable-and-publishable-libraries)\n\n## More Documentation\n\n- [Angular Nx Tutorial](/angular-tutorial/01-create-application)\n- [Setup Module Federation with Angular and Nx](/recipe/faster-builds)\n- [Using NgRx](/recipe/misc-ngrx)\n- [Using Data Persistence operators](/recipe/misc-data-persistence)\n- [Upgrading an AngularJS application to Angular](/recipe/migration-angularjs)\n- [Using Tailwind CSS with Angular projects](/recipe/using-tailwind-css-with-angular-projects)\n"
     },
     {
       "name": "Angular and Nx Version Matrix",
@@ -2375,7 +2375,7 @@
         "$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\": \"@nrwl/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> You can read more about when to use incremental builds [here](/ci/incremental-builds#when-should-i-use-incremental-builds).\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\": \"@nrwl/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"buildLibsFromSource\": false\n    }\n}\n```\n",
+        "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\": \"@nrwl/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> You can read more about when to use incremental builds [here](/more-concepts/incremental-builds#when-should-i-use-incremental-builds).\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\": \"@nrwl/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"buildLibsFromSource\": false\n    }\n}\n```\n",
         "type": "object",
         "presets": [
           {

docs/generated/packages/cypress.json

@@ -11,7 +11,7 @@
       "id": "overview",
       "path": "/packages/cypress",
       "file": "shared/cypress-plugin",
-      "content": "![Cypress logo](/shared/cypress-logo.png)\n\nCypress is a test runner built for the modern web. It has a lot of great features:\n\n- Time travel\n- Real-time reloads\n- Automatic waiting\n- Spies, stubs, and clocks\n- Network traffic control\n- Screenshots and videos\n\n## Setting Up Cypress\n\n> Info about [Cypress Component Testing can be found here](/cypress/cypress-component-testing)\n\nIf the `@nrwl/cypress` package is not installed, install the version that matches your `nx` package version.\n\n```bash\nyarn add --dev @nrwl/cypress\n```\n\n```bash\nnpm install --save-dev @nrwl/cypress\n```\n\n## E2E Testing\n\nBy default, when creating a new frontend application, Nx will use Cypress to create the e2e tests project.\n\n```bash\nnx g @nrwl/web:app frontend\n```\n\n### Creating a Cypress E2E project for an existing project\n\nTo generate an E2E project based on an existing project, run the following generator\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --project=your-app-name\n```\n\nOptionally, you can use the `--baseUrl` option if you don't want cypress plugin to serve `your-app-name`.\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --baseUrl=http://localhost:4200\n```\n\nReplace `your-app-name` with the app's name as defined in your `workspace.json` file.\n\n### Testing Applications\n\nRun `nx e2e frontend-e2e` to execute e2e tests with Cypress.\n\nYou can run your e2e test against a production build with the `--prod` flag\n\n```bash\nnx e2e frontend-e2e --prod\n```\n\nBy default, Cypress will run in headless mode. You will have the result of all the tests and errors (if any) in your\nterminal. Screenshots and videos will be accessible in `dist/cypress/apps/frontend/screenshots` and `dist/cypress/apps/frontend/videos`.\n\n### Watching for Changes (Headed Mode)\n\nWith, `nx e2e frontend-e2e --watch` Cypress will start in headed mode where you can see your application being tested.\n\nRunning Cypress with `--watch` is a great way to enhance dev workflow - you can build up test files with the application\nrunning and Cypress will re-run those tests as you enhance and add to the suite.\n\n```bash\nnx e2e frontend-e2e --prod\n```\n\n### Specifying a Custom Url to Test\n\nThe `baseUrl` property provides you the ability to test an application hosted on a specific domain.\n\n```bash\nnx e2e frontend-e2e --baseUrl=https://frontend.com\n```\n\n> If no `baseUrl` and no `devServerTarget` are provided, Cypress will expect to have the `baseUrl` property in\n> the cypress config file, or will error.\n\n## Using cypress.config.ts\n\nIf you need to fine tune your Cypress setup, you can do so by modifying `cypress.config.ts` in the project root. For\ninstance,\nyou can easily add your `projectId` to save all the screenshots and videos into your Cypress dashboard. The complete\nconfiguration is documented\non [the official website](https://docs.cypress.io/guides/references/configuration.html#Options).\n\n## Environment Variables\n\nIf you're needing to pass a variable to cypress that you wish to not commit to your repository, i.e. API keys, or dynamic values based on configurations, i.e. API Urls. This is where [Cypress environment variables](https://docs.cypress.io/guides/guides/environment-variables) can be used.\n\nThere are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the [env executor option for cypress](https://nx.dev/packages/cypress/executors/cypress#env) or the commandline.\n\nCreate a `cypress.env.json` file in the projects root i.e. `apps/my-cool-app-e2e/cypress.env.json`. Cypress will automatically pick up this file. This method is helpful for configurations that you want to not commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to popluate in their local copy of the `cypress.env.json` file.\n\nUsing [@nrwl/cypress:cypress](/packages/cypress/executors/cypress) env executor option is a good way to add values you want to define that you don't mine commit to the repository, such as a base API url. You can leverage [target configurations](/configuration/projectjson#targets) to define different values as well.\n\nOptionally, you can pass environment variables via the commandline with the `--env` flag.\n\n{% callout type=\"warning\" title=\"Executor options and --env\" %}\nWhen using the `--env` flag, this will not be merged with any values used in the `env` executor option.\n{% /callout %}\n\n```bash\nnx e2e frontend-e2e --env.API_URL=\"https://api.my-nx-website.com\" --env.API_KEY=\"abc-123\"\n```\n"
+      "content": "![Cypress logo](/shared/cypress-logo.png)\n\nCypress is a test runner built for the modern web. It has a lot of great features:\n\n- Time travel\n- Real-time reloads\n- Automatic waiting\n- Spies, stubs, and clocks\n- Network traffic control\n- Screenshots and videos\n\n## Setting Up Cypress\n\n> Info about [Cypress Component Testing can be found here](/cypress/cypress-component-testing)\n\nIf the `@nrwl/cypress` package is not installed, install the version that matches your `nx` package version.\n\n```bash\nyarn add --dev @nrwl/cypress\n```\n\n```bash\nnpm install --save-dev @nrwl/cypress\n```\n\n## E2E Testing\n\nBy default, when creating a new frontend application, Nx will use Cypress to create the e2e tests project.\n\n```bash\nnx g @nrwl/web:app frontend\n```\n\n### Creating a Cypress E2E project for an existing project\n\nTo generate an E2E project based on an existing project, run the following generator\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --project=your-app-name\n```\n\nOptionally, you can use the `--baseUrl` option if you don't want cypress plugin to serve `your-app-name`.\n\n```bash\nnx g @nrwl/cypress:cypress-project your-app-name-e2e --baseUrl=http://localhost:4200\n```\n\nReplace `your-app-name` with the app's name as defined in your `workspace.json` file.\n\n### Testing Applications\n\nRun `nx e2e frontend-e2e` to execute e2e tests with Cypress.\n\nYou can run your e2e test against a production build with the `--prod` flag\n\n```bash\nnx e2e frontend-e2e --prod\n```\n\nBy default, Cypress will run in headless mode. You will have the result of all the tests and errors (if any) in your\nterminal. Screenshots and videos will be accessible in `dist/cypress/apps/frontend/screenshots` and `dist/cypress/apps/frontend/videos`.\n\n### Watching for Changes (Headed Mode)\n\nWith, `nx e2e frontend-e2e --watch` Cypress will start in headed mode where you can see your application being tested.\n\nRunning Cypress with `--watch` is a great way to enhance dev workflow - you can build up test files with the application\nrunning and Cypress will re-run those tests as you enhance and add to the suite.\n\n```bash\nnx e2e frontend-e2e --prod\n```\n\n### Specifying a Custom Url to Test\n\nThe `baseUrl` property provides you the ability to test an application hosted on a specific domain.\n\n```bash\nnx e2e frontend-e2e --baseUrl=https://frontend.com\n```\n\n> If no `baseUrl` and no `devServerTarget` are provided, Cypress will expect to have the `baseUrl` property in\n> the cypress config file, or will error.\n\n## Using cypress.config.ts\n\nIf you need to fine tune your Cypress setup, you can do so by modifying `cypress.config.ts` in the project root. For\ninstance,\nyou can easily add your `projectId` to save all the screenshots and videos into your Cypress dashboard. The complete\nconfiguration is documented\non [the official website](https://docs.cypress.io/guides/references/configuration.html#Options).\n\n## Environment Variables\n\nIf you're needing to pass a variable to cypress that you wish to not commit to your repository, i.e. API keys, or dynamic values based on configurations, i.e. API Urls. This is where [Cypress environment variables](https://docs.cypress.io/guides/guides/environment-variables) can be used.\n\nThere are a handful of ways to pass environment variables to Cypress, but the most common is going to be via the [`cypress.env.json` file](https://docs.cypress.io/guides/guides/environment-variables#Option-1-configuration-file), the [env executor option for cypress](https://nx.dev/packages/cypress/executors/cypress#env) or the commandline.\n\nCreate a `cypress.env.json` file in the projects root i.e. `apps/my-cool-app-e2e/cypress.env.json`. Cypress will automatically pick up this file. This method is helpful for configurations that you want to not commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to popluate in their local copy of the `cypress.env.json` file.\n\nUsing [@nrwl/cypress:cypress](/packages/cypress/executors/cypress) env executor option is a good way to add values you want to define that you don't mine commit to the repository, such as a base API url. You can leverage [target configurations](/reference/project-configuration#targets) to define different values as well.\n\nOptionally, you can pass environment variables via the commandline with the `--env` flag.\n\n{% callout type=\"warning\" title=\"Executor options and --env\" %}\nWhen using the `--env` flag, this will not be merged with any values used in the `env` executor option.\n{% /callout %}\n\n```bash\nnx e2e frontend-e2e --env.API_URL=\"https://api.my-nx-website.com\" --env.API_KEY=\"abc-123\"\n```\n"
     },
     {
       "name": "Component Testing",

docs/generated/packages/eslint-plugin-nx.json

@@ -11,7 +11,7 @@
       "name": "Overview",
       "path": "/packages/eslint-plugin-nx",
       "file": "shared/eslint-plugin-nx",
-      "content": "![ESLint logo](/shared/eslint-logo.png)\n\nA plugin containing a collection of recommended ESLint rule configurations wrapped as ESLint plugins and an Nx specific [enforce-module-boundaries](#enforce-module-boundaries) rule.\n\n## Setting Up ESLint Plugin\n\n### Installation\n\nIn any Nx workspace, you can install `@nrwl/eslint-plugin-nx` by running the following commands if the package is not already installed:\n\n```bash\nnpm i --save-dev @nrwl/eslint-plugin-nx\n```\n\n```bash\nyarn add --dev @nrwl/eslint-plugin-nx\n```\n\n## ESLint plugins\n\nThe plugin contains the following rule configurations divided into sub-plugins.\n\n### JavaScript\n\nThe `@nrwl/nx/javascript` ESLint plugin contains best practices when using JavaScript.\n\n### TypeScript\n\nThe `@nrwl/nx/typescript` ESLint plugin contains best practices when using TypeSript.\n\n### Angular\n\nContains configurations matching best practices when using Angular framework:\n\n- @nrwl/nx/angular\n- @nrwl/nx/angular-template\n\n### React\n\nContains configurations matching best practices when using React framework:\n\n- @nrwl/nx/react-base\n- @nrwl/nx/react-jsx\n- @nrwl/nx/react-typescript\n\nYou can also use `@nrwl/nx/react` which includes all three `@nrwl/nx/react-*` plugins\n\n## enforce-module-boundaries\n\nThe `@nrwl/nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between different projects in the repository. By enforcing strict boundaries it helps keep prevent unplanned cross-dependencies.\n\n### Usage\n\nYou can use `enforce-module-boundaries` rule by adding it to your ESLint rules configuration:\n\n```json\n{\n  // ... more ESLint config here\n  \"overrides\": [\n    {\n      \"files\": [\"*.ts\", \"*.tsx\", \"*.js\", \"*.jsx\"],\n      \"rules\": {\n        \"@nrwl/nx/enforce-module-boundaries\": [\n          \"error\",\n          {\n            // ...rule specific configuration\n          }\n        ]\n      }\n    }\n    // ... more ESLint overrides here\n  ]\n}\n```\n\nRead more about proper usage of this rule:\n\n- [Imposing Constraints on the Project Graph](/structure/monorepo-tags)\n- [Taming Code Organization with Module Boundaries in Nx](https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4)\n"
+      "content": "![ESLint logo](/shared/eslint-logo.png)\n\nA plugin containing a collection of recommended ESLint rule configurations wrapped as ESLint plugins and an Nx specific [enforce-module-boundaries](#enforce-module-boundaries) rule.\n\n## Setting Up ESLint Plugin\n\n### Installation\n\nIn any Nx workspace, you can install `@nrwl/eslint-plugin-nx` by running the following commands if the package is not already installed:\n\n```bash\nnpm i --save-dev @nrwl/eslint-plugin-nx\n```\n\n```bash\nyarn add --dev @nrwl/eslint-plugin-nx\n```\n\n## ESLint plugins\n\nThe plugin contains the following rule configurations divided into sub-plugins.\n\n### JavaScript\n\nThe `@nrwl/nx/javascript` ESLint plugin contains best practices when using JavaScript.\n\n### TypeScript\n\nThe `@nrwl/nx/typescript` ESLint plugin contains best practices when using TypeSript.\n\n### Angular\n\nContains configurations matching best practices when using Angular framework:\n\n- @nrwl/nx/angular\n- @nrwl/nx/angular-template\n\n### React\n\nContains configurations matching best practices when using React framework:\n\n- @nrwl/nx/react-base\n- @nrwl/nx/react-jsx\n- @nrwl/nx/react-typescript\n\nYou can also use `@nrwl/nx/react` which includes all three `@nrwl/nx/react-*` plugins\n\n## enforce-module-boundaries\n\nThe `@nrwl/nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between different projects in the repository. By enforcing strict boundaries it helps keep prevent unplanned cross-dependencies.\n\n### Usage\n\nYou can use `enforce-module-boundaries` rule by adding it to your ESLint rules configuration:\n\n```json\n{\n  // ... more ESLint config here\n  \"overrides\": [\n    {\n      \"files\": [\"*.ts\", \"*.tsx\", \"*.js\", \"*.jsx\"],\n      \"rules\": {\n        \"@nrwl/nx/enforce-module-boundaries\": [\n          \"error\",\n          {\n            // ...rule specific configuration\n          }\n        ]\n      }\n    }\n    // ... more ESLint overrides here\n  ]\n}\n```\n\nRead more about proper usage of this rule:\n\n- [Enforce Project Boundaries](/core-features/enforce-project-boundaries)\n- [Ban Dependencies with Certain Tags](/recipe/ban-dependencies-with-tags)\n- [Tag in Multiple Dimensions](/recipe/tag-multiple-dimensions)\n- [Ban External Imports](/recipe/ban-external-imports)\n- [Tags Allow List](/recipe/tags-allow-list)\n- [Taming Code Organization with Module Boundaries in Nx](https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4)\n"
     }
   ],
   "generators": [],

docs/generated/packages/express.json

@@ -11,7 +11,7 @@
       "name": "Overview",
       "path": "/packages/express",
       "file": "shared/express-plugin",
-      "content": "![Express Logo](/shared/express-logo.png)\n\n[Express](https://expressjs.com/) is mature, minimal, and an open source web framework for making web applications and\napis.\n\n## Setting Up Express\n\nTo create a new workspace with Express, run the following command:\n\n```shell\n npx create-nx-workspace --preset=express\n```\n\n### Adding Express to an Existing Project\n\nInstall the express plugin\n\n```shell\nnpm install --save-dev @nrwl/express\n```\n\n```shell\nyarn add --dev @nrwl/express\n```\n\n## Creating Applications\n\nAdd a new application to your workspace with the following command:\n\n```shell\nnx g @nrwl/express:app my-app\n```\n\nServe the application by running\n\n```shell\nnx serve my-app\n```\n\nThis starts the application on localhost:3333/api by default.\n\n> Express does not come with any library generators, but you can leverage the[`@nrwl/js`](/packages/js#create-libraries) plugin to generate a Node.js library for your express application.\n\n### Application Proxies\n\nThe Express application generator has an option to configure other projects in the workspace to proxy API requests. This\ncan be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.\n\n```shell\nnx g @nrwl/express:app <express-app> --frontendProject my-react-app\n```\n\n## Using Express\n\n### Testing Projects\n\nYou can run unit tests with:\n\n```shell\nnx test <project-name>\n```\n\n### Building Projects\n\nExpress projects can be built with:\n\n```shell\nnx build <project-name>\n```\n\nBuild artifacts will be found in the `dist` directory under `apps/<project-name>` by default. Customize the build\nconfiguration by editing `outputPath` in the [project configuration](/configuration/projectjson).\n\n### Waiting for Other Tasks\n\nYou can wait for other tasks to run before serving the express app which can be handy for spinning up various services\nthe application depends on— for example, other apis in a microservice.\n\nSetting the `waitUntilTargets` option with an array of targets (format: `\"project:target\"`) executes those tasks\nbefore serving the Express application.\n\n## More Documentation\n\n- [Using Jest](/packages/jest)\n- [@nrwl/js](/packages/js)\n- [Express](https://expressjs.com/)\n"
+      "content": "![Express Logo](/shared/express-logo.png)\n\n[Express](https://expressjs.com/) is mature, minimal, and an open source web framework for making web applications and\napis.\n\n## Setting Up Express\n\nTo create a new workspace with Express, run the following command:\n\n```shell\n npx create-nx-workspace --preset=express\n```\n\n### Adding Express to an Existing Project\n\nInstall the express plugin\n\n```shell\nnpm install --save-dev @nrwl/express\n```\n\n```shell\nyarn add --dev @nrwl/express\n```\n\n## Creating Applications\n\nAdd a new application to your workspace with the following command:\n\n```shell\nnx g @nrwl/express:app my-app\n```\n\nServe the application by running\n\n```shell\nnx serve my-app\n```\n\nThis starts the application on localhost:3333/api by default.\n\n> Express does not come with any library generators, but you can leverage the[`@nrwl/js`](/packages/js#create-libraries) plugin to generate a Node.js library for your express application.\n\n### Application Proxies\n\nThe Express application generator has an option to configure other projects in the workspace to proxy API requests. This\ncan be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.\n\n```shell\nnx g @nrwl/express:app <express-app> --frontendProject my-react-app\n```\n\n## Using Express\n\n### Testing Projects\n\nYou can run unit tests with:\n\n```shell\nnx test <project-name>\n```\n\n### Building Projects\n\nExpress projects can be built with:\n\n```shell\nnx build <project-name>\n```\n\nBuild artifacts will be found in the `dist` directory under `apps/<project-name>` by default. Customize the build\nconfiguration by editing `outputPath` in the [project configuration](/reference/project-configuration).\n\n### Waiting for Other Tasks\n\nYou can wait for other tasks to run before serving the express app which can be handy for spinning up various services\nthe application depends on— for example, other apis in a microservice.\n\nSetting the `waitUntilTargets` option with an array of targets (format: `\"project:target\"`) executes those tasks\nbefore serving the Express application.\n\n## More Documentation\n\n- [Using Jest](/packages/jest)\n- [@nrwl/js](/packages/js)\n- [Express](https://expressjs.com/)\n"
     }
   ],
   "generators": [

docs/generated/packages/linter.json

@@ -17,7 +17,7 @@
       "id": "eslint-plugin-nx",
       "name": "eslint-plugin-nx",
       "file": "shared/eslint-plugin-nx",
-      "content": "![ESLint logo](/shared/eslint-logo.png)\n\nA plugin containing a collection of recommended ESLint rule configurations wrapped as ESLint plugins and an Nx specific [enforce-module-boundaries](#enforce-module-boundaries) rule.\n\n## Setting Up ESLint Plugin\n\n### Installation\n\nIn any Nx workspace, you can install `@nrwl/eslint-plugin-nx` by running the following commands if the package is not already installed:\n\n```bash\nnpm i --save-dev @nrwl/eslint-plugin-nx\n```\n\n```bash\nyarn add --dev @nrwl/eslint-plugin-nx\n```\n\n## ESLint plugins\n\nThe plugin contains the following rule configurations divided into sub-plugins.\n\n### JavaScript\n\nThe `@nrwl/nx/javascript` ESLint plugin contains best practices when using JavaScript.\n\n### TypeScript\n\nThe `@nrwl/nx/typescript` ESLint plugin contains best practices when using TypeSript.\n\n### Angular\n\nContains configurations matching best practices when using Angular framework:\n\n- @nrwl/nx/angular\n- @nrwl/nx/angular-template\n\n### React\n\nContains configurations matching best practices when using React framework:\n\n- @nrwl/nx/react-base\n- @nrwl/nx/react-jsx\n- @nrwl/nx/react-typescript\n\nYou can also use `@nrwl/nx/react` which includes all three `@nrwl/nx/react-*` plugins\n\n## enforce-module-boundaries\n\nThe `@nrwl/nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between different projects in the repository. By enforcing strict boundaries it helps keep prevent unplanned cross-dependencies.\n\n### Usage\n\nYou can use `enforce-module-boundaries` rule by adding it to your ESLint rules configuration:\n\n```json\n{\n  // ... more ESLint config here\n  \"overrides\": [\n    {\n      \"files\": [\"*.ts\", \"*.tsx\", \"*.js\", \"*.jsx\"],\n      \"rules\": {\n        \"@nrwl/nx/enforce-module-boundaries\": [\n          \"error\",\n          {\n            // ...rule specific configuration\n          }\n        ]\n      }\n    }\n    // ... more ESLint overrides here\n  ]\n}\n```\n\nRead more about proper usage of this rule:\n\n- [Imposing Constraints on the Project Graph](/structure/monorepo-tags)\n- [Taming Code Organization with Module Boundaries in Nx](https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4)\n"
+      "content": "![ESLint logo](/shared/eslint-logo.png)\n\nA plugin containing a collection of recommended ESLint rule configurations wrapped as ESLint plugins and an Nx specific [enforce-module-boundaries](#enforce-module-boundaries) rule.\n\n## Setting Up ESLint Plugin\n\n### Installation\n\nIn any Nx workspace, you can install `@nrwl/eslint-plugin-nx` by running the following commands if the package is not already installed:\n\n```bash\nnpm i --save-dev @nrwl/eslint-plugin-nx\n```\n\n```bash\nyarn add --dev @nrwl/eslint-plugin-nx\n```\n\n## ESLint plugins\n\nThe plugin contains the following rule configurations divided into sub-plugins.\n\n### JavaScript\n\nThe `@nrwl/nx/javascript` ESLint plugin contains best practices when using JavaScript.\n\n### TypeScript\n\nThe `@nrwl/nx/typescript` ESLint plugin contains best practices when using TypeSript.\n\n### Angular\n\nContains configurations matching best practices when using Angular framework:\n\n- @nrwl/nx/angular\n- @nrwl/nx/angular-template\n\n### React\n\nContains configurations matching best practices when using React framework:\n\n- @nrwl/nx/react-base\n- @nrwl/nx/react-jsx\n- @nrwl/nx/react-typescript\n\nYou can also use `@nrwl/nx/react` which includes all three `@nrwl/nx/react-*` plugins\n\n## enforce-module-boundaries\n\nThe `@nrwl/nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between different projects in the repository. By enforcing strict boundaries it helps keep prevent unplanned cross-dependencies.\n\n### Usage\n\nYou can use `enforce-module-boundaries` rule by adding it to your ESLint rules configuration:\n\n```json\n{\n  // ... more ESLint config here\n  \"overrides\": [\n    {\n      \"files\": [\"*.ts\", \"*.tsx\", \"*.js\", \"*.jsx\"],\n      \"rules\": {\n        \"@nrwl/nx/enforce-module-boundaries\": [\n          \"error\",\n          {\n            // ...rule specific configuration\n          }\n        ]\n      }\n    }\n    // ... more ESLint overrides here\n  ]\n}\n```\n\nRead more about proper usage of this rule:\n\n- [Enforce Project Boundaries](/core-features/enforce-project-boundaries)\n- [Ban Dependencies with Certain Tags](/recipe/ban-dependencies-with-tags)\n- [Tag in Multiple Dimensions](/recipe/tag-multiple-dimensions)\n- [Ban External Imports](/recipe/ban-external-imports)\n- [Tags Allow List](/recipe/tags-allow-list)\n- [Taming Code Organization with Module Boundaries in Nx](https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4)\n"
     }
   ],
   "generators": [

docs/generated/packages/nest.json

@@ -11,7 +11,7 @@
       "name": "Overview",
       "path": "/packages/nest",
       "file": "shared/nest-plugin",
-      "content": "![NestJS logo](/shared/nest-logo.png)\n\nNest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers:\n\n- It has excellent TypeScript support.\n- Its dependency injection system is similar to the one in Angular.\n- It emphasises testability.\n- Its configuration APIs are similar to Angular as well.\n\nMany conventions and best practices used in Angular applications can be also be used in Nest.\n\n## Setting Up Nest\n\nTo create a new workspace with Nest, run the following command:\n\n```shell\nnpx create-nx-workspace my-workspace --preset=nest\n```\n\nYarn users can use the following command instead:\n\n```shell\nyarn create nx-workspace my-workspace --preset=nest\n```\n\nTo add the Nest plugin to an existing workspace, run one the following commands:\n\n```shell\nnpm install -D @nrwl/nest\n```\n\n```shell\nyarn add -D @nrwl/nest\n```\n\n### Create Applications\n\nYou can add a new Nest application with the following command:\n\n```shell\nnx g @nrwl/nest:app my-nest-app\n```\n\n#### Application Proxies\n\nGenerating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.\n\n```shell\nnx g @nrwl/nest:app my-nest-app --frontendProject my-angular-app\n```\n\n### Create Libraries\n\nYou can add a new Nest library with the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib\n```\n\nTo make the library `buildable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --buildable\n```\n\nTo make the library `publishable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --publishable --importPath=@my-workspace/my-nest-lib\n```\n\n> Read more about [building and publishing libraries here](/structure/buildable-and-publishable-libraries).\n\n### Nest Generators\n\nThe Nest plugin for Nx extends the generators provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--project` flag should be used for all Nest generators.\n\n> `--project` is used to infer the root of the project where the generators will generate the files.\n\n## Using Nest\n\n### Build\n\nYou can build an application with the following command:\n\n```shell\nnx build my-nest-app\n```\n\nThis applies to `buildable` libraries as well\n\n```shell\nnx build my-nest-lib\n```\n\n#### Waiting for other builds\n\nSetting the `waitUntilTargets` option with an array of projects (with the following format: `\"project:architect\"`) will execute those commands before serving the Nest application.\n\n### Serve\n\nYou can serve an application with the following command:\n\n```shell\nnx serve my-nest-app\n```\n\nThe `serve` command runs the `build` target, and executes the application.\n\nBy default, the serve command will run in `watch` mode. This allows code to be changed, and the Nest application to be rebuilt automatically.\n\n#### Debugging\n\nNest applications also have the `inspect` flag set, so you can attach your debugger to the running instance.\n\nDebugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port <number>`.\n\nFor additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients).\n\n### Lint\n\nYou can lint an application with the following command:\n\n```shell\nnx lint my-nest-app\n```\n\nYou can lint a library with the following command:\n\n```shell\nnx lint my-nest-lib\n```\n\n### Unit Test\n\nYou can run unit test for an application with the following command:\n\n```shell\nnx test my-nest-app\n```\n\nYou can run unit test for a library with the following command:\n\n```shell\nnx test my-nest-lib\n```\n\n## More Documentation\n\n- [Todo Tutorial](/node-tutorial/01-create-application)\n- [Using Jest](/packages/jest)\n"
+      "content": "![NestJS logo](/shared/nest-logo.png)\n\nNest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers:\n\n- It has excellent TypeScript support.\n- Its dependency injection system is similar to the one in Angular.\n- It emphasises testability.\n- Its configuration APIs are similar to Angular as well.\n\nMany conventions and best practices used in Angular applications can be also be used in Nest.\n\n## Setting Up Nest\n\nTo create a new workspace with Nest, run the following command:\n\n```shell\nnpx create-nx-workspace my-workspace --preset=nest\n```\n\nYarn users can use the following command instead:\n\n```shell\nyarn create nx-workspace my-workspace --preset=nest\n```\n\nTo add the Nest plugin to an existing workspace, run one the following commands:\n\n```shell\nnpm install -D @nrwl/nest\n```\n\n```shell\nyarn add -D @nrwl/nest\n```\n\n### Create Applications\n\nYou can add a new Nest application with the following command:\n\n```shell\nnx g @nrwl/nest:app my-nest-app\n```\n\n#### Application Proxies\n\nGenerating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.\n\n```shell\nnx g @nrwl/nest:app my-nest-app --frontendProject my-angular-app\n```\n\n### Create Libraries\n\nYou can add a new Nest library with the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib\n```\n\nTo make the library `buildable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --buildable\n```\n\nTo make the library `publishable`, use the following command:\n\n```shell\nnx g @nrwl/nest:lib my-nest-lib --publishable --importPath=@my-workspace/my-nest-lib\n```\n\n> Read more about [building and publishing libraries here](/more-concepts/buildable-and-publishable-libraries).\n\n### Nest Generators\n\nThe Nest plugin for Nx extends the generators provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--project` flag should be used for all Nest generators.\n\n> `--project` is used to infer the root of the project where the generators will generate the files.\n\n## Using Nest\n\n### Build\n\nYou can build an application with the following command:\n\n```shell\nnx build my-nest-app\n```\n\nThis applies to `buildable` libraries as well\n\n```shell\nnx build my-nest-lib\n```\n\n#### Waiting for other builds\n\nSetting the `waitUntilTargets` option with an array of projects (with the following format: `\"project:architect\"`) will execute those commands before serving the Nest application.\n\n### Serve\n\nYou can serve an application with the following command:\n\n```shell\nnx serve my-nest-app\n```\n\nThe `serve` command runs the `build` target, and executes the application.\n\nBy default, the serve command will run in `watch` mode. This allows code to be changed, and the Nest application to be rebuilt automatically.\n\n#### Debugging\n\nNest applications also have the `inspect` flag set, so you can attach your debugger to the running instance.\n\nDebugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` architect in the workspace.json. Or by running the serve command with `--port <number>`.\n\nFor additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients).\n\n### Lint\n\nYou can lint an application with the following command:\n\n```shell\nnx lint my-nest-app\n```\n\nYou can lint a library with the following command:\n\n```shell\nnx lint my-nest-lib\n```\n\n### Unit Test\n\nYou can run unit test for an application with the following command:\n\n```shell\nnx test my-nest-app\n```\n\nYou can run unit test for a library with the following command:\n\n```shell\nnx test my-nest-lib\n```\n\n## More Documentation\n\n- [Todo Tutorial](/node-tutorial/01-create-application)\n- [Using Jest](/packages/jest)\n"
     }
   ],
   "generators": [

docs/generated/packages/nx.json

@@ -16,127 +16,127 @@
       "name": "init",
       "id": "init",
       "file": "generated/cli/init",
-      "content": "---\ntitle: 'init - CLI command'\ndescription: 'Adds nx.json file and installs nx if not installed already'\n---\n\n# init\n\nAdds nx.json file and installs nx if not installed already\n\n## Usage\n\n```bash\nnx init\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
+      "content": "---\ntitle: 'init - CLI command'\ndescription: 'Adds nx.json file and installs nx if not installed already'\n---\n\n# init\n\nAdds nx.json file and installs nx if not installed already\n\n## Usage\n\n```bash\nnx init\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
     },
     {
       "name": "generate",
       "id": "generate",
       "file": "generated/cli/generate",
-      "content": "---\ntitle: 'generate - CLI command'\ndescription: 'Runs a generator that creates and/or modifies files based on a generator from a collection.'\n---\n\n# generate\n\nRuns a generator that creates and/or modifies files based on a generator from a collection.\n\n## Usage\n\n```bash\nnx generate <collection:generator>\n```\n\n```bash\nnx g <generator>\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nGenerate a new Angular application:\n\n```bash\nnx generate @nrwl/angular:app myapp\n```\n\nGenerate a new React application:\n\n```bash\nnx generate @nrwl/react:app myapp\n```\n\nGenerate a new web component application:\n\n```bash\nnx generate @nrwl/web:app myapp\n```\n\nGenerate a new Node application:\n\n```bash\nnx generate @nrwl/node:app myapp\n```\n\nGenerate a new Angular library application:\n\n```bash\nnx generate @nrwl/angular:library mylibrary\n```\n\nGenerate a new React library application:\n\n```bash\nnx generate @nrwl/react:library mylibrary\n```\n\nGenerate a new Node library application:\n\n```bash\nnx generate @nrwl/node:library mylibrary\n```\n\n## Options\n\n### defaults\n\nDefault: `false`\n\nWhen true, disables interactive input prompts for options with a default.\n\n### dryRun\n\nDefault: `false`\n\nWhen true, disables interactive input prompts for options with a default.\n\n### force\n\nDefault: `false`\n\nWhen true, forces overwriting of existing files.\n\n### interactive\n\nDefault: `true`\n\nWhen false, disables interactive input prompts.\n\n### help\n\nShow help and display available generators in the default collection.\n\n### version\n\nShow version number\n"
+      "content": "---\ntitle: 'generate - CLI command'\ndescription: 'Runs a generator that creates and/or modifies files based on a generator from a collection.'\n---\n\n# generate\n\nRuns a generator that creates and/or modifies files based on a generator from a collection.\n\n## Usage\n\n```bash\nnx generate <collection:generator>\n```\n\n```bash\nnx g <generator>\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nGenerate a new Angular application:\n\n```bash\nnx generate @nrwl/angular:app myapp\n```\n\nGenerate a new React application:\n\n```bash\nnx generate @nrwl/react:app myapp\n```\n\nGenerate a new web component application:\n\n```bash\nnx generate @nrwl/web:app myapp\n```\n\nGenerate a new Node application:\n\n```bash\nnx generate @nrwl/node:app myapp\n```\n\nGenerate a new Angular library application:\n\n```bash\nnx generate @nrwl/angular:library mylibrary\n```\n\nGenerate a new React library application:\n\n```bash\nnx generate @nrwl/react:library mylibrary\n```\n\nGenerate a new Node library application:\n\n```bash\nnx generate @nrwl/node:library mylibrary\n```\n\n## Options\n\n### defaults\n\nDefault: `false`\n\nWhen true, disables interactive input prompts for options with a default.\n\n### dryRun\n\nDefault: `false`\n\nWhen true, disables interactive input prompts for options with a default.\n\n### force\n\nDefault: `false`\n\nWhen true, forces overwriting of existing files.\n\n### interactive\n\nDefault: `true`\n\nWhen false, disables interactive input prompts.\n\n### help\n\nShow help and display available generators in the default collection.\n\n### version\n\nShow version number\n"
     },
     {
       "name": "run",
       "id": "run",
       "file": "generated/cli/run",
-      "content": "---\ntitle: 'run - CLI command'\ndescription: 'Runs an Architect target with an optional custom builder configuration defined in your project.'\n---\n\n# run\n\nRuns an Architect target with an optional custom builder configuration defined in your project.\n\n## Usage\n\n```bash\nnx run <target> [options]\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nRun the `build` target for the `myapp` :\n\n```bash\nnx run myapp:build\n```\n\nRun the `build` target for the `myapp` project with a `production` configuration:\n\n```bash\nnx run myapp:build:production\n```\n\n## Options\n\n### configuration (-c)\n\nA named builder configuration, defined in the \"configurations\" section of the workspace configuration file. The builder uses the named configuration to run the given target.\n\n### help\n\nShow help\n\n### version\n\nShow version number\n"
+      "content": "---\ntitle: 'run - CLI command'\ndescription: 'Runs an Architect target with an optional custom builder configuration defined in your project.'\n---\n\n# run\n\nRuns an Architect target with an optional custom builder configuration defined in your project.\n\n## Usage\n\n```bash\nnx run <target> [options]\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nRun the `build` target for the `myapp` :\n\n```bash\nnx run myapp:build\n```\n\nRun the `build` target for the `myapp` project with a `production` configuration:\n\n```bash\nnx run myapp:build:production\n```\n\n## Options\n\n### configuration (-c)\n\nA named builder configuration, defined in the \"configurations\" section of the workspace configuration file. The builder uses the named configuration to run the given target.\n\n### help\n\nShow help\n\n### version\n\nShow version number\n"
     },
     {
       "name": "daemon",
       "id": "daemon",
       "file": "generated/cli/daemon",
-      "content": "---\ntitle: 'daemon - CLI command'\ndescription: 'Prints information about the Nx Daemon process or starts a daemon process'\n---\n\n# daemon\n\nPrints information about the Nx Daemon process or starts a daemon process\n\n## Usage\n\n```bash\nnx daemon\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### background\n\nType: boolean\n\nDefault: true\n\n### help\n\nType: boolean\n\nShow help\n\n### start\n\nType: boolean\n\nDefault: false\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'daemon - CLI command'\ndescription: 'Prints information about the Nx Daemon process or starts a daemon process'\n---\n\n# daemon\n\nPrints information about the Nx Daemon process or starts a daemon process\n\n## Usage\n\n```bash\nnx daemon\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### background\n\nType: boolean\n\nDefault: true\n\n### help\n\nType: boolean\n\nShow help\n\n### start\n\nType: boolean\n\nDefault: false\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "graph",
       "id": "dep-graph",
       "file": "generated/cli/graph",
-      "content": "---\ntitle: 'graph - CLI command'\ndescription: 'Graph dependencies within workspace'\n---\n\n# graph\n\nGraph dependencies within workspace\n\n## Usage\n\n```bash\nnx graph\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nOpen the project graph of the workspace in the browser:\n\n```bash\nnx graph\n```\n\nSave the project graph into a json file:\n\n```bash\nnx graph --file=output.json\n```\n\nGenerate a static website with project graph into an html file, accompanied by an asset folder called static:\n\n```bash\nnx graph --file=output.html\n```\n\nShow the graph where every node is either an ancestor or a descendant of todos-feature-main:\n\n```bash\nnx graph --focus=todos-feature-main\n```\n\nInclude project-one and project-two in the project graph:\n\n```bash\nnx graph --include=project-one,project-two\n```\n\nExclude project-one and project-two from the project graph:\n\n```bash\nnx graph --exclude=project-one,project-two\n```\n\nShow the graph where every node is either an ancestor or a descendant of todos-feature-main, but exclude project-one and project-two:\n\n```bash\nnx graph --focus=todos-feature-main --exclude=project-one,project-two\n```\n\nWatch for changes to project graph and update in-browser:\n\n```bash\nnx graph --watch\n```\n\n## Options\n\n### exclude\n\nType: array\n\nList of projects delimited by commas to exclude from the project graph.\n\n### file\n\nType: string\n\nOutput file (e.g. --file=output.json or --file=dep-graph.html)\n\n### focus\n\nType: string\n\nUse to show the project graph for a particular project and every node that is either an ancestor or a descendant.\n\n### groupByFolder\n\nType: boolean\n\nGroup projects by folder in the project graph\n\n### help\n\nType: boolean\n\nShow help\n\n### host\n\nType: string\n\nBind the project graph server to a specific ip address.\n\n### open\n\nType: boolean\n\nDefault: true\n\nOpen the project graph in the browser.\n\n### port\n\nType: number\n\nBind the project graph server to a specific port.\n\n### version\n\nType: boolean\n\nShow version number\n\n### watch\n\nType: boolean\n\nDefault: false\n\nWatch for changes to project graph and update in-browser\n"
+      "content": "---\ntitle: 'graph - CLI command'\ndescription: 'Graph dependencies within workspace'\n---\n\n# graph\n\nGraph dependencies within workspace\n\n## Usage\n\n```bash\nnx graph\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nOpen the project graph of the workspace in the browser:\n\n```bash\nnx graph\n```\n\nSave the project graph into a json file:\n\n```bash\nnx graph --file=output.json\n```\n\nGenerate a static website with project graph into an html file, accompanied by an asset folder called static:\n\n```bash\nnx graph --file=output.html\n```\n\nShow the graph where every node is either an ancestor or a descendant of todos-feature-main:\n\n```bash\nnx graph --focus=todos-feature-main\n```\n\nInclude project-one and project-two in the project graph:\n\n```bash\nnx graph --include=project-one,project-two\n```\n\nExclude project-one and project-two from the project graph:\n\n```bash\nnx graph --exclude=project-one,project-two\n```\n\nShow the graph where every node is either an ancestor or a descendant of todos-feature-main, but exclude project-one and project-two:\n\n```bash\nnx graph --focus=todos-feature-main --exclude=project-one,project-two\n```\n\nWatch for changes to project graph and update in-browser:\n\n```bash\nnx graph --watch\n```\n\n## Options\n\n### exclude\n\nType: array\n\nList of projects delimited by commas to exclude from the project graph.\n\n### file\n\nType: string\n\nOutput file (e.g. --file=output.json or --file=dep-graph.html)\n\n### focus\n\nType: string\n\nUse to show the project graph for a particular project and every node that is either an ancestor or a descendant.\n\n### groupByFolder\n\nType: boolean\n\nGroup projects by folder in the project graph\n\n### help\n\nType: boolean\n\nShow help\n\n### host\n\nType: string\n\nBind the project graph server to a specific ip address.\n\n### open\n\nType: boolean\n\nDefault: true\n\nOpen the project graph in the browser.\n\n### port\n\nType: number\n\nBind the project graph server to a specific port.\n\n### version\n\nType: boolean\n\nShow version number\n\n### watch\n\nType: boolean\n\nDefault: false\n\nWatch for changes to project graph and update in-browser\n"
     },
     {
       "name": "run-many",
       "id": "run-many",
       "file": "generated/cli/run-many",
-      "content": "---\ntitle: 'run-many - CLI command'\ndescription: 'Run target for multiple listed projects'\n---\n\n# run-many\n\nRun target for multiple listed projects\n\n## Usage\n\n```bash\nnx run-many\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nTest all projects:\n\n```bash\nnx run-many --target=test\n```\n\nTest proj1 and proj2:\n\n```bash\nnx run-many --target=test --projects=proj1,proj2\n```\n\nTest proj1 and proj2 in parallel:\n\n```bash\nnx run-many --target=test --projects=proj1,proj2 --parallel=2\n```\n\n## Options\n\n### all\n\nType: boolean\n\nDefault: true\n\n[deprecated] Run the target on all projects in the workspace\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nOnly run the target on projects which previously failed\n\n### output-style\n\nType: string\n\nChoices: [dynamic, static, stream, stream-without-prefixes]\n\nDefines how Nx emits outputs tasks logs\n\n### parallel\n\nType: string\n\nMax number of parallel processes [default is 3]\n\n### projects\n\nType: string\n\nProjects to run (comma delimited)\n\n### runner\n\nType: string\n\nOverride the tasks runner in `nx.json`\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### target\n\nType: string\n\nTask to run for affected projects\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'run-many - CLI command'\ndescription: 'Run target for multiple listed projects'\n---\n\n# run-many\n\nRun target for multiple listed projects\n\n## Usage\n\n```bash\nnx run-many\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nTest all projects:\n\n```bash\nnx run-many --target=test\n```\n\nTest proj1 and proj2:\n\n```bash\nnx run-many --target=test --projects=proj1,proj2\n```\n\nTest proj1 and proj2 in parallel:\n\n```bash\nnx run-many --target=test --projects=proj1,proj2 --parallel=2\n```\n\n## Options\n\n### all\n\nType: boolean\n\nDefault: true\n\n[deprecated] Run the target on all projects in the workspace\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nOnly run the target on projects which previously failed\n\n### output-style\n\nType: string\n\nChoices: [dynamic, static, stream, stream-without-prefixes]\n\nDefines how Nx emits outputs tasks logs\n\n### parallel\n\nType: string\n\nMax number of parallel processes [default is 3]\n\n### projects\n\nType: string\n\nProjects to run (comma delimited)\n\n### runner\n\nType: string\n\nOverride the tasks runner in `nx.json`\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### target\n\nType: string\n\nTask to run for affected projects\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "affected",
       "id": "affected",
       "file": "generated/cli/affected",
-      "content": "---\ntitle: 'affected - CLI command'\ndescription: 'Run target for affected projects'\n---\n\n# affected\n\nRun target for affected projects\n\n## Usage\n\n```bash\nnx affected\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nRun custom target for all affected projects:\n\n```bash\nnx affected --target=custom-target\n```\n\nRun tests in parallel:\n\n```bash\nnx affected --target=test --parallel=5\n```\n\nRun the test target for all projects:\n\n```bash\nnx affected --target=test --all\n```\n\nRun tests for all the projects affected by changing the index.ts file:\n\n```bash\nnx affected --target=test --files=libs/mylib/src/index.ts\n```\n\nRun tests for all the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected --target=test --base=main --head=HEAD\n```\n\nRun tests for all the projects affected by the last commit on main:\n\n```bash\nnx affected --target=test --base=main~1 --head=main\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### output-style\n\nType: string\n\nChoices: [dynamic, static, stream, stream-without-prefixes]\n\nDefines how Nx emits outputs tasks logs\n\n### parallel\n\nType: string\n\nMax number of parallel processes [default is 3]\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### target\n\nType: string\n\nTask to run for affected projects\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'affected - CLI command'\ndescription: 'Run target for affected projects'\n---\n\n# affected\n\nRun target for affected projects\n\n## Usage\n\n```bash\nnx affected\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nRun custom target for all affected projects:\n\n```bash\nnx affected --target=custom-target\n```\n\nRun tests in parallel:\n\n```bash\nnx affected --target=test --parallel=5\n```\n\nRun the test target for all projects:\n\n```bash\nnx affected --target=test --all\n```\n\nRun tests for all the projects affected by changing the index.ts file:\n\n```bash\nnx affected --target=test --files=libs/mylib/src/index.ts\n```\n\nRun tests for all the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected --target=test --base=main --head=HEAD\n```\n\nRun tests for all the projects affected by the last commit on main:\n\n```bash\nnx affected --target=test --base=main~1 --head=main\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### output-style\n\nType: string\n\nChoices: [dynamic, static, stream, stream-without-prefixes]\n\nDefines how Nx emits outputs tasks logs\n\n### parallel\n\nType: string\n\nMax number of parallel processes [default is 3]\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### target\n\nType: string\n\nTask to run for affected projects\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "affected:graph",
       "id": "affected-dep-graph",
       "file": "generated/cli/affected-graph",
-      "content": "---\ntitle: 'affected:graph - CLI command'\ndescription: 'Graph dependencies affected by changes'\n---\n\n# affected:graph\n\nGraph dependencies affected by changes\n\n## Usage\n\n```bash\nnx affected:graph\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nOpen the project graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file:\n\n```bash\nnx affected:graph --files=libs/mylib/src/index.ts\n```\n\nOpen the project graph of the workspace in the browser, and highlight the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:graph --base=main --head=HEAD\n```\n\nSave the project graph of the workspace in a json file, and highlight the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:graph --base=main --head=HEAD --file=output.json\n```\n\nGenerate a static website with project graph data in an html file, highlighting the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:graph --base=main --head=HEAD --file=output.html\n```\n\nOpen the project graph of the workspace in the browser, and highlight the projects affected by the last commit on main:\n\n```bash\nnx affected:graph --base=main~1 --head=main\n```\n\nOpen the project graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two:\n\n```bash\nnx affected:graph --exclude=project-one,project-two\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### file\n\nType: string\n\nOutput file (e.g. --file=output.json or --file=dep-graph.html)\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### focus\n\nType: string\n\nUse to show the project graph for a particular project and every node that is either an ancestor or a descendant.\n\n### groupByFolder\n\nType: boolean\n\nGroup projects by folder in the project graph\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### host\n\nType: string\n\nBind the project graph server to a specific ip address.\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### open\n\nType: boolean\n\nDefault: true\n\nOpen the project graph in the browser.\n\n### port\n\nType: number\n\nBind the project graph server to a specific port.\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n\n### watch\n\nType: boolean\n\nDefault: false\n\nWatch for changes to project graph and update in-browser\n"
+      "content": "---\ntitle: 'affected:graph - CLI command'\ndescription: 'Graph dependencies affected by changes'\n---\n\n# affected:graph\n\nGraph dependencies affected by changes\n\n## Usage\n\n```bash\nnx affected:graph\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nOpen the project graph of the workspace in the browser, and highlight the projects affected by changing the index.ts file:\n\n```bash\nnx affected:graph --files=libs/mylib/src/index.ts\n```\n\nOpen the project graph of the workspace in the browser, and highlight the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:graph --base=main --head=HEAD\n```\n\nSave the project graph of the workspace in a json file, and highlight the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:graph --base=main --head=HEAD --file=output.json\n```\n\nGenerate a static website with project graph data in an html file, highlighting the projects affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:graph --base=main --head=HEAD --file=output.html\n```\n\nOpen the project graph of the workspace in the browser, and highlight the projects affected by the last commit on main:\n\n```bash\nnx affected:graph --base=main~1 --head=main\n```\n\nOpen the project graph of the workspace in the browser, highlight the projects affected, but exclude project-one and project-two:\n\n```bash\nnx affected:graph --exclude=project-one,project-two\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### file\n\nType: string\n\nOutput file (e.g. --file=output.json or --file=dep-graph.html)\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### focus\n\nType: string\n\nUse to show the project graph for a particular project and every node that is either an ancestor or a descendant.\n\n### groupByFolder\n\nType: boolean\n\nGroup projects by folder in the project graph\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### host\n\nType: string\n\nBind the project graph server to a specific ip address.\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### open\n\nType: boolean\n\nDefault: true\n\nOpen the project graph in the browser.\n\n### port\n\nType: number\n\nBind the project graph server to a specific port.\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n\n### watch\n\nType: boolean\n\nDefault: false\n\nWatch for changes to project graph and update in-browser\n"
     },
     {
       "name": "affected:apps",
       "id": "affected-apps",
       "file": "generated/cli/affected-apps",
-      "content": "---\ntitle: 'affected:apps - CLI command'\ndescription: 'Print applications affected by changes'\n---\n\n# affected:apps\n\n**Deprecated:** Use `nx print-affected --type=app ...` instead. This command will be removed in v15.\n\nPrint applications affected by changes\n\n## Usage\n\n```bash\nnx affected:apps\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nPrint the names of all the apps affected by changing the index.ts file:\n\n```bash\nnx affected:apps --files=libs/mylib/src/index.ts\n```\n\nPrint the names of all the apps affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:apps --base=main --head=HEAD\n```\n\nPrint the names of all the apps affected by the last commit on main:\n\n```bash\nnx affected:apps --base=main~1 --head=main\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### plain\n\nProduces a plain output for affected:apps and affected:libs\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'affected:apps - CLI command'\ndescription: 'Print applications affected by changes'\n---\n\n# affected:apps\n\n**Deprecated:** Use `nx print-affected --type=app ...` instead. This command will be removed in v15.\n\nPrint applications affected by changes\n\n## Usage\n\n```bash\nnx affected:apps\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nPrint the names of all the apps affected by changing the index.ts file:\n\n```bash\nnx affected:apps --files=libs/mylib/src/index.ts\n```\n\nPrint the names of all the apps affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:apps --base=main --head=HEAD\n```\n\nPrint the names of all the apps affected by the last commit on main:\n\n```bash\nnx affected:apps --base=main~1 --head=main\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### plain\n\nProduces a plain output for affected:apps and affected:libs\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "affected:libs",
       "id": "affected-libs",
       "file": "generated/cli/affected-libs",
-      "content": "---\ntitle: 'affected:libs - CLI command'\ndescription: 'Print libraries affected by changes'\n---\n\n# affected:libs\n\n**Deprecated:** Use `nx print-affected --type=lib ...` instead. This command will be removed in v15.\n\nPrint libraries affected by changes\n\n## Usage\n\n```bash\nnx affected:libs\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nPrint the names of all the libs affected by changing the index.ts file:\n\n```bash\nnx affected:libs --files=libs/mylib/src/index.ts\n```\n\nPrint the names of all the libs affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:libs --base=main --head=HEAD\n```\n\nPrint the names of all the libs affected by the last commit on main:\n\n```bash\nnx affected:libs --base=main~1 --head=main\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### plain\n\nProduces a plain output for affected:apps and affected:libs\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'affected:libs - CLI command'\ndescription: 'Print libraries affected by changes'\n---\n\n# affected:libs\n\n**Deprecated:** Use `nx print-affected --type=lib ...` instead. This command will be removed in v15.\n\nPrint libraries affected by changes\n\n## Usage\n\n```bash\nnx affected:libs\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nPrint the names of all the libs affected by changing the index.ts file:\n\n```bash\nnx affected:libs --files=libs/mylib/src/index.ts\n```\n\nPrint the names of all the libs affected by the changes between main and HEAD (e.g., PR):\n\n```bash\nnx affected:libs --base=main --head=HEAD\n```\n\nPrint the names of all the libs affected by the last commit on main:\n\n```bash\nnx affected:libs --base=main~1 --head=main\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### plain\n\nProduces a plain output for affected:apps and affected:libs\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "print-affected",
       "id": "print-affected",
       "file": "generated/cli/print-affected",
-      "content": "---\ntitle: 'print-affected - CLI command'\ndescription: 'Prints information about the projects and targets affected by changes'\n---\n\n# print-affected\n\nPrints information about the projects and targets affected by changes\n\n## Usage\n\n```bash\nnx print-affected\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nPrint information about affected projects and the project graph:\n\n```bash\nnx print-affected\n```\n\nPrint information about the projects affected by the changes between main and HEAD (e.g,. PR):\n\n```bash\nnx print-affected --base=main --head=HEAD\n```\n\nPrints information about the affected projects and a list of tasks to test them:\n\n```bash\nnx print-affected --target=test\n```\n\nPrints the projects property from the print-affected output:\n\n```bash\nnx print-affected --target=build --select=projects\n```\n\nPrints the tasks.target.project property from the print-affected output:\n\n```bash\nnx print-affected --target=build --select=tasks.target.project\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### select\n\nType: string\n\nSelect the subset of the returned json document (e.g., --selected=projects)\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### type\n\nType: string\n\nChoices: [app, lib]\n\nSelect the type of projects to be returned (e.g., --type=app)\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'print-affected - CLI command'\ndescription: 'Prints information about the projects and targets affected by changes'\n---\n\n# print-affected\n\nPrints information about the projects and targets affected by changes\n\n## Usage\n\n```bash\nnx print-affected\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nPrint information about affected projects and the project graph:\n\n```bash\nnx print-affected\n```\n\nPrint information about the projects affected by the changes between main and HEAD (e.g,. PR):\n\n```bash\nnx print-affected --base=main --head=HEAD\n```\n\nPrints information about the affected projects and a list of tasks to test them:\n\n```bash\nnx print-affected --target=test\n```\n\nPrints the projects property from the print-affected output:\n\n```bash\nnx print-affected --target=build --select=projects\n```\n\nPrints the tasks.target.project property from the print-affected output:\n\n```bash\nnx print-affected --target=build --select=tasks.target.project\n```\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### select\n\nType: string\n\nSelect the subset of the returned json document (e.g., --selected=projects)\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### type\n\nType: string\n\nChoices: [app, lib]\n\nSelect the type of projects to be returned (e.g., --type=app)\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "format:check",
       "id": "format-check",
       "file": "generated/cli/format-check",
-      "content": "---\ntitle: 'format:check - CLI command'\ndescription: 'Check for un-formatted files'\n---\n\n# format:check\n\nCheck for un-formatted files\n\n## Usage\n\n```bash\nnx format:check\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### libs-and-apps\n\nType: boolean\n\nFormat only libraries and applications files.\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### projects\n\nType: array\n\nProjects to format (comma delimited)\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'format:check - CLI command'\ndescription: 'Check for un-formatted files'\n---\n\n# format:check\n\nCheck for un-formatted files\n\n## Usage\n\n```bash\nnx format:check\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### libs-and-apps\n\nType: boolean\n\nFormat only libraries and applications files.\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### projects\n\nType: array\n\nProjects to format (comma delimited)\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "format:write",
       "id": "format-write",
       "file": "generated/cli/format-write",
-      "content": "---\ntitle: 'format:write - CLI command'\ndescription: 'Overwrite un-formatted files'\n---\n\n# format:write\n\nOverwrite un-formatted files\n\n## Usage\n\n```bash\nnx format:write\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### libs-and-apps\n\nType: boolean\n\nFormat only libraries and applications files.\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### projects\n\nType: array\n\nProjects to format (comma delimited)\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'format:write - CLI command'\ndescription: 'Overwrite un-formatted files'\n---\n\n# format:write\n\nOverwrite un-formatted files\n\n## Usage\n\n```bash\nnx format:write\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### all\n\nType: boolean\n\nAll projects\n\n### base\n\nType: string\n\nBase of the current branch (usually main)\n\n### configuration\n\nType: string\n\nThis is the configuration to use when performing tasks on projects\n\n### exclude\n\nType: array\n\nDefault: []\n\nExclude certain projects from being processed\n\n### files\n\nType: array\n\nChange the way Nx is calculating the affected command by providing directly changed files, list of files delimited by commas\n\n### head\n\nType: string\n\nLatest commit of the current branch (usually HEAD)\n\n### help\n\nType: boolean\n\nShow help\n\n### libs-and-apps\n\nType: boolean\n\nFormat only libraries and applications files.\n\n### nx-bail\n\nType: boolean\n\nDefault: false\n\nStop command execution after the first failed task\n\n### nx-ignore-cycles\n\nType: boolean\n\nDefault: false\n\nIgnore cycles in the task graph\n\n### ~~only-failed~~\n\nType: boolean\n\nDefault: false\n\n**Deprecated:** The command to rerun failed projects will appear if projects fail. This now does nothing and will be removed in v15.\n\nIsolate projects which previously failed\n\n### projects\n\nType: array\n\nProjects to format (comma delimited)\n\n### runner\n\nType: string\n\nThis is the name of the tasks runner configured in nx.json\n\n### skip-nx-cache\n\nType: boolean\n\nDefault: false\n\nRerun the tasks even when the results are available in the cache\n\n### uncommitted\n\nType: boolean\n\nUncommitted changes\n\n### untracked\n\nType: boolean\n\nUntracked changes\n\n### verbose\n\nType: boolean\n\nDefault: false\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "migrate",
       "id": "migrate",
       "file": "generated/cli/migrate",
-      "content": "---\ntitle: \"migrate - CLI command\"\ndescription: \"Creates a migrations file or runs migrations from the migrations file.\n- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest)\n- Run migrations (e.g., nx migrate --run-migrations=migrations.json)\"\n---\n\n# migrate\n\nCreates a migrations file or runs migrations from the migrations file.\n\n- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest)\n- Run migrations (e.g., nx migrate --run-migrations=migrations.json)\n\n## Usage\n\n```bash\nnx migrate [packageAndVersion]\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nUpdate @nrwl/workspace to \"next\". This will update other packages and will generate migrations.json:\n\n```bash\nnx migrate next\n```\n\nUpdate @nrwl/workspace to \"9.0.0\". This will update other packages and will generate migrations.json:\n\n```bash\nnx migrate 9.0.0\n```\n\nUpdate @nrwl/workspace and generate the list of migrations starting with version 8.0.0 of @nrwl/workspace and @nrwl/node, regardless of what installed locally:\n\n```bash\nnx migrate @nrwl/workspace@9.0.0 --from=\"@nrwl/workspace@8.0.0,@nrwl/node@8.0.0\"\n```\n\nUpdate @nrwl/workspace to \"9.0.0\". If it tries to update @nrwl/react or @nrwl/angular, use version \"9.0.1\":\n\n```bash\nnx migrate @nrwl/workspace@9.0.0 --to=\"@nrwl/react@9.0.1,@nrwl/angular@9.0.1\"\n```\n\nUpdate another-package to \"12.0.0\". This will update other packages and will generate migrations.json file:\n\n```bash\nnx migrate another-package@12.0.0\n```\n\nRun migrations from the provided migrations.json file. You can modify migrations.json and run this command many times:\n\n```bash\nnx migrate --run-migrations=migrations.json\n```\n\nCreate a dedicated commit for each successfully completed migration. You can customize the prefix used for each commit by additionally setting --commit-prefix=\"PREFIX_HERE \":\n\n```bash\nnx migrate --run-migrations --create-commits\n```\n\n## Options\n\n### commitPrefix\n\nType: string\n\nDefault: chore: [nx migration]\n\nCommit prefix to apply to the commit for each migration, when --create-commits is enabled\n\n### createCommits\n\nType: boolean\n\nDefault: false\n\nAutomatically create a git commit after each migration runs\n\n### from\n\nType: string\n\nUse the provided versions for packages instead of the ones installed in node_modules (e.g., --from=\"@nrwl/react:12.0.0,@nrwl/js:12.0.0\")\n\n### help\n\nType: boolean\n\nShow help\n\n### packageAndVersion\n\nType: string\n\nThe target package and version (e.g, @nrwl/workspace@13.0.0)\n\n### runMigrations\n\nType: string\n\nExecute migrations from a file (when the file isn't provided, execute migrations from migrations.json)\n\n### to\n\nType: string\n\nUse the provided versions for packages instead of the ones calculated by the migrator (e.g., --to=\"@nrwl/react:12.0.0,@nrwl/js:12.0.0\")\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: \"migrate - CLI command\"\ndescription: \"Creates a migrations file or runs migrations from the migrations file.\n- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest)\n- Run migrations (e.g., nx migrate --run-migrations=migrations.json)\"\n---\n\n# migrate\n\nCreates a migrations file or runs migrations from the migrations file.\n\n- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest)\n- Run migrations (e.g., nx migrate --run-migrations=migrations.json)\n\n## Usage\n\n```bash\nnx migrate [packageAndVersion]\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nUpdate @nrwl/workspace to \"next\". This will update other packages and will generate migrations.json:\n\n```bash\nnx migrate next\n```\n\nUpdate @nrwl/workspace to \"9.0.0\". This will update other packages and will generate migrations.json:\n\n```bash\nnx migrate 9.0.0\n```\n\nUpdate @nrwl/workspace and generate the list of migrations starting with version 8.0.0 of @nrwl/workspace and @nrwl/node, regardless of what installed locally:\n\n```bash\nnx migrate @nrwl/workspace@9.0.0 --from=\"@nrwl/workspace@8.0.0,@nrwl/node@8.0.0\"\n```\n\nUpdate @nrwl/workspace to \"9.0.0\". If it tries to update @nrwl/react or @nrwl/angular, use version \"9.0.1\":\n\n```bash\nnx migrate @nrwl/workspace@9.0.0 --to=\"@nrwl/react@9.0.1,@nrwl/angular@9.0.1\"\n```\n\nUpdate another-package to \"12.0.0\". This will update other packages and will generate migrations.json file:\n\n```bash\nnx migrate another-package@12.0.0\n```\n\nRun migrations from the provided migrations.json file. You can modify migrations.json and run this command many times:\n\n```bash\nnx migrate --run-migrations=migrations.json\n```\n\nCreate a dedicated commit for each successfully completed migration. You can customize the prefix used for each commit by additionally setting --commit-prefix=\"PREFIX_HERE \":\n\n```bash\nnx migrate --run-migrations --create-commits\n```\n\n## Options\n\n### commitPrefix\n\nType: string\n\nDefault: chore: [nx migration]\n\nCommit prefix to apply to the commit for each migration, when --create-commits is enabled\n\n### createCommits\n\nType: boolean\n\nDefault: false\n\nAutomatically create a git commit after each migration runs\n\n### from\n\nType: string\n\nUse the provided versions for packages instead of the ones installed in node_modules (e.g., --from=\"@nrwl/react:12.0.0,@nrwl/js:12.0.0\")\n\n### help\n\nType: boolean\n\nShow help\n\n### packageAndVersion\n\nType: string\n\nThe target package and version (e.g, @nrwl/workspace@13.0.0)\n\n### runMigrations\n\nType: string\n\nExecute migrations from a file (when the file isn't provided, execute migrations from migrations.json)\n\n### to\n\nType: string\n\nUse the provided versions for packages instead of the ones calculated by the migrator (e.g., --to=\"@nrwl/react:12.0.0,@nrwl/js:12.0.0\")\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "report",
       "id": "report",
       "file": "generated/cli/report",
-      "content": "---\ntitle: 'report - CLI command'\ndescription: 'Reports useful version numbers to copy into the Nx issue template'\n---\n\n# report\n\nReports useful version numbers to copy into the Nx issue template\n\n## Usage\n\n```bash\nnx report\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
+      "content": "---\ntitle: 'report - CLI command'\ndescription: 'Reports useful version numbers to copy into the Nx issue template'\n---\n\n# report\n\nReports useful version numbers to copy into the Nx issue template\n\n## Usage\n\n```bash\nnx report\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
     },
     {
       "name": "list",
       "id": "list",
       "file": "generated/cli/list",
-      "content": "---\ntitle: 'list - CLI command'\ndescription: 'Lists installed plugins, capabilities of installed plugins and other available plugins.'\n---\n\n# list\n\nLists installed plugins, capabilities of installed plugins and other available plugins.\n\n## Usage\n\n```bash\nnx list [plugin]\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nList the plugins installed in the current workspace:\n\n```bash\nnx list\n```\n\nList the generators and executors available in the `@nrwl/web` plugin if it is installed (If the plugin is not installed `nx` will show advice on how to add it to your workspace):\n\n```bash\nnx list @nrwl/web\n```\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### plugin\n\nType: string\n\nThe name of an installed plugin to query\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'list - CLI command'\ndescription: 'Lists installed plugins, capabilities of installed plugins and other available plugins.'\n---\n\n# list\n\nLists installed plugins, capabilities of installed plugins and other available plugins.\n\n## Usage\n\n```bash\nnx list [plugin]\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n### Examples\n\nList the plugins installed in the current workspace:\n\n```bash\nnx list\n```\n\nList the generators and executors available in the `@nrwl/web` plugin if it is installed (If the plugin is not installed `nx` will show advice on how to add it to your workspace):\n\n```bash\nnx list @nrwl/web\n```\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### plugin\n\nType: string\n\nThe name of an installed plugin to query\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "workspace-lint",
       "id": "workspace-lint",
       "file": "generated/cli/workspace-lint",
-      "content": "---\ntitle: 'workspace-lint - CLI command'\ndescription: 'Lint nx specific workspace files (nx.json, workspace.json)'\n---\n\n# workspace-lint\n\nLint nx specific workspace files (nx.json, workspace.json)\n\n## Usage\n\n```bash\nnx workspace-lint [files..]\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
+      "content": "---\ntitle: 'workspace-lint - CLI command'\ndescription: 'Lint nx specific workspace files (nx.json, workspace.json)'\n---\n\n# workspace-lint\n\nLint nx specific workspace files (nx.json, workspace.json)\n\n## Usage\n\n```bash\nnx workspace-lint [files..]\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
     },
     {
       "name": "workspace-generator",
       "id": "workspace-generator",
       "file": "generated/cli/workspace-generator",
-      "content": "---\ntitle: 'workspace-generator - CLI command'\ndescription: 'Runs a workspace generator from the tools/generators directory'\n---\n\n# workspace-generator\n\nRuns a workspace generator from the tools/generators directory\n\n## Usage\n\n```bash\nnx workspace-generator [name]\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### list-generators\n\nType: boolean\n\nList the available workspace-generators\n\n### name\n\nType: string\n\nThe name of your generator\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'workspace-generator - CLI command'\ndescription: 'Runs a workspace generator from the tools/generators directory'\n---\n\n# workspace-generator\n\nRuns a workspace generator from the tools/generators directory\n\n## Usage\n\n```bash\nnx workspace-generator [name]\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### list-generators\n\nType: boolean\n\nList the available workspace-generators\n\n### name\n\nType: string\n\nThe name of your generator\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "connect-to-nx-cloud",
       "id": "connect-to-nx-cloud",
       "file": "generated/cli/connect-to-nx-cloud",
-      "content": "---\ntitle: 'connect-to-nx-cloud - CLI command'\ndescription: 'Makes sure the workspace is connected to Nx Cloud'\n---\n\n# connect-to-nx-cloud\n\nMakes sure the workspace is connected to Nx Cloud\n\n## Usage\n\n```bash\nnx connect-to-nx-cloud\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'connect-to-nx-cloud - CLI command'\ndescription: 'Makes sure the workspace is connected to Nx Cloud'\n---\n\n# connect-to-nx-cloud\n\nMakes sure the workspace is connected to Nx Cloud\n\n## Usage\n\n```bash\nnx connect-to-nx-cloud\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### version\n\nType: boolean\n\nShow version number\n"
     },
     {
       "name": "reset",
       "id": "reset",
       "file": "generated/cli/reset",
-      "content": "---\ntitle: 'reset - CLI command'\ndescription: 'Clears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon.'\n---\n\n# reset\n\nClears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon.\n\n## Usage\n\n```bash\nnx reset\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
+      "content": "---\ntitle: 'reset - CLI command'\ndescription: 'Clears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon.'\n---\n\n# reset\n\nClears all the cached Nx artifacts and metadata about the workspace and shuts down the Nx Daemon.\n\n## Usage\n\n```bash\nnx reset\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n"
     },
     {
       "name": "repair",
       "id": "repair",
       "file": "generated/cli/repair",
-      "content": "---\ntitle: 'repair - CLI command'\ndescription: 'Repair any configuration that is no longer supported by Nx.'\n---\n\n# repair\n\nRepair any configuration that is no longer supported by Nx.\n\n## Usage\n\n```bash\nnx repair\n```\n\n[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### verbose\n\nType: boolean\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
+      "content": "---\ntitle: 'repair - CLI command'\ndescription: 'Repair any configuration that is no longer supported by Nx.'\n---\n\n# repair\n\nRepair any configuration that is no longer supported by Nx.\n\n## Usage\n\n```bash\nnx repair\n```\n\nInstall `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.\n\n## Options\n\n### help\n\nType: boolean\n\nShow help\n\n### verbose\n\nType: boolean\n\nPrints additional information about the commands (e.g., stack traces)\n\n### version\n\nType: boolean\n\nShow version number\n"
     }
   ],
   "generators": [],

docs/generated/packages/react.json

@@ -11,7 +11,7 @@
       "id": "overview",
       "path": "/packages/react",
       "file": "shared/react-plugin",
-      "content": "![React Logo](/shared/react-logo.png)\n\nThe React plugin contains executors and generators for managing React applications and libraries within an Nx workspace.\nIt provides:\n\n- Integration with libraries such as Jest, Cypress, and Storybook.\n- Generators for applications, libraries, components, hooks, and more.\n- Library build support for publishing packages to npm or other registries.\n- Utilities for automatic workspace refactoring.\n\n## Setting Up React\n\nTo create a new workspace with React, run `npx create-nx-workspace@latest --preset=react`.\n\nTo add the React plugin to an existing workspace, run one of the following:\n\n```bash\n# For npm users\nnpm install -D @nrwl/react\n\n# For yarn users\nyarn add -D @nrwl/react\n```\n\n### Creating Applications and Libraries\n\nYou can add a new application with the following:\n\n```bash\nnx g @nrwl/react:app my-new-app\n```\n\nTo start the application in development mode, run `nx serve my-new-app`.\n\nAnd add a new library as follows:\n\n```bash\nnx g @nrwl/react:lib my-new-lib\n\n# If you want the library to be buildable or publishable to npm\nnx g @nrwl/react:lib my-new-lib --buildable\nnx g @nrwl/react:lib my-new-lib \\\n--publishable \\\n--importPath=@myorg/my-new-lib\n```\n\nRead more about [building and publishing libraries here](/structure/buildable-and-publishable-libraries).\n\n### Creating Components\n\nAdding a component to an existing project can be done with:\n\n```bash\nnx g @nrwl/react:component my-new-component \\\n--project=my-new-app\n\n# Note: If you want to export the component\n# from the library use  --export\nnx g @nrwl/react:component my-new-component \\\n--project=my-new-lib \\\n--export\n```\n\nReplace `my-new-app` and `my-new-lib` with the name of your projects.\n\n### Creating Hooks\n\nIf you want to add a new hook, run the following\n\n```bash\nnx g @nrwl/react:hook my-new-hook --project=my-new-lib\n```\n\nReplace `my-new-lib` with the name of your project.\n\n## Using React\n\n### Testing Projects\n\nYou can run unit tests with:\n\n```bash\nnx test my-new-app\nnx test my-new-lib\n```\n\nReplace `my-new-app` with the name or your project. This command works for both applications and libraries.\n\nYou can also run E2E tests for applications:\n\n```bash\nnx e2e my-new-app-e2e\n```\n\nReplace `my-new-app-e2e` with the name or your project with `-e2e` appended.\n\n### Building Projects\n\nReact applications can be build with:\n\n```bash\nnx build my-new-app\n```\n\nAnd if you generated a library with `--buildable`, then you can build a library as well:\n\n```bash\nnx build my-new-lib\n```\n\nThe output is in the `dist` folder. You can customize the output folder by setting `outputPath` in the\nproject's `project.json` file.\n\nThe application in `dist` is deployable, and you can try it out locally with:\n\n```bash\nnpx http-server dist/apps/my-new-app\n```\n\nThe library in `dist` is publishable to npm or a private registry.\n\n## More Documentation\n\n- [Using Cypress](/packages/cypress)\n- [Using Jest](/packages/jest)\n- [Using Storybook](/storybook/overview-react)\n"
+      "content": "![React Logo](/shared/react-logo.png)\n\nThe React plugin contains executors and generators for managing React applications and libraries within an Nx workspace.\nIt provides:\n\n- Integration with libraries such as Jest, Cypress, and Storybook.\n- Generators for applications, libraries, components, hooks, and more.\n- Library build support for publishing packages to npm or other registries.\n- Utilities for automatic workspace refactoring.\n\n## Setting Up React\n\nTo create a new workspace with React, run `npx create-nx-workspace@latest --preset=react`.\n\nTo add the React plugin to an existing workspace, run one of the following:\n\n```bash\n# For npm users\nnpm install -D @nrwl/react\n\n# For yarn users\nyarn add -D @nrwl/react\n```\n\n### Creating Applications and Libraries\n\nYou can add a new application with the following:\n\n```bash\nnx g @nrwl/react:app my-new-app\n```\n\nTo start the application in development mode, run `nx serve my-new-app`.\n\nAnd add a new library as follows:\n\n```bash\nnx g @nrwl/react:lib my-new-lib\n\n# If you want the library to be buildable or publishable to npm\nnx g @nrwl/react:lib my-new-lib --buildable\nnx g @nrwl/react:lib my-new-lib \\\n--publishable \\\n--importPath=@myorg/my-new-lib\n```\n\nRead more about [building and publishing libraries here](/more-concepts/buildable-and-publishable-libraries).\n\n### Creating Components\n\nAdding a component to an existing project can be done with:\n\n```bash\nnx g @nrwl/react:component my-new-component \\\n--project=my-new-app\n\n# Note: If you want to export the component\n# from the library use  --export\nnx g @nrwl/react:component my-new-component \\\n--project=my-new-lib \\\n--export\n```\n\nReplace `my-new-app` and `my-new-lib` with the name of your projects.\n\n### Creating Hooks\n\nIf you want to add a new hook, run the following\n\n```bash\nnx g @nrwl/react:hook my-new-hook --project=my-new-lib\n```\n\nReplace `my-new-lib` with the name of your project.\n\n## Using React\n\n### Testing Projects\n\nYou can run unit tests with:\n\n```bash\nnx test my-new-app\nnx test my-new-lib\n```\n\nReplace `my-new-app` with the name or your project. This command works for both applications and libraries.\n\nYou can also run E2E tests for applications:\n\n```bash\nnx e2e my-new-app-e2e\n```\n\nReplace `my-new-app-e2e` with the name or your project with `-e2e` appended.\n\n### Building Projects\n\nReact applications can be build with:\n\n```bash\nnx build my-new-app\n```\n\nAnd if you generated a library with `--buildable`, then you can build a library as well:\n\n```bash\nnx build my-new-lib\n```\n\nThe output is in the `dist` folder. You can customize the output folder by setting `outputPath` in the\nproject's `project.json` file.\n\nThe application in `dist` is deployable, and you can try it out locally with:\n\n```bash\nnpx http-server dist/apps/my-new-app\n```\n\nThe library in `dist` is publishable to npm or a private registry.\n\n## More Documentation\n\n- [Using Cypress](/packages/cypress)\n- [Using Jest](/packages/jest)\n- [Using Storybook](/storybook/overview-react)\n"
     }
   ],
   "generators": [

docs/generated/packages/workspace.json

@@ -11,7 +11,13 @@
       "id": "overview",
       "path": "/packages/workspace",
       "file": "shared/workspace-plugin",
-      "content": "The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it.\n\n## Creating Workspace Generators\n\nCodifying your organization's best practices into workspace generators is a great way to ensure that the best practices are easy to follow and implement. Running `nx g @nrwl/workspace:workspace-generator feature` will create a workspace generator which is written the same way generators are written for Nx plugins. The workspace generator can then be run with `nx workspace-generator feature`.\n\n> See more about [workspace generators](/generators/workspace-generators)\n\n## Reorganizing Projects\n\nAfter some time of working within a workspace, projects might need to be moved or sometimes even removed.\nThe workspace plugin provides the [`@nrwl/workspace:move`](/packages/workspace/generators/move) and [`@nrwl/workspace:remove`](/packages/workspace/generators/remove) generators to help aid with this.\n\n### Moving Projects\n\nRunning `nx g @nrwl/workspace:move new/location/my-lib --projectName my-lib` will move the `my-lib` library to `libs/new/location/my-lib`.\n\nMoving the files manually can be done easily but a lot of steps are often missed when projects are moved. This generator will also handle the following:\n\n1. The project's files will be moved\n2. The project will be renamed to `new-location-my-lib`\n3. The path mapping in `tsconfig.base.json` will be changed to `@npmScope/new/location/my-lib`\n4. Imports in other projects will be changed to `@npmScope/new/location/my-lib`\n5. Paths in target options such as output path will be changed\n6. Other configuration will be updated too, such as `extends` in `tsconfig.json`, the name of the project in `jest.config.js`, and the extends in `.eslintrc.json`\n\n> See more about [`@nrwl/workspace:move`](/packages/workspace/generators/move)\n\n### Removing Projects\n\nRunning `nx g @nrwl/workspace:remove my-lib` will remove the `my-lib` from the workspace. It is important to note that sometimes, projects cannot be removed if they are still depended on by other projects.\n\nLike when moving projects, some steps are often missed when removing projects. This generator will also handle the following:\n\n1. Checks if other projects depend on the project being removed. This can be ignored via the `--forceRemove` flag.\n2. The project's files will be deleted.\n3. The project's configuration will be removed.\n4. The path mapping in `tsconfig.base.json` will be removed.\n\n> See more about [`@nrwl/workspace:remove`](/packages/workspace/generators/remove)\n\n## Running custom commands\n\nExecutors provide an optimized way of running targets but unfortunately, not every target has an executor written for it. The [`nx:run-commands`](/packages/nx/executors/run-commands) executor is an executor that runs any command or multiple commands in the shell. This can be useful when integrating with other tools which do not have an executor provided. There is also a generator to help configure this executor.\n\nRunning `nx g nx:run-commands printhello --project my-feature-lib --command 'echo hello'` will create a `my-feature-lib:printhello` target that executes `echo hello` in the shell.\n\n> See more about [`nx:run-commands`](/packages/nx/executors/run-commands)\n"
+      "content": "The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it.\n\n## Creating Workspace Generators\n\nCodifying your organization's best practices into workspace generators is a great way to ensure that the best practices are easy to follow and implement. Running `nx g @nrwl/workspace:workspace-generator feature` will create a workspace generator which is written the same way generators are written for Nx plugins. The workspace generator can then be run with `nx workspace-generator feature`.\n\n> See more about [workspace generators](/recipe/workspace-generators)\n\n## Reorganizing Projects\n\nAfter some time of working within a workspace, projects might need to be moved or sometimes even removed.\nThe workspace plugin provides the [`@nrwl/workspace:move`](/packages/workspace/generators/move) and [`@nrwl/workspace:remove`](/packages/workspace/generators/remove) generators to help aid with this.\n\n### Moving Projects\n\nRunning `nx g @nrwl/workspace:move new/location/my-lib --projectName my-lib` will move the `my-lib` library to `libs/new/location/my-lib`.\n\nMoving the files manually can be done easily but a lot of steps are often missed when projects are moved. This generator will also handle the following:\n\n1. The project's files will be moved\n2. The project will be renamed to `new-location-my-lib`\n3. The path mapping in `tsconfig.base.json` will be changed to `@npmScope/new/location/my-lib`\n4. Imports in other projects will be changed to `@npmScope/new/location/my-lib`\n5. Paths in target options such as output path will be changed\n6. Other configuration will be updated too, such as `extends` in `tsconfig.json`, the name of the project in `jest.config.js`, and the extends in `.eslintrc.json`\n\n> See more about [`@nrwl/workspace:move`](/packages/workspace/generators/move)\n\n### Removing Projects\n\nRunning `nx g @nrwl/workspace:remove my-lib` will remove the `my-lib` from the workspace. It is important to note that sometimes, projects cannot be removed if they are still depended on by other projects.\n\nLike when moving projects, some steps are often missed when removing projects. This generator will also handle the following:\n\n1. Checks if other projects depend on the project being removed. This can be ignored via the `--forceRemove` flag.\n2. The project's files will be deleted.\n3. The project's configuration will be removed.\n4. The path mapping in `tsconfig.base.json` will be removed.\n\n> See more about [`@nrwl/workspace:remove`](/packages/workspace/generators/remove)\n\n## Running custom commands\n\nExecutors provide an optimized way of running targets but unfortunately, not every target has an executor written for it. The [`nx:run-commands`](/packages/nx/executors/run-commands) executor is an executor that runs any command or multiple commands in the shell. This can be useful when integrating with other tools which do not have an executor provided. There is also a generator to help configure this executor.\n\nRunning `nx g nx:run-commands printhello --project my-feature-lib --command 'echo hello'` will create a `my-feature-lib:printhello` target that executes `echo hello` in the shell.\n\n> See more about [`nx:run-commands`](/packages/nx/executors/run-commands)\n"
+    },
+    {
+      "name": "Nx, NodeJS and Typescript Versions",
+      "id": "nx-nodejs-typescript-version-matrix",
+      "file": "shared/nx-compatibility-matrix",
+      "content": "# Nx, NodeJS and TypeScript Compatibility Matrix\n\nBelow is a reference table that matches versions the latest major versions of Nx to the version TypeScript that it uses and the version of NodeJS that we tested it against.\n\n> _Note: Other versions of NodeJS **may** still work without issue for these versions of Nx. This table outlines the version of NodeJS that we used when building and testing each particular version of Nx._\n\n| Nx Version | Node Version | Typescript Version |\n| ---------- | ------------ | ------------------ |\n| 10.4.15    | ^12.18       | 4.0.3              |\n| 11.6.3     | ^12.20       | 4.0.5              |\n| 12.10.1    | ^14.17       | ~4.3.5             |\n| 13.10.6    | ^16.5.0      | ~4.6.2             |\n| 14.5.4     | ^16.16.0     | ~4.7.2             |\n| latest     | ^16.16.0     | ~4.7.2             |\n"
     }
   ],
   "generators": [

docs/map.json

@@ -13,158 +13,24 @@
             "file": "shared/getting-started/intro"
           },
           {
-            "name": "Nx Setup",
-            "id": "nx-setup",
-            "file": "shared/getting-started/nx-setup"
+            "name": "Core Tutorial",
+            "id": "core-tutorial",
+            "file": "shared/core-tutorial/01-create-blog"
           },
           {
-            "name": "Nx Without Plugins",
-            "id": "nx-core",
-            "file": "shared/nx-core"
+            "name": "React Tutorial",
+            "id": "react-tutorial",
+            "file": "shared/react-tutorial/01-create-application"
           },
           {
-            "name": "Nx and TypeScript",
-            "id": "nx-and-typescript",
-            "file": "shared/guides/nx-and-ts"
+            "name": "Angular Tutorial",
+            "id": "angular-tutorial",
+            "file": "shared/angular-tutorial/01-create-application"
           },
           {
-            "name": "Nx and React",
-            "id": "nx-and-react",
-            "file": "shared/getting-started/nx-and-react"
-          },
-          {
-            "name": "Nx and Angular",
-            "id": "nx-and-angular",
-            "file": "shared/getting-started/nx-and-angular"
-          }
-        ]
-      },
-      {
-        "name": "Configuration Choices",
-        "id": "configuration",
-        "itemList": [
-          {
-            "name": "package.json and nx.json",
-            "id": "packagejson",
-            "file": "shared/configuration/packagejson"
-          },
-          {
-            "name": "project.json and nx.json",
-            "id": "projectjson",
-            "file": "shared/configuration/projectjson"
-          }
-        ]
-      },
-      {
-        "name": "Using Nx",
-        "id": "using-nx",
-        "itemList": [
-          {
-            "name": "Nx CLI",
-            "id": "nx-cli",
-            "file": "shared/using-nx/nx-cli"
-          },
-          {
-            "name": "Nx Editor Plugins",
-            "id": "console",
-            "file": "shared/console"
-          },
-          {
-            "name": "Mental Model",
-            "id": "mental-model",
-            "file": "shared/mental-model"
-          },
-          {
-            "name": "Computation Caching",
-            "id": "caching",
-            "file": "shared/using-nx/caching"
-          },
-          {
-            "name": "Distributed Task Execution",
-            "id": "dte",
-            "file": "shared/using-nx/dte"
-          },
-          {
-            "name": "Affected",
-            "id": "affected",
-            "file": "shared/using-nx/affected"
-          },
-          {
-            "name": "CI Setup",
-            "id": "ci-overview",
-            "file": "shared/ci-overview"
-          },
-          {
-            "name": "Updating Nx",
-            "id": "updating-nx",
-            "file": "shared/update"
-          },
-          {
-            "name": "Nx, NodeJS and Typescript Versions",
-            "id": "nx-nodejs-typescript-version-matrix",
-            "file": "shared/nx-compatibility-matrix"
-          }
-        ]
-      },
-      {
-        "name": "Extending Nx",
-        "id": "extending-nx",
-        "itemList": [
-          {
-            "name": "Nx Plugins and Devkit",
-            "id": "nx-devkit",
-            "file": "shared/extending-nx/devkit-and-nx-plugins"
-          },
-          {
-            "name": "Project Inference Plugins",
-            "id": "project-inference-plugins",
-            "file": "shared/extending-nx/project-inference-plugins"
-          },
-          {
-            "name": "Project Graph Plugins",
-            "id": "project-graph-plugins",
-            "file": "shared/extending-nx/project-graph-plugins"
-          }
-        ]
-      },
-      {
-        "name": "Migration",
-        "id": "migration",
-        "itemList": [
-          {
-            "name": "Nx and Lerna",
-            "id": "lerna-and-nx",
-            "file": "shared/migration/lerna-and-nx"
-          },
-          {
-            "name": "NPM/Yarn/PNPM workspaces",
-            "id": "adding-to-monorepo",
-            "file": "shared/migration/adding-to-monorepo"
-          },
-          {
-            "name": "From CRA",
-            "id": "migration-cra",
-            "file": "shared/migration/migration-cra"
-          },
-          {
-            "name": "From Angular CLI",
-            "id": "migration-angular",
-            "file": "shared/migration/migration-angular"
-          },
-          {
-            "name": "From AngularJS",
-            "id": "migration-angularjs",
-            "file": "shared/migration/migration-angularjs"
-          },
-          {
-            "name": "Preserving Git Histories",
-            "id": "preserving-git-histories",
-            "file": "shared/migration/preserving-git-histories"
-          },
-          {
-            "name": "Manual migration",
-            "id": "manual",
-            "file": "shared/migration/manual"
+            "name": "Node Tutorial",
+            "id": "node-tutorial",
+            "file": "shared/node-tutorial/01-create-application"
           }
         ]
       },
@@ -383,66 +249,152 @@
         ]
       },
       {
-        "name": "Executors / Builders",
-        "id": "executors",
+        "name": "Core Features",
+        "id": "core-features",
         "itemList": [
           {
-            "name": "Using Executors / Builders",
-            "id": "using-builders",
-            "file": "shared/using-executors"
+            "name": "Run Tasks",
+            "id": "run-tasks",
+            "file": "shared/core-features/run-tasks"
           },
           {
-            "name": "Running Custom Commands",
-            "id": "run-commands-builder",
-            "file": "shared/running-custom-commands"
+            "name": "Cache Task Results",
+            "id": "cache-task-results",
+            "file": "shared/core-features/cache-task-results"
           },
           {
-            "name": "Creating Custom Executors",
-            "id": "creating-custom-builders",
-            "file": "shared/tools-workspace-builders"
+            "name": "Explore the Graph",
+            "id": "explore-graph",
+            "file": "shared/core-features/explore-graph"
+          },
+          {
+            "name": "Distribute Task Execution",
+            "id": "distribute-task-execution",
+            "file": "shared/core-features/distribute-task-execution"
+          },
+          {
+            "name": "Integrate with Editors",
+            "id": "integrate-with-editors",
+            "file": "shared/core-features/integrate-with-editors"
+          },
+          {
+            "name": "Automate Updating Dependencies",
+            "id": "automate-updating-dependencies",
+            "file": "shared/core-features/automate-updating-dependencies"
+          },
+          {
+            "name": "Enforce Project Boundaries",
+            "id": "enforce-project-boundaries",
+            "file": "shared/core-features/enforce-project-boundaries"
           }
         ]
       },
       {
-        "name": "Generators",
-        "id": "generators",
+        "name": "Plugin Features",
+        "id": "plugin-features",
         "itemList": [
           {
-            "name": "Using Generators",
-            "id": "using-generators",
-            "file": "shared/generators/using-generators"
+            "name": "Use Task Executors",
+            "id": "use-task-executors",
+            "file": "shared/plugin-features/use-task-executors"
           },
           {
-            "name": "Workspace Generators",
-            "id": "workspace-generators",
-            "file": "shared/generators/workspace-generators"
+            "name": "Use Code Generators",
+            "id": "use-code-generators",
+            "file": "shared/plugin-features/use-code-generators"
           },
           {
-            "name": "Composing Generators",
-            "id": "composing-generators",
-            "file": "shared/generators/composing-generators"
-          },
-          {
-            "name": "Generator Options",
-            "id": "generator-options",
-            "file": "shared/generators/generator-options"
-          },
-          {
-            "name": "Creating Files",
-            "id": "creating-files",
-            "file": "shared/generators/creating-files"
-          },
-          {
-            "name": "Modifying Files",
-            "id": "modifying-files",
-            "file": "shared/generators/modifying-files"
+            "name": "Create Your Own Plugin",
+            "id": "create-your-own-plugin",
+            "file": "shared/plugin-features/create-your-own-plugin"
           }
         ]
       },
       {
-        "name": "Workspace Structure",
-        "id": "structure",
+        "name": "Concepts",
+        "id": "concepts",
         "itemList": [
+          {
+            "name": "Mental Model",
+            "id": "mental-model",
+            "file": "shared/mental-model"
+          },
+          {
+            "name": "How Caching Works",
+            "id": "how-caching-works",
+            "file": "shared/concepts/how-caching-works"
+          },
+          {
+            "name": "Distributed Task Execution Guide",
+            "id": "dte",
+            "file": "shared/concepts/dte-guide"
+          },
+          {
+            "name": "Task Pipeline Configuration",
+            "id": "task-pipeline-configuration",
+            "file": "shared/concepts/task-pipeline-configuration"
+          },
+          {
+            "name": "Affected",
+            "id": "affected",
+            "file": "shared/using-nx/affected"
+          },
+          {
+            "name": "More Concept Guides »",
+            "id": "more-concept-guides",
+            "file": "shared/concepts/more-concepts"
+          }
+        ]
+      },
+      {
+        "name": "More Concepts",
+        "id": "more-concepts",
+        "itemList": [
+          {
+            "name": "Incremental Builds",
+            "id": "incremental-builds",
+            "file": "shared/incremental-builds"
+          },
+          {
+            "name": "Nx and Turborepo",
+            "id": "turbo-and-nx",
+            "file": "shared/guides/turbo-and-nx"
+          },
+          {
+            "name": "Monorepos",
+            "id": "why-monorepos",
+            "file": "shared/guides/why-monorepos"
+          },
+          {
+            "name": "Using Nx at Enterprises",
+            "id": "monorepo-nx-enterprise",
+            "file": "shared/monorepo-nx-enterprise"
+          },
+          {
+            "name": "Nx Daemon",
+            "id": "nx-daemon",
+            "file": "shared/daemon"
+          },
+          {
+            "name": "Nx and the Angular CLI",
+            "id": "nx-and-angular",
+            "file": "shared/guides/nx-and-angular-cli"
+          },
+          {
+            "name": "Folder Structure",
+            "id": "folder-structure",
+            "file": "shared/guides/integrated-repo-folder-structure"
+          },
+          {
+            "name": "Nx Devkit and Angular Devkit",
+            "id": "nx-devkit-angular-devkit",
+            "file": "shared/guides/nx-devkit-angular-devkit"
+          },
+          {
+            "name": "Micro Frontend Architecture",
+            "id": "micro-frontend-architecture",
+            "file": "shared/guides/module-federation/micro-frontend-architecture"
+          },
           {
             "name": "Applications and Libraries",
             "id": "applications-and-libraries",
@@ -469,26 +421,67 @@
             "file": "shared/workspace/buildable-and-publishable-libraries"
           },
           {
-            "name": "Using Tags",
-            "id": "monorepo-tags",
-            "file": "shared/monorepo-tags"
-          },
-          {
-            "name": "Project Graph",
-            "id": "dependency-graph",
-            "file": "shared/workspace/structure/dependency-graph"
-          },
-          {
-            "name": "Extending the Project Graph",
-            "id": "project-graph-plugins",
-            "file": "shared/extending-nx/project-graph-plugins"
+            "name": "How the Project Graph is Built",
+            "id": "how-project-graph-is-built",
+            "file": "shared/concepts/how-project-graph-is-built"
           }
         ]
       },
       {
-        "name": "CI",
-        "id": "ci",
+        "name": "Recipes",
+        "id": "recipes",
         "itemList": [
+          {
+            "name": "CI Setup",
+            "id": "ci-setup",
+            "file": "shared/ci-overview"
+          },
+          {
+            "name": "Adopting Nx",
+            "id": "adopting-nx",
+            "file": "shared/recipes/adopt-nx"
+          },
+          {
+            "name": "All Recipes »",
+            "id": "all",
+            "file": "shared/recipes/recipe-list"
+          }
+        ]
+      },
+      {
+        "name": "Recipe",
+        "id": "recipe",
+        "itemList": [
+          {
+            "name": "Nx Console Generate Command",
+            "id": "console-generate-command",
+            "file": "shared/recipes/console-generate-command"
+          },
+          {
+            "name": "Nx Console Run Command",
+            "id": "console-run-command",
+            "file": "shared/recipes/console-run-command"
+          },
+          {
+            "name": "Nx Console Project Pane",
+            "id": "console-project-pane",
+            "file": "shared/recipes/console-project-pane"
+          },
+          {
+            "name": "Nx Console Keyboard Shortcuts",
+            "id": "console-shortcuts",
+            "file": "shared/recipes/console-shortcuts"
+          },
+          {
+            "name": "Advanced Update Nx",
+            "id": "advanced-update",
+            "file": "shared/recipes/advanced-update"
+          },
+          {
+            "name": "Set up a new workspace",
+            "id": "set-up-a-new-workspace",
+            "file": "shared/recipes/set-up-a-new-workspace"
+          },
           {
             "name": "Setting up Azure Pipelines",
             "id": "monorepo-ci-azure",
@@ -520,35 +513,94 @@
             "file": "shared/monorepo-ci-bitbucket-pipelines"
           },
           {
-            "name": "Distributed CI",
-            "id": "distributed-builds",
-            "file": "shared/distributed-builds"
+            "name": "Nx and Lerna",
+            "id": "lerna-and-nx",
+            "file": "shared/migration/lerna-and-nx"
           },
           {
-            "name": "Incremental Builds",
-            "id": "incremental-builds",
-            "file": "shared/incremental-builds"
+            "name": "NPM/Yarn/PNPM workspaces",
+            "id": "adding-to-monorepo",
+            "file": "shared/migration/adding-to-monorepo"
           },
           {
-            "name": "Setup incremental builds for Angular applications",
-            "id": "setup-incremental-builds-angular",
-            "file": "shared/guides/setup-incremental-builds-angular"
-          }
-        ]
-      },
-      {
-        "name": "Guides",
-        "id": "guides",
-        "itemList": [
-          {
-            "name": "Nx and Turborepo",
-            "id": "turbo-and-nx",
-            "file": "shared/guides/turbo-and-nx"
+            "name": "From CRA",
+            "id": "migration-cra",
+            "file": "shared/migration/migration-cra"
           },
           {
-            "name": "Monorepos",
-            "id": "why-monorepos",
-            "file": "shared/guides/why-monorepos"
+            "name": "From Angular CLI",
+            "id": "migration-angular",
+            "file": "shared/migration/migration-angular"
+          },
+          {
+            "name": "From AngularJS",
+            "id": "migration-angularjs",
+            "file": "shared/migration/migration-angularjs"
+          },
+          {
+            "name": "Preserving Git Histories",
+            "id": "preserving-git-histories",
+            "file": "shared/migration/preserving-git-histories"
+          },
+          {
+            "name": "Manual migration",
+            "id": "manual",
+            "file": "shared/migration/manual"
+          },
+          {
+            "name": "Running Custom Commands",
+            "id": "run-commands-executor",
+            "file": "shared/running-custom-commands"
+          },
+          {
+            "name": "Use Executor Configurations",
+            "id": "use-executor-configurations",
+            "file": "shared/recipes/use-executor-configurations"
+          },
+          {
+            "name": "Creating Custom Executors",
+            "id": "creating-custom-executors",
+            "file": "shared/tools-workspace-builders"
+          },
+          {
+            "name": "Compose Executors",
+            "id": "compose-executors",
+            "file": "shared/recipes/compose-executors"
+          },
+          {
+            "name": "Workspace Generators",
+            "id": "workspace-generators",
+            "file": "shared/generators/workspace-generators"
+          },
+          {
+            "name": "Composing Generators",
+            "id": "composing-generators",
+            "file": "shared/generators/composing-generators"
+          },
+          {
+            "name": "Generator Options",
+            "id": "generator-options",
+            "file": "shared/generators/generator-options"
+          },
+          {
+            "name": "Creating Files",
+            "id": "creating-files",
+            "file": "shared/generators/creating-files"
+          },
+          {
+            "name": "Modifying Files",
+            "id": "modifying-files",
+            "file": "shared/generators/modifying-files"
+          },
+          {
+            "name": "JavaScript and TypeScript",
+            "id": "js-and-ts",
+            "file": "shared/guides/js-and-ts"
+          },
+          {
+            "name": "React Native with Nx",
+            "id": "react-native",
+            "file": "shared/guides/react-native"
           },
           {
             "name": "Adding Images, Fonts, and Files",
@@ -556,14 +608,24 @@
             "file": "shared/guides/adding-assets"
           },
           {
-            "name": "Using Environment Variables",
-            "id": "environment-variables",
-            "file": "shared/guides/environment-variables"
+            "name": "Define Environment Variables",
+            "id": "define-environment-variables",
+            "file": "shared/guides/define-environment-variables"
           },
           {
-            "name": "Using Nx at Enterprises",
-            "id": "monorepo-nx-enterprise",
-            "file": "shared/monorepo-nx-enterprise"
+            "name": "Use Environment Variables in React",
+            "id": "use-environment-variables-in-react",
+            "file": "shared/guides/use-environment-variables-in-react"
+          },
+          {
+            "name": "Use Environment Variables in Angular",
+            "id": "use-environment-variables-in-angular",
+            "file": "shared/guides/use-environment-variables-in-angular"
+          },
+          {
+            "name": "Setup incremental builds for Angular applications",
+            "id": "setup-incremental-builds-angular",
+            "file": "shared/guides/setup-incremental-builds-angular"
           },
           {
             "name": "Profiling Build Performance",
@@ -575,31 +637,11 @@
             "id": "eslint",
             "file": "shared/eslint"
           },
-          {
-            "name": "Customizing Webpack Config",
-            "id": "customize-webpack",
-            "file": "shared/guides/customize-webpack"
-          },
-          {
-            "name": "Nx Daemon",
-            "id": "nx-daemon",
-            "file": "shared/daemon"
-          },
-          {
-            "name": "JavaScript and TypeScript",
-            "id": "js-and-ts",
-            "file": "shared/guides/js-and-ts"
-          },
           {
             "name": "Configuring Browser Support",
             "id": "browser-support",
             "file": "shared/guides/browser-support"
           },
-          {
-            "name": "React Native with Nx",
-            "id": "react-native",
-            "file": "shared/guides/react-native"
-          },
           {
             "name": "Deploying Next.js applications to Vercel",
             "id": "deploy-nextjs-to-vercel",
@@ -636,37 +678,20 @@
             "file": "shared/guides/misc-data-persistence"
           },
           {
-            "name": "Nx Devkit and Angular Devkit",
-            "id": "nx-devkit-angular-devkit",
-            "file": "shared/guides/nx-devkit-angular-devkit"
-          }
-        ]
-      },
-      {
-        "name": "Module Federation",
-        "id": "module-federation",
-        "itemList": [
+            "name": "Customizing Webpack Config",
+            "id": "customize-webpack",
+            "file": "shared/guides/customize-webpack"
+          },
           {
             "name": "Faster Builds with Module Federation",
             "id": "faster-builds",
             "file": "shared/guides/module-federation/faster-builds"
           },
-          {
-            "name": "Micro Frontend Architecture",
-            "id": "micro-frontend-architecture",
-            "file": "shared/guides/module-federation/micro-frontend-architecture"
-          },
           {
             "name": "Advanced Micro Frontends with Angular using Dynamic Federation",
             "id": "dynamic-module-federation-with-angular",
             "file": "shared/guides/module-federation/dynamic-mfe-angular"
-          }
-        ]
-      },
-      {
-        "name": "Examples",
-        "id": "examples",
-        "itemList": [
+          },
           {
             "name": "Nx Micro-Frontend Example",
             "id": "nx-examples",
@@ -691,6 +716,77 @@
             "name": "Large Repo and DTE",
             "id": "dte",
             "file": "shared/examples/dte"
+          },
+          {
+            "name": "Project Inference Plugins",
+            "id": "project-inference-plugins",
+            "file": "shared/extending-nx/project-inference-plugins"
+          },
+          {
+            "name": "Project Graph Plugins",
+            "id": "project-graph-plugins",
+            "file": "shared/extending-nx/project-graph-plugins"
+          },
+          {
+            "name": "Ban Dependencies with Certain Tags",
+            "id": "ban-dependencies-with-tags",
+            "file": "shared/recipes/ban-dependencies-with-tags"
+          },
+          {
+            "name": "Tag in Multiple Dimensions",
+            "id": "tag-multiple-dimensions",
+            "file": "shared/recipes/tag-multiple-dimensions"
+          },
+          {
+            "name": "Ban External Imports",
+            "id": "ban-external-imports",
+            "file": "shared/recipes/ban-external-imports"
+          },
+          {
+            "name": "Tags Allow List",
+            "id": "tags-allow-list",
+            "file": "shared/recipes/tags-allow-list"
+          },
+          {
+            "name": "Export Project Graph",
+            "id": "export-project-graph",
+            "file": "shared/recipes/export-project-graph"
+          },
+          {
+            "name": "Resolve Circular Dependencies",
+            "id": "resolve-circular-dependencies",
+            "file": "shared/recipes/resolve-circular-dependencies"
+          }
+        ]
+      },
+      {
+        "name": "Reference",
+        "id": "reference",
+        "itemList": [
+          {
+            "name": "Commands",
+            "id": "commands",
+            "file": "shared/reference/commands"
+          },
+          {
+            "name": "nx.json",
+            "id": "nx-json",
+            "file": "shared/reference/nx-json"
+          },
+          {
+            "name": "Project Configuration",
+            "id": "project-configuration",
+            "file": "shared/reference/project-configuration"
+          },
+          {
+            "name": ".nxignore",
+            "id": "nxignore",
+            "file": "shared/reference/nxignore"
+          },
+          {
+            "name": "Environment Variables",
+            "id": "environment-variables",
+            "file": "shared/reference/environment-variables"
           }
         ]
       }
@@ -948,6 +1044,11 @@
             "id": "overview",
             "path": "/packages/workspace",
             "file": "shared/workspace-plugin"
+          },
+          {
+            "name": "Nx, NodeJS and Typescript Versions",
+            "id": "nx-nodejs-typescript-version-matrix",
+            "file": "shared/nx-compatibility-matrix"
           }
         ]
       },

docs/nx-cloud/intro/nx-cloud.md

@@ -2,9 +2,9 @@
 
 ## Save Time With Distributed Task Execution & Distributed Cache
 
-Nx partitions a command into smaller tasks and runs them in parallel, in the correct order. Nx Cloud takes it one step further and [runs any command across multiple machines](/using-nx/dte), while giving you a consolidated view of the command as if it ran locally.
+Nx partitions a command into smaller tasks and runs them in parallel, in the correct order. Nx Cloud takes it one step further and [runs any command across multiple machines](/concepts/dte), while giving you a consolidated view of the command as if it ran locally.
 
-Nx caches the output of any previously run command such as testing and building, so it can replay the cached results instead of rerunning it. Nx Cloud allows you to [share the computation cache](/using-nx/caching#distributed-computation-caching) across everyone in your team and CI.
+Nx caches the output of any previously run command such as testing and building, so it can replay the cached results instead of rerunning it. Nx Cloud allows you to [share the computation cache](/core-features/cache-task-results#distributed-computation-caching) across everyone in your team and CI.
 
 And it takes five minutes to set up.
 

docs/nx-cloud/set-up/set-up-dte.md

@@ -44,11 +44,11 @@ Every organization manages their CI/CD pipelines differently, so the examples do
 
 Read the guides for more information on how to configure them in CI.
 
-- [Overview](/using-nx/ci-overview#distributed-ci-with-nx-cloud)
-- [Azure Pipelines](/ci/monorepo-ci-azure#distributed-ci-with-nx-cloud)
-- [Circle CI](/ci/monorepo-ci-circle-ci#distributed-ci-with-nx-cloud)
-- [GitHub Actions](/ci/monorepo-ci-github-actions#distributed-ci-with-nx-cloud)
-- [Jenkins](/ci/monorepo-ci-jenkins#distributed-ci-with-nx-cloud)
+- [Overview](/recipes/ci-setup#distributed-ci-with-nx-cloud)
+- [Azure Pipelines](/recipe/monorepo-ci-azure#distributed-ci-with-nx-cloud)
+- [Circle CI](/recipe/monorepo-ci-circle-ci#distributed-ci-with-nx-cloud)
+- [GitHub Actions](/recipe/monorepo-ci-github-actions#distributed-ci-with-nx-cloud)
+- [Jenkins](/recipe/monorepo-ci-jenkins#distributed-ci-with-nx-cloud)
 
 ## Additional Notes
 

docs/shared/angular-plugin.md

@@ -71,15 +71,15 @@ nx lint libName
 
 Read more about:
 
-- [Creating Libraries](/structure/creating-libraries)
-- [Library Types](/structure/library-types)
-- [Buildable and Publishable Libraries](/structure/buildable-and-publishable-libraries)
+- [Creating Libraries](/more-concepts/creating-libraries)
+- [Library Types](/more-concepts/library-types)
+- [Buildable and Publishable Libraries](/more-concepts/buildable-and-publishable-libraries)
 
 ## More Documentation
 
 - [Angular Nx Tutorial](/angular-tutorial/01-create-application)
-- [Setup Module Federation with Angular and Nx](/module-federation/faster-builds)
-- [Using NgRx](/guides/misc-ngrx)
-- [Using Data Persistence operators](/guides/misc-data-persistence)
-- [Upgrading an AngularJS application to Angular](/migration/migration-angularjs)
-- [Using Tailwind CSS with Angular projects](/guides/using-tailwind-css-with-angular-projects)
+- [Setup Module Federation with Angular and Nx](/recipe/faster-builds)
+- [Using NgRx](/recipe/misc-ngrx)
+- [Using Data Persistence operators](/recipe/misc-data-persistence)
+- [Upgrading an AngularJS application to Angular](/recipe/migration-angularjs)
+- [Using Tailwind CSS with Angular projects](/recipe/using-tailwind-css-with-angular-projects)

docs/shared/angular-tutorial/01-create-application.md

@@ -8,9 +8,24 @@ width="100%" /%}
 In this tutorial you use Nx to build a full-stack application out of common libraries using modern technologies like Cypress and Nest.
 
 {% callout type="note" title="Plugins for a rich developer experience" %}
-In this tutorial, we use several Nx plugins to provide a rich developer experience that do most of the work for you. **All the plugins are optional.** [Read about using Nx Core without plugins](/getting-started/nx-core).
+In this tutorial, we use several Nx plugins to provide a rich developer experience that do most of the work for you. **All the plugins are optional.** [Read about using Nx without plugins](/core-tutorial/01-create-blog).
 {% /callout %}
 
+## Contents
+
+- [1 - Create Application](/angular-tutorial/01-create-application)
+- [2 - Add E2E Test](/angular-tutorial/02-add-e2e-test)
+- [3 - Display Todos](/angular-tutorial/03-display-todos)
+- [4 - Connect to API](/angular-tutorial/04-connect-to-api)
+- [5 - Add Node Application](/angular-tutorial/05-add-node-app)
+- [6 - Proxy Configuration](/angular-tutorial/06-proxy)
+- [7 - Share Code](/angular-tutorial/07-share-code)
+- [8 - Create Libraries](/angular-tutorial/08-create-libs)
+- [9 - Project Graph](/angular-tutorial/09-dep-graph)
+- [10 - Use Computation Caching](/angular-tutorial/10-computation-caching)
+- [11 - Test Affected Projects](/angular-tutorial/11-test-affected-projects)
+- [12 - Summary](/angular-tutorial/12-summary)
+
 ## Create a new workspace
 
 **Start by creating a new workspace.**

docs/shared/angular-tutorial/07-share-code.md

@@ -53,7 +53,7 @@ export interface Todo {
 
 ### A note about VS Code :
 
-If you're using [VS Code](https://code.visualstudio.com/) it may be necessary at this point to restart the TS server so that the new `@myorg/data` package is recognized. This may need to be done **every time a new workspace library is added**. If you install the [Nx Console](/using-nx/console) extension you won't need to take this step.
+If you're using [VS Code](https://code.visualstudio.com/) it may be necessary at this point to restart the TS server so that the new `@myorg/data` package is recognized. This may need to be done **every time a new workspace library is added**. If you install the [Nx Console](/core-features/integrate-with-editors) extension you won't need to take this step.
 
 ## Refactor the API
 

docs/shared/angular-tutorial/10-computation-caching.md

@@ -76,7 +76,7 @@ And notice the output:
 Nx read the output from the cache instead of running the command for 1 out of 2 tasks.
 ```
 
-Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache here [here](/using-nx/caching).
+Nx built `api` and retrieved `todos` from its computation cache. Read more about the cache here [here](/concepts/how-caching-works).
 
 {% callout type="check" title="Go faster" %}
 Add --parallel to any command, and Nx does most of the work in parallel.

docs/shared/angular-tutorial/12-summary.md

@@ -13,6 +13,5 @@ In this tutorial you:
 
 **Dive Deep:**
 
-- [Nx CLI](/using-nx/nx-cli)
-- [Computation Caching](/using-nx/caching)
-- [Rebuilding What is Affected](/using-nx/affected)
+- [Computation Caching](/concepts/how-caching-works)
+- [Rebuilding What is Affected](/concepts/affected)

docs/shared/ci-overview.md

@@ -51,9 +51,9 @@ Learn more about configuring your CI environment using Nx Cloud with [Distribute
 
 The following guides cover optimizing your CI/CD environments with affected commands and distributed caching:
 
-- [Setting up CI using Azure Pipelines](/ci/monorepo-ci-azure)
-- [Setting up CI using CircleCI](/ci/monorepo-ci-circle-ci)
-- [Setting up CI using GitHub Actions](/ci/monorepo-ci-github-actions)
-- [Setting up CI using Jenkins](/ci/monorepo-ci-jenkins)
-- [Setting up CI using GitLab](/ci/monorepo-ci-gitlab)
-- [Setting up CI using Bitbucket](/ci/monorepo-ci-bitbucket-pipelines)
+- [Setting up CI using Azure Pipelines](/recipe/monorepo-ci-azure)
+- [Setting up CI using CircleCI](/recipe/monorepo-ci-circle-ci)
+- [Setting up CI using GitHub Actions](/recipe/monorepo-ci-github-actions)
+- [Setting up CI using Jenkins](/recipe/monorepo-ci-jenkins)
+- [Setting up CI using GitLab](/recipe/monorepo-ci-gitlab)
+- [Setting up CI using Bitbucket](/recipe/monorepo-ci-bitbucket-pipelines)

docs/shared/cli/generate.md

@@ -17,7 +17,7 @@ nx generate <collection:generator>
 nx g <generator>
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/shared/cli/run.md

@@ -13,7 +13,7 @@ Runs an Architect target with an optional custom builder configuration defined i
 nx run <target> [options]
 ```
 
-[Install `nx` globally](/getting-started/nx-setup#install-nx) to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
+Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpx nx`.
 
 ### Examples
 

docs/shared/concepts/dte-guide.md

@@ -0,0 +1,60 @@
+# Distributed Task Execution Guide
+
+The illustrations in this guide are created by Nrwlian [Nicole Oliver](https://twitter.com/nixcodes)
+
+![how does distributed task execution work in Nx Cloud?](../images/dte/how-does-dte-work.jpeg)
+
+## What's a Task?
+
+![what's a task? project + target (i.e. shared-product-ui + test).  each run contains many tasks.  affected:test contains shared-product-ui:test, product-page:test, shared-e2e-util:test and shared-ui:test](../images/dte/whats-a-task.jpeg)
+
+A task, from Nx's perspective, is a target running on a project. i.e. The target `test` running on the project `shared-product-ui` is a task. For more information about tasks, see the [Run Tasks article](../features/run-tasks).
+
+## Nx Cloud Schedules Your CI Tasks Automatically
+
+![when you turn on DTE, Nx will schedule your commands' tasks in CI.  for example, say you want to run these 3 commands to verify your code: nx affected --target=lint, nx affected --target=test and nx affected --target=build](../images/dte/schedule-tasks.jpeg)
+
+Let's imagine for every PR in CI, you want to lint, test and build all affected projects. When you write your CI workflow, you have no way of knowing how many projects will be affected by each PR or how long each task will take. No matter how carefully you set things up, there will be wasted time if you manually assign a static number of agent machines for linting, testing and building. This approach is called binning.
+
+Luckily, with distributed task execution, Nx Cloud can dynamically assign tasks to agents as they become available.
+
+## Nx Cloud Efficiently Orchestrates Agents
+
+![Nx will automatically schedule tasks w/agents you assign in CI.](../images/dte/use-agents.jpeg)
+
+When you set up DTE, you define (1) the tasks that you want to run and (2) the number of agents that are available for Nx Cloud to use. Then the Nx Cloud orchestrator distributes tasks to agents efficiently - so that all the agents are being fully utilized and your CI process finishes as soon as possible.
+
+## Task Execution Order Matters
+
+![but don't some tasks depend on others' results?  Yep! Nx knows about your dependency tree, so it will execute tasks in the right order and make sure the results are available where they're needed.](../images/dte/task-dependencies.jpeg)
+
+There are some tasks that need to be executed before other tasks, but Nx Cloud takes that into account when it assigns tasks to agents. For a more detailed look at defining those dependencies, read the [Run Tasks article](../features/run-tasks).
+
+## Why Distribute Tasks?
+
+![Result: Faster Builds!](../images/dte/faster-builds.jpeg)
+
+Efficiently parallelizing your CI process across many agents can dramatically speed up your CI, which helps developers identify problems faster and get more work done.
+
+## What Does It Cost?
+
+Nx Cloud is FREE for open source projects. Contact cloud-support@nrwl.io to get set up.
+
+For closed source projects, the first 500 computation hours per month are free. Most workspaces don't exceed this amount. No credit card is required. After 500 hours, the cost is $1 per computation hour.
+
+For more details, see the [Nx Cloud pricing page](https://nx.app/pricing).
+
+## Security
+
+Your actual code is not stored in the cloud, but the hashed inputs and cached results of your tasks are. It is possible to enable end to end encryption of that data so that no one can view that information without your key. Also, if you want to host Nx Cloud on your own servers, you can sign up for Nx Private Cloud.
+
+## Example
+
+[This is an example repo](https://github.com/vsavkin/lerna-dte) showing how easy it is to set up distributed task
+execution, showing the performance gains, and comparing to sharding/binning.
+
+## Illustration
+
+Here is the full illustrated explanation page that [Nicole Oliver](https://twitter.com/nixcodes) made:
+
+![How Does DTE Work Explainer](../images/dte/nx-cloud-how-does-dte-work.png)

docs/shared/concepts/how-caching-works.md

@@ -0,0 +1,194 @@
+# How Caching Works
+
+Before running any task, Nx computes its computation hash. As long as the computation hash is the same, the output of
+running the task is the same.
+
+By default, the computation hash for - say - `nx test remixapp` includes:
+
+- All the source files of `remixapp` and its dependencies
+- Relevant global configuration
+- Versions of external dependencies
+- Runtime values provisioned by the user such as the version of Node
+- CLI Command flags
+
+![computation-hashing](../images/caching/nx-hashing.png)
+
+> This behavior is customizable. For instance, lint checks may only depend on the source code of the project and global
+> configs. Builds can depend on the dts files of the compiled libs instead of their source.
+
+After Nx computes the hash for a task, it then checks if it ran this exact computation before. First, it checks
+locally, and then if it is missing, and if a remote cache is configured, it checks remotely.
+
+If Nx finds the computation, Nx retrieves it and replays it. Nx places the right files in the right folders and
+prints the terminal output. From the user’s point of view, the command ran the same, just a lot faster.
+
+![cache](../images/caching/cache.png)
+
+If Nx doesn’t find a corresponding computation hash, Nx runs the task, and after it completes, it takes the
+outputs and the terminal logs and stores them locally (and if configured remotely as well). All of this happens
+transparently, so you don’t have to worry about it.
+
+Although conceptually this is fairly straightforward, Nx optimizes this to make this experience good for you. For
+instance, Nx:
+
+- Captures stdout and stderr to make sure the replayed output looks the same, including on Windows.
+- Minimizes the IO by remembering what files are replayed where.
+- Only shows relevant output when processing a large task graph.
+- Provides affordances for troubleshooting cache misses. And many other optimizations.
+
+As your workspace grows, the task graph looks more like this:
+
+![cache](../images/caching/task-graph-big.png)
+
+All of these optimizations are crucial for making Nx usable for any non-trivial workspace. Only the minimum amount of
+work happens. The rest is either left as is or restored from the cache.
+
+## Source Code Hash Inputs
+
+The result of building/testing an application or a library depends on the source code of that project and all the source
+codes of all the libraries it depends on (directly or indirectly).
+
+By default, Nx is conservative. When running,
+say, `nx run test --script=remixapp` Nx will consider all the files in the `remixapp` directory and all the files
+in the `header` and `footer` directories (`remixapp` dependencies). This would result in unnecessary cache misses. For
+instance, we know that changing a `footer`'s spec file will not change the result of the test command above.
+
+We can define a more precise configuration as follows:
+
+```json title="nx.json"
+{
+  "namedInputs": {
+    "default": ["{projectRoot}/**/*"],
+    "prod": ["!{projectRoot}/**/*.spec.tsx"]
+  },
+  "targetDefaults": {
+    "build": {
+      "inputs": ["prod", "^prod"]
+    },
+    "test": {
+      "inputs": ["default", "^prod", "{workspaceRoot}/jest.config.ts"]
+    }
+  }
+}
+```
+
+With this configuration, the build script will only consider the non-test files of `remixapp`, `header` and `footer`.
+The test script will consider all the source files for the project under test and only non-test files of its
+dependencies. The test script will also consider the jest config file at the root of the workspace.
+
+## Runtime Hash Inputs
+
+Your targets can also depend on runtime values.
+
+```json title="nx.json"
+{
+  "targetDefaults": {
+    "build": {
+      "inputs": [{ "env": "MY_ENV_NAME" }, { "runtime": "node -v" }]
+    }
+  }
+}
+```
+
+## Args Hash Inputs
+
+Finally, in addition to Source Code Hash Inputs and Runtime Hash Inputs, Nx needs to consider the arguments: For
+example, `nx build remixapp` and `nx build remixapp -- --flag=true` produce different
+results.
+
+Note, only the flags passed to the npm scripts itself affect results of the computation. For instance, the following
+commands are identical from the caching perspective.
+
+```bash
+npx nx build remixapp
+npx nx run-many --target=build --projects=remixapp
+```
+
+In other words, Nx does not cache what the developer types into the terminal.
+
+If you build/test/lint… multiple projects, each individual build has its own hash value and will either be retrieved
+from
+cache or run. This means that from the caching point of view, the following command:
+
+```bash
+npx nx run-many --target=build --projects=header,footer
+```
+
+is identical to the following two commands:
+
+```bash
+npx nx build header
+npx nx build footer
+```
+
+## What is Cached
+
+Nx works on the process level. Regardless of the tools used to build/test/lint/etc.. your project, the results are
+cached.
+
+Nx sets up hooks to collect stdout/stderr before running the command. All the output is cached and then replayed
+during a cache hit.
+
+Nx also caches the files generated by a command. The list of files/folders is listed in the `outputs` property of the project's `package.json`:
+
+```json title="package.json"
+{
+  "nx": {
+    "targets": {
+      "build": {
+        "outputs": ["{projectRoot}/build", "{projectRoot}/public/build"]
+      }
+    }
+  }
+}
+```
+
+If the `outputs` property for a given target isn't defined in the project'
+s `package.json` file, Nx will look at the `targetDefaults` section of `nx.json`:
+
+```json title="nx.json"
+{
+  ...
+  "targetDefaults": {
+    "build": {
+      "dependsOn": [
+        "^build"
+      ],
+      "outputs": [
+        "{projectRoot}/dist",
+        "{projectRoot}/build",
+        "{projectRoot}/public/build"
+      ]
+    }
+  }
+}
+```
+
+If neither is defined, Nx defaults to caching `dist` and `build` at the root of the repository.
+
+## Skipping Cache
+
+Sometimes you want to skip the cache. If, for example, you are measuring the performance of a command, you can use
+the `--skip-nx-cache` flag to skip checking the computation cache.
+
+```bash
+npx nx run build --skip-nx-cache
+npx nx run test --skip-nx-cache
+```
+
+## Customizing the Cache Location
+
+The cache is stored in `node_modules/.cache/nx` by default. To change the cache location, update the `cacheDirectory` option for the task runner in `nx.json`:
+
+```json
+{
+  "tasksRunnerOptions": {
+    "default": {
+      "options": {
+        "cacheableOperations": ["build", "test"],
+        "cacheDirectory": "/tmp/mycache"
+      }
+    }
+  }
+}
+```

docs/shared/concepts/how-project-graph-is-built.md

@@ -0,0 +1,44 @@
+# How the Project Graph is Built
+
+Nx creates a graph of all the dependencies between projects in your workspace using two sources of information:
+
+1. Typescript `import` statements referencing a particular project's path alias
+
+   For instance, if a file in `my-app` has this code:
+
+   ```typescript
+   import { something } from '@myorg/awesome-library';
+   ```
+
+   Then `my-app` depends on `awesome-library`
+
+2. Manually created `implicitDependencies` in the project configuration file.
+
+   If your project configuration has this content:
+
+{% tabs %}
+{% tab label="package.json" %}
+
+```jsonc
+{
+  "name": "myapp",
+  "nx": {
+    "implicitDependencies": ["some-api"]
+  }
+}
+```
+
+{% /tab %}
+{% tab label="project.json" %}
+
+```jsonc
+{
+  "root": "/libs/myapp",
+  "implicitDependencies": ["some-api"]
+}
+```
+
+{% /tab %}
+{% /tabs %}
+
+Then `my-app` depends on `some-api`

docs/shared/concepts/more-concepts.md

@@ -0,0 +1,15 @@
+# More Concept Guides
+
+- [Incremental Builds](/more-concepts/incremental-builds)
+- [Nx and Turborepo](/more-concepts/turbo-and-nx)
+- [Monorepos](/more-concepts/why-monorepos)
+- [Using Nx at Enterprises](/more-concepts/monorepo-nx-enterprise)
+- [Nx Daemon](/more-concepts/nx-daemon)
+- [Nx Devkit and Angular Devkit](/more-concepts/nx-devkit-angular-devkit)
+- [Micro Frontend Architecture](/more-concepts/micro-frontend-architecture)
+- [Applications and Libraries](/more-concepts/applications-and-libraries)
+- [Creating Libraries](/more-concepts/creating-libraries)
+- [Library Types](/more-concepts/library-types)
+- [Grouping Libraries](/more-concepts/grouping-libraries)
+- [Buildable and Publishable Libraries](/more-concepts/buildable-and-publishable-libraries)
+- [How the Project Graph is Built](/more-concepts/how-project-graph-is-built)

docs/shared/concepts/task-pipeline-configuration.md

@@ -0,0 +1,97 @@
+# Task Pipeline Configuration
+
+Nx runs tasks in the most efficient way possible. The `nx.json` file is the place where you can configure how Nx does it.
+
+## Run Tasks in Parallel
+
+If you want to increase the number of processes running tasks to, say, 5 (by default, it is 3), pass the
+following:
+
+```bash
+npx nx build myapp --parallel=5
+```
+
+Note, you can also change the default in `nx.json`, like this:
+
+```json title="nx.json"
+{
+  "tasksRunnerOptions": {
+    "default": {
+      "runner": "nx/tasks-runners/default",
+      "options": {
+        "cacheableOperations": [],
+        "parallel": 5
+      }
+    }
+  }
+}
+```
+
+## Define Task Dependencies (aka Task Pipelines)
+
+To ensure tasks run in the correct order, Nx needs to know how the tasks depend on each other. Add the following to `nx.json`:
+
+```json title="nx.json"
+{
+  ...
+  "targetDefaults": {
+    "build": {
+      "dependsOn": ["^build"]
+    }
+  }
+}
+```
+
+With this, Nx knows that before it can build a project, it needs to build all of its dependencies first. There are, however, no constraints on tests.
+
+This mechanism is very flexible. Let's look at this example:
+
+```json title="nx.json"
+{
+  ...
+  "targetDefaults": {
+    "build": {
+      "dependsOn": ["^build", "prebuild"]
+    },
+    "test": {
+      "dependsOn": ["build"]
+    }
+  }
+}
+```
+
+> Note, older versions of Nx used targetDependencies instead of targetDefaults. Both still work, but targetDefaults is
+> recommended.
+
+When running `nx test myproj`, the above configuration would tell Nx to
+
+1. Run the `test` command for `myproj`
+2. But since there's a dependency defined from `test -> build` (see `test:["build"]`), Nx runs `build` for `myproj`
+   first.
+3. `build` itself defines a dependency on `prebuild` (on the same project) as well as `build` of all the dependencies.
+   Therefore, it will run the `prebuild` script and will run the `build` script for all the dependencies.
+
+Note, Nx doesn't have to run all builds before it starts running tests. The task orchestrator will run as many tasks
+in parallel as possible as long as the constraints are met.
+
+Situations like this are pretty common:
+
+![Mixing Targets](../images/running-tasks/mixing-targets.png)
+
+Because we described the rules in `nx.json`, they will apply to all the projects in the repo. You can also define
+project-specific rules by adding them to the project's configuration.
+
+```json
+{
+  ...
+  "nx": {
+    "targets": {
+      "test": {
+        "dependsOn": [
+          "build"
+        ]
+      }
+    }
+  }
+}
+```

docs/shared/configuration/packagejson.md

@@ -1,580 +0,0 @@
-# Configuration: package.json and nx.json
-
-There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration)
-and [the global Nx CLI configuration](#cli-configuration).
-
-Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (if you
-use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two
-files to get each project's configuration. This guide covers the `package.json` case.
-
-## Project Configuration
-
-Every npm script defined in `package.json` is a target you can invoke via Nx. For instance, if your project has the
-following `package.json`:
-
-```jsonc
-{
-  "name": "mylib",
-  "scripts": {
-    "test": "jest",
-    "build": "tsc -p tsconfig.lib.json" // the actual command here is arbitrary
-  }
-}
-```
-
-you can invoke `nx build mylib` or `nx test mylib` without any extra configuration.
-
-You can add Nx-specific configuration as follows:
-
-```jsonc
-{
-  "name": "mylib",
-  "scripts": {
-    "test: "jest",
-    "build": "tsc -p tsconfig.lib.json" // the actual command here is arbitrary
-  },
-  "nx": {
-    "namedInputs": {
-      "default": [
-        "{projectRoot}/**/*"
-      ],
-      "prod": [
-        "!{projectRoot}/**/*.spec.tsx"
-      ]
-    },
-    "targets": {
-      "build": {
-        "inputs": ["prod", "^prod"],
-        "outputs": ["dist/libs/mylib"],
-        "dependsOn": ["^build"]
-      },
-      "test": {
-        "inputs": ["default", "^prod"],
-        "outputs": [],
-        "dependsOn": ["build"]
-      }
-    }
-  }
-}
-```
-
-### inputs & namedInputs
-
-The `inputs` array tells Nx what to consider to determine whether a particular invocation of a script should be a cache
-hit or not. There are three types of inputs:
-
-_Filesets_
-
-Examples:
-
-- `{projectRoot}/**.*.ts`
-- same as `{fileset: "{projectRoot}/**/*.ts"}`
-- `{workspaceRoot}/jest.config.ts`
-- same as `{fileset: "{workspaceRoot}/jest.config.ts}`
-
-_Runtime Inputs_
-
-Examples:
-
-- `{runtime: "node -v"}`
-
-Node the result value is hashed, so it is never displayed.
-
-_Env Variables_
-
-Examples:
-
-- `{env: "MY_ENV_VAR"}`
-
-Node the result value is hashed, so it is never displayed.
-
-_Named Inputs_
-
-Examples:
-
-- `inputs: ["prod"]`
-- same as `inputs: [{input: "prod", projects: "self"}]`
-
-Often the same glob will appear in many places (e.g., prod fileset will exclude spec files for all projects). Because
-keeping them in sync is error-prone, we recommend defining named inputs, which you can then reference in all of those
-places.
-
-#### Using ^
-
-Examples:
-
-- `inputs: ["^prod"]`
-- same as `inputs: [{input: "prod", projects: "dependencies"}]`
-
-Similar to `dependsOn`, the "^" symbols means "dependencies". This is a very important idea, so let's illustrate it with
-an example.
-
-```
-"test": {
-  "inputs": [ "default", "^prod" ]
-}
-```
-
-The configuration above means that the test target depends on all source files of a given project and only prod
-sources (non-test sources) of its dependencies. In other words, it treats test sources as private.
-
-### outputs
-
-Targets may define outputs to tell Nx where the target is going to create file artifacts that Nx should cache. `"outputs": ["dist/libs/mylib"]` tells Nx where the `build` target is going to create file artifacts.
-
-This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the configuration above.
-
-#### Basic Example
-
-Usually, a target writes to a specific directory or a file. The following instructs Nx to cache `dist/libs/mylib` and `build/libs/mylib/main.js`:
-
-```json
-{
-  "build": {
-    "outputs": ["dist/libs/mylib", "build/libs/mylib/main.js"]
-  }
-}
-```
-
-#### Specifying Globs
-
-Sometimes, multiple targets might write to the same directory. When possible it is recommended to direct these targets into separate directories.
-
-```json
-{
-  "build-js": {
-    "outputs": ["dist/libs/mylib/js"]
-  },
-  "build-css": {
-    "outputs": ["dist/libs/mylib/css"]
-  }
-}
-```
-
-But if the above is not possible, globs can be specified as outputs to only cache a set of files rather than the whole directory.
-
-```json
-{
-  "build-js": {
-    "outputs": ["dist/libs/mylib/**/*.js"]
-  },
-  "build-css": {
-    "outputs": ["dist/libs/mylib/**/*.css"]
-  }
-}
-```
-
-### dependsOn
-
-Targets can depend on other targets. This is the relevant portion of the configuration file:
-
-```json
-"build": {
-  "dependsOn": ["^build"]
-},
-"test": {
-  "dependsOn": ["build"]
-}
-```
-
-A common scenario is having to build dependencies of a project first before building the project. This is what
-the `"dependsOn": ["^build"]` property of the `build` target configures. It tells Nx that before it can build `mylib` it
-needs to make
-sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right
-artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but they are available
-in the cache, Nx will retrieve them from the cache.
-
-Another common scenario is for a target to depend on another target of the same project. For
-instance, `"dependsOn": ["build"]` of
-the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will
-result in `mylib`'s dependencies being built as well.
-
-You can also express the same configuration using:
-
-```json
-"build": {
-  "dependsOn": [{ "projects": "dependencies", "target": "build" }]
-},
-"test": {
-  "dependsOn": [{ "projects": "self", "target": "build" }]
-}
-```
-
-With the expanded syntax, you also have a third option available to configure how to handle the params passed to the target. You can either forward them or you can ignore them (default).
-
-```json
-"build": {
-   // forward params passed to this target to the dependency targets
-  "dependsOn": [{ "projects": "dependencies", "target": "build", "params": "forward" }]
-},
-"test": {
-  // ignore params passed to this target, won't be forwarded to the dependency targets
-  "dependsOn": [{ "projects": "dependencies", "target": "build", "params": "ignore" }]
-}
-"lint": {
-  // ignore params passed to this target, won't be forwarded to the dependency targets
-  "dependsOn": [{ "projects": "dependencies", "target": "build" }]
-}
-```
-
-Obviously this also works when defining a relation for the target of the project itself using `"projects": "self"`:
-
-```json
-"build": {
-   // forward params passed to this target to the project target
-  "dependsOn": [{ "projects": "self", "target": "pre-build", "params": "forward" }]
-}
-```
-
-This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the
-configuration above.
-
-### tags
-
-You can annotate your projects with `tags` as follows:
-
-```jsonc
-{
-  "name": "mylib",
-  "nx": {
-    "tags": ["scope:myteam"]
-  }
-}
-```
-
-You can [configure lint rules using these tags](/structure/monorepo-tags) to, for instance, ensure that libraries
-belonging to `myteam` are not depended on by libraries belong to `theirteam`.
-
-### implicitDependencies
-
-Nx uses powerful source-code analysis to figure out your workspace's project graph. Some dependencies cannot be deduced
-statically, so you can set them manually like this:
-
-```jsonc
-{
-  "name": "mylib",
-  "nx": {
-    "implicitDependencies": ["anotherlib"]
-  }
-}
-```
-
-You can also remove a dependency as follows:
-
-```jsonc
-{
-  "name": "mylib",
-  "nx": {
-    "implicitDependencies": ["!anotherlib"] # regardless of what Nx thinks, "mylib" doesn't depend on "anotherlib"
-  }
-}
-```
-
-### Ignoring a project
-
-Nx will add every project with a `package.json` file in it to its project graph. If you want to ignore a particular
-project, add the following to its `package.json`:
-
-```jsonc
-{
-  "name": "mylib",
-  "nx": {
-    "ignore": true
-  }
-}
-```
-
-### workspace json
-
-The `workspace.json` file in the root directory is optional. It's used if you want to list the projects in your
-workspace explicitly instead of Nx scanning the file tree for all `project.json` and `package.json` files that match the
-globs specified in the `workspaces` property of the root `package.json`.
-
-```json
-{
-  "version": 2,
-  "projects": {
-    "myapp": "apps/myapp"
-  }
-}
-```
-
-- `"version": 2` tells Nx that we are using Nx's format for the `workspace.json` file.
-- `projects` is a map of project names to their locations.
-
-## CLI Configuration
-
-The `nx.json` file configures the Nx CLI and project defaults.
-
-The following is an expanded version showing all options. Your `nx.json` will likely be much shorter.
-
-```json
-{
-  "npmScope": "happyorg",
-  "affected": {
-    "defaultBase": "main"
-  },
-  "workspaceLayout": {
-    "appsDir": "demos",
-    "libsDir": "packages"
-  },
-  "implicitDependencies": {
-    "workspace.json": "*",
-    "package.json": {
-      "dependencies": "*",
-      "devDependencies": "*"
-    },
-    "tsconfig.base.json": "*",
-    "nx.json": "*"
-  },
-  "namedInputs": {
-    "default": ["{projectRoot}/**/*"],
-    "prod": ["!{projectRoot}/**/*.spec.tsx"]
-  },
-  "targetDefaults": {
-    "build": {
-      "inputs": ["prod", "^prod"],
-      "dependsOn": ["^build"]
-    }
-  },
-  "cli": {
-    "defaultCollection": "@nrwl/js"
-  },
-  "generators": {
-    "@nrwl/js:library": {
-      "buildable": true
-    }
-  },
-  "tasksRunnerOptions": {
-    "default": {
-      "runner": "nx/tasks-runners/default",
-      "options": {
-        "cacheableOperations": ["build", "lint", "test", "e2e"]
-      }
-    }
-  }
-}
-```
-
-### NPM Scope
-
-Tells Nx what prefix to use when generating library imports.
-
-### Affected
-
-Tells Nx which branch and HEAD to use when calculating affected projects.
-
-- `defaultBase` defines the default base branch, defaulted to `main`.
-
-### Workspace Layout
-
-You can add a `workspaceLayout` property to modify where libraries and apps are located.
-
-```json
-{
-  "workspaceLayout": {
-    "appsDir": "demos",
-    "libsDir": "packages"
-  }
-}
-```
-
-These settings would store apps in `/demos/` and libraries in `/packages/`. The paths specified are relative to the
-workspace root.
-
-### Files & Implicit Dependencies
-
-Nx performs advanced source-code analysis to figure out the project graph of the workspace. So when you make a change,
-Nx can deduce what can be broken by this change. Some dependencies between projects and shared files cannot be inferred
-statically. You can configure those using `implicitDependencies`.
-
-```json
-{
-  "implicitDependencies": {
-    "workspace.json": "*",
-    "package.json": {
-      "dependencies": "*",
-      "devDependencies": {
-        "mypackage": ["mylib"]
-      },
-      "scripts": {
-        "check:*": "*"
-      }
-    },
-    "globalFile": ["myapp"],
-    "styles/**/*.css": ["myapp"]
-  }
-}
-```
-
-In the example above:
-
-- Changing `workspace.json` affects every project.
-- Changing the `dependencies` property in `package.json` affects every project.
-- Changing the `mypackage` property in `package.json` only affects `mylib`.
-- Changing any of the custom check `scripts` in `package.json` affects every project.
-- Changing `globalFile` only affects `myapp`.
-- Changing any CSS file inside the `styles` directory only affects `myapp`.
-
-### inputs & namedInputs
-
-Named inputs defined in `nx.json` are merged with the named inputs defined in each project's package.json.
-In other words, every project has a set of named inputs, and it's defined as: `{...namedInputsFromNxJson, ...namedInputsFromProjectsPackageJson}`.
-
-Defining `inputs` for a given target would replace the set of inputs for that target name defined in `nx.json`.
-Using pseudocode `inputs = packageJson.targets.build.inputs || nxJson.targetDefaults.build.inputs`.
-
-You can also define and redefine named inputs. This enables one key use case, where your `nx.json` can define things
-like this (which applies to every project):
-
-```
-"test": {
-  "inputs": [
-    "default",
-    "^prod"
-  ]
-}
-```
-
-And projects can define their prod fileset, without having to redefine the inputs for the `test` target.
-
-```json title="package.json"
-{
-  "name": "parent",
-  "scripts": {
-    "build": "...",
-    "test": "..."
-  },
-  "dependencies": {...},
-  "nx": {
-    "namedInputs": {
-      "prod": [
-        "!{projectRoot}/**/*.test.js",
-        "{workspacRoot}/jest.config.js"
-      ]
-    }
-  }
-}
-```
-
-In this case Nx will use the right `prod` input for each project.
-
-### Target Defaults
-
-Targets can depend on other targets. A common scenario is having to build dependencies of a project first before
-building the project. The `dependsOn` property in `package.json` can be used to define the list of dependencies of an
-individual target.
-
-Often the same `dependsOn` configuration has to be defined for every project in the repo, and that's when
-defining `targetDefaults` in `nx.json` is helpful.
-
-```json
-{
-  "targetDefaults": {
-    "build": {
-      "dependsOn": ["^build"]
-    }
-  }
-}
-```
-
-The configuration above is identical to adding `{"dependsOn": ["^build"]}` to every build target of every project.
-
-Another target default you can configure is `outputs`:
-
-```json
-{
-  "targetDefaults": {
-    "build": {
-      "outputs": ["{projectRoot}/custom-dist"]
-    }
-  }
-}
-```
-
-{% callout type="warning" title="Nx < 14.3.4" %}
-Previous versions of Nx (before 14.3.4) supported `targetDependencies` to configure dependencies in `nx.json`
-. `targetDefaults` is the same mechanism but generalized to support other properties.
-{% /callout %}
-
-### CLI Options
-
-The following command generates a new library: `nx g @nrwl/js:lib mylib`. After setting the `defaultCollection`property,
-the lib is generated without mentioning the plugin name: `nx g lib mylib`.
-
-```json
-{
-  "cli": {
-    "defaultCollection": "@nrwl/js"
-  }
-}
-```
-
-### Generators
-
-Default generator options are configured in `nx.json` as well. For instance, the following tells Nx to always
-pass `--buildable=true` when creating new libraries.
-
-```json
-{
-  "generators": {
-    "@nrwl/js:library": {
-      "buildable": true
-    }
-  }
-}
-```
-
-### Tasks Runner Options
-
-> A task is an invocation of a target.
-
-Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner
-named "default" is used by default. Specify a different one like
-this `nx run-many --target=build --all --runner=another`.
-
-Tasks runners can accept different options. The following are the options supported
-by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
-
-| Property                | Descrtipion                                                                                                                                                                                                                                                                                                                                   |
-| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| cacheableOperations     | defines the list of targets/operations that are cached by Nx                                                                                                                                                                                                                                                                                  |
-| parallel                | defines the max number of targets ran in parallel (in older versions of Nx you had to pass `--parallel --maxParallel=3` instead of `--parallel=3`)                                                                                                                                                                                            |
-| captureStderr           | defines whether the cache captures stderr or just stdout                                                                                                                                                                                                                                                                                      |
-| skipNxCache             | defines whether the Nx Cache should be skipped (defaults to `false`)                                                                                                                                                                                                                                                                          |
-| cacheDirectory          | defines where the local cache is stored (defaults to `node_modules/.cache/nx`)                                                                                                                                                                                                                                                                |
-| encryptionKey           | (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable |
-| runtimeCacheInputs      | defines the list of commands that are run by the runner to include into the computation hash value                                                                                                                                                                                                                                            |
-| selectivelyHashTsConfig | only hash the path mapping of the active project in the `tsconfig.base.json` (e.g., adding/removing projects doesn't affect the hash of existing projects) (defaults to `false`)                                                                                                                                                              |
-
-`runtimeCacheInputs` are set as follows:
-
-```json
-{
-  "tasksRunnerOptions": {
-    "default": {
-      "runner": "nx/tasks-runners/default",
-      "options": {
-        "cacheableOperations": ["build", "lint", "test", "e2e"],
-        "runtimeCacheInputs": ["node -v"]
-      }
-    }
-  }
-}
-```
-
-You can configure `parallel` in `nx.json`, but you can also pass them in the
-terminal `nx run-many --target=test --parallel=5`.
-
-## .nxignore
-
-You may optionally add an `.nxignore` file to the root. This file is used to specify files in your workspace that should
-be completely ignored by Nx.
-
-The syntax is the same as
-a [`.gitignore` file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring).
-
-**When a file is specified in the `.nxignore` file:**
-
-1. Changes to that file are not taken into account in the `affected` calculations.
-2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it.

docs/shared/configuration/projectjson.md

@@ -1,749 +0,0 @@
-# Configuration: project.json and nx.json
-
-There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration)
-and [the global Nx CLI configuration](#cli-configuration).
-
-Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (if you
-use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two
-files to get each project's configuration. This guide covers the `project.json` case.
-
-{% callout type="note" title="Using Angular?" %}
-Angular developers can also configure projects in angular.json. [Read this guide for more information](/getting-started/nx-and-angular#angularjson).
-{% /callout %}
-
-## Project Configuration
-
-The `project.json` file contains configuration specific to its project. This file is often created when you use Nx
-Plugins. It configures custom executors, which are used instead of npm scripts. Custom executors are typed, toolable and provide a
-lot more flexibility for running long-live processes. They are also more composable.
-
-If you're satisfied with npm scripts though, you will never see a `project.json` file in your workspace. But we encourage
-you to explore Nx Plugins and the power they bring.
-
-Let's look at the following `project.json`:
-
-```json
-{
-  "root": "libs/mylib/",
-  "sourceRoot": "libs/mylib/src",
-  "projectType": "library",
-  "namedInputs": {
-    "default": ["{projectRoot}/**/*"],
-    "prod": ["!{projectRoot}/**/*.spec.tsx"]
-  },
-  "targets": {
-    "test": {
-      "executor": "@nrwl/jest:jest",
-      "inputs": ["default", "^prod"],
-      "outputs": [],
-      "dependsOn": ["build"],
-      "options": {
-        "jestConfig": "libs/mylib/jest.config.js",
-        "tsConfig": "libs/mylib/tsconfig.spec.json"
-      }
-    },
-    "build": {
-      "executor": "@nrwl/js:tsc",
-      "inputs": ["prod", "^prod"],
-      "outputs": ["dist/libs/mylib"],
-      "dependsOn": ["^build"],
-      "options": {
-        "tsConfig": "libs/mylib/tsconfig.lib.json",
-        "main": "libs/mylib/src/main.ts"
-      },
-      "configurations": {
-        "production": {
-          "tsConfig": "libs/mylib/tsconfig-prod.lib.json"
-        }
-      }
-    }
-  },
-  "tags": ["scope:myteam"],
-  "implicitDependencies": ["anotherlib"]
-}
-```
-
-- `root` tells Nx the location of the library including its sources and configuration files.
-- `sourceRoot` tells Nx the location of the library's source files.
-- `projectType` is either 'application' or 'library'. The project type is used in project graph viz and in a few aux
-  commands.
-
-### inputs & namedInputs
-
-The `inputs` array tells Nx what to consider to determine whether a particular invocation of a script should be a cache
-hit or not. There are three types of inputs:
-
-_Filesets_
-
-Examples:
-
-- `{projectRoot}/**.*.ts`
-- same as `{fileset: "{projectRoot}/**/*.ts"}`
-- `{workspaceRoot}/jest.config.ts`
-- same as `{fileset: "{workspaceRoot}/jest.config.ts}`
-
-_Runtime Inputs_
-
-Examples:
-
-- `{runtime: "node -v"}`
-
-Node the result value is hashed, so it is never displayed.
-
-_Env Variables_
-
-Examples:
-
-- `{env: "MY_ENV_VAR"}`
-
-Node the result value is hashed, so it is never displayed.
-
-_Named Inputs_
-
-Examples:
-
-- `inputs: ["prod"]`
-- same as `inputs: [{input: "prod", projects: "self"}]`
-
-Often the same glob will appear in many places (e.g., prod fileset will exclude spec files for all projects). Because
-keeping them in sync is error-prone, we recommend defining named inputs, which you can then reference in all of those
-places.
-
-#### Using ^
-
-Examples:
-
-- `inputs: ["^prod"]`
-- same as `inputs: [{input: "prod", projects: "dependencies"}]`
-
-Similar to `dependsOn`, the "^" symbols means "dependencies". This is a very important idea, so let's illustrate it with
-an example.
-
-```
-"test": {
-  "inputs": [ "default", "^prod" ]
-}
-```
-
-The configuration above means that the test target depends on all source files of a given project and only prod
-sources (non-test sources) of its dependencies. In other words, it treats test sources as private.
-
-### Targets
-
-Let's look at a sample test target:
-
-```json
-{
-  "test": {
-    "executor": "@nrwl/jest:jest",
-    "outputs": [],
-    "dependsOn": ["build"],
-    "options": {
-      "jestConfig": "libs/mylib/jest.config.js",
-      "tsConfig": "libs/mylib/tsconfig.spec.json"
-    }
-  }
-}
-```
-
-**Target Name**
-
-The name of the target `test` means that you can invoke it as follows: `nx test mylib` or `nx run mylib:test`. The name
-isn't significant in any other way. If you rename it to, for example, `mytest`, you will be able to run as
-follows: `nx mytest mylib` or `nx run mylib:mytest`.
-
-**Executor**
-
-The `executor` property tells Nx what function to invoke when you run the target. `"@nrwl/jest:jest"` tells Nx to find
-the `@nrwl/jest` package, find the executor named `jest` and invoke it with the options.
-
-**Options**
-
-The `options` provides a map of values that will be passed to the executor. The provided command line args will be
-merged into this map. I.e., `nx test mylib --jestConfig=libs/mylib/another-jest.config.js` will pass the following to
-the executor:
-
-```json
-{
-  "jestConfig": "libs/mylib/another-jest.config.js",
-  "tsConfig": "libs/mylib/tsconfig.spec.json"
-}
-```
-
-**Configurations**
-
-The `configurations` property provides extra sets of values that will be merged into the options map.
-
-```json
-{
-  "build": {
-    "executor": "@nrwl/js:tsc",
-    "outputs": ["dist/libs/mylib"],
-    "dependsOn": ["^build"],
-    "options": {
-      "tsConfig": "libs/mylib/tsconfig.lib.json",
-      "main": "libs/mylib/src/main.ts"
-    },
-    "configurations": {
-      "production": {
-        "tsConfig": "libs/mylib/tsconfig-prod.lib.json"
-      }
-    }
-  }
-}
-```
-
-You can select a configuration like this: `nx build mylib --configuration=production`
-or `nx run mylib:build:configuration=production`.
-
-The following code snippet shows how the executor options get constructed:
-
-```javascript
-require(`@nrwl/jest`).executors['jest']({
-  ...options,
-  ...selectedConfiguration,
-  ...commandLineArgs,
-}); // Pseudocode
-```
-
-The selected configuration adds/overrides the default options, and the provided command line args add/override the
-configuration options.
-
-### inputs & namedInputs
-
-The `inputs` array tells Nx what to consider to determine whether a particular invocation of a script should be a cache
-hit or not. There are three types of inputs:
-
-_Filesets_
-
-Examples:
-
-- `{projectRoot}/**.*.ts`
-- same as `{fileset: "{projectRoot}/**/*.ts"}`
-- `{workspaceRoot}/jest.config.ts`
-- same as `{fileset: "{workspaceRoot}/jest.config.ts}`
-
-_Runtime Inputs_
-
-Examples:
-
-- `{runtime: "node -v"}`
-
-Node the result value is hashed, so it is never displayed.
-
-_Env Variables_
-
-Examples:
-
-- `{env: "MY_ENV_VAR"}`
-
-Node the result value is hashed, so it is never displayed.
-
-_Named Inputs_
-
-Examples:
-
-- `inputs: ["prod"]`
-- same as `inputs: [{input: "prod", projects: "self"}]`
-
-Often the same glob will appear in many places (e.g., prod fileset will exclude spec files for all projects). Because
-keeping them in sync is error-prone, we recommend defining named inputs, which you can then reference in all of those
-places.
-
-#### Using ^
-
-Examples:
-
-- `inputs: ["^prod"]`
-- same as `inputs: [{input: "prod", projects: "dependencies"}]`
-
-Similar to `dependsOn`, the "^" symbols means "dependencies". This is a very important idea, so let's illustrate it with
-an example.
-
-```
-"test": {
-  "inputs": [ "default", "^prod" ]
-}
-```
-
-The configuration above means that the test target depends on all source files of a given project and only prod
-sources (non-test sources) of its dependencies. In other words, it treats test sources as private.
-
-### Outputs
-
-Targets may define outputs to tell Nx where the target is going to create file artifacts that Nx should cache. `"outputs": ["dist/libs/mylib"]` tells Nx where the `build` target is going to create file artifacts.
-
-#### Basic Example
-
-Usually, a target writes to a specific directory or a file. The following instructs Nx to cache `dist/libs/mylib` and `build/libs/mylib/main.js`:
-
-```json
-  {
-    "build": {
-      ...,
-      "outputs": ["dist/libs/mylib", "build/libs/mylib/main.js"],
-      "options": {
-        ...
-      },
-    }
-  }
-```
-
-#### Referencing Options
-
-Most commonly, targets have an option for an output file or directory. Rather than duplicating the information as seen above, options can be referenced using the below syntax:
-
-> When the `outputPath` option is changed, Nx will start caching the new path as well.
-
-```json
-{
-  "build": {
-    ...,
-    "outputs": ["{options.outputPath}"],
-    "options": {
-      "outputPath": "dist/libs/mylib"
-    }
-  }
-}
-```
-
-#### Specifying Globs
-
-Sometimes, multiple targets might write to the same directory. When possible it is recommended to direct these targets into separate directories.
-
-```json
-{
-  "build-js": {
-    ...,
-    "outputs": ["dist/libs/mylib/js"],
-    "options": {
-      "outputPath": "dist/libs/mylib/js"
-    }
-  },
-  "build-css": {
-    ...,
-    "outputs": ["dist/libs/mylib/css"],
-    "options": {
-      "outputPath": "dist/libs/mylib/css"
-    }
-  }
-}
-```
-
-But if the above is not possible, globs can be specified as outputs to only cache a set of files rather than the whole directory.
-
-```json
-{
-  "build-js": {
-    ...,
-    "outputs": ["dist/libs/mylib/**/*.js"],
-    "options": {
-      "outputPath": "dist/libs/mylib"
-    }
-  },
-  "build-css": {
-    ...,
-    "outputs": ["dist/libs/mylib/**/*.css"],
-    "options": {
-      "outputPath": "dist/libs/mylib"
-    }
-  }
-}
-```
-
-### dependsOn
-
-Targets can depend on other targets. This is the relevant portion of the configuration file:
-
-```json
-"build": {
-  "dependsOn": ["^build"]
-},
-"test": {
-  "dependsOn": ["build"]
-}
-```
-
-A common scenario is having to build dependencies of a project first before building the project. This is what
-the `"dependsOn": ["^build"]` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make
-sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right
-artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but they are available
-in the cache, Nx will retrieve them from the cache.
-
-Another common scenario is for a target to depend on another target of the same project. For instance, `"dependsOn": ["build"]` of
-the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will
-result in `mylib`'s dependencies being built as well.
-
-You can also express the same configuration using:
-
-```json
-"build": {
-  "dependsOn": [{ "projects": "dependencies", "target": "build" }]
-},
-"test": {
-  "dependsOn": [{ "projects": "self", "target": "build" }]
-}
-```
-
-With the expanded syntax, you also have a third option available to configure how to handle the params passed to the target. You can either forward them or you can ignore them (default).
-
-```json
-"build": {
-   // forward params passed to this target to the dependency targets
-  "dependsOn": [{ "projects": "dependencies", "target": "build", "params": "forward" }]
-},
-"test": {
-  // ignore params passed to this target, won't be forwarded to the dependency targets
-  "dependsOn": [{ "projects": "dependencies", "target": "build", "params": "ignore" }]
-}
-"lint": {
-  // ignore params passed to this target, won't be forwarded to the dependency targets
-  "dependsOn": [{ "projects": "dependencies", "target": "build" }]
-}
-```
-
-Obviously this also works when defining a relation for the target of the project itself using `"projects": "self"`:
-
-```json
-"build": {
-   // forward params passed to this target to the project target
-  "dependsOn": [{ "projects": "self", "target": "pre-build", "params": "forward" }]
-}
-```
-
-This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the
-configuration above.
-
-### tags
-
-You can annotate your projects with `tags` as follows:
-
-```jsonc
-{
-  "tags": ["scope:myteam"]
-}
-```
-
-You can [configure lint rules using these tags](/structure/monorepo-tags) to, for instance, ensure that libraries belonging to `myteam` are not depended on by libraries belong to `theirteam`.
-
-### implicitDependencies
-
-Nx uses powerful source-code analysis to figure out your workspace's project graph. Some dependencies cannot be deduced
-statically, so you can set them manually like this:
-
-```json
-{
-  "root": "libs/mylib/",
-  "sourceRoot": "libs/mylib/src",
-  "projectType": "library",
-  "targets": {},
-  "implicitDependencies": ["anotherlib"]
-}
-```
-
-You can also remove a dependency as follows:
-
-```jsonc
-{
-  "root": "libs/mylib/",
-  "sourceRoot": "libs/mylib/src",
-  "projectType": "library",
-  "targets": {},
-  "implicitDependencies": ["!anotherlib"] # regardless of what Nx thinks, "mylib" doesn't depend on "anotherlib"
-}
-```
-
-### workspace json
-
-The `workspace.json` file in the root directory is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx scanning the file tree for all `project.json` and `package.json` files.
-
-```json
-{
-  "version": 2,
-  "projects": {
-    "myapp": "apps/myapp"
-  }
-}
-```
-
-- `"version": 2` tells Nx that we are using Nx's format for the `workspace.json` file.
-- `projects` is a map of project names to their locations.
-
-You could inline `project.json` files into `workspace.json`. This used to be the default, but it's no longer
-recommended. If you have an existing workspace where the configuration is inlined,
-run `nx g convert-to-nx-project --all`.
-
-If you have an old workspace where the configuration version is set to 1, change the version number to 2 and
-run `nx format`.
-
-## CLI Configuration
-
-The `nx.json` file configures the Nx CLI and project defaults.
-
-The following is an expanded version showing all options. Your `nx.json` will likely be much shorter.
-
-```json
-{
-  "npmScope": "happyorg",
-  "affected": {
-    "defaultBase": "main"
-  },
-  "workspaceLayout": {
-    "appsDir": "demos",
-    "libsDir": "packages"
-  },
-  "implicitDependencies": {
-    "workspace.json": "*",
-    "package.json": {
-      "dependencies": "*",
-      "devDependencies": "*"
-    },
-    "tsconfig.base.json": "*",
-    "nx.json": "*"
-  },
-  "namedInputs": {
-    "default": ["{projectRoot}/**/*"],
-    "prod": ["!{projectRoot}/**/*.spec.tsx"]
-  },
-  "targetDefaults": {
-    "build": {
-      "inputs": ["prod", "^prod"],
-      "dependsOn": ["^build"]
-    }
-  },
-  "cli": {
-    "defaultCollection": "@nrwl/js"
-  },
-  "generators": {
-    "@nrwl/js:library": {
-      "buildable": true
-    }
-  },
-  "tasksRunnerOptions": {
-    "default": {
-      "runner": "nx/tasks-runners/default",
-      "options": {
-        "cacheableOperations": ["build", "lint", "test", "e2e"]
-      }
-    }
-  }
-}
-```
-
-### NPM Scope
-
-Tells Nx what prefix to use when generating library imports.
-
-### Affected
-
-Tells Nx which branch and HEAD to use when calculating affected projects.
-
-- `defaultBase` defines the default base branch, defaulted to `main`.
-
-### Workspace Layout
-
-You can add a `workspaceLayout` property to modify where libraries and apps are located.
-
-```json
-{
-  "workspaceLayout": {
-    "appsDir": "demos",
-    "libsDir": "packages"
-  }
-}
-```
-
-These settings would store apps in `/demos/` and libraries in `/packages/`. The paths specified are relative to the
-workspace root.
-
-### Files & Implicit Dependencies
-
-Nx performs advanced source-code analysis to figure out the project graph of the workspace. So when you make a change,
-Nx can deduce what can be broken by this change. Some dependencies between projects and shared files cannot be inferred
-statically. You can configure those using `implicitDependencies`.
-
-```json
-{
-  "implicitDependencies": {
-    "workspace.json": "*",
-    "package.json": {
-      "dependencies": "*",
-      "devDependencies": {
-        "mypackage": ["mylib"]
-      },
-      "scripts": {
-        "check:*": "*"
-      }
-    },
-    "globalFile": ["myapp"],
-    "styles/**/*.css": ["myapp"]
-  }
-}
-```
-
-In the example above:
-
-- Changing `workspace.json` affects every project.
-- Changing the `dependencies` property in `package.json` affects every project.
-- Changing the `mypackage` property in `package.json` only affects `mylib`.
-- Changing any of the custom check `scripts` in `package.json` affects every project.
-- Changing `globalFile` only affects `myapp`.
-- Changing any CSS file inside the `styles` directory only affects `myapp`.
-
-### inputs & namedInputs
-
-Named inputs defined in `nx.json` are merged with the named inputs defined in each project's project.json.
-In other words, every project has a set of named inputs, and it's defined as: `{...namedInputsFromNxJson, ...namedInputsFromProjectsProjectJson}`.
-
-Defining `inputs` for a given target would replace the set of inputs for that target name defined in `nx.json`.
-Using pseudocode `inputs = projectJson.targets.build.inputs || nxJson.targetDefaults.build.inputs`.
-
-You can also define and redefine named inputs. This enables one key use case, where your `nx.json` can define things
-like this (which applies to every project):
-
-```
-"test": {
-  "inputs": [
-    "default",
-    "^prod"
-  ]
-}
-```
-
-And projects can define their prod fileset, without having to redefine the inputs for the `test` target.
-
-```json title="project.json"
-{
-  "namedInputs": {
-    "prod": ["!{projectRoot}/**/*.test.js", "{workspacRoot}/jest.config.js"]
-  }
-}
-```
-
-In this case Nx will use the right `prod` input for each project.
-
-### Target Defaults
-
-Targets can depend on other targets. A common scenario is having to build dependencies of a project first before
-building the project. The `dependsOn` property in `project.json` can be used to define the list of dependencies of an
-individual target.
-
-Often the same `dependsOn` configuration has to be defined for every project in the repo, and that's when
-defining `targetDefaults` in `nx.json` is helpful.
-
-```json
-{
-  "targetDefaults": {
-    "build": {
-      "dependsOn": ["^build"]
-    }
-  }
-}
-```
-
-The configuration above is identical to adding `{"dependsOn": ["^build"]}` to every build target of every project.
-
-Another target default you can configure is `outputs`:
-
-```json
-{
-  "targetDefaults": {
-    "build": {
-      "outputs": ["./custom-dist"]
-    }
-  }
-}
-```
-
-### CLI Options
-
-The following command generates a new library: `nx g @nrwl/js:lib mylib`. After setting the `defaultCollection`property,
-the lib is generated without mentioning the collection name: `nx g lib mylib`.
-
-```json
-{
-  "cli": {
-    "defaultCollection": "@nrwl/js"
-  }
-}
-```
-
-### Generators
-
-Default generator options are configured in `nx.json` as well. For instance, the following tells Nx to always
-pass `--buildable=true` when creating new libraries.
-
-```json
-{
-  "generators": {
-    "@nrwl/js:library": {
-      "buildable": true
-    }
-  }
-}
-```
-
-### Tasks Runner Options
-
-> A task is an invocation of a target.
-
-Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner
-named "default" is used by default. Specify a different one like this `nx run-many --target=build --all --runner=another`.
-
-Tasks runners can accept different options. The following are the options supported
-by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
-
-| Property                | Descrtipion                                                                                                                                                                                                                                                                                                                                   |
-| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| cacheableOperations     | defines the list of targets/operations that are cached by Nx                                                                                                                                                                                                                                                                                  |
-| parallel                | defines the max number of targets ran in parallel (in older versions of Nx you had to pass `--parallel --maxParallel=3` instead of `--parallel=3`)                                                                                                                                                                                            |
-| captureStderr           | defines whether the cache captures stderr or just stdout                                                                                                                                                                                                                                                                                      |
-| skipNxCache             | defines whether the Nx Cache should be skipped (defaults to `false`)                                                                                                                                                                                                                                                                          |
-| cacheDirectory          | defines where the local cache is stored (defaults to `node_modules/.cache/nx`)                                                                                                                                                                                                                                                                |
-| encryptionKey           | (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable |
-| runtimeCacheInputs      | defines the list of commands that are run by the runner to include into the computation hash value                                                                                                                                                                                                                                            |
-| selectivelyHashTsConfig | only hash the path mapping of the active project in the `tsconfig.base.json` (e.g., adding/removing projects doesn't affect the hash of existing projects) (defaults to `false`)                                                                                                                                                              |
-
-`runtimeCacheInputs` are set as follows:
-
-```json
-{
-  "tasksRunnerOptions": {
-    "default": {
-      "runner": "nx/tasks-runners/default",
-      "options": {
-        "cacheableOperations": ["build", "lint", "test", "e2e"],
-        "runtimeCacheInputs": ["node -v"]
-      }
-    }
-  }
-}
-```
-
-You can configure `parallel` in `nx.json`, but you can also pass them in the
-terminal `nx run-many --target=test --parallel=5`.
-
-## .nxignore
-
-You may optionally add an `.nxignore` file to the root. This file is used to specify files in your workspace that should
-be completely ignored by Nx.
-
-The syntax is the same as
-a [`.gitignore` file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring).
-
-**When a file is specified in the `.nxignore` file:**
-
-1. Changes to that file are not taken into account in the `affected` calculations.
-2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it.
-
-## Validating the configuration
-
-If at any point in time you want to check if your configuration is in sync, you can use
-the [workspace-lint](/nx/workspace-lint) executor:
-
-```bash
-nx workspace-lint
-```
-
-This will identify any projects with no files in the configured project root folder, as well as any file that's not part
-of any project configured in the workspace.

docs/shared/console.md

@@ -1,160 +0,0 @@
-# Nx Editor Plugins
-
-**Spend less time looking up command line arguments and more time shipping incredible products.**
-
-With Nx, you can get a full-stack application up and running in minutes, no need to figure out sourcemaps, webpack or test runners. It all works out of the box. Nx also helps you to enforce consistent development practices by generating components, services, and state management modules.
-
-## Why use Nx Editor Plugins?
-
-Developers use both command-line tools and user interfaces. They commit in the terminal, but resolve conflicts in VSCode or WebStorm. They use the right tool for the job.
-
-Nx is a command-line tool, which works great when you want to serve an application or generate a simple component. But it falls short once you start doing advanced things.
-
-For instance:
-
-- Exploring custom generator collections is hard in the terminal, but it's easy using Nx Console.
-- Using rarely-used flags is challenging. Do you pass absolute or relative paths? You don't have to remember any flags, names or paths -  Nx Console will help you by providing autocompletion and validating your inputs.
-- Finding the right Nx extension can take a long time. When using Nx Console, you can find and install an extension in minutes.
-
-Nx Console does all that and more!
-
-## Download
-
-### VSCode
-
-If you are using [VSCode](https://code.visualstudio.com/), you can install the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) from Marketplace. The Nx Console VSCode Plugin is **built and maintained by the Nx team**.
-
-### WebStorm
-
-If you are using [WebStorm](https://www.jetbrains.com/webstorm/), you can install one of the available plugins:
-
-- [nx-webstorm](https://plugins.jetbrains.com/plugin/15000-nx-webstorm)
-- [Nx Console Idea](https://plugins.jetbrains.com/plugin/15101-nx-console-idea)
-
-These plugins are **NOT** built or maintained by the Nx team. They are maintained by independent community contributors.
-
-### Neovim
-
-If you are using [Neovim](https://neovim.io/), you can install [Equilibris/nx.nvim](https://github.com/Equilibris/nx.nvim) with your favorite package manager.
-
-This plugin is **NOT** built or maintained by the Nx team. They are maintained by independent community contributors.
-
-## Nx Console for VSCode
-
-![Nx Console logo](/shared/nx-console-logo.png)
-
-- [Install from the VSCode Marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
-- [Contribute on GitHub](https://github.com/nrwl/nx-console)
-
-![Nx Console screenshot](/shared/nx-console-screenshot.png)
-
-### True UI for Nx
-
-Nx Console is the UI for Nx. It works for any generator or any architect commands. Nx Console does not have a specific UI for, say, generating a component. Instead, Nx Console does what the command-line version of Nx does - it analyzes the same meta information to create the needed UI. This means that anything you can do with Nx, you can do with Nx Console. After all, Nx Console is the UI for Nx.
-
-### Useful for both experts and beginners
-
-Even though we started building Nx Console as a tool for experts, we also aimed to make Nx Console a great tool for developers who are new to development or Nx. You can create projects, interact with your editor, run generators and commands and install extensions without ever touching the terminal or having to install any node packages globally. Also, Nx Console highlights the properties you are likely to use for built-in generators and commands, so if you haven't used the CLI, you don't get overwhelmed.
-
-### Documentation
-
-#### Generate
-
-The `Generate` action allows you to choose a generator and then opens a form listing out all the options for that generator. As you make changes to the form, the generator is executed in `--dry-run` mode in a terminal so you can preview the results of running the generator in real time.
-
-{% youtube
-src="https://www.youtube.com/embed/-nUr66MWRiE"
-title="Nx Console Generate UI Form"
-width="100%" /%}
-
-**From the Command Palette**
-
-You can also launch the `Generate` action from the Command Palette (`⇧⌘P`) by selecting `nx: generate (ui)`.
-
-{% youtube
-src="https://www.youtube.com/embed/Sk2XjFwF8Zo"
-title="Nx Console Generate UI from Command Palette"
-width="100%" /%}
-
-You can even construct the generator options while staying entirely within the Command Palette. Use `⇧⌘P` to open the Command Palette, then select `nx: generate`. After choosing a generator, select any of the listed options to modify the generator command. When you're satisfied with the constructed command, choose the `Execute` command at the top of the list.
-
-{% youtube
-src="https://www.youtube.com/embed/q5NTTqRYq9c"
-title="Nx Console Generate with Command Palette"
-width="100%" /%}
-
-#### Run
-
-The `Run` action allows you to choose an executor command and then opens a form listing out all the options for that executor. The frequently used executor commands `build`, `serve`, `test`, `e2e` and `lint` also have their own dedicated actions.
-
-{% youtube
-src="https://www.youtube.com/embed/rNImFxo9gYs"
-title="Nx Console Run UI Form"
-width="100%" /%}
-
-**From the Command Palette**
-
-You can also construct the executor command options while staying entirely within the Command Palette. Use `⇧⌘P` to open the Command Palette, then select `nx: test`. After choosing a project, select any of the listed options to modify the executor command options. When you're satisfied with the constructed command, choose the `Execute` command at the top of the list.
-
-{% youtube
-src="https://www.youtube.com/embed/CsUkSyQcxwQ"
-title="Nx Console Run from Command Palette"
-width="100%" /%}
-
-#### Common Nx Commands
-
-You can also launch other common Nx commands with the options listed out in the Command Palette.
-
-{% youtube
-src="https://www.youtube.com/embed/v6Tso0lB6S4"
-title="Nx Console Affected"
-width="100%" /%}
-
-#### Projects
-
-Clicking on the name of any project navigates to that project's `project.json` file. Clicking on the name of any executor command navigates to that executor command's definition in the `project.json` file.
-
-Clicking the ![refresh-light.svg](./refresh-light.svg) icon next to the `PROJECTS` header repopulates the Projects pane from the `project.json` files.
-
-Clicking the ![folder-light.svg](./folder-light.svg) icon next to a project reveals that project's folder in the VSCode Explorer pane.
-
-Clicking the ![continue-light.svg](./continue-light.svg) icon next to an executor command executes that command without prompting for options.
-
-{% youtube
-src="https://www.youtube.com/embed/ve_N3unDqAg"
-title="Nx Console Projects Pane"
-width="100%" /%}
-
-#### Streamlining
-
-If you find yourself running the same command many times, here are few tips to save yourself some key strokes.
-
-**Rerun Last Task**
-
-If you want to rerun the last task with all the same options specified, bring up the Command Palette (`⇧⌘P`) and choose `Rerun Last Task`.
-
-**Keyboard Shortcuts**
-
-You can also set up custom tasks and assign keyboard shortcuts to them. In `.vscode/tasks.json` add a task like this:
-
-```json
-{
-  "label": "Test Affected",
-  "type": "shell",
-  "command": "nx affected --target=test"
-}
-```
-
-Then from the Command Palette (`⇧⌘P`) choose `Preferences: Open Keyboard Shortcuts (JSON)`. Then add the following shortcut:
-
-```json
-{
-  "key": "ctrl+cmd+t",
-  "command": "workbench.action.tasks.runTask",
-  "args": "Test Affected"
-}
-```
-
-Now, pressing `^⌘T` will run `nx affected --target=test`.
-
-Here is more information on [VSCode tasks](https://code.visualstudio.com/docs/editor/tasks) and [keyboard shortcuts](https://code.visualstudio.com/docs/getstarted/keybindings).

docs/shared/core-features/automate-updating-dependencies.md

@@ -0,0 +1,74 @@
+# Automate Updating Dependencies
+
+The Nx CLI provides the `migrate` command to help you stay up to date with the latest version of Nx.
+
+Not only does `nx migrate` update you to the latest version of Nx, but it also updates the versions of dependencies that we support and test such as Jest and Cypress. You can also use the `migrate` command to update any Nx plugin.
+
+## Migrating to the latest Nx version
+
+Migration happens in three steps:
+
+- The installed dependencies are updated including the `package.json` (and `node_modules`).
+- The source code in the repo is updated to match the new versions of packages in `package.json`.
+- Remove the `migrations.json` file
+
+### Step 1: Updating dependencies and generating migrations
+
+First, run the `migrate` command:
+
+```bash
+nx migrate latest # same as nx migrate @nrwl/workspace@latest
+```
+
+You can also specify the name of the package and the version:
+
+```bash
+nx migrate @nrwl/workspace@version # you can also specify version
+```
+
+This fetches the specified version of the `@nrwl/workspace` package, analyzes the dependencies and fetches all the dependent packages. The process keeps going until all the dependencies are resolved. This results in:
+
+- The `package.json` being updated
+- A `migrations.json` being generated if there are pending migrations.
+
+At this point, no packages have been installed, and no other files have been touched.
+
+Now, you can inspect `package.json` to see if the changes make sense. Sometimes the migration can update a package to a version that is either not allowed or conflicts with another package. Feel free to manually apply the desired adjustments.
+
+{% callout type="note" title="Inspect the changes" %}
+At this stage, after inspecting the `package.json`, you may wish to manually run the appropriate install command for your workspace (e.g. `npm install`, `yarn`, or `pnpm install`) but in the next step `nx migrate --run-migrations` will also run this automatically for you.
+{% /callout %}
+
+### Step 2: Running migrations
+
+The next step in the process involves using the `migrate` CLI in order to apply the migrations that were generated in `migrations.json` in the previous step.
+
+Each Nx plugin is able to provide a set of migrations which are relevant to particular versions of the package, and so `migrations.json` will only contain migrations which are appropriate for the update you are currently applying.
+
+The common case is that you will simply apply all migrations from the generated JSON file, exactly as they were generated in the previous step, by running:
+
+```bash
+nx migrate --run-migrations
+```
+
+This will update your source code in your workspace in accordance with the implementation of the various migrations which ran and all the changes will be unstaged ready for you to review and commit yourself.
+
+### Step 3: Cleaning up
+
+After you run all the migrations, you can remove `migrations.json` and commit any outstanding changes.
+
+Note: You may want to keep the `migrations.json` until every branch that was created before the migration has been merged. Leaving the `migrations.json` in place allows devs to run `nx migrate --run-migrations` to apply the same migration process to their newly merged code as well.
+
+## Problems?
+
+If you can't run `nx migrate --run-migrations` all in one step, try the tips in [Advanced Update Process](/recipe/advanced-update)
+
+## Related Documentation
+
+### Recipes
+
+- [Advanced Update Process](/recipe/advanced-update)
+
+### Reference
+
+- [migrate command](/nx/migrate)

docs/shared/core-features/cache-task-results.md

@@ -0,0 +1,95 @@
+# Cache Task Results
+
+It's costly to rebuild and retest the same code over and over again. Nx uses a computation cache to never rebuild the
+same code twice.
+
+## Setup
+
+Nx has the most sophisticated and battle-tested computation caching system. It knows when the task you are
+about to run has been executed before, so it can use the cache to restore the results of running that task.
+
+To enable caching for `build` and `test`, edit the `cacheableOperations` property in `nx.json` to include the `build` and `test` tasks:
+
+```json title="nx.json"
+{
+  "tasksRunnerOptions": {
+    "default": {
+      "runner": "nx/tasks-runners/default",
+      "options": {
+        "cacheableOperations": ["build", "test"]
+      }
+    }
+  }
+}
+```
+
+{% callout type="note" title="Cacheable operations need to be side effect free" %}
+This means that given the same input they should always result in
+the same output. As an example, e2e test runs that hit the backend API cannot be cached as the backend might influence
+the result of the test run.
+{% /callout %}
+
+Now, run the following command twice. The second time the operation will be instant:
+
+```bash
+nx test header
+```
+
+```bash title="Terminal Output"
+> nx run header:test  [existing outputs match the cache, left as is]
+
+
+> header@0.0.0 test
+> jest
+
+ PASS  src/Header.spec.tsx
+  ✓ renders header (14 ms)
+
+Test Suites: 1 passed, 1 total
+Tests:       1 passed, 1 total
+Snapshots:   0 total
+Time:        0.528 s, estimated 2 s
+Ran all test suites.
+
+ ————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
+
+ >  NX   Successfully ran target test for project header (4ms)
+
+   Nx read the output from the cache instead of running the command for 1 out of 1 tasks.
+```
+
+## Advanced Caching
+
+For a more in-depth understanding of the caching implementation and to fine-tune the caching for your repo, read [How Caching Works](/concepts/how-caching-works).
+
+## Local Computation Caching
+
+By default, Nx uses a local computation cache. Nx stores the cached values only for a week, after which they
+are deleted. To clear the cache run [`nx reset`](/nx/reset), and Nx will create a new one the next time it tries to access it.
+
+## Distributed Computation Caching
+
+The computation cache provided by Nx can be distributed across multiple machines. You can either build an implementation
+of the cache or use Nx Cloud. Nx Cloud is an app that provides a fast and zero-config implementation of distributed
+caching. It's completely free for OSS projects and for most closed-sourced
+projects ([read more here](https://dev.to/nrwl/more-time-saved-for-free-with-nx-cloud-4a2j)).
+
+You can connect your workspace to Nx Cloud by running:
+
+```bash
+npx nx connect-to-nx-cloud
+```
+
+Learn more about Nx Cloud at [https://nx.app](https://nx.app).
+
+## Related Documentation
+
+### Concepts
+
+- [How Caching Works](/concepts/how-caching-works)
+
+### Reference
+
+- [--skip-nx-cache](/nx/affected#skip-nx-cache)
+- [reset command](/nx/reset)
+- [tasks-runner-options](/reference/nx-json#tasks-runner-options)

docs/shared/core-features/distribute-task-execution.md

@@ -0,0 +1,65 @@
+# Distribute Task Execution (DTE)
+
+Nx supports running commands across multiple machines. You can either set it up by hand (by using batching or binning) or use Nx Cloud.
+
+[Read the comparison of the two approaches.](https://blog.nrwl.io/distributing-ci-binning-and-distributed-task-execution-632fe31a8953?source=friends_link&sk=5120b7ff982730854ed22becfe7a640a)
+
+## Set up
+
+To distribute your task execution, you need to (1) connect to Nx Cloud and (2) enable DTE in your CI workflow. Each of these steps can be enabled with a single command:
+
+```bash title="1. Connect to Nx Cloud"
+nx connect-to-nx-cloud
+```
+
+```bash title="2. Enable DTE in CI"
+nx generate @nrwl/workspace:ci-workflow --ci=github
+```
+
+The `--ci` flag can be `github`, `circleci` or `azure`. For more details on setting up DTE, read [this guide](https://nx.dev/nx-cloud/set-up/set-up-dte).
+
+## CI Execution Flow
+
+There are two main parts to the CI set up:
+
+1. The main job that controls what is going to be executed
+2. The agent jobs that actually execute the tasks
+
+The main job execution flow looks like this:
+
+```yml
+# Coordinate the agents to run the tasks
+- npx nx-cloud start-ci-run
+# Run any commands you want here
+- nx affected --target=lint
+- nx affected --target=test
+- nx affected --target=build
+# Stop any run away agents
+- npx nx-cloud stop-all-agents
+```
+
+The agent job execution flow is very simple:
+
+```yml
+# Wait for tasks to execute
+- npx nx-cloud start-agent
+```
+
+## Illustrated Guide
+
+For more details about how distributed task execution works, check out the [illustrated guide](../concepts/dte) by Nrwlian [Nicole Oliver](https://twitter.com/nixcodes).
+
+[![how does distributed task execution work in Nx Cloud?](../images/dte/how-does-dte-work.jpeg)](../concepts/dte)
+
+## Related Documentation
+
+- [Nx Cloud Documentation](/nx-cloud/intro/what-is-nx-cloud)
+- [Nx Cloud Main Site](https://nx.app)
+
+### Recipes
+
+- [CI Setup](/recipes/ci-setup)
+
+### Reference
+
+- [connect-to-nx-cloud command](/nx/connect-to-nx-cloud)

docs/shared/core-features/enforce-project-boundaries.md

@@ -0,0 +1,180 @@
+# Enforce Project Boundaries
+
+If you partition your code into well-defined cohesive units, even a small organization will end up with a dozen apps and dozens or hundreds of libs. If all of them can depend on each other freely, chaos will ensue, and the workspace will become unmanageable.
+
+To help with that Nx uses code analysis to make sure projects can only depend on each other's well-defined public API. It also allows you to declaratively impose constraints on how projects can depend on each other.
+
+## Project APIs
+
+Nx provides an `enfore-module-boundaries` eslint rule that enforces the public API of projects in the repo. Each project defines its public API in an `index.ts` (or `index.js`) file. If another project tries to import a variable from a file deep within a different project, an error will be thrown during linting.
+
+To set up the lint rule, install these dependencies:
+
+```bash
+npm i @nrwl/eslint-plugin-nx @nrwl/devkit
+```
+
+And configure the rule in your root `.eslintrc.json` file:
+
+```jsonc
+{
+  "plugins": ["@nrwl/nx"],
+  // ...
+  "rules": {
+    "@nrwl/nx/enforce-module-boundaries": [
+      "error",
+      {
+        /* options */
+      }
+    ]
+  }
+}
+```
+
+## Tags
+
+Nx comes with a generic mechanism for expressing constraints on project dependencies: tags.
+
+First, use your project configuration (in `project.json` or `package.json`) to annotate your projects with `tags`. In this example, we will use three tags: `scope:client`. `scope:admin`, `scope:shared`.
+
+{% tabs %}
+{% tab label="package.json" %}
+
+```jsonc
+// client/package.json
+{
+  // ... more project configuration here
+  "nx": {
+    "tags": ["scope:client"]
+  }
+}
+```
+
+```jsonc
+// admin/package.json
+{
+  // ... more project configuration here
+  "nx": {
+    "tags": ["scope:admin"]
+  }
+}
+```
+
+```jsonc
+// utils/package.json
+{
+  // ... more project configuration here
+  "nx": {
+    "tags": ["scope:shared"]
+  }
+}
+```
+
+{% /tab %}
+{% tab label="project.json" %}
+
+```jsonc
+// client/project.json
+{
+  // ... more project configuration here
+  "tags": ["scope:client"]
+}
+```
+
+```jsonc
+// admin/project.json
+{
+  // ... more project configuration here
+  "tags": ["scope:admin"]
+}
+```
+
+```jsonc
+// utils/project.json
+{
+  // ... more project configuration here
+  "tags": ["scope:shared"]
+}
+```
+
+{% /tab %}
+{% /tabs %}
+
+Next you should update your root lint configuration:
+
+- If you are using **ESLint** you should look for an existing rule entry in your root `.eslintrc.json` called `"@nrwl/nx/enforce-module-boundaries"` and you should update the `"depConstraints"`:
+
+```jsonc
+{
+  // ... more ESLint config here
+
+  // @nrwl/nx/enforce-module-boundaries should already exist within an "overrides" block using `"files": ["*.ts", "*.tsx", "*.js", "*.jsx",]`
+  "@nrwl/nx/enforce-module-boundaries": [
+    "error",
+    {
+      "allow": [],
+      // update depConstraints based on your tags
+      "depConstraints": [
+        {
+          "sourceTag": "scope:shared",
+          "onlyDependOnLibsWithTags": ["scope:shared"]
+        },
+        {
+          "sourceTag": "scope:admin",
+          "onlyDependOnLibsWithTags": ["scope:shared", "scope:admin"]
+        },
+        {
+          "sourceTag": "scope:client",
+          "onlyDependOnLibsWithTags": ["scope:shared", "scope:client"]
+        }
+      ]
+    }
+  ]
+
+  // ... more ESLint config here
+}
+```
+
+With these constraints in place, `scope:client` projects can only depend on other `scope:client` projects or on `scope:shared` projects. And `scope:admin` projects can only depend on other `scope:admin` projects or on `scope:shared` projects. So `scope:client` and `scope:admin` cannot depend on each other.
+
+Projects without any tags cannot depend on any other projects. If you add the following, projects without any tags will be able to depend on any other project.
+
+```json
+{
+  "sourceTag": "*",
+  "onlyDependOnLibsWithTags": ["*"]
+}
+```
+
+If you try to violate the constraints, you will get an error when linting:
+
+```bash
+A project tagged with "scope:admin" can only depend on projects
+tagged with "scoped:shared" or "scope:admin".
+```
+
+## Related Documentation
+
+### Concepts
+
+- [Using Nx at Enterprises](/more-concepts/monorepo-nx-enterprise)
+- [Applications and Libraries](/more-concepts/applications-and-libraries)
+- [Creating Libraries](/more-concepts/creating-libraries)
+- [Library Types](/more-concepts/library-types)
+- [Grouping Libraries](/more-concepts/grouping-libraries)
+
+### Recipes
+
+- [Using ESLint in Nx Workspaces](/recipe/eslint)
+- [Ban Dependencies with Certain Tags](/recipe/ban-dependencies-with-tags)
+- [Tag in Multiple Dimensions](/recipe/tag-multiple-dimensions)
+- [Ban External Imports](/recipe/ban-external-imports)
+- [Tags Allow List](/recipe/tags-allow-list)
+
+### Reference
+
+- [workspace-lint command](/nx/workspace-lint)
+- [format:check](/nx/format-check)
+- [format:write](/nx/format-write)
+- [nx.json workspaceLayout property](/reference/nx-json#workspace-layout)
+- [nxignore file](/reference/nxignore)

docs/shared/core-features/explore-graph.md

@@ -0,0 +1,34 @@
+# Explore the Graph
+
+For Nx to run tasks quickly and correctly, it creates a graph of the dependencies between all the projects in the repository. Exploring this graph visually can be useful to understand why Nx is behaving in a certain way and to get a high level view of your code architecture.
+
+To launch the project graph visualization run:
+
+```bash
+nx graph
+```
+
+This will open a browser window with an interactive representation of the project graph of your current codebase. Viewing the entire graph can be unmanageable even for smaller repositories, so there are several ways to narrow the focus of the visualization down to the most useful part of the graph at the moment.
+
+1. Focus on a specific project and then use the proximity and group by folder controls to modify the graph around that project.
+2. Use the search bar to find all projects with names that contain a certain string.
+3. Manually hide or show projects in the sidebar
+
+Once the graph is displayed, you can click on an individual dependency link to find out what specific file(s) created that dependency.
+
+![Project Graph screenshot](../images/project-graph.png)
+
+## Related Documentation:
+
+### Concepts
+
+- [How the Project Graph is Built](/more-concepts/how-project-graph-is-built)
+
+### Recipes
+
+- [Export Project Graph to JSON](/recipe/export-project-graph)
+- [Resolve Circular Dependencies](/recipe/resolve-circular-dependencies)
+
+### Reference
+
+- [Graph Command](/nx/dep-graph)

docs/shared/core-features/integrate-with-editors.md

@@ -0,0 +1,34 @@
+# Integrate with Editors
+
+Nx Console is the UI for Nx. It works for any generator or any architect commands. Nx Console does not have a specific UI for, say, generating a component. Instead, Nx Console does what the command-line version of Nx does - it analyzes the same meta information to create the needed UI. This means that anything you can do with Nx, you can do with Nx Console.
+
+## Download
+
+### VSCode
+
+If you are using [VSCode](https://code.visualstudio.com/), you can install the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) from Marketplace. The Nx Console VSCode Plugin is **built and maintained by the Nx team**.
+
+![Nx Console logo](/shared/nx-console-logo.png)
+
+- [Install from the VSCode Marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
+- [Contribute on GitHub](https://github.com/nrwl/nx-console)
+
+![Nx Console screenshot](/shared/nx-console-screenshot.png)
+
+### WebStorm
+
+If you are using [WebStorm](https://www.jetbrains.com/webstorm/), you can install one of the available plugins:
+
+- [nx-webstorm](https://plugins.jetbrains.com/plugin/15000-nx-webstorm)
+- [Nx Console Idea](https://plugins.jetbrains.com/plugin/15101-nx-console-idea)
+
+These plugins are **NOT** built or maintained by the Nx team. They are maintained by independent community contributors.
+
+## Related Documentation
+
+### Recipes
+
+- [Nx Console Generate Command](/recipe/console-generate-command)
+- [Nx Console Run Command](/recipe/console-run-command)
+- [Nx Console Project Pane](/recipe/console-project-pane)
+- [Nx Console Keyboard Shortcuts](/recipe/console-shortcuts)

docs/shared/core-features/run-tasks.md

@@ -0,0 +1,113 @@
+# Run Tasks
+
+Monorepos can have hundreds or even thousands of projects, so being able to run actions against all (or some) of
+them is a key feature of a tool like Nx.
+
+## Definitions
+
+- **Command -** anything the developer types into the terminal (e.g., `nx run header:build`).
+- **Target -** the name of an action taken on a project (e.g., `build`)
+- **Task -** an invocation of a target on a specific project (e.g., `header:build`).
+
+## Define Tasks
+
+For these examples, we'll imagine a repo that has three projects: `myapp`, `header` and `footer`. `myapp` is a deployable app and uses the `header` and `footer` libraries.
+
+Each project has the `test` and `build` targets defined. Tasks can be defined as npm scripts in a project's `package.json` file or as targets in a `project.json` file:
+
+{% tabs %}
+{% tab label="package.json" %}
+
+```json
+{
+  "scripts": {
+    "build": "webpack -c webpack.conf.js",
+    "test": "jest --coverage"
+  }
+}
+```
+
+{% /tab %}
+{% tab label="project.json" %}
+
+```json
+{
+  "targets": {
+    "build": {
+      "executor": "nx:run-commands",
+      "options": {
+        "command": "webpack -c webpack.conf.js"
+      }
+    },
+    "test": {
+      "executor": "@nrwl/jest:jest",
+      "options": {
+        "codeCoverage": true
+      }
+    }
+  }
+}
+```
+
+{% /tab %}
+{% /tabs %}
+
+## Run a Single Task
+
+To run the `test` target on the `header` project run this command:
+
+```bash
+npx nx test header
+```
+
+## Run Everything
+
+To run the `build` target for all projects in the repo, run:
+
+```bash
+npx nx run-many --target=build
+```
+
+This will build the projects in the right order: `footer` and `header` and then `myapp`.
+
+```bash title="Terminal Output"
+    ✔  nx run header:build (501ms)
+    ✔  nx run footer:build (503ms)
+    ✔  nx run myapp:build (670ms)
+
+ —————————————————————————————————————————————————————————————————————————————
+
+ >  NX   Successfully ran target build for 3 projects (1s)
+```
+
+Note that Nx doesn't care what each of the build scripts does. The name `build` is also **not** special: it's simply
+the name of the target.
+
+## Run Tasks Affected by a PR
+
+You can also run a command for all the projects affected in your PR like this:
+
+```bash
+npx nx affected --target=test
+```
+
+Learn more about the affected command [here](/concepts/affected).
+
+## Control How Tasks Run
+
+For more control over the order tasks are executed, edit the [Task Pipeline Configuration](../concepts/task-pipeline-configuration).
+
+To speed up your task execution, learn how to [Cache Task Results](./cache-task-results) and [Distribute Task Execution](./distribute-task-execution)
+
+## Related Documentation
+
+### Concepts
+
+- [Task Pipeline Configuration](/concepts/task-pipeline-configuration)
+- [How Affected Works](/concepts/affected)
+
+### Reference
+
+- [run command](/nx/run)
+- [run-many command](/nx/run-many)
+- [affected command](/nx/affected)

docs/shared/core-tutorial/01-create-blog.md

@@ -2,6 +2,15 @@
 
 In this tutorial you create multiple projects in a monorepo and take advantage of the core Nx features with a minimum of configuration.
 
+## Contents:
+
+- [1 - Create Blog](/core-tutorial/01-create-blog)
+- [2 - Create CLI](/core-tutorial/02-create-cli)
+- [3 - Share Assets](/core-tutorial/03-share-assets)
+- [4 - Build Affected Projects](/core-tutorial/04-build-affected-projects)
+- [5 - Automatically Detect Dependencies](/core-tutorial/05-auto-detect-dependencies)
+- [6 - Summary](/core-tutorial/06-summary)
+
 ## Create a New Workspace
 
 **Start by creating a new workspace.**

docs/shared/core-tutorial/02-create-cli.md

@@ -61,7 +61,7 @@ There are a few reasons to choose `project.json` for the CLI project.
 2. As the scripts in the project get more complex, `project.json` tends to have a flatter structure - rather than a long horizontal line in `package.json` with all the cli flags.
 3. The easiest method to run scripts provided in Nx plugins is to use a `project.json` file.
 
-All of these reasons are matters of preference. After this tutorial, you should have enough of a taste of both styles to make an informed decision about which format you prefer. Read more about [package.json configuration](/configuration/packagejson) and [project.json configuration](configuration/projectjson) in their respective guides.
+All of these reasons are matters of preference. After this tutorial, you should have enough of a taste of both styles to make an informed decision about which format you prefer. Read more about [project configuration](/reference/project-configuration).
 
 ### Project.json syntax
 

docs/shared/core-tutorial/06-summary.md

@@ -17,6 +17,5 @@ You created a workspace from scratch in this tutorial, but if you would like to
 
 **Dive Deep:**
 
-- [Nx CLI](/using-nx/nx-cli)
-- [Computation Caching](/using-nx/caching)
-- [Rebuilding What is Affected](/using-nx/affected)
+- [Computation Caching](/concepts/how-caching-works)
+- [Rebuilding What is Affected](/concepts/affected)

docs/shared/cypress-plugin.md

@@ -98,7 +98,7 @@ There are a handful of ways to pass environment variables to Cypress, but the mo
 
 Create a `cypress.env.json` file in the projects root i.e. `apps/my-cool-app-e2e/cypress.env.json`. Cypress will automatically pick up this file. This method is helpful for configurations that you want to not commit. Just don't forget to add the file to the `.gitignore` and add documentation so people in your repo know what values to popluate in their local copy of the `cypress.env.json` file.
 
-Using [@nrwl/cypress:cypress](/packages/cypress/executors/cypress) env executor option is a good way to add values you want to define that you don't mine commit to the repository, such as a base API url. You can leverage [target configurations](/configuration/projectjson#targets) to define different values as well.
+Using [@nrwl/cypress:cypress](/packages/cypress/executors/cypress) env executor option is a good way to add values you want to define that you don't mine commit to the repository, such as a base API url. You can leverage [target configurations](/reference/project-configuration#targets) to define different values as well.
 
 Optionally, you can pass environment variables via the commandline with the `--env` flag.
 

docs/shared/distributed-builds.md

@@ -1,18 +0,0 @@
-# Distributed Builds and Distributed CI
-
-Nx uses computation caching and code change analysis (`affected:*` commands) to limit the number of things that have to be rebuilt and retested. This can drastically reduce the average CI time.
-
-But regardless of how smart Nx is, there will be some large changes affecting the whole codebase. The only way to keep those fast as your repository keeps growing is to build and test them using multiple machines/agents.
-
-There are several ways to distribute your CI across multiple machines.
-
-The easiest way is to use Nx Cloud. Learn more about [configuring your CI](/nx-cloud/set-up/set-up-dte#cicd-examples) environment using Nx Cloud with [Distributed Caching](/nx-cloud/set-up/set-up-caching) and [Distributed Task Execution](/nx-cloud/set-up/set-up-dte) in the Nx Cloud docs.
-
-But you can also set up distribution manually using the `print-affected` and `run-many` commands.
-
-{% github-repository url="https://github.com/nrwl/nx-azure-build" /%}
-{% github-repository url="https://github.com/nrwl/nx-jenkins-build" /%}
-
-The Azure example is very easy to port to other CI providers (e.g., CircleCI, GitLab).
-
-Read [Distributing CI: Binning and Distributed Task Execution](https://blog.nrwl.io/distributing-ci-binning-and-distributed-task-execution-632fe31a8953?source=friends_link&sk=5120b7ff982730854ed22becfe7a640a) to learn about the two approaches.

docs/shared/eslint-plugin-nx.md

@@ -75,5 +75,9 @@ You can use `enforce-module-boundaries` rule by adding it to your ESLint rules c
 
 Read more about proper usage of this rule:
 
-- [Imposing Constraints on the Project Graph](/structure/monorepo-tags)
+- [Enforce Project Boundaries](/core-features/enforce-project-boundaries)
+- [Ban Dependencies with Certain Tags](/recipe/ban-dependencies-with-tags)
+- [Tag in Multiple Dimensions](/recipe/tag-multiple-dimensions)
+- [Ban External Imports](/recipe/ban-external-imports)
+- [Tags Allow List](/recipe/tags-allow-list)
 - [Taming Code Organization with Module Boundaries in Nx](https://blog.nrwl.io/mastering-the-project-boundaries-in-nx-f095852f5bf4)

docs/shared/express-plugin.md

@@ -69,7 +69,7 @@ nx build <project-name>
 ```
 
 Build artifacts will be found in the `dist` directory under `apps/<project-name>` by default. Customize the build
-configuration by editing `outputPath` in the [project configuration](/configuration/projectjson).
+configuration by editing `outputPath` in the [project configuration](/reference/project-configuration).
 
 ### Waiting for Other Tasks
 

docs/shared/extending-nx/project-graph-plugins.md

@@ -120,7 +120,7 @@ If a file hasn't changed since the last invocation, it doesn't need to be reanal
 
 ## Visualizing the Project Graph
 
-You can then visualize the project graph as described [here](/structure/dependency-graph). However, there is a cache that Nx uses to avoid recalculating the project graph as much as possible. As you develop your project graph plugin, it might be a good idea to set the following environment variable to disable the project graph cache: `NX_CACHE_PROJECT_GRAPH=false`.
+You can then visualize the project graph as described [here](/core-features/explore-graph). However, there is a cache that Nx uses to avoid recalculating the project graph as much as possible. As you develop your project graph plugin, it might be a good idea to set the following environment variable to disable the project graph cache: `NX_CACHE_PROJECT_GRAPH=false`.
 
 It might also be a good idea to ensure that the dep graph is not running on the nx daemon by setting `NX_DAEMON=false`, as this will ensure you will be able to see any `console.log` statements you add as you're developing.
 

docs/shared/generators/modifying-files.md

@@ -4,7 +4,7 @@ Modifying existing files is an order of magnitude harder than creating new files
 
 ## Compose Existing Generators
 
-If you can compose together existing generators to modify the files you need, you should take that approach. See [Composing Generators](/generators/composing-generators) for more information.
+If you can compose together existing generators to modify the files you need, you should take that approach. See [Composing Generators](/recipe/composing-generators) for more information.
 
 ## Modify JSON Files
 

docs/shared/getting-started/intro.md

@@ -16,13 +16,12 @@ the boilerplate. However, the vast majority of the features will work the same w
 
 ## Getting Started
 
-- [Using Nx without plugins](/getting-started/nx-core) will help you understand the core of Nx.
-- [Adding Nx to an existing monorepo](/migration/adding-to-monorepo) will show how to add Nx to an existing monorepo.
-- [Mental model](/using-nx/mental-model) is a good starting point for those who like to understand things theoretically first.
-- [Nx core tutorial](/core-tutorial/01-create-blog) to start learning how to use Nx.
+- [Nx core tutorial](/core-tutorial/01-create-blog) will help you understand the core of Nx.
+- [Adding Nx to an existing monorepo](/recipe/adding-to-monorepo) shows several paths to adopting Nx in your organization.
+- [Mental model](/concepts/mental-model) is a good starting point for those who like to understand things theoretically first.
 
-If you want to use Nx plugins to really level up your productivity, pick one of the following guides:
+If you want to use Nx plugins to really level up your productivity, pick one of the following tutorials:
 
-- [Nx and TypeScript](/getting-started/nx-and-typescript)
-- [Nx and React](/getting-started/nx-and-react)
-- [Nx and Angular](/getting-started/nx-and-angular)
+- [Nx and Node](/node-tutorial/01-create-application)
+- [Nx and React](/react-tutorial/01-create-application)
+- [Nx and Angular](/angular-tutorial/01-create-application)

docs/shared/getting-started/nx-and-react.md

@@ -1,34 +0,0 @@
-# Nx and React
-
-Nx is a smart, fast and extensible build system with first class monorepo support and powerful integrations. It has a powerful core and a rich plugin ecosystem.
-
-## Making Things Fast
-
-If you're only interested in improving the performance of your monorepo by using Nx's [affected:\* commands](/using-nx/affected), [computation cache](/using-nx/caching), and [distributed task execution](/using-nx/dte), then you don't need to use any plugins. Everything will work the same way whether your monorepo has React, Vue, Svelte, or even Go, Rust, or Java apps. Nx is technology-agnostic.
-
-Check out the following guides to get started:
-
-- [Using Nx without plugins](/getting-started/nx-core)
-- [Adding Nx to an existing monorepo](/migration/adding-to-monorepo)
-- [Migrating from CRA](/migration/migration-cra)
-
-{% callout type="note" title="Going deeper" %}
-It is also a good idea to read the [mental model guide](/using-nx/mental-model) to understand how Nx works.
-{% /callout %}
-
-## Nx and React Plugins
-
-Nx plugins help you develop [React](/packages/react) applications with fully integrated support for modern tools
-and libraries like [Jest](/packages/jest), [Cypress](/packages/cypress),
-[Storybook](/packages/storybook), [ESLint](/packages/linter), and more. Nx also supports React
-frameworks like [Next.js](/packages/next), Remix, and has great support for [React Native](/packages/react-native).
-
-{% youtube
-src="https://www.youtube.com/embed/sNz-4PUM0k8"
-title="Scale your React development with Nx"
-width="100%" /%}
-
-Check out the following to get started:
-
-- [React: Interactive Nx Tutorial (with videos)](/react-tutorial/01-create-application)
-- [Free Nx Course on Egghead: Scale React Development with Nx](https://egghead.io/playlists/scale-react-development-with-nx-4038)

docs/shared/getting-started/nx-setup.md

@@ -1,84 +0,0 @@
-# Nx Setup
-
-## Set up a New Nx Workspace
-
-Run the following command to create a new workspace.
-
-```bash
-# pass @latest in case npx cached an older version of create-nx-workspace
-npx create-nx-workspace@latest
-```
-
-When creating a workspace, you will have to choose a preset, which will preconfigure a few things for you.
-
-```bash
-# create an empty workspace set up for building applications
-npx create-nx-workspace --preset=apps
-
-# create an empty workspace set up for building packages
-npx create-nx-workspace --preset=core
-
-# create an empty workspace set up for building packages with the @nrwl/js plugin installed
-npx create-nx-workspace --preset=ts
-```
-
-Some presets set up applications, e2e tests, etc.
-
-```bash
-npx create-nx-workspace --preset=react
-npx create-nx-workspace --preset=react-native
-npx create-nx-workspace --preset=angular
-```
-
-For more information about possible options see the [create-nx-workspace command](/nx/create-nx-workspace).
-
-## Add Nx to an Existing Project
-
-If you have an existing Lerna or Yarn monorepo, you can gain the benefits of Nx's computation cache and distributed task execution without modifying the file structure by running this command:
-
-```bash
-npx add-nx-to-monorepo
-```
-
-If you have an existing Create React App project, you can gain the benefits of Nx's computation cache and distributed task execution without modifying the file structure by running this command:
-
-```bash
-npx cra-to-nx
-```
-
-For more information on adding Nx to an existing repository see the [migration guide](/migration/migration-cra)
-
-## Install Nx CLI
-
-To make the developer experience nicer, you may want to install the Nx CLI globally.
-
-```bash
-npm install -g nx
-```
-
-## Folder Structure
-
-Nx can be added to any workspace, so there is no fixed folder structure. However, if you use one of the existing presets, you will likely see something like this:
-
-```treeview
-myorg/
-├── apps/
-├── libs/
-├── tools/
-├── workspace.json
-├── nx.json
-├── package.json
-└── tsconfig.base.json
-```
-
-`/apps/` contains the application projects. This is the main entry point for a runnable application. We recommend keeping applications as light-weight as possible, with all the heavy lifting being done by libraries that are imported by each application.
-
-`/libs/` contains the library projects. There are many kinds of libraries, and each library defines its own external API so that boundaries between libraries remain clear.
-
-`/tools/` contains scripts that act on your code base. This could be database scripts, [custom executors](/executors/creating-custom-builders), or [workspace generators](/generators/workspace-generators).
-
-`/workspace.json` lists every project in your workspace. (this file is optional)
-
-`/nx.json` configures the Nx CLI itself. It tells Nx what needs to be cached, how to run tasks etc.
-
-`/tsconfig.base.json` sets up the global TypeScript settings and creates aliases for each library to aid when creating TS/JS imports.

docs/shared/guides/customize-webpack.md

@@ -69,7 +69,7 @@ module.exports = (config, context) => {
 
 ## Module Federation
 
-If you use the [Module Federation](/module-federation/faster-builds) support from `@nrwl/angular` or `@nrwl/react` then
+If you use the [Module Federation](/recipe/faster-builds) support from `@nrwl/angular` or `@nrwl/react` then
 you can customize your webpack configuration as follows.
 
 ```typescript

docs/shared/guides/define-environment-variables.md

@@ -0,0 +1,78 @@
+# Define Environment Variables
+
+Environment variables are global system variables accessible by all the processes running under the Operating System (OS).
+Environment variables are useful to store system-wide values such as the directories to search for executable programs
+(PATH), OS version, Network Information, and custom variables. These env variables are passed at build time and used at
+the runtime of an app.
+
+This guide is divided into two sections:
+
+- [Define Environment Variables](#define-environment-variables)
+  - [Setting environment variables](#setting-environment-variables)
+    - [Pointing to custom env files](#pointing-to-custom-env-files)
+    - [Ad-hoc variables](#ad-hoc-variables)
+      [Angular](#using-environment-variables-in-angular-applications)
+
+## Setting environment variables
+
+By default, Nx will load any environment variables you place in the following files:
+
+1. `apps/my-app/.local.env`
+2. `apps/my-app/.env.local`
+3. `apps/my-app/.env`
+4. `.local.env`
+5. `.env.local`
+6. `.env`
+
+{% callout type="warning" title="Order is important" %}
+Nx will move through the above list, ignoring files it can't find, and loading environment variables
+into the current process for the ones it can find. If it finds a variable that has already been loaded into the process,
+it will ignore it. It does this for two reasons:
+
+1. Developers can't accidentally overwrite important system level variables (like `NODE_ENV`)
+2. Allows developers to create `.env.local` or `.local.env` files for their local environment and override any project
+   defaults set in `.env`
+
+For example:
+
+1. `apps/my-app/.env.local` contains `NX_API_URL=http://localhost:3333`
+2. `apps/my-app/.env` contains `NX_API_URL=https://api.example.com`
+3. Nx will first load the variables from `apps/my-app/.env.local` into the process. When it tries to load the variables
+   from `apps/my-app/.env`, it will notice that `NX_API_URL` already exists, so it will ignore it.
+
+We recommend nesting your **app** specific `env` files in `apps/your-app`, and creating workspace/root level `env` files
+for workspace-specific settings (like the [Nx Cloud token](/concepts/how-caching-works#distributed-computation-caching)).
+{% /callout %}
+
+### Pointing to custom env files
+
+If you want to load variables from `env` files other than the ones listed above:
+
+1. Use the [env-cmd](https://www.npmjs.com/package/env-cmd) package: `env-cmd -f .qa.env nx serve`
+2. Use the `envFile` option of the [run-commands](/packages/nx/executors/run-commands#envfile) builder and execute your command inside of the builder
+
+### Ad-hoc variables
+
+You can also define environment variables in an ad-hoc manner using support from your OS and shell.
+
+**Unix systems**
+
+In Unix systems, we need to set the environment variables before calling a command.
+
+Let's say that we want to define an API URL for the application to use:
+
+```bash
+NX_API_URL=http://localhost:3333 nx build myapp
+```
+
+**Windows (cmd.exe)**
+
+```bash
+set "NX_API_URL=http://localhost:3333" && nx build myapp
+```
+
+**Windows (Powershell)**
+
+```bash
+($env:NX_API_URL = "http://localhost:3333") -and (nx build myapp)
+```

docs/shared/guides/environment-variables.md

@@ -1,273 +0,0 @@
-# Environment Variables
-
-Environment variables are global system variables accessible by all the processes running under the Operating System (OS).
-Environment variables are useful to store system-wide values such as the directories to search for executable programs
-(PATH), OS version, Network Information, and custom variables. These env variables are passed at build time and used at
-the runtime of an app.
-
-This guide is divided into two sections:
-
-1. [Setting environment variables](#setting-environment-variables)
-2. Using environment variables in [React](#using-environment-variables-in-react-applications) and
-   [Angular](#using-environment-variables-in-angular-applications)
-
-## Setting environment variables
-
-By default, Nx will load any environment variables you place in the following files:
-
-1. `apps/my-app/.local.env`
-2. `apps/my-app/.env.local`
-3. `apps/my-app/.env`
-4. `.local.env`
-5. `.env.local`
-6. `.env`
-
-{% callout type="warning" title="Order is important" %}
-Nx will move through the above list, ignoring files it can't find, and loading environment variables
-into the current process for the ones it can find. If it finds a variable that has already been loaded into the process,
-it will ignore it. It does this for two reasons:
-
-1. Developers can't accidentally overwrite important system level variables (like `NODE_ENV`)
-2. Allows developers to create `.env.local` or `.local.env` files for their local environment and override any project
-   defaults set in `.env`
-
-For example:
-
-1. `apps/my-app/.env.local` contains `NX_API_URL=http://localhost:3333`
-2. `apps/my-app/.env` contains `NX_API_URL=https://api.example.com`
-3. Nx will first load the variables from `apps/my-app/.env.local` into the process. When it tries to load the variables
-   from `apps/my-app/.env`, it will notice that `NX_API_URL` already exists, so it will ignore it.
-
-We recommend nesting your **app** specific `env` files in `apps/your-app`, and creating workspace/root level `env` files
-for workspace-specific settings (like the [Nx Cloud token](/using-nx/caching#distributed-computation-caching)).
-{% /callout %}
-
-### Pointing to custom env files
-
-If you want to load variables from `env` files other than the ones listed above:
-
-1. Use the [env-cmd](https://www.npmjs.com/package/env-cmd) package: `env-cmd -f .qa.env nx serve`
-2. Use the `envFile` option of the [run-commands](/packages/nx/executors/run-commands#envfile) builder and execute your command inside of the builder
-
-### Ad-hoc variables
-
-You can also define environment variables in an ad-hoc manner using support from your OS and shell.
-
-**Unix systems**
-
-In Unix systems, we need to set the environment variables before calling a command.
-
-Let's say that we want to define an API URL for the application to use:
-
-```bash
-NX_API_URL=http://localhost:3333 nx build myapp
-```
-
-**Windows (cmd.exe)**
-
-```bash
-set "NX_API_URL=http://localhost:3333" && nx build myapp
-```
-
-**Windows (Powershell)**
-
-```bash
-($env:NX_API_URL = "http://localhost:3333") -and (nx build myapp)
-```
-
-## Using environment variables
-
-Handling of environment variables can differ between Nx plugins. For [React applications](#environment-variables-in-react-applications),
-usage of variables in TS/JS files and `index.html` is automatically included in the build process; whereas in
-[Angular applications](#environment-variables-in-angular-applications), environment variables require extra setup to use,
-and by default Angular encourages using `environment.*.ts` files in combination with `fileReplacement` option during build.
-
-### Using environment variables in React applications
-
-In React applications (e.g. those using `@nrwl/web:webpack` or `@nrwl/next:build` executors for `build` target), Nx
-includes the following variables in the build process:
-
-- `NODE_ENV`
-- Variables prefixed with `NX_`, such as `NX_CUSTOM_VAR`
-
-Defining environment variables can vary between OSes. It's also important to know that this is temporary for the life of
-the shell session.
-
-#### Using environment variables in `index.html`
-
-Nx supports interpolating environment variables into your `index.html` file for React and Web applications.
-
-To interpolate an environment variable named `NX_DOMAIN_NAME` into your `index.html`, surround it with `%` symbols like so:
-
-```html
-<html>
-  <body>
-    <p>The domain name is %NX_DOMAIN_NAME%.</p>
-  </body>
-</html>
-```
-
-### Using environment variables in Angular applications
-
-By default, Angular only provides the `NODE_ENV` variable when building the application. You may use `process.env.NODE_ENV`
-anywhere in your TS/JS source, and the build will inline this value in the output chunks.
-
-Other variables, such as those prefixed by `NX_` will not work in Angular. To add support for other environment variables,
-do the following.
-
-First, install `@types/node` so we can use `process.env` in our code.
-
-```bash
-npm install --save-dev @types/node
-
-# Or with yarn
-yarn add --dev @types/node
-```
-
-Next, update the `build` and `serve` targets (in `project.json` or `angular.json` file), to the following.
-
-```json lines
-{
-  "build": {
-    // NOTE: change the executor to one that supports custom webpack config.
-    "executor": "@nrwl/angular:webpack-browser",
-    // snip
-    "options": {
-      // NOTE: This file needs to be created.
-      "customWebpackConfig": {
-        "path": "apps/myapp/webpack.config.js"
-      }
-      // snip
-    }
-  },
-  "serve": {
-    // NOTE: use dev-server that supports custom webpack config.
-    "executor": "@nrwl/angular:webpack-server"
-    // snip
-  }
-}
-```
-
-Then, we can use `DefinePlugin` in our custom webpack.
-
-```javascript
-// apps/myapp/webpack.config.js
-const webpack = require('webpack');
-
-function getClientEnvironment(configuration) {
-  // Grab NODE_ENV and NX_* environment variables and prepare them to be
-  // injected into the application via DefinePlugin in webpack configuration.
-  const NX_APP = /^NX_/i;
-
-  const raw = Object.keys(process.env)
-    .filter((key) => NX_APP.test(key))
-    .reduce(
-      (env, key) => {
-        env[key] = process.env[key];
-        return env;
-      },
-      {
-        NODE_ENV: process.env.NODE_ENV || configuration,
-      }
-    );
-
-  // Stringify all values so we can feed into webpack DefinePlugin
-  return {
-    'process.env': Object.keys(raw).reduce((env, key) => {
-      env[key] = JSON.stringify(raw[key]);
-      return env;
-    }, {}),
-  };
-}
-
-module.exports = (config, options, context) => {
-  config.plugins.push(
-    new webpack.DefinePlugin(getClientEnvironment(context.configuration))
-  );
-  return config;
-};
-```
-
-Now, when we define variables in our `.env` file, such as...
-
-```text
-# apps/myapp/.env
-NX_API_URL=http://localhost:3333
-```
-
-Finally, We can use environment variables in our code. For example,
-
-```typescript
-// apps/myapp/src/main.ts
-import { enableProdMode } from '@angular/core';
-import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
-import { AppModule } from './app/app.module';
-
-if (process.env['NODE_ENV'] === 'production') {
-  enableProdMode();
-}
-
-// This is defined in our .env file.
-console.log('>>> NX_API_URL', process.env['NX_API_URL']);
-
-platformBrowserDynamic()
-  .bootstrapModule(AppModule)
-  .catch((err) => console.error(err));
-```
-
-You should also update `tsconfig.apps.json` and `tsconfig.spec.json` files to include node types.
-
-```json lines
-{
-  "extends": "./tsconfig.json",
-  "compilerOptions": {
-    // snip
-    "types": ["node"]
-  }
-  // snip
-}
-```
-
-#### Using environment variables in `index.html`
-
-While you cannot use variable in `index.html`, one workaround for this is to create different `index.*.html` files, such
-as `index.prod.html`, then swap it in different environments.
-
-For example in `project.json` (or `angular.json`),
-
-```json lines
-{
-  "build": {
-    "executor": "@angular-devkit/build-angular:browser",
-    // snip
-    "configurations": {
-      "production": {
-        // snip
-        "fileReplacements": [
-          {
-            "replace": "apps/myapp/src/environments/environment.ts",
-            "with": "apps/myapp/src/environments/environment.prod.ts"
-          },
-          {
-            "replace": "apps/myapp/src/index.html",
-            "with": "apps/myapp/src/index.prod.html"
-          }
-        ]
-      }
-    }
-  }
-}
-```
-
-{% callout type="note" title="Optimize" %}
-You can also customize your webpack configuration, similar to using `DefinePlugin` above. This approach will require post-processing the `index.html` file, and is out of scope for this guide.
-{% /callout %}
-
-## Summary
-
-Nx supports setting environment variables from env files in your projects and workspace root. If there are multiple env
-files, then the values from the application (e.g. `<root>/apps/myapp/.env`) takes precedence over the values from workspace
-(e.g. `<root>/.env`). You can also set local overrides in `.env.local` or `.local.env` files.
-
-Usage of environment variables different between React and Angular applications, so make sure your usage matches the
-support from each Framework.

docs/shared/guides/integrated-repo-folder-structure.md

@@ -0,0 +1,26 @@
+# Integrated Repo Folder Structure
+
+Nx can be added to any workspace, so there is no fixed folder structure. However, if you use one of the existing presets, you will likely see something like this:
+
+```treeview
+myorg/
+├── apps/
+├── libs/
+├── tools/
+├── workspace.json
+├── nx.json
+├── package.json
+└── tsconfig.base.json
+```
+
+`/apps/` contains the application projects. This is the main entry point for a runnable application. We recommend keeping applications as light-weight as possible, with all the heavy lifting being done by libraries that are imported by each application.
+
+`/libs/` contains the library projects. There are many kinds of libraries, and each library defines its own external API so that boundaries between libraries remain clear.
+
+`/tools/` contains scripts that act on your code base. This could be database scripts, [custom executors](/recipe/creating-custom-executors), or [workspace generators](/recipe/workspace-generators).
+
+`/workspace.json` lists every project in your workspace. (this file is optional)
+
+`/nx.json` configures the Nx CLI itself. It tells Nx what needs to be cached, how to run tasks etc.
+
+`/tsconfig.base.json` sets up the global TypeScript settings and creates aliases for each library to aid when creating TS/JS imports.

docs/shared/guides/js-and-ts.md

@@ -15,4 +15,4 @@ Regardless whether you use JavaScript or TypeScript, you will have a `tsconfig.b
 
 ## Interested in building and distributing TypeScript packages?
 
-You might want to check out the `@nrwl/js` package which comes with advanced TypeScript support, including [SWC](https://swc.rs/) and more. Find out more in the [Nx and TypeScript guide](/getting-started/nx-and-typescript).
+You might want to check out the `@nrwl/js` package which comes with advanced TypeScript support, including [SWC](https://swc.rs/) and more. Find out more in the [plugin documentation](/packages/js).

docs/shared/guides/module-federation/faster-builds.md

@@ -286,7 +286,7 @@ module.exports = withModuleFederation({
 Now you can run `nx build host` to build all the `host` and all the implicit dependencies in production mode.
 
 {% callout type="note" title="Distributed caching" %}
-Again, if you don't use [Nx Cloud's Distributed Tasks Execution](/using-nx/dte) using Module Federation will be slower than building everything in a single process. It's only if you enable Distributed Tasks Execution, your CI will be able to build each remote on a separate machine, in parallel, (or not build it at all and retrieve it from cache), which will reduce the CI time.
+Again, if you don't use [Nx Cloud's Distributed Tasks Execution](/concepts/dte) using Module Federation will be slower than building everything in a single process. It's only if you enable Distributed Tasks Execution, your CI will be able to build each remote on a separate machine, in parallel, (or not build it at all and retrieve it from cache), which will reduce the CI time.
 {% /callout %}
 
 After running that command you'll see the following artifacts in `dist` folder.
@@ -344,7 +344,7 @@ Because Nx Cloud's Distributed Tasks Execution works with any task graph, having
 
 ## Summary
 
-You could use Module Federation to implement [micro frontends](/module-federation/micro-frontend-architecture), but this guide showed how to use it to speed up your builds.
+You could use Module Federation to implement [micro frontends](/more-concepts/micro-frontend-architecture), but this guide showed how to use it to speed up your builds.
 
 Module Federation allows you to split a single build process into multiple processes which can run in parallel or even on multiple machines. The result of each build process can be cached independently. For this to work well in practice you need to have a build system supporting distributed computation caching and distributed tasks execution (e.g., Nx + Nx Cloud).
 

docs/shared/guides/module-federation/micro-frontend-architecture.md

@@ -1,9 +1,9 @@
 # Micro Frontend Architecture
 
-Since version 14, Nx provides out-of-the-box [Module Federation](/module-federation/faster-builds) support to both React
+Since version 14, Nx provides out-of-the-box [Module Federation](/recipe/faster-builds) support to both React
 and Angular. The Micro Frontend (MFE) architecture builds on top of Module Federation by providing _independent deployability_.
 
-If you have not read the [Module Federation guide](/module-federation/faster-builds) yet, we recommend that you read it
+If you have not read the [Module Federation guide](/recipe/faster-builds) yet, we recommend that you read it
 before continuing with this MFE guide.
 
 ## When should I use micro frontend architecture?
@@ -17,7 +17,7 @@ of MFEs and decide whether it makes sense for your own teams.
   logic that breaks compatibility with remotes.
 
 If you are looking at optimizing builds and do not need independent deployments, we recommend reading our guide on
-[Faster Builds with Module Federation](/module-federation/faster-builds).
+[Faster Builds with Module Federation](/recipe/faster-builds).
 
 If you need to use MFEs, keep reading, and we'll examine the architecture and strategies to deal with shared libraries and
 deployments.
@@ -29,7 +29,7 @@ With MFE architecture, a large application is split into:
 1. A single **Host** application that references external...
 2. **Remote** applications, which handle a single domain or feature.
 
-In a normal Module Federation setup, we [recommend setting up implicit dependencies](/module-federation/faster-builds#architectural-overview)
+In a normal Module Federation setup, we [recommend setting up implicit dependencies](/recipe/faster-builds#architectural-overview)
 from the host application to remote applications. However, in an MFE architecture you _do not_ want these dependencies
 to exist between host and remotes.
 

docs/shared/guides/nx-and-angular-cli.md

@@ -1,39 +1,4 @@
-# Nx and Angular
-
-Nx is a smart, fast and extensible build system with first class monorepo support and powerful integrations. It has a powerful core and a rich plugin ecosystem.
-
-## Making Things Fast
-
-If you're only interested in improving the performance of your monorepo by using Nx's [affected:\* commands](/using-nx/affected), [computation cache](/using-nx/caching), and [distributed task execution](/using-nx/dte), then you don't need to use any plugins. Everything will work the same way whether your monorepo has React, Vue, Svelte, or even Go, Rust, or Java apps. Nx is technology-agnostic.
-
-Check out the following guides to get started:
-
-- [Using Nx without plugins](/getting-started/nx-core)
-- [Adding Nx to an existing monorepo](/migration/adding-to-monorepo)
-- [Adding Nx to an Angular CLI project](/migration/migration-angular)
-- [Migrating from AngularJS](/migration/migration-angularjs)
-
-{% callout type="note" title="Going deeper" %}
-It is also a good idea to read the [mental model guide](/using-nx/mental-model) to understand how Nx works.
-{% /callout %}
-
-## Nx and Angular Plugins
-
-Nx plugins helps you develop [Angular](/packages/angular) applications with fully integrated support for
-modern tools and libraries like [Jest](/packages/jest), [Cypress](/packages/cypress),
-[ESLint](/packages/linter), [Storybook](/packages/storybook), [NgRx](/guides/misc-ngrx) and more.
-
-{% youtube
-src="https://www.youtube.com/embed/cXOkmOy-8dk"
-title="Modern Angular with Nx Dev Tools"
-width="100%" /%}
-
-Check out the following to get started:
-
-- [Angular: Interactive Nx Tutorial (with videos)](/angular-tutorial/01-create-application)
-- [Free Nx Course on YouTube](https://www.youtube.com/watch?time_continue=49&v=2mYLe9Kp9VM&feature=emb_logo)
-
-## Nx and Angular CLI
+# Nx and the Angular CLI
 
 {% callout type="check" title="Nx and AngularCLI commands are interchangeable" %}
 If you add Nx to an Angular CLI project, `ng` and `nx` are interchangeable (they invoke the same command). So anywhere you see `"nx build"` or `"nx affected"`, you can also use `"ng build"` or `"ng affected"`.
@@ -61,7 +26,7 @@ What we recommend instead is to split `angular.json` into multiple `project.json
 - Run `nx generate @nrwl/workspace:convert-to-nx-project --all=true`
 
 {% callout type="check" title="Nx and AngularCLI are compatible" %}
-But regardless of whether you use `angular.json` or `project.json`, the configuration remains the same. So anything written about `project.json` or `workspace.json` applies to `angular.json` in the same way. For instance, everything in [project.json and nx.json](/configuration/projectjson) applies to `angular.json` in the same way.
+But regardless of whether you use `angular.json` or `project.json`, the configuration remains the same. So anything written about `project.json` or `workspace.json` applies to `angular.json` in the same way. For instance, everything in [project.json](/reference/project-configuration) and [nx.json](/reference/nx-json) applies to `angular.json` in the same way.
 {% /callout %}
 
 Note that even though the configuration is split, everything works the same way. All migrations and schematics that expect a single `angular.json` file, will receive a single file. Nx is smart, so it merges all the files in memory to make those migrations and schematics work.

docs/shared/guides/nx-and-ts.md

@@ -1,239 +0,0 @@
-# Nx and TypeScript
-
-> The build system for TypeScript that TypeScript deserves
-
-The `@nrwl/js` package ships with corresponding generators and executors that best work when it comes to developing TypeScript applications and libraries.
-
-{% callout type="note" title="Want to use plain Javascript instead?" %}
-Note, you can also opt out of TypeScript and use plain JavaScript by passing the `--js` flag to the generators.
-{% /callout %}
-
-{% youtube
-src="https://www.youtube.com/embed/-OmQ-PaSY5M"
-title="Develop great Typescript Packages with Nx"
-width="100%" /%}
-
-`@nrwl/js` is particularly useful if you want to
-
-- Create framework-agnostic TypeScript libraries within an existing Nx workspace (say to use in your React, Node or Angular app)
-- Publish TypeScript packages to NPM
-
-To get started with TypeScript packages in Nx, either add the `@nrwl/js` package to an existing Nx workspace or generate a new Nx workspace using the `--preset=ts` preset.
-
-```bash
-npx create-nx-workspace happynrwl --preset=ts
-```
-
-Generating a new workspace creates a lightweight setup with a `packages` and `tools` folder. The `tools` folder is where you can add monorepo specific scripts and custom Nx generators, the `packages` folder is where all our TS based libs will live.
-
-```treeview
-happynrwl/
-├── packages/
-├── tools/
-├── workspace.json
-├── nx.json
-├── package.json
-└── tsconfig.base.json
-```
-
-As with most Nx plugins, `@nrwl/js` comes with a set of generators to quickly scaffold new TypeScript libraries. Let’s have a look at an example.
-
-## Create a new TypeScript based library
-
-We can use Nx Console and choose the `@nrwl/js:library` generator or directly use the following command:
-
-```bash
-nx generate @nrwl/js:library --name=hello-tsc --buildable
-```
-
-This creates a new library in the `packages/hello-tsc` folder that already comes with both ESLint and Jest set up and ready to use.
-
-You can run `nx lint hello-tsc` to run linting or `nx test hello-tsc` to run Jest tests.
-
-Note, by passing the `--buildable` flag, our library can be built.
-
-```bash
-nx build hello-tsc
-```
-
-The output of the build step is placed into the `dist/packages/hello-tsc` by default.
-
-## Create a TypeScript based application
-
-Using either @nrwl/node or @nrwl/web, you can also setup a plain TypeScript application that is framework agnostic.
-
-Note, before using either of these commands you must first install the required "generator" into the root of the project:
-
-```bash
-npm install @nrwl/node
-```
-
-To generate a new framework agnostic TS node application, run
-
-```bash
-nx generate @nrwl/node:app demoapp
-```
-
-To generate a new framework agnostic TS web application, run
-
-```bash
-nx generate @nrwl/web:app demoapp
-```
-
-Applications also come with a “serve” target, that allow you to run the app in watch mode:
-
-```bash
-nx serve demoapp
-```
-
-## Importing Libraries
-
-All the libraries generated within the Nx workspace are configured with corresponding TypeScript path mappings in the root-level `tsconfig.base.json` file:
-
-```json
-{
-  "compileOnSave": false,
-  "compilerOptions": {
-    ...
-    "paths": {
-      "@happynrwl/hello-swc": ["packages/hello-swc/src/index.ts"],
-      "@happynrwl/hello-tsc": ["packages/hello-tsc/src/index.ts"]
-    }
-  },
-}
-```
-
-This allows you to easily import from libraries, by using the corresponding TypeScript path mapping. The following shows an example of importing the `helloTsc` function from the `hello-tsc` library into the `tsapp` application (the same method works between libraries as well):
-
-```typescript
-// file: packages/tsapp/src/index.ts
-
-// importing from hello-tsc
-import { helloTsc } from '@happynrwl/hello-tsc';
-
-// use the function
-helloTsc();
-
-console.log(`Running ${tsapp()}`);
-```
-
-## Use SWC as the compiler
-
-Nx also ships with support to use SWC instead of TSC. When generating a new library/application just pass the `--compiler=swc`.
-
-Here's an example of generating a new library:
-
-```bash
-nx generate @nrwl/js:library --name=hello-tsc --buildable --compiler=swc
-```
-
-Alternatively, if you already have an existing tsc based library/application, you can run the `@nrwl/js:convert-to-swc` generator to migrate the package from TSC to SWC.
-
-The following command converts the `hello-tsc` library to SWC:
-
-```bash
-nx generate @nrwl/js:convert-to-swc --name=hello-tsc
-```
-
-## Using NPM Scripts rather than Nx executors
-
-If you want to use NPM scripts rather than Nx executors, you can use the `--config=npm-scripts`:
-
-```bash
-nx g @nrwl/js:lib mylib --config=npm-scripts
-```
-
-The Nx generator then creates NPM scripts in the generated library's `package.json` (rather than in the `project.json`):
-
-```json
-// packages/mylib/package.json
-{
-  "name": "@happynrwl/mylib",
-  "version": "0.0.1",
-  "type": "commonjs",
-  "scripts": {
-    "build": "echo 'implement build'",
-    "test": "echo 'implement test'"
-  }
-}
-```
-
-To run these scripts with Nx, use the same syntax as Nx executors. `nx build mylib` or `nx test mylib` will build or test your library, respectively.
-
-## Publish your TypeScript packages to NPM
-
-### `--publishable` flag
-
-Let's start by generating a new library `publish-me` with the following command:
-
-```shell
-nx g @nrwl/js:lib publish-me --publishable --importPath="@happynrwl/publish-me"
-```
-
-Generating a library with `--publishable` flag does several things extra on top of `--buildable`. It generates a minimal `publish.mjs` script in `tools/scripts/` directory if it does not already exist. Additionally, `--publishable` also adds a `publish` target to the library's `project.json` with the following content:
-
-```json
-{
-  "root": "packages/publish-me",
-  "sourceRoot": "packages/publish-me/src",
-  "targets": {
-    "build": {},
-    "publish": {
-      "executor": "nx:run-commands",
-      "options": {
-        "command": "node tools/scripts/publish.mjs publish-me {args.ver} {args.tag}"
-      },
-      "dependsOn": ["build"]
-    },
-    "lint": {},
-    "test": {}
-  },
-  "tags": []
-}
-```
-
-The `publish` target invokes the generated `publish.mjs` script using [`nx:run-commands`](/executors/run-commands-builder) executor. The script does the following:
-
-- Validate the `ver` argument against a simple [SemVer](https://semver.org/) RegExp.
-- Validate the `name` of the project (eg: `publish-me`) against the workspace existing projects.
-- Update the `version` property in the `package.json` of your project's `build.outputPath`
-- Invoke `npm publish` with the provided tag (default to `next` so you won't publish to `latest` by accident)
-
-> Make sure to authenticate with `npm` before running the `publish` target.
-
-```shell
-nx publish publish-me --ver=<required-version> --tag=[custom-tag]
-```
-
-Thanks to [“Target Dependencies” (`dependsOn`)](/configuration/projectjson#dependson) property under the `publish` target, Nx runs the `build` target automatically before Nx runs `publish`. And of course, if `build` has already run, it won't execute again, thanks to [Nx computation caching](/using-nx/caching).
-
-{% callout type="note" title="Only to get you started" %}
-The generated `publish.mjs` script is a minimal version of what a publishing process looks like. You can definitely add more to it as you see fit for your project. For example: you can add a capability to automatic increment the version.
-{% /callout %}
-
-### Manual setup
-
-Let's set up our `hello-tsc` library to be publishable as well but this time, we'll do it manually. All we have to do is to copy the `publish` target from `publish-me` library to `hello-tsc` and modify it to use `hello-tsc` project name instead.
-
-```shell
-{
-  "root": "packages/hello-tsc",
-  "sourceRoot": "packages/hello-tsc/src",
-  "targets": {
-    "build": {},
-    "publish": {
-      "executor": "nx:run-commands",
-      "options": {
-        "command": "node tools/scripts/publish.mjs hello-tsc {args.ver} {args.tag}",
-      },
-      "dependsOn": ["build"]
-    },
-    "lint": {},
-    "test": {}
-  },
-  "tags": []
-}
-
-```
-
-Now, you should be able to invoke `nx publish hello-tsc --ver=<required-version>` to publish it to `npm`

docs/shared/guides/nx-devkit-angular-devkit.md

@@ -185,7 +185,7 @@ export default createBuilder<NextBuildBuilderOptions>(run);
 
 ### Notable Differences
 
-- Nx Devkit executors return a Promise (or async iterable). If you want, you can always convert an observable to a promise or an async iterable. See [Using Rxjs Observables](/executors/using-builders#using-rxjs-observables)
+- Nx Devkit executors return a Promise (or async iterable). If you want, you can always convert an observable to a promise or an async iterable.
 - Nx Devkit executors do not have to be wrapped using `createBuilder`.
 
 The schema files for both Nx Devkit executors and Angular Builders are the same. Nx can run both of them in the same way.

docs/shared/guides/react-native.md

@@ -155,8 +155,8 @@ Nx allows you to create libraries with just one command. Some reasons you might
 - Publish a package to be used outside the monorepo
 - Better visualize the architecture using `npx nx graph`
 
-For more information on Nx libraries, see our documentation on [Creating Libraries](/structure/creating-libraries)
-and [Library Types](/structure/library-types).
+For more information on Nx libraries, see our documentation on [Creating Libraries](/more-concepts/creating-libraries)
+and [Library Types](/more-concepts/library-types).
 
 To generate a new library run:
 

docs/shared/guides/setup-incremental-builds-angular.md

@@ -197,7 +197,7 @@ Say you have the same application above with a configuration as follows:
       }
     },
     "build": {
-      "executor": "@nrwl/workspace:run-commands",
+      "executor": "nx:run-commands",
       "outputs": [
         "{options.outputPath}"
       ],

docs/shared/guides/storybook/storybook-composition-setup.md

@@ -156,7 +156,7 @@ Let's first generate a new `target` called `storybook-composition` for our `main
 Run the following command:
 
 ```bash
-nx generate @nrwl/workspace:run-commands storybook-composition --command='nx storybook one-composed' --project=main-host
+nx generate nx:run-commands storybook-composition --command='nx storybook one-composed' --project=main-host
 ```
 
 This will create a new `target` in your `apps/main-host/project.json`:

docs/shared/guides/turbo-and-nx.md

@@ -79,7 +79,7 @@ If you want to learn more, check out our article on [Distributing CI - Binning a
 
 All the available Nx commands can be executed via the command line. But as your monorepo grows, with multiple teams and hundreds of projects, even just finding the project to run a command against can sometimes be difficult. Having a high quality IDE integration can be a time saver there.
 
-- Nx has [VSCode](https://nx.dev/using-nx/console) and WebStorm/Intellij plugins.
+- Nx has [VSCode](/core-features/integrate-with-editors) and WebStorm/Intellij plugins.
 - Turborepo doesn’t have any plugins, and the maintainer has indicated there's no intention to provide editor support.
 
 Learn more [by watching this Egghead lesson](https://egghead.io/lessons/javascript-generate-new-projects-for-nx-with-nx-console).
@@ -127,8 +127,6 @@ At this point, Turborepo doesn’t do any of that. So for a monorepo of any non-
 Nx is like the **VSCode of build tools**. In VSCode you can get started with the plain, core VSCode setup and it would be fine. But if you want to enhance your experience, there's the option to add extensions for managing Git, Docker, Mongo etc. Similarly, **you don’t have to use all the Nx plugins or, say, the Nx Cloud GitHub integration.**  
 Nx doesn’t replace any of your tools, and it’s not “all in”. You can start without any Nx plugins and Nx Cloud affordances, as with Turborepo. Or you can add them in as you go, both natively supported plugins by Nx as well as our growing [set of community plugins](https://nx.dev/community). **Turborepo isn’t pluggable**, so if you use the same analogy, you would have to use different tools (GitTower, DataGrip, Mongo Compass) to meet the same needs.
 
-Read [this guide](https://nx.dev/getting-started/nx-core) to learn more about how to only use Nx Core.
-
 ## Tech and Performance
 
 Turborepo is mostly written in Golang. Nx is mostly written in TypeScript, but most of the heavy computation in Nx is done by core Node.js capabilities and node modules written in C++, so performance isn’t affected by this.

docs/shared/guides/use-environment-variables-in-angular.md

@@ -0,0 +1,155 @@
+# Using environment variables in Angular applications
+
+By default, Angular only provides the `NODE_ENV` variable when building the application. You may use `process.env.NODE_ENV`
+anywhere in your TS/JS source, and the build will inline this value in the output chunks.
+
+Other variables, such as those prefixed by `NX_` will not work in Angular. To add support for other environment variables,
+do the following.
+
+First, install `@types/node` so we can use `process.env` in our code.
+
+```bash
+npm install --save-dev @types/node
+
+# Or with yarn
+yarn add --dev @types/node
+```
+
+Next, update the `build` and `serve` targets (in `project.json` or `angular.json` file), to the following.
+
+```json lines
+{
+  "build": {
+    // NOTE: change the executor to one that supports custom webpack config.
+    "executor": "@nrwl/angular:webpack-browser",
+    // snip
+    "options": {
+      // NOTE: This file needs to be created.
+      "customWebpackConfig": {
+        "path": "apps/myapp/webpack.config.js"
+      }
+      // snip
+    }
+  },
+  "serve": {
+    // NOTE: use dev-server that supports custom webpack config.
+    "executor": "@nrwl/angular:webpack-server"
+    // snip
+  }
+}
+```
+
+Then, we can use `DefinePlugin` in our custom webpack.
+
+```javascript
+// apps/myapp/webpack.config.js
+const webpack = require('webpack');
+
+function getClientEnvironment(configuration) {
+  // Grab NODE_ENV and NX_* environment variables and prepare them to be
+  // injected into the application via DefinePlugin in webpack configuration.
+  const NX_APP = /^NX_/i;
+
+  const raw = Object.keys(process.env)
+    .filter((key) => NX_APP.test(key))
+    .reduce(
+      (env, key) => {
+        env[key] = process.env[key];
+        return env;
+      },
+      {
+        NODE_ENV: process.env.NODE_ENV || configuration,
+      }
+    );
+
+  // Stringify all values so we can feed into webpack DefinePlugin
+  return {
+    'process.env': Object.keys(raw).reduce((env, key) => {
+      env[key] = JSON.stringify(raw[key]);
+      return env;
+    }, {}),
+  };
+}
+
+module.exports = (config, options, context) => {
+  config.plugins.push(
+    new webpack.DefinePlugin(getClientEnvironment(context.configuration))
+  );
+  return config;
+};
+```
+
+Now, when we define variables in our `.env` file, such as...
+
+```text
+# apps/myapp/.env
+NX_API_URL=http://localhost:3333
+```
+
+Finally, We can use environment variables in our code. For example,
+
+```typescript
+// apps/myapp/src/main.ts
+import { enableProdMode } from '@angular/core';
+import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
+import { AppModule } from './app/app.module';
+
+if (process.env['NODE_ENV'] === 'production') {
+  enableProdMode();
+}
+
+// This is defined in our .env file.
+console.log('>>> NX_API_URL', process.env['NX_API_URL']);
+
+platformBrowserDynamic()
+  .bootstrapModule(AppModule)
+  .catch((err) => console.error(err));
+```
+
+You should also update `tsconfig.apps.json` and `tsconfig.spec.json` files to include node types.
+
+```json lines
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    // snip
+    "types": ["node"]
+  }
+  // snip
+}
+```
+
+## Using environment variables in `index.html`
+
+While you cannot use variable in `index.html`, one workaround for this is to create different `index.*.html` files, such
+as `index.prod.html`, then swap it in different environments.
+
+For example in `project.json` (or `angular.json`),
+
+```json lines
+{
+  "build": {
+    "executor": "@angular-devkit/build-angular:browser",
+    // snip
+    "configurations": {
+      "production": {
+        // snip
+        "fileReplacements": [
+          {
+            "replace": "apps/myapp/src/environments/environment.ts",
+            "with": "apps/myapp/src/environments/environment.prod.ts"
+          },
+          {
+            "replace": "apps/myapp/src/index.html",
+            "with": "apps/myapp/src/index.prod.html"
+          }
+        ]
+      }
+    }
+  }
+}
+```
+
+{% callout type="note" title="Optimize" %}
+You can also customize your webpack configuration, similar to using `DefinePlugin` above. This approach will require post-processing the `index.html` file, and is out of scope for this guide.
+{% /callout %}

docs/shared/guides/use-environment-variables-in-react.md

@@ -0,0 +1,24 @@
+# Using environment variables in React applications
+
+In React applications (e.g. those using `@nrwl/web:webpack` or `@nrwl/next:build` executors for `build` target), Nx
+includes the following variables in the build process:
+
+- `NODE_ENV`
+- Variables prefixed with `NX_`, such as `NX_CUSTOM_VAR`
+
+Defining environment variables can vary between OSes. It's also important to know that this is temporary for the life of
+the shell session.
+
+## Using environment variables in `index.html`
+
+Nx supports interpolating environment variables into your `index.html` file for React and Web applications.
+
+To interpolate an environment variable named `NX_DOMAIN_NAME` into your `index.html`, surround it with `%` symbols like so:
+
+```html
+<html>
+  <body>
+    <p>The domain name is %NX_DOMAIN_NAME%.</p>
+  </body>
+</html>
+```

docs/shared/guides/why-monorepos.md

@@ -3,7 +3,7 @@
 A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them.
 
 {% callout type="note" title="Lerna users" %}
-If you are familiar with Lerna or Yarn workspaces, check out [this guide](/migration/lerna-and-nx) (with a quick video) showing how to add Nx to a Lerna/Yarn workspace, what the difference is, when to use both and when to use just Nx.
+If you are familiar with Lerna or Yarn workspaces, check out [this guide](/recipe/lerna-and-nx) (with a quick video) showing how to add Nx to a Lerna/Yarn workspace, what the difference is, when to use both and when to use just Nx.
 {% /callout %}
 
 ## What are the benefits of a monorepo?