miel.truyen/nx
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs(core): clean up more concepts section (#22957)

Browse Source
This commit is contained in:
Isaac Mann 2024-04-24 04:28:53 -04:00 committed by GitHub
parent 48e8752b7a
commit 33008f25b5
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
24 changed files with 746 additions and 880 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

184
docs/generated/manifests/menus.json
View File

@ -766,22 +766,6 @@
"id": "more-concepts",
"isExternal": false,
"children": [
{
"name": "Incremental Builds",
"path": "/concepts/more-concepts/incremental-builds",
"id": "incremental-builds",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx and Turborepo",
"path": "/concepts/more-concepts/turbo-and-nx",
"id": "turbo-and-nx",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Monorepos",
"path": "/concepts/more-concepts/why-monorepos",
@ -806,14 +790,6 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Using Nx at Enterprises",
"path": "/concepts/more-concepts/monorepo-nx-enterprise",
"id": "monorepo-nx-enterprise",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Daemon",
"path": "/concepts/more-concepts/nx-daemon",
@ -823,25 +799,9 @@
"disableCollapsible": false
},
{
"name": "Nx and the Angular CLI",
"path": "/concepts/more-concepts/nx-and-angular",
"id": "nx-and-angular",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Folder Structure",
"path": "/concepts/more-concepts/folder-structure",
"id": "folder-structure",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Devkit and Angular Devkit",
"path": "/concepts/more-concepts/nx-devkit-angular-devkit",
"id": "nx-devkit-angular-devkit",
"name": "Nx and Turborepo",
"path": "/concepts/more-concepts/turbo-and-nx",
"id": "turbo-and-nx",
"isExternal": false,
"children": [],
"disableCollapsible": false
@ -855,7 +815,7 @@
"disableCollapsible": false
},
{
"name": "Creating Libraries",
"name": "When to Create a New Library",
"path": "/concepts/more-concepts/creating-libraries",
"id": "creating-libraries",
"isExternal": false,
@ -885,14 +845,6 @@
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "How the Project Graph is Built",
"path": "/concepts/more-concepts/how-project-graph-is-built",
"id": "how-project-graph-is-built",
"isExternal": false,
"children": [],
"disableCollapsible": false
}
],
"disableCollapsible": false
@ -1043,22 +995,6 @@
"id": "more-concepts",
"isExternal": false,
"children": [
{
"name": "Incremental Builds",
"path": "/concepts/more-concepts/incremental-builds",
"id": "incremental-builds",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx and Turborepo",
"path": "/concepts/more-concepts/turbo-and-nx",
"id": "turbo-and-nx",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Monorepos",
"path": "/concepts/more-concepts/why-monorepos",
@ -1083,14 +1019,6 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Using Nx at Enterprises",
"path": "/concepts/more-concepts/monorepo-nx-enterprise",
"id": "monorepo-nx-enterprise",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Daemon",
"path": "/concepts/more-concepts/nx-daemon",
@ -1100,25 +1028,9 @@
"disableCollapsible": false
},
{
"name": "Nx and the Angular CLI",
"path": "/concepts/more-concepts/nx-and-angular",
"id": "nx-and-angular",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Folder Structure",
"path": "/concepts/more-concepts/folder-structure",
"id": "folder-structure",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Devkit and Angular Devkit",
"path": "/concepts/more-concepts/nx-devkit-angular-devkit",
"id": "nx-devkit-angular-devkit",
"name": "Nx and Turborepo",
"path": "/concepts/more-concepts/turbo-and-nx",
"id": "turbo-and-nx",
"isExternal": false,
"children": [],
"disableCollapsible": false
@ -1132,7 +1044,7 @@
"disableCollapsible": false
},
{
"name": "Creating Libraries",
"name": "When to Create a New Library",
"path": "/concepts/more-concepts/creating-libraries",
"id": "creating-libraries",
"isExternal": false,
@ -1162,34 +1074,10 @@
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "How the Project Graph is Built",
"path": "/concepts/more-concepts/how-project-graph-is-built",
"id": "how-project-graph-is-built",
"isExternal": false,
"children": [],
"disableCollapsible": false
}
],
"disableCollapsible": false
},
{
"name": "Incremental Builds",
"path": "/concepts/more-concepts/incremental-builds",
"id": "incremental-builds",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx and Turborepo",
"path": "/concepts/more-concepts/turbo-and-nx",
"id": "turbo-and-nx",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Monorepos",
"path": "/concepts/more-concepts/why-monorepos",
@ -1214,14 +1102,6 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Using Nx at Enterprises",
"path": "/concepts/more-concepts/monorepo-nx-enterprise",
"id": "monorepo-nx-enterprise",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Daemon",
"path": "/concepts/more-concepts/nx-daemon",
@ -1231,25 +1111,9 @@
"disableCollapsible": false
},
{
"name": "Nx and the Angular CLI",
"path": "/concepts/more-concepts/nx-and-angular",
"id": "nx-and-angular",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Folder Structure",
"path": "/concepts/more-concepts/folder-structure",
"id": "folder-structure",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Devkit and Angular Devkit",
"path": "/concepts/more-concepts/nx-devkit-angular-devkit",
"id": "nx-devkit-angular-devkit",
"name": "Nx and Turborepo",
"path": "/concepts/more-concepts/turbo-and-nx",
"id": "turbo-and-nx",
"isExternal": false,
"children": [],
"disableCollapsible": false
@ -1263,7 +1127,7 @@
"disableCollapsible": false
},
{
"name": "Creating Libraries",
"name": "When to Create a New Library",
"path": "/concepts/more-concepts/creating-libraries",
"id": "creating-libraries",
"isExternal": false,
@ -1294,14 +1158,6 @@
"children": [],
"disableCollapsible": false
},
{
"name": "How the Project Graph is Built",
"path": "/concepts/more-concepts/how-project-graph-is-built",
"id": "how-project-graph-is-built",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Recipes",
"path": "/recipes",
@ -6699,6 +6555,22 @@
"children": [],
"disableCollapsible": false
},
{
"name": "Nx and the Angular CLI",
"path": "/nx-api/angular/documents/nx-and-angular",
"id": "nx-and-angular",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Nx Devkit and Angular Devkit",
"path": "/nx-api/angular/documents/nx-devkit-angular-devkit",
"id": "nx-devkit-angular-devkit",
"isExternal": false,
"children": [],
"disableCollapsible": false
},
{
"name": "Angular and Nx Version Matrix",
"path": "/nx-api/angular/documents/angular-nx-version-matrix",

22
docs/generated/manifests/nx-api.json
View File

@ -16,6 +16,28 @@
"tags": [],
"originalFilePath": "shared/packages/angular/angular-plugin"
},
"/nx-api/angular/documents/nx-and-angular": {
"id": "nx-and-angular",
"name": "Nx and the Angular CLI",
"description": "The 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, ESLint, Tailwind CSS, and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
"file": "generated/packages/angular/documents/nx-and-angular",
"itemList": [],
"isExternal": false,
"path": "/nx-api/angular/documents/nx-and-angular",
"tags": [],
"originalFilePath": "shared/guides/nx-and-angular-cli"
},
"/nx-api/angular/documents/nx-devkit-angular-devkit": {
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"description": "The 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, ESLint, Tailwind CSS, and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
"file": "generated/packages/angular/documents/nx-devkit-angular-devkit",
"itemList": [],
"isExternal": false,
"path": "/nx-api/angular/documents/nx-devkit-angular-devkit",
"tags": ["create-your-own-plugin"],
"originalFilePath": "shared/guides/nx-devkit-angular-devkit"
},
"/nx-api/angular/documents/angular-nx-version-matrix": {
"id": "angular-nx-version-matrix",
"name": "Angular and Nx Version Matrix",

236
docs/generated/manifests/nx.json
View File

@ -1044,28 +1044,6 @@
"mediaImage": "",
"file": "",
"itemList": [
{
"id": "incremental-builds",
"name": "Incremental Builds",
"description": "",
"mediaImage": "",
"file": "shared/incremental-builds",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/incremental-builds",
"tags": []
},
{
"id": "turbo-and-nx",
"name": "Nx and Turborepo",
"description": "",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/turbo-and-nx",
"tags": []
},
{
"id": "why-monorepos",
"name": "Monorepos",
@ -1099,17 +1077,6 @@
"path": "/concepts/more-concepts/code-sharing",
"tags": []
},
{
"id": "monorepo-nx-enterprise",
"name": "Using Nx at Enterprises",
"description": "",
"mediaImage": "",
"file": "shared/monorepo-nx-enterprise",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/monorepo-nx-enterprise",
"tags": ["enforce-module-boundaries", "generate-code"]
},
{
"id": "nx-daemon",
"name": "Nx Daemon",
@ -1122,38 +1089,16 @@
"tags": []
},
{
"id": "nx-and-angular",
"name": "Nx and the Angular CLI",
"id": "turbo-and-nx",
"name": "Nx and Turborepo",
"description": "",
"mediaImage": "",
"file": "shared/guides/nx-and-angular-cli",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/nx-and-angular",
"path": "/concepts/more-concepts/turbo-and-nx",
"tags": []
},
{
"id": "folder-structure",
"name": "Folder Structure",
"description": "",
"mediaImage": "",
"file": "shared/guides/integrated-repo-folder-structure",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/folder-structure",
"tags": []
},
{
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"description": "",
"mediaImage": "",
"file": "shared/guides/nx-devkit-angular-devkit",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/nx-devkit-angular-devkit",
"tags": ["create-your-own-plugin"]
},
{
"id": "applications-and-libraries",
"name": "Applications and Libraries",
@ -1167,7 +1112,7 @@
},
{
"id": "creating-libraries",
"name": "Creating Libraries",
"name": "When to Create a New Library",
"description": "",
"mediaImage": "",
"file": "shared/workspace/creating-libraries",
@ -1208,17 +1153,6 @@
"isExternal": false,
"path": "/concepts/more-concepts/buildable-and-publishable-libraries",
"tags": []
},
{
"id": "how-project-graph-is-built",
"name": "How the Project Graph is Built",
"description": "",
"mediaImage": "",
"file": "shared/concepts/how-project-graph-is-built",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/how-project-graph-is-built",
"tags": ["explore-graph", "inferred-tasks"]
}
],
"isExternal": false,
@ -1425,28 +1359,6 @@
"mediaImage": "",
"file": "",
"itemList": [
{
"id": "incremental-builds",
"name": "Incremental Builds",
"description": "",
"mediaImage": "",
"file": "shared/incremental-builds",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/incremental-builds",
"tags": []
},
{
"id": "turbo-and-nx",
"name": "Nx and Turborepo",
"description": "",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/turbo-and-nx",
"tags": []
},
{
"id": "why-monorepos",
"name": "Monorepos",
@ -1480,17 +1392,6 @@
"path": "/concepts/more-concepts/code-sharing",
"tags": []
},
{
"id": "monorepo-nx-enterprise",
"name": "Using Nx at Enterprises",
"description": "",
"mediaImage": "",
"file": "shared/monorepo-nx-enterprise",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/monorepo-nx-enterprise",
"tags": ["enforce-module-boundaries", "generate-code"]
},
{
"id": "nx-daemon",
"name": "Nx Daemon",
@ -1503,38 +1404,16 @@
"tags": []
},
{
"id": "nx-and-angular",
"name": "Nx and the Angular CLI",
"id": "turbo-and-nx",
"name": "Nx and Turborepo",
"description": "",
"mediaImage": "",
"file": "shared/guides/nx-and-angular-cli",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/nx-and-angular",
"path": "/concepts/more-concepts/turbo-and-nx",
"tags": []
},
{
"id": "folder-structure",
"name": "Folder Structure",
"description": "",
"mediaImage": "",
"file": "shared/guides/integrated-repo-folder-structure",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/folder-structure",
"tags": []
},
{
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"description": "",
"mediaImage": "",
"file": "shared/guides/nx-devkit-angular-devkit",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/nx-devkit-angular-devkit",
"tags": ["create-your-own-plugin"]
},
{
"id": "applications-and-libraries",
"name": "Applications and Libraries",
@ -1548,7 +1427,7 @@
},
{
"id": "creating-libraries",
"name": "Creating Libraries",
"name": "When to Create a New Library",
"description": "",
"mediaImage": "",
"file": "shared/workspace/creating-libraries",
@ -1589,45 +1468,12 @@
"isExternal": false,
"path": "/concepts/more-concepts/buildable-and-publishable-libraries",
"tags": []
},
{
"id": "how-project-graph-is-built",
"name": "How the Project Graph is Built",
"description": "",
"mediaImage": "",
"file": "shared/concepts/how-project-graph-is-built",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/how-project-graph-is-built",
"tags": ["explore-graph", "inferred-tasks"]
}
],
"isExternal": false,
"path": "/concepts/more-concepts",
"tags": []
},
"/concepts/more-concepts/incremental-builds": {
"id": "incremental-builds",
"name": "Incremental Builds",
"description": "",
"mediaImage": "",
"file": "shared/incremental-builds",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/incremental-builds",
"tags": []
},
"/concepts/more-concepts/turbo-and-nx": {
"id": "turbo-and-nx",
"name": "Nx and Turborepo",
"description": "",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/turbo-and-nx",
"tags": []
},
"/concepts/more-concepts/why-monorepos": {
"id": "why-monorepos",
"name": "Monorepos",
@ -1661,17 +1507,6 @@
"path": "/concepts/more-concepts/code-sharing",
"tags": []
},
"/concepts/more-concepts/monorepo-nx-enterprise": {
"id": "monorepo-nx-enterprise",
"name": "Using Nx at Enterprises",
"description": "",
"mediaImage": "",
"file": "shared/monorepo-nx-enterprise",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/monorepo-nx-enterprise",
"tags": ["enforce-module-boundaries", "generate-code"]
},
"/concepts/more-concepts/nx-daemon": {
"id": "nx-daemon",
"name": "Nx Daemon",
@ -1683,39 +1518,17 @@
"path": "/concepts/more-concepts/nx-daemon",
"tags": []
},
"/concepts/more-concepts/nx-and-angular": {
"id": "nx-and-angular",
"name": "Nx and the Angular CLI",
"/concepts/more-concepts/turbo-and-nx": {
"id": "turbo-and-nx",
"name": "Nx and Turborepo",
"description": "",
"mediaImage": "",
"file": "shared/guides/nx-and-angular-cli",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/nx-and-angular",
"path": "/concepts/more-concepts/turbo-and-nx",
"tags": []
},
"/concepts/more-concepts/folder-structure": {
"id": "folder-structure",
"name": "Folder Structure",
"description": "",
"mediaImage": "",
"file": "shared/guides/integrated-repo-folder-structure",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/folder-structure",
"tags": []
},
"/concepts/more-concepts/nx-devkit-angular-devkit": {
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"description": "",
"mediaImage": "",
"file": "shared/guides/nx-devkit-angular-devkit",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/nx-devkit-angular-devkit",
"tags": ["create-your-own-plugin"]
},
"/concepts/more-concepts/applications-and-libraries": {
"id": "applications-and-libraries",
"name": "Applications and Libraries",
@ -1729,7 +1542,7 @@
},
"/concepts/more-concepts/creating-libraries": {
"id": "creating-libraries",
"name": "Creating Libraries",
"name": "When to Create a New Library",
"description": "",
"mediaImage": "",
"file": "shared/workspace/creating-libraries",
@ -1771,17 +1584,6 @@
"path": "/concepts/more-concepts/buildable-and-publishable-libraries",
"tags": []
},
"/concepts/more-concepts/how-project-graph-is-built": {
"id": "how-project-graph-is-built",
"name": "How the Project Graph is Built",
"description": "",
"mediaImage": "",
"file": "shared/concepts/how-project-graph-is-built",
"itemList": [],
"isExternal": false,
"path": "/concepts/more-concepts/how-project-graph-is-built",
"tags": ["explore-graph", "inferred-tasks"]
},
"/recipes": {
"id": "recipes",
"name": "Recipes",

44
docs/generated/manifests/tags.json
View File

@ -258,13 +258,6 @@
"name": "Explore your Workspace",
"path": "/features/explore-graph"
},
{
"description": "",
"file": "shared/concepts/how-project-graph-is-built",
"id": "how-project-graph-is-built",
"name": "How the Project Graph is Built",
"path": "/concepts/more-concepts/how-project-graph-is-built"
},
{
"description": "",
"file": "shared/recipes/analyze-source-files",
@ -309,13 +302,6 @@
"name": "What Are Nx Plugins",
"path": "/concepts/nx-plugins"
},
{
"description": "",
"file": "shared/monorepo-nx-enterprise",
"id": "monorepo-nx-enterprise",
"name": "Using Nx at Enterprises",
"path": "/concepts/more-concepts/monorepo-nx-enterprise"
},
{
"description": "",
"file": "",
@ -404,13 +390,6 @@
"name": "Enforce Module Boundaries",
"path": "/features/enforce-module-boundaries"
},
{
"description": "",
"file": "shared/monorepo-nx-enterprise",
"id": "monorepo-nx-enterprise",
"name": "Using Nx at Enterprises",
"path": "/concepts/more-concepts/monorepo-nx-enterprise"
},
{
"description": "",
"file": "shared/workspace/applications-and-libraries",
@ -422,7 +401,7 @@
"description": "",
"file": "shared/workspace/creating-libraries",
"id": "creating-libraries",
"name": "Creating Libraries",
"name": "When to Create a New Library",
"path": "/concepts/more-concepts/creating-libraries"
},
{
@ -606,13 +585,6 @@
"name": "Inferred Tasks",
"path": "/concepts/inferred-tasks"
},
{
"description": "",
"file": "shared/concepts/how-project-graph-is-built",
"id": "how-project-graph-is-built",
"name": "How the Project Graph is Built",
"path": "/concepts/more-concepts/how-project-graph-is-built"
},
{
"description": "",
"file": "shared/recipes/plugins/project-graph-plugins",
@ -629,13 +601,6 @@
"name": "What Are Nx Plugins",
"path": "/concepts/nx-plugins"
},
{
"description": "",
"file": "shared/guides/nx-devkit-angular-devkit",
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"path": "/concepts/more-concepts/nx-devkit-angular-devkit"
},
{
"description": "",
"file": "shared/recipes/plugins/migration-generators",
@ -663,6 +628,13 @@
"id": "project-graph-plugins",
"name": "Modify the Project Graph",
"path": "/extending-nx/recipes/project-graph-plugins"
},
{
"description": "The 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, ESLint, Tailwind CSS, and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
"file": "generated/packages/generated/packages/angular/documents/nx-devkit-angular-devkit",
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"path": "/nx-api/angular/documents/nx-devkit-angular-devkit"
}
],
"repository-types": [

22
docs/generated/packages-metadata.json
View File

@ -13,6 +13,28 @@
"tags": [],
"originalFilePath": "shared/packages/angular/angular-plugin"
},
{
"id": "nx-and-angular",
"name": "Nx and the Angular CLI",
"description": "The 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, ESLint, Tailwind CSS, and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
"file": "generated/packages/angular/documents/nx-and-angular",
"itemList": [],
"isExternal": false,
"path": "angular/documents/nx-and-angular",
"tags": [],
"originalFilePath": "shared/guides/nx-and-angular-cli"
},
{
"id": "nx-devkit-angular-devkit",
"name": "Nx Devkit and Angular Devkit",
"description": "The 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, ESLint, Tailwind CSS, and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
"file": "generated/packages/angular/documents/nx-devkit-angular-devkit",
"itemList": [],
"isExternal": false,
"path": "angular/documents/nx-devkit-angular-devkit",
"tags": ["create-your-own-plugin"],
"originalFilePath": "shared/guides/nx-devkit-angular-devkit"
},
{
"id": "angular-nx-version-matrix",
"name": "Angular and Nx Version Matrix",

403
docs/generated/packages/angular/documents/nx-and-angular.md Normal file
View File

@ -0,0 +1,403 @@
# Nx and the Angular CLI
{% youtube
src="https://www.youtube.com/embed/bwPkz4MrPDI?si=OLPUENWXLkQ9GRtR"
title="Nx vs Angular CLI - The Showdown"
width="100%" /%}
Nx evolved from being an extension of the Angular CLI to a [fully standalone CLI working with multiple frameworks](/getting-started/why-nx#how-does-nx-work). As a result, adopting Nx as an Angular user is relatively straightforward. This guide explores some of the similarities and in particular, added benefits of using Nx over the Angular CLI for your Angular project.
## TL;DR: Why should I use Nx for my Angular project?
Nx...
- helps define clear architectural guidelines and promotes best practices to organize and scale your codebase.
- helps integrate modern tooling by actively working with devtool authors to make sure they work well with Nx and your framework of choice.
- is adaptable: start small with a single-project setup and grow it to a monorepo when needed.
- has an active community of contributors and plugin authors.
- has been proven in large enterprise-level projects.
Note, the Nx team's focus is on building the best possible developer productivity tool.
### Quick Overview Comparison
Here's a quick side-by-side overview comparing the features between the Angular CLI and Nx. _(Kudos to [Daniel Glejzner](https://twitter.com/DanielGlejzner) for helping with this)_
| Feature/Tool | Angular CLI | Nx |
| ----------------------------------------------------------------------------------------------------- | --------------- | ------------- |
| Create Angular Apps | ✅ | ✅ |
| Generate Angular Components, Services, etc. | ✅ | ✅ |
| Building & Bundling | ✅ | ✅ |
| Local Development Server | ✅ | ✅ |
| Code Schematics | ✅ | ✅ |
| Automated Update with Migrations | ✅ | ✅ (Enhanced) |
| Generators | ✅ (Schematics) | ✅ |
| Executors | ✅ (Builders) | ✅ |
| Advanced Generators (e.g. Module Federation, Tailwind,...) | ❌ | ✅ |
| Integrated Tooling (Jest, Cypress, Playwright etc.) | ❌ | ✅ |
| Support for [single-project Workspaces](/getting-started/tutorials/angular-standalone-tutorial) | ✅ | ✅ |
| First-Class [Monorepo Support](/getting-started/tutorials/angular-monorepo-tutorial) | ❌\* | ✅ |
| [Enforced Module Boundaries](/features/enforce-module-boundaries) | ❌ | ✅ |
| Interactive [Project Graph](/features/explore-graph) | ❌ | ✅ |
| Task Graph | ❌ | ✅ |
| [Running Tasks in Parallel](/recipes/running-tasks/run-tasks-in-parallel) | ❌ | ✅ |
| Building, Testing [Only What is Affected](/features/run-tasks#run-tasks-on-projects-affected-by-a-pr) | ❌ | ✅ |
| [Local Caching](/features/cache-task-results) | ❌\*\* | ✅ |
| [Remote Caching](/ci/features/remote-cache) | ❌ | ✅ |
| [Distributed Task Execution on CI](/ci/features/distribute-task-execution) | ❌ | ✅ |
| Custom Hashers | ❌ | ✅ |
| [Extensible Plugin System](/extending-nx/intro/getting-started) | ❌ | ✅ |
{% callout type="info" title="Notes" %}
\* You can setup a monorepo with the Angular CLI creating buildable Angular ng-packagr projects, but the DX is not as optimized compared to what you'd get with Nx.
\*\* The Angular CLI has a [caching mechanism](https://angular.io/cli/cache) which persists the Webpack/ESBuild/"TS incremental build info" cache to disk. Nx leverages that cache as well but in addition adds a more powerful process-level caching on top that is framework agnostic.
{% /callout %}
## Similarities and Differences
Learn about the similarities between the Angular CLI and Nx which makes it easy to [migrate](#migrate-from-the-angular-cli) but also about how Nx goes beyond to further improve your developer productivity.
### Not just for Monorepos: Project Setup & Structure
Nx is not just exclusively for monorepos, but can create
- a single-project workspace (basically what the Angular CLI gives you)
- a monorepo workspace (multiple projects in a single repo)
You can check out the [Angular single-project workspace tutorial](/getting-started/tutorials/angular-standalone-tutorial) to learn more about it.
### Generate a new project
You can create a new Nx single-project workspace using the following command:
```shell
npx create-nx-workspace myngapp --preset=angular-standalone
```
{% callout type="note" title="Want a monorepo instead?" %}
You can use the `--preset=angular-monorepo` to start with a monorepo structure. Note, however, that you can start simple and migrate to a monorepo later.
{% /callout %}
The single-project workspace setup follows a similar structure to what the Angular CLI generates.
```plaintext
└─ myngapp
├─ ...
├─ src
│ ├─ app
│ │ ├─ app.component.css
│ │ ├─ app.component.html
│ │ ├─ app.component.spec.ts
│ │ ├─ app.component.ts
│ │ └─ app.module.ts
│ ├─ assets
│ ├─ favicon.ico
│ ├─ index.html
│ ├─ main.ts
│ └─ styles.css
├─ nx.json
├─ package.json
├─ project.json
├─ ...
```
### project.json vs angular.json
Nx configures projects and their targets in a format similar to `angular.json`. However, instead of storing the configuration for every project in a single large `angular.json` file at the root, the configuration is split into multiple `project.json` files, one for each project.
Smaller, focused config files allow you to quickly find the relevant configuration for the project you are working on, and editing a single project configuration does not cause the `nx affected` command to rerun all the tests in the repo. This conversion is done automatically when you run `nx init`.
Note that even though the configuration is split, everything works similarly. Migrations and schematics written with the Angular devkit 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.
More details: Nx [project configuration](/reference/project-configuration).
### Executors vs. Builders, Generators vs. Schematics
Nx comes with slightly different terminology than the Angular CLI for some features.
**Angular Builders** are called [Executors](/concepts/executors-and-configurations) in Nx but work very much similarly. You use them in your project configuration to define how to build, test, lint, and serve your project. You can use both Nx executors from [Nx Plugins](/plugin-registry) or Angular Builders from the Angular Devkit.
```json
{
"name": "myngapp",
...
"targets": {
"build": {
"executor": "@angular-devkit/build-angular:browser",
...
},
...
}
}
```
**Angular Schematics** are called [Generators](/features/generate-code) in Nx. You can invoke them in the same way as you would with the Angular CLI, but you use the `nx` command instead of `ng`:
```shell
npx nx g @nx/angular:component my-component
```
You can also run Angular Schematics through the Nx CLI. So something like this works as well:
```shell
npx nx g @schematics/angular:component my-component
```
{% callout type="check" title="Important" %}
Support to run Angular Devkit builders and schematics is enabled by installing the [`@nx/angular` plugin](/nx-api/angular/documents/overview). This plugin is installed by default when creating a new Angular workspace with Nx or [migrate an existing Angular CLI workspace to Nx](#migrate-from-the-angular-cli).
{% /callout %}
### Running Commands
Commands are run in the very same way as with the Angular CLI. You just switch `ng` with `nx`. For example:
```shell
npx nx serve
```
Nx has more abilities to run commands in parallel, just for specific projects etc. Find out more [in the docs](/features/run-tasks).
### Integrating with Modern Tools
An Angular-based Nx Workspace already comes with a lot of batteries included:
- Prettier preconfigured
- ESLint
- e2e testing with [Cypress](https://www.cypress.io/) or [Playwright](https://playwright.dev/)
- unit testing with [Jest](https://jestjs.io/)
But Nx expands beyond just that, offering automated integration with a lot of modern tools such as [Storybook](https://storybook.js.org/) or [Tailwind](https://tailwindcss.com/) just to mention a few.
### 'ng update' vs. 'nx migrate'
Like the Angular CLI, Nx has a command that allows you to upgrade your existing workspace tools, packages, and source code to the next version. Instead of `ng update`, you run `nx migrate`:
```shell
npx nx migrate latest
```
What's the difference?
`nx migrate` is a much-improved version of `ng update`. It runs the same migrations but allows you to:
- Rerun the same migration multiple times.
- Reorder migrations.
- Skip migrations.
- Fix migrations that "almost work".
- Commit a partially migrated state.
- Change versions of packages to match org requirements.
- [Opt out of Angular updates when updating Nx versions](/recipes/tips-n-tricks/advanced-update#choosing-optional-package-updates-to-apply) as long as [the Angular version is still supported](/nx-api/angular/documents/angular-nx-version-matrix)
`nx migrate` does this by splitting the process into two steps. `nx migrate latest` creates a `migrations.json` file with a list of all the migrations needed by Nx, Angular, and other packages. You can then modify that file before running `nx migrate --run-migrations` to execute those migrations.
To reiterate: `nx migrate` runs the migrations written by the Angular team the same way `ng update` runs them. So everything should still work. You just get more control over how it works. You can learn more in our docs about [Automate Updating Dependencies](/features/automate-updating-dependencies).
### 'nx add'
The [`nx add` command](/nx-api/nx/documents/add) is similar to the `ng add` command. It installs a given package specifier (e.g. `@nx/react`, `@nx/react@18.1.0`, `@nx/react@latest`) and it runs an `init` or `ng-add` generator if the installed package contains it.
```shell
nx add [package]
```
The command was introduced in **Nx 17.3.0**. If you're using an older version, you can instead run:
{% tabs %}
{% tab label="npm" %}
```shell
npm add [package]
nx g [package]:ng-add
```
{% /tab %}
{% tab label="yarn" %}
```shell
yarn add [package]
nx g [package]:ng-add
```
{% /tab %}
{% tab label="pnpm" %}
```shell
pnpm add [package]
nx g [package]:ng-add
```
{% /tab %}
{% /tabs %}
Replace `[package]` with the package name you're trying to add.
### Speed
Nx is designed to be fast. The Angular CLI leverages Webpack's caching, which Nx also does since it relies on the Angular Devkit when it comes to compiling or running apps. But Nx goes way beyond that, introducing features vital for a fast CI experience, mainly when you have a monorepo.
Features like
- only running tasks on [affected projects](/ci/features/affected)
- running [tasks in parallel](/features/run-tasks#run-tasks-for-multiple-projects)
- applying [computation caching](/features/cache-task-results)
- offering [remote caching abilities](/ci/features/remote-cache) on CI
- offering [task distribution across machines (Nx Agents)](/ci/features/distribute-task-execution)
And, Nx already uses fast, modern tooling like [ESBuild](/nx-api/esbuild), [Vite](/nx-api/vite), Vitest and [Rspack](/nx-api/rspack) for non-Angular stacks. So once Angular is ready to use these tools, Nx will also be ready.
### Editor Integration
Nx goes beyond being just a CLI and comes with [Nx Console](/getting-started/editor-setup), a VSCode and WebStorm extension allowing you to run commands, generate code and visualize your workspace.
![Nx Console screenshot](/shared/images/nx-console/nx-console-screenshot.webp)
### Scaling: Start Simple, Grow to a Monorepo
Nx is really made to scale with you. You can
- start small with a single-project workspace
- modularize your application into more fine-grained libraries for better maintainability as your application (and team) grows ([more about that here](/getting-started/tutorials/angular-standalone-tutorial#modularizing-your-angular-app-with-local-libraries)), including mechanisms to make sure [things stay within their boundaries](/features/enforce-module-boundaries)
- you can then migrate to a monorepo when you are ready and need one ([more here](/recipes/tips-n-tricks/standalone-to-integrated))
- or even [add Webpack Module Federation support](/recipes/angular/module-federation-with-ssr)
### Visualize your Workspace
As you start modularizing your Angular workspace, Nx can visualize it using the `nx graph` command or via [Nx Console](/getting-started/editor-setup) directly in your editor.
{% graph height="450px" %}
```json
{
"hash": "58420bb4002bb9b6914bdeb7808c77a591a089fc82aaee11e656d73b2735e3fa",
"projects": [
{
"name": "shared-product-state",
"type": "lib",
"data": {
"tags": ["scope:shared", "type:state"]
}
},
{
"name": "shared-product-types",
"type": "lib",
"data": {
"tags": ["type:types", "scope:shared"]
}
},
{
"name": "shared-product-data",
"type": "lib",
"data": {
"tags": ["type:data", "scope:shared"]
}
},
{
"name": "cart-cart-page",
"type": "lib",
"data": {
"tags": ["scope:cart", "type:feature"]
}
},
{
"name": "shared-styles",
"type": "lib",
"data": {
"tags": ["scope:shared", "type:styles"]
}
},
{
"name": "cart-e2e",
"type": "e2e",
"data": {
"tags": ["scope:cart", "type:e2e"]
}
},
{
"name": "cart",
"type": "app",
"data": {
"tags": ["type:app", "scope:cart"]
}
}
],
"dependencies": {
"shared-product-state": [
{
"source": "shared-product-state",
"target": "shared-product-data",
"type": "static"
},
{
"source": "shared-product-state",
"target": "shared-product-types",
"type": "static"
}
],
"shared-product-types": [],
"shared-product-data": [
{
"source": "shared-product-data",
"target": "shared-product-types",
"type": "static"
}
],
"shared-e2e-utils": [],
"cart-cart-page": [
{
"source": "cart-cart-page",
"target": "shared-product-state",
"type": "static"
}
],
"shared-styles": [],
"cart-e2e": [
{ "source": "cart-e2e", "target": "cart", "type": "implicit" }
],
"cart": [
{ "source": "cart", "target": "shared-styles", "type": "implicit" },
{ "source": "cart", "target": "cart-cart-page", "type": "static" }
]
},
"workspaceLayout": {
"appsDir": "apps",
"libsDir": "libs"
},
"affectedProjectIds": [],
"focus": null,
"groupByFolder": false,
"exclude": [],
"enableTooltips": true
}
```
{% /graph %}
Learn more about the [graph features here](/features/explore-graph).
### Extensible and Customizable: Make it fit your own needs
Nx is [built to be extensible](/getting-started/why-nx#how-does-nx-work). Just like the [packages published by the Nx core team](/nx-api) you can create your own Nx plugins by [extending Nx](/extending-nx/intro/getting-started). This can be as simple as using [run-commands](/nx-api/nx/executors/run-commands) to integrate custom commands into the project configuration or as complex as [creating your own local executor](/extending-nx/recipes/local-executors).
And if you ever need to expand beyond Angular or diversify your stack, you can still keep using Nx, which is [battle-tested with many different technologies](/getting-started/intro#pick-your-stack).
## Migrate from the Angular CLI?
Migrating an Angular CLI project to Nx can be done by running
```shell
npx nx@latest init
```
or alternatively using the `--integrated` flag if you want to create an Nx monorepo right away. Learn more about all the details on the [dedicated docs page](/recipes/angular/migration/angular).
There is also a guide describing how to [consolidate multiple Angular CLI projects into a single Nx monorepo](/recipes/angular/migration/angular-multiple).
You can learn more about Angular & Nx by following our dedicated tutorials:
- [Tutorial: Building Angular Apps with the Nx Standalone Projects Setup](/getting-started/tutorials/angular-standalone-tutorial)
- [Tutorial: Building Angular Apps in an Nx Monorepo](/getting-started/tutorials/angular-monorepo-tutorial)

201
docs/generated/packages/angular/documents/nx-devkit-angular-devkit.md Normal file
View File

@ -0,0 +1,201 @@
# Nx Devkit and Angular Devkit
{% callout type="note" title="Nx & Angular" %}
This document covers the difference between Nx Devkit and Angular Devkit. See the [Nx Devkit](/nx-api/devkit/documents/nx_devkit) guide for more in-depth details about Nx Devkit.
{% /callout %}
Nx comes with a devkit to write generators and executors, but you can also use Angular devkit (schematics and builders). In other words, you can use an Angular schematic to implement a generator, and you can use an Angular builder to implement an executor.
{% callout type="check" title="Important" %}
Support to run Angular Devkit builders and schematics is enabled by installing the [`@nx/angular` plugin](/nx-api/angular/documents/overview). This plugin is installed by default when creating a new Angular workspace with Nx or [migrate an existing Angular CLI workspace to Nx](/recipes/angular/migration/angular).
{% /callout %}
**What are the differences between Nx Devkit and Angular Devkit?**
## Generators
The following is a generator written using Nx Devkit:
```typescript
import { Tree, formatFiles, generateFiles } from '@nx/devkit';
import * as path from 'path';
interface Schema {
name: string;
skipFormat: boolean;
}
export default async function (tree: Tree, options: Schema) {
generateFiles(
tree,
path.join(__dirname, 'files'),
path.join('tools/generators', schema.name),
options
);
if (!schema.skipFormat) {
await formatFiles(tree);
}
}
```
The following is an analogous generator written as an Angular Schematic.
```typescript
import {
apply,
branchAndMerge,
chain,
mergeWith,
Rule,
template,
url,
move,
} from '@angular-devkit/schematics';
import { formatFiles } from '@nx/workspace';
import { toFileName } from '@nx/workspace';
interface Schema {
name: string;
skipFormat: boolean;
}
export default function (options: Schema): Rule {
const templateSource = apply(url('./files'), [
template({
dot: '.',
tmpl: '',
...(options as any),
}),
move('tools/generators'),
]);
return chain([
branchAndMerge(chain([mergeWith(templateSource)])),
formatFiles(options),
]);
}
```
### Notable Differences
- Nx Devkit generators do not use partial application. An Angular Schematic returns a rule that is then invoked with a tree.
- Nx Devkit generators do not use RxJS observables. Instead, you invoke the helpers directly, which makes them more debuggable. As you step through the generator you can see the tree being updated.
- There are more affordances for commonly used operations. For instance, `chain([mergeWith(apply(url` is replaced with `generateFiles`)
- Nx Devkit generators return a function that performs side effects. Angular Schematics have to create a custom task runner and register a task using it.
- Nx Devkit generators are composed as any other JS function. You do need to go through a special resolution step (`externalSchematic`) that is required when using Angular Schematics.
- No special utilities are needed to test Nx Devkit generators. Special utilities are needed to test Angular Schematics.
### Conversions
The Nx CLI can invoke Nx Generator or Angular Schematics directly. When the user runs:
```shell
nx g mygenerator params
nx g myschematic params
```
The Nx CLI will identify whether it is running an Nx generator or an Angular schematic and will invoke it using the right machinery. The user doesn't have to know how the generator is implemented.
At times, however, it might be useful to use an Nx Devkit generator in an Angular Schematic or vice versa.
**Making an Angular Schematic out of Nx Devkit Generator:**
First, you need to
```typescript
export async function mygenerator(tree: Tree, options: Schema) {
// ...
}
export const mygeneratorSchematic = convertNxGenerator(mygenerator);
```
Then, you might need to register it in the `collections.json`:
```json
{
"name": "Nx React",
"version": "0.1",
"extends": ["@nx/workspace"],
"schematics": {
"mygenerator": {
"factory": "./src/generators/mygenerator/mygenerator#mygeneratorSchematic",
"schema": "./src/generators/mygenerator/schema.json"
}
},
"generators": {
"init": {
"factory": "./src/generators/mygenerator/mygenerator#mygenerator",
"schema": "./src/generators/mygenerator/schema.json"
}
}
}
```
**Making an Nx Devkit Generator out of Angular Schematic:**
```typescript
export const libraryGenerator = wrapAngularDevkitSchematic(
'@schematics/angular',
'library'
);
export async function mygenerator(tree: Tree, options: Schema) {
await libraryGenerator(tree, options);
}
```
## Executors
The following is an executor written using Nx Devkit:
```typescript
interface Schema {
message: string;
allCaps: boolean;
}
export default async function (
options: Schema,
context: ExecutorContext
): Promise<{ success: true }> {
if (options.allCaps) {
console.log(options.message.toUpperCase());
} else {
console.log(options.message);
}
return { success: true };
}
```
The following is an analogous executor written as an Angular builder:
```typescript
interface Schema {
message: string;
allCaps: boolean;
}
export function run(
options: Schema,
context: BuilderContext
): Observable<{ success: true }> {
if (options.allCaps) {
console.log(options.message.toUpperCase());
} else {
console.log(options.message);
}
return of({ success: true });
}
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.
- 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.
## When to Use What
If you are writing an Nx plugin, use Nx Devkit. It's **much** easier to use and debug. It has better docs and more people supporting it.
Do you have to rewrite your Nx Plugin if it is written using Angular Devkit? No. Nx supports both and will always support both. And, most importantly, the end user might not even know what you used to write a generator or an executor.

2
docs/generated/packages/angular/executors/webpack-browser.json
View File

@ -7,7 +7,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\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications. \n> You can read more about when to use incremental builds [here](/concepts/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\": \"@nx/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\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n}\n```\n",
"type": "object",
"presets": [
{

55
docs/map.json
View File

@ -315,18 +315,6 @@
"id": "more-concepts",
"description": "Get deeper into how Nx works and its different aspects.",
"itemList": [
{
"name": "Incremental Builds",
"id": "incremental-builds",
"tags": [],
"file": "shared/incremental-builds"
},
{
"name": "Nx and Turborepo",
"id": "turbo-and-nx",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx"
},
{
"name": "Monorepos",
"id": "why-monorepos",
@ -342,32 +330,16 @@
"id": "code-sharing",
"file": "shared/concepts/code-sharing"
},
{
"name": "Using Nx at Enterprises",
"id": "monorepo-nx-enterprise",
"tags": ["enforce-module-boundaries", "generate-code"],
"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",
"tags": ["create-your-own-plugin"],
"file": "shared/guides/nx-devkit-angular-devkit"
"name": "Nx and Turborepo",
"id": "turbo-and-nx",
"mediaImage": "./shared/guides/nx-media-monorepo.jpg",
"file": "shared/guides/turbo-and-nx"
},
{
"name": "Applications and Libraries",
@ -376,7 +348,7 @@
"file": "shared/workspace/applications-and-libraries"
},
{
"name": "Creating Libraries",
"name": "When to Create a New Library",
"id": "creating-libraries",
"tags": ["enforce-module-boundaries"],
"file": "shared/workspace/creating-libraries"
@ -397,12 +369,6 @@
"name": "Buildable and Publishable Libraries",
"id": "buildable-and-publishable-libraries",
"file": "shared/workspace/buildable-and-publishable-libraries"
},
{
"name": "How the Project Graph is Built",
"id": "how-project-graph-is-built",
"tags": ["explore-graph", "inferred-tasks"],
"file": "shared/concepts/how-project-graph-is-built"
}
]
}
@ -2260,6 +2226,17 @@
"path": "/nx-api/angular",
"file": "shared/packages/angular/angular-plugin"
},
{
"name": "Nx and the Angular CLI",
"id": "nx-and-angular",
"file": "shared/guides/nx-and-angular-cli"
},
{
"name": "Nx Devkit and Angular Devkit",
"id": "nx-devkit-angular-devkit",
"tags": ["create-your-own-plugin"],
"file": "shared/guides/nx-devkit-angular-devkit"
},
{
"name": "Angular and Nx Version Matrix",
"id": "angular-nx-version-matrix",

8
docs/shared/angular-standalone-tutorial/angular-standalone.md
View File

@ -105,10 +105,10 @@ The setup includes:
Compared to the Angular CLI, you might notice the addition of an `nx.json` file and the absence of an `angular.json` file. Instead of the `angular.json` file there is a `project.json` file. Each file is described below:
| File | Description |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `nx.json` | This is where we can fine-tune how Nx works, define the [cacheable operations](/features/cache-task-results), our [task pipelines](/concepts/task-pipeline-configuration) as well as defaults for the Nx generators. Find more details in [the reference docs](/reference/nx-json). |
| `project.json` | Nx uses this file to define targets that can be run, similar to how the Angular CLI uses the `angular.json` file. If you're familiar with the Angular CLI you should have no difficulty navigating the `project.json` file. If you're curious how the two compare, you can learn more in [the Nx and Angular CLI comparision article](/concepts/more-concepts/nx-and-angular). The [project-configuration documentation page](/reference/project-configuration) has more details on how to use the `project.json` file. |
| File | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `nx.json` | This is where we can fine-tune how Nx works, define the [cacheable operations](/features/cache-task-results), our [task pipelines](/concepts/task-pipeline-configuration) as well as defaults for the Nx generators. Find more details in [the reference docs](/reference/nx-json). |
| `project.json` | Nx uses this file to define targets that can be run, similar to how the Angular CLI uses the `angular.json` file. If you're familiar with the Angular CLI you should have no difficulty navigating the `project.json` file. If you're curious how the two compare, you can learn more in [the Nx and Angular CLI comparision article](/nx-api/angular/documents/nx-and-angular). The [project-configuration documentation page](/reference/project-configuration) has more details on how to use the `project.json` file. |
## Serving the App

12
docs/shared/angular-tutorial/angular-monorepo.md
View File

@ -26,11 +26,11 @@ Advantages of Nx over the Angular CLI:
- [Cache any target](/features/cache-task-results)
- [Run only tasks affected by a code change](/ci/features/affected)
- [Split a large angular.json into multiple project.json files](/concepts/more-concepts/nx-and-angular#projectjson-vs-angularjson)
- [Integrate with modern tools](/concepts/more-concepts/nx-and-angular#integrating-with-modern-tools)
- [Controllable update process](/concepts/more-concepts/nx-and-angular#ng-update-vs-nx-migrate)
- [Split a large angular.json into multiple project.json files](/nx-api/angular/documents/nx-and-angular#projectjson-vs-angularjson)
- [Integrate with modern tools](/nx-api/angular/documents/nx-and-angular#integrating-with-modern-tools)
- [Controllable update process](/nx-api/angular/documents/nx-and-angular#ng-update-vs-nx-migrate)
Visit our ["Nx and the Angular CLI" page](/concepts/more-concepts/nx-and-angular) for more details.
Visit our ["Nx and the Angular CLI" page](/nx-api/angular/documents/nx-and-angular) for more details.
## Final Code
@ -106,7 +106,7 @@ The setup includes:
- ESLint preconfigured
- Jest preconfigured
Typically, an integrated Nx workspace places application projects in the `apps` folder and library projects in the `libs` folder. [Applications are encouraged to be as light-weight as possible](/concepts/more-concepts/applications-and-libraries) so that more code is pushed into libraries and can be reused in other projects. This [folder structure](/concepts/more-concepts/folder-structure) is just a suggestion and can be modified to suit your organization's needs.
Typically, an integrated Nx workspace places application projects in the `apps` folder and library projects in the `libs` folder. [Applications are encouraged to be as light-weight as possible](/concepts/more-concepts/applications-and-libraries) so that more code is pushed into libraries and can be reused in other projects. This folder structure is just a suggestion and can be modified to suit your organization's needs.
The [`nx.json` file](/reference/nx-json) contains configuration settings for Nx itself and global default settings that individual projects inherit. The `apps/angular-store/project.json` file contains [settings that are specific to the `angular-store` project](/reference/project-configuration). We'll examine that file more in the next section.
@ -1261,7 +1261,7 @@ Check out one of these detailed tutorials on setting up CI with Nx:
Here's some things you can dive into next:
- Read more about [how Nx compares to the Angular CLI](/concepts/more-concepts/nx-and-angular)
- Read more about [how Nx compares to the Angular CLI](/nx-api/angular/documents/nx-and-angular)
- Learn more about the [underlying mental model of Nx](/concepts/mental-model)
- Learn about popular generators such as [how to setup Tailwind](/recipes/angular/using-tailwind-css-with-angular-projects)
- Learn how to [migrate your existing Angular CLI repo to Nx](/recipes/angular/migration/angular)

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

@ -1,62 +0,0 @@
# How the Project Graph is Built
Nx creates a graph of all the dependencies between projects in your workspace using three sources of information:
1. Package dependencies defined in the `package.json` file for each project.
If the `myapp/package.json` file has this dependency:
```jsonc {% fileName="myapp/package.json"%}
{
"dependencies": {
"@myorg/awesome-library": "*"
}
}
```
Then `my-app` depends on `awesome-library`.
Note: We typically use `*` for the dependency instead of a specific version because we want to depend on the version of the library as it currently exists in the repo.
2. 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`
This can be [turned on or off with the `analyzeSourceFiles` flag](../../recipes/tips-n-tricks/analyze-source-files).
3. Manually created `implicitDependencies` in the project configuration file.
If your project configuration has this content:
{% tabs %}
{% tab label="package.json" %}
```jsonc {% fileName="package.json"%}
{
"name": "myapp",
"nx": {
"implicitDependencies": ["some-api"]
}
}
```
{% /tab %}
{% tab label="project.json" %}
```jsonc {% fileName="project.json"%}
{
"root": "/libs/myapp",
"implicitDependencies": ["some-api"]
}
```
{% /tab %}
{% /tabs %}
Then `my-app` depends on `some-api`.

2
docs/shared/features/explore-graph.md
View File

@ -38,7 +38,7 @@ Each target has different options which determine how Nx runs the task.
Nx understands the projects in your workspace as a graph and uses this understanding to behave intelligently.
Exploring this graph visually is vital to understanding how your code is structured and how Nx behaves.
It always stays up to date without having to actively maintain a document as it is [calculated by analyzing your source code](/concepts/more-concepts/how-project-graph-is-built#how-the-project-graph-is-built)
It always stays up to date without having to actively maintain a document as it is calculated by analyzing your source code.
### Launching the Project Graph

23
docs/shared/guides/integrated-repo-folder-structure.md
View File

@ -1,23 +0,0 @@
# 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:
```text
myorg/
├── apps/
├── libs/
├── tools/
├── 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, [local executors](/extending-nx/recipes/local-executors), or [local generators](/extending-nx/recipes/local-generators).
`/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.

BIN
docs/shared/incremental-build-webpack-vs-incremental.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

87
docs/shared/incremental-builds.md
View File

@ -1,87 +0,0 @@
# Incremental Builds
As your applications are getting bigger, one of the main ways to scale your development is to build them in an incremental fashion.
Right now, for instance, say we generate an application and a library as follows:
```shell
nx g @nx/react:app myapp
nx g @nx/react:lib mylib
```
...and then import the library from the application. In this case, `mylib` isn't a buildable library. We can test and lint it independently, but the only way to build it is by building some application using it (in this case `myapp`). The default setup is to use Webpack, which builds "mylib" and bundles it directly into "myapp".
This provides the best dev experience for small and medium-size applications, because Webpack is optimized for this scenario. But as your application keeps growing, the dev experience degrades.
> The **duration** of the invoked operations should be **proportional** to the **size of the change**
## Publishable and Buildable Libraries
Nx has **publishable libraries**. As the name suggests, such libraries are meant to be built and published to some package registry s.t. they can be consumed also from outside the Nx workspace. The executor for building a publishable library does more than just building. It makes sure the output is properly compressed and might even produce more bundles s.t. the package can be consumed in a variety of ways (e.g. also produces UMD bundles).
```shell
nx g @nx/react:lib mylib --publishable --importPath=@myorg/mylib
```
On the other hand, the executor of a **buildable library**, performs a subset of the operations compared to the publishable library's executor. That's because buildable libraries are not intended to be published and thus only produce the minimum necessary output for the incremental build scenario to work. For example, no UMD bundles or minification is being done. The main goal of the executor is to perform the build as fast as possible.
```shell
nx g @nx/react:lib mylib --buildable
```
Read more
about [Publishable and Buildable Nx Libraries here.](/concepts/more-concepts/buildable-and-publishable-libraries)
## Nx computation cache and Nx Cloud
In an incremental build scenario, when building the app, all it's dependencies need to be built first. In our scenario above, that means we need to first run `nx build mylib` and then `nx build myapp`. As the number of libraries grows, running these commands quickly becomes unmanageable. Instead, we can run `nx build myapp`.
It is costly to rebuild all the buildable libraries from scratch every time you want to serve the app. That's why the Nx computation caching is so important. The caching allows us to only rebuild a small subset of the libraries, which results in much better performance.
If we can share the cache with our teammates, we can get a much better dev experience. For instance, [this repo](https://github.com/nrwl/nx-incremental-large-repo) has a large application, where `nx serve` takes just a few seconds.
{% github-repository url="https://github.com/nrwl/nx-incremental-large-repo" /%}
![comparison: webpack vs incremental build](/shared/incremental-build-webpack-vs-incremental.png)
The above chart has three different test runs:
- **Normal build -** which visualizes using the normal Angular webpack setup executing “nx build” (blue), “nx serve” (red) and the time to rebuild/re-serve when a file change happened (yellow)
- **Incremental build (cold) -** running all the above commands but using the Nx incremental builds but without having any kind of cache. That run takes slightly more than the normal Webpack build, which is expected.
- **Incremental build (warm) -** running the Nx incremental build having already cached results from a previous run or from some other coworker that executed the build before. In a real world scenario, we expect always some kind of cached results either of the entire workspace or part of it. This is where the teams really get the value and speed improvements.
## When should I use incremental builds
Whether incremental builds are a good choice depends on your repository. For most small and mid-sized applications, the costs introduced by incremental builds will outweigh the benefits.
The upsides of incremental builds:
- Compiling only a subset of code
- Distributing the compilation
The downsides of incremental builds:
- Complex "watch" mode
- Overhead with initializing the TypeScript compiler multiple times
- The linking part of a WebPack build is indivisible
If you are only planning to use incremental builds to speed up your CI, then the watch mode concern is irrelevant, and the only thing you need to assess is whether the benefits of skipping the compilation outweigh the costs of initializing the TypeScript compiler several times.
## Custom Serve Target with Webpack
If you are implementing a custom serve command, you can use `WebpackNxBuildCoordinationPlugin` provided by `@nx/webpack`. It's a webpack plugin you can use to coordinate the compiling of the libs and the webpack linking.
## Using Webpack Module Federation to implement incremental builds
When we talk about incremental builds we often talk about incrementally compiling the code and then linking them with a single webpack build. In this case the build artifact when using incremental builds is the same as without using incremental builds, but the build process itself has different characteristics.
But there are other ways to make the build process incremental. One of them is using WebPack Module Federation.
When using WebPack Module Federation, you split the application into multiple webpack builds. Imagine the application has 3 big sections, and they are built using 3 webpack builds: `W1`, `W2`, and `W3`. Each of them has to build shared code in addition to building the corresponding application section code. So the time it takes to build all of them (`W1` + `W2` + `W3`) will be greater than `W`. However, if you change only Section 1, you will only need to run `W1`. `W2` and `W3` will be retrieved from cache. In addition, `W1`, `W2`, and `W3` can run on separate machines. Because of that, both the CI time and the local serve time can be drastically reduced.
Learn more: [Faster Builds with Module Federation](/concepts/module-federation/faster-builds-with-module-federation)
## See Also
- [Enable Typescript Batch Mode](/recipes/tips-n-tricks/enable-tsc-batch-mode)
- [Typescript Batch Mode Benchmark](/showcase/benchmarks/tsc-batch-mode)

2
docs/shared/migration/migration-angular.md
View File

@ -132,7 +132,7 @@ Once the script has run, commit the changes. Reverting this commit will effectiv
{% cards cols="1" mdCols="3" smCols="3" lgCols="3" %}
{% card title="Nx and the Angular CLI" description="Differences between Nx and the Angular CLI" type="documentation" url="/concepts/more-concepts/nx-and-angular" /%}
{% card title="Nx and the Angular CLI" description="Differences between Nx and the Angular CLI" type="documentation" url="/nx-api/angular/documents/nx-and-angular" /%}
{% card title="Multiple Angular Repositories to one Nx Workspace" description="Combine multiple Angular CLI workspaces into one Nx workspace" type="documentation" url="/recipes/angular/migration/angular-multiple" /%}

231
docs/shared/monorepo-nx-enterprise.md
View File

@ -1,231 +0,0 @@
# Using Nx at Enterprises
Nx is a great tool for companies of all sizes. These days even small products have several microservices and several
frontends (say desktop and mobile) which are often built by distributed teams. Being able to do this type of development
holistically, using modern tools, is as important for a startup as it is for a well-established organization.
Some things, however, are much more important for large companies:
- Code organization & naming conventions
- Code ownership
- Enforcing best practices
- Developer workflow
- Deployment flexibility
{% callout type="note" title="Do what is best for you" %}
Everything below are just recommendations. Every large organization has unique needs, so treat this document as a
starting point not the definite list of what you must and must not do.
{% /callout %}
## Code Organization & Naming Conventions
### Apps and Libs
- Apps configure dependency injection and wire up libraries. They should not contain any components, services, or
business logic.
- Libs contain services, components, utilities, etc. They have well-defined public API.
A typical Nx workspace has many more libs than apps, so pay especially careful attention to the organization of the libs
directory.
### Scope (Where a library lives, who owns it)
It's a good convention to put applications-specific libraries into the directory matching the application name. This
provides enough organization for small to mid-size applications.
```treeview
happynrwl/
├── apps/
│ ├── happynrwlapp/
│ ├── happynrwlapp-e2e/
│ ├── adminapp/
│ └── adminapp-e2e/
├── libs/
│ ├── happynrwlapp/
│ │ ├── feature-main/
│ │ ├── ui-table/
│ │ └── utils-testing/
│ ├── adminapp/
│ │ ├── feature-main/
│ │ ├── feature-login/
│ │ ├── ui/
│ │ └── utils-testing/
│ └── shared/
│ ├── ui/
│ └── utils-testing/
├── tools/
├── nx.json
├── package.json
└── tsconfig.base.json
```
For larger projects, it is a good idea to group libraries into application sections.
```treeview
happynrwl/
├── apps/
├── libs/
│ ├── happynrwlapp/
│ │ ├── registration/
│ │ │ ├── feature-main/
│ │ │ ├── feature-login/
│ │ │ ├── ui-form/
│ │ │ └── utils-testing/
│ │ ├── search/
│ │ │ ├── feature-results/
│ │ │ └── utils-testing/
│ │ └── shared/
│ │ └── ui/
│ ├── adminapp/
| └── shared/
│ ├── ui/
│ └── utils-testing/
├── tools/
├── nx.json
├── package.json
└── tsconfig.base.json
```
Here we have:
- `happynrwlapp/registration/feature-main`--a scoped library used in one place
- `happynrwlapp/shared/ui`--a shared library used in a single application
- `shared/ui`--a shared library used across applications
**Portal**
Many enterprise applications are portals: slim shells loading different modules at runtime. If this is what you are
building, the following might be a better starting point:
```treeview
happynrwl/
├── apps/
│ ├── happynrwlapp/
│ ├── happynrwlapp-e2e/
├── libs/
│ ├── shell/
│ │ └── feature-main
│ ├── registration/
│ │ ├── feature-main/
│ │ ├── feature-login/
│ │ ├── ui-form/
│ │ └── utils-testing/
│ ├── search/
│ │ ├── feature-results/
│ │ └── utils-testing/
│ └── shared/
│ ├── ui/
│ └── utils-testing/
├── tools/
├── nx.json
├── package.json
└── tsconfig.base.json
```
### Type (What is in the library)
With Nx, we can partition our code into small libraries with well-defined public API. So we can categorize our libraries
based on what they contain.
**These are some common library types:**
- Utility libraries contain utilities and services.
- Data-access can contain NgRx-related code.
- Component libraries should contain presentational components and directives.
- Feature libraries contain business logic, application screens, etc.
This categorization is a good starting point, but other library types are quite common too (e.g., mock libraries). It's
a good idea to establish naming conventions (e.g., `utilities-testing`, `components-buttons`). Having them helps
developers explore the code and feel comfortable no matter where they are in the repository.
### Managing Dependencies
For a large organization it's crucial to establish how projects can depend on each other. For instance:
- Libraries with a broader scope (e.g., `shared/ui`) should not depend on the libraries with narrower scope (
e.g., `happynrwlapp/search/utils-testing`).
- Component libraries should only depend on other component libraries and utility libraries, but should not depend on
feature libraries.
Nx provides a feature called tags that can be used to codify and statically-enforce these rules. Read more about
tags [here](/features/enforce-module-boundaries).
## Code Ownership
It's crucial for a large company with multiple teams contributing to the same repository to establish clear code
ownership.
Since Nx allows us to group apps and libs in directories, those directories can become code-ownership boundaries. That's
why the structure of an Nx workspace often reflects the structure of an organization. GitHub users can use
the `CODEOWNERS` file for that.
```plaintext
/libs/happynrwlapp julie-happynrwlapp-lead
/apps/happynrwlapp julie-happynrwlapp-lead
/libs/shared/ui hank-the-ui-guy
/libs/shared/utils-testing julie,hank
```
If you want to know more about code ownership on GitHub, please
check [the documentation on the `CODEOWNERS` file](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
## Enforcing Best Practices
When we have 10 people working on an app in the same room, we can agree on best practices over lunch. We can also make
sure the team follows them by reviewing each other's PRs. For a team of a hundred located in different cities, this no
longer works.
With Nx, we can help teams adopt best practices by using workspace generators and workspace lint checks.
### Workspace Generators
Generators is a library used by Nx to do code generation. `nx g lib mylib` invokes the lib generator from the default
collection. Generators are a great way to codify conventions and best practices. Unfortunately, creating a custom
generators collection is not very straightforward, so few do it.
Nx simplifies it. With Nx, we can create custom generators in the `tools/generators` folder and invoke them without
having to do compile, build, deploy anything.
Read more about workspace generators in the Workspace Generators guide.
### Workspace Lint Checks
Custom lint checks is another great way to enforce best practices. We can create custom lint checks in the `tools/lint`
directory and then register them in `.eslintrc.json`.
## Developer Workflow
Embracing the monorepo-style development often requires some changes to the development workflow.
**Our CI should run the following checks:**
- It checks that the changed code is formatted properly. (`nx format:check`)
- It runs lint checks for all the projects affected by a PR/commit.
- It runs unit tests for all the projects affected by a PR/commit.
- It runs e2e tests for all the apps affected by a PR/commit.
- It rebuilds all the apps affected by a PR/commit.
Note `all the projects affected by a PR/commit`. This is very important. Monorepo-style development only works if we
rebuild, retest, and relint only the projects that can be affected by our changes. If we instead retest everything, we
will get the following problems:
- The performance of CI checks will degrade over time. The time it takes to run the CI checks should be proportional to
the impact of the change, not the size of the repo.
- We will be affected by the code your change didn't touch
We should utilize `affected:*` commands to build and test projects. Read more about
them [here](/nx-api/nx/documents/affected).
### Trunk-based development
Monorepo-style development works best when used with trunk-based development.
When using trunk-based development, we have a single main branch (say `main`) where every team submits their code. And
they do it as soon as possible. So if someone works on a large feature, they split it into a few small changes that can
be integrated into main in a week. In other words, when using trunk-based development, teams can create branches, but
they are short-lived and focus on a specific user story.
One issue folks often raise in regard to trunk-based development is "things change under you while you are trying to
create a release". This can definitely happen, especially when manual testing is involved. To mitigate we can create a
release branch where we would cherry-pick commits from `main` to. With this, we can still frequently merge code
into `main` and have our release isolated from changes made by other teams.

2
docs/shared/react-tutorial/react-monorepo.md
View File

@ -103,7 +103,7 @@ The setup includes..
- ESLint preconfigured
- Jest preconfigured
Typically, an integrated Nx workspace places application projects in the `apps` folder and library projects in the `libs` folder. [Applications are encouraged to be as light-weight as possible](/concepts/more-concepts/applications-and-libraries) so that more code is pushed into libraries and can be reused in other projects. This [folder structure](/concepts/more-concepts/folder-structure) is just a suggestion and can be modified to suit your organization's needs.
Typically, an integrated Nx workspace places application projects in the `apps` folder and library projects in the `libs` folder. [Applications are encouraged to be as light-weight as possible](/concepts/more-concepts/applications-and-libraries) so that more code is pushed into libraries and can be reused in other projects. This folder structure is just a suggestion and can be modified to suit your organization's needs.
The [`nx.json` file](/reference/nx-json) contains configuration settings for Nx itself and global default settings that individual projects inherit. The `apps/react-store/project.json` file contains [settings that are specific to the `react-store` project](/reference/project-configuration). We'll examine that file more in the next section.

2
docs/shared/recipes/storybook/one-storybook-per-scope.md
View File

@ -8,7 +8,7 @@ description: Learn how to set up individual Storybook instances for each scope w
This guide extends the
[Using Storybook in a Nx workspace - Best practices](/nx-api/storybook/documents/best-practices) guide. In that guide, we discussed the best practices of using Storybook in a Nx workspace. We explained the main concepts and the mental model of how to best set up Storybook. In this guide, we are going to see how to put that into practice, by looking at a real-world example. We are going to see how you can publish one Storybook per scope (eg. theme, app, framework) for your workspace.
Sometimes, you have multiple apps and libraries, and each of these is associated with a specific scope. You can read more about grouping libraries and scoping them in the [Library Types](/concepts/more-concepts/library-types) documentation page, and also in the [Code Organization and Naming Conventions](/concepts/more-concepts/monorepo-nx-enterprise#code-organization-&-naming-conventions) documentation section.
Sometimes, you have multiple apps and libraries, and each of these is associated with a specific scope. You can read more about grouping libraries and scoping them in the [Library Types](/concepts/more-concepts/library-types) documentation page.
In this case, you can have one Storybook instance per scope. If you follow the folder organization convention described above, it is easy to configure Storybook to import all the stories under a specific folder, for example, which are associated with a specific app or scope.

12
docs/shared/reference/sitemap.md
View File

@ -43,22 +43,16 @@
- [Micro Frontend Architecture](/concepts/module-federation/micro-frontend-architecture)
- [Manage Library Versions with Module Federation](/concepts/module-federation/manage-library-versions-with-module-federation)
- [More Concepts](/concepts/more-concepts)
- [Incremental Builds](/concepts/more-concepts/incremental-builds)
- [Nx and Turborepo](/concepts/more-concepts/turbo-and-nx)
- [Monorepos](/concepts/more-concepts/why-monorepos)
- [Dependency Management](/concepts/more-concepts/dependency-management)
- [Code Sharing](/concepts/more-concepts/code-sharing)
- [Using Nx at Enterprises](/concepts/more-concepts/monorepo-nx-enterprise)
- [Nx Daemon](/concepts/more-concepts/nx-daemon)
- [Nx and the Angular CLI](/concepts/more-concepts/nx-and-angular)
- [Folder Structure](/concepts/more-concepts/folder-structure)
- [Nx Devkit and Angular Devkit](/concepts/more-concepts/nx-devkit-angular-devkit)
- [Nx and Turborepo](/concepts/more-concepts/turbo-and-nx)
- [Applications and Libraries](/concepts/more-concepts/applications-and-libraries)
- [Creating Libraries](/concepts/more-concepts/creating-libraries)
- [When to Create a New Library](/concepts/more-concepts/creating-libraries)
- [Library Types](/concepts/more-concepts/library-types)
- [Grouping Libraries](/concepts/more-concepts/grouping-libraries)
- [Buildable and Publishable Libraries](/concepts/more-concepts/buildable-and-publishable-libraries)
- [How the Project Graph is Built](/concepts/more-concepts/how-project-graph-is-built)
- [Recipes](/recipes)
- [Installation](/recipes/installation)
- [Install Nx in a Non-Javascript Repo](/recipes/installation/install-non-javascript)
@ -317,6 +311,8 @@
- [angular](/nx-api/angular)
- [documents](/nx-api/angular/documents)
- [Overview](/nx-api/angular/documents/overview)
- [Nx and the Angular CLI](/nx-api/angular/documents/nx-and-angular)
- [Nx Devkit and Angular Devkit](/nx-api/angular/documents/nx-devkit-angular-devkit)
- [Angular and Nx Version Matrix](/nx-api/angular/documents/angular-nx-version-matrix)
- [executors](/nx-api/angular/executors)
- [delegate-build](/nx-api/angular/executors/delegate-build)

2
docs/shared/workspace/buildable-and-publishable-libraries.md
View File

@ -29,7 +29,7 @@ For more details on the mechanics, remember that Nx is an open source project, s
Buildable libraries are similar to "publishable libraries" described above. Their scope however is not to distribute or publish them to some external registry. Thus they might not be optimized for bundling and distribution.
Buildable libraries are mostly used for producing some pre-compiled output that can be directly referenced from an Nx workspace application without the need to again compile it. A typical scenario is to leverage Nx’s [incremental building](/concepts/more-concepts/incremental-builds) capabilities.
Buildable libraries are mostly used for producing some pre-compiled output that can be directly referenced from an Nx workspace application without the need to again compile it. A typical scenario is to leverage Nx’s incremental building capabilities.
{% callout type="warning" title="More details" %}
In order for a buildable library to be pre-compiled, it can only depend on other buildable libraries. This allows you to take full advantage of incremental builds.

9
nx-dev/nx-dev/redirect-rules.js
View File

@ -259,15 +259,12 @@ const diataxis = {
'/ci/monorepo-ci-bitbucket-pipelines':
'/recipes/ci/monorepo-ci-bitbucket-pipelines',
'/ci/distributed-builds': '/nx-cloud/concepts/parallelization-distribution', // 👀
'/ci/incremental-builds': '/concepts/more-concepts/incremental-builds',
'/ci/setup-incremental-builds-angular':
'/recipes/other/setup-incremental-builds-angular',
'/guides/turbo-and-nx': '/concepts/more-concepts/turbo-and-nx',
'/guides/why-monorepos': '/concepts/more-concepts/why-monorepos',
'/guides/adding-assets-react': '/recipes/other/adding-assets-react',
'/guides/environment-variables': '/reference/environment-variables',
'/guides/monorepo-nx-enterprise':
'/concepts/more-concepts/monorepo-nx-enterprise',
'/guides/performance-profiling': '/recipes/other/performance-profiling',
'/guides/eslint': '/recipes/other/eslint',
'/guides/customize-webpack': '/recipes/webpack/webpack-config-setup',
@ -775,6 +772,12 @@ const conceptUrls = {
'/concepts/module-federation/micro-frontend-architecture',
'/concepts/more-concepts/faster-builds-with-module-federation':
'/concepts/module-federation/faster-builds-with-module-federation',
'/concepts/more-concepts/nx-and-angular':
'/nx-api/angular/documents/nx-and-angular',
'/concepts/more-concepts/nx-devkit-angular-devkit':
'/nx-api/angular/documents/nx-devkit-angular-devkit',
'/concepts/more-concepts/incremental-builds':
'/concepts/more-concepts/buildable-and-publishable-libraries',
};
const nested5minuteTutorialUrls = {

3
packages/angular/docs/webpack-browser-examples.md
View File

@ -31,8 +31,7 @@ The executor supports incrementally building your Angular application by buildin
This 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.
> 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.
> You can read more about when to use incremental builds [here](/concepts/more-concepts/incremental-builds#when-should-i-use-incremental-builds).
> 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.
To allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following: