chore(repo): small changes in the turbo guide

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

@@ -136,13 +136,13 @@ Benchmarking is hard because a lot depends on what you are trying to run, in wha
 This is the result:
 ![nx and turbo benchmark](/shared/turbo-nx-perf.gif)
 
-Nx is 5 times faster on the latest MBP. Nx is 7.5 times faster on a Windows laptop.
+Nx is 9.4 times faster on the latest MBP. Nx is 19.5 times faster on a Windows laptop.
 
-Why is it faster? Nx is in many ways akin to React in that it's doing tree diffing when restoring files from the cache. If the right files are in the right place, Nx won't touch them. Turbo blows everything away every time. Nx's version isn't just faster, it's also more useful (again similarly to tree diffing in React). Blowing everything away on every restoration means that if any tools watch the folders (which is common when you build large apps or build microfrontends), they are going to get confused or triggered for no reason. This is similar to how recreating the DOM from scratch isn't just slower, but results in worse UX. But even if you disable tree-diffing and make Nx do what Turbo does, it is still 1.5 times faster.
+Why is it faster? Nx is in many ways akin to React in that it's doing tree diffing when restoring files from the cache. If the right files are in the right place, Nx won't touch them. Turbo blows everything away every time. Nx's version isn't just faster, it's also more useful (again similarly to tree diffing in React). Blowing everything away on every restoration means that if any tools watch the folders (which is common when you build large apps or build microfrontends), they are going to get confused or triggered for no reason. This is similar to how recreating the DOM from scratch isn't just slower, but results in worse UX. But even if you disable tree-diffing and make Nx do what Turbo does, it is still 1.7 times faster.
 
 The cache restoration Turborepo provides might be fast enough for a lot of repos (3 seconds is still plenty fast). What matters for larger repos like this one is the ability to distribute any command across say 50 machines while preserving the dev ergonomics of running it on a single machine. Nx can do it. Bazel can do it (which Nx borrows some ideas from). Turbo can't.
 
-The one advantage Turbo's Go implementation has, is that any time you run an Nx command you pay a ~150ms penalty to boot Node.js. If you test 1 project, you pay a 150ms penalty, if you test 1000 projects, it is still a 150ms penalty. We don’t think in practice it matters because most other CLIs (e.g,. yarn) have the same penalty. The real performance gains from both Nx and Turborepo are in how intelligently they reduce, cache, and in Nx's case, distribute tasks.
+The one advantage Turbo's Go implementation has, is that any time you run an Nx command you pay a ~70ms penalty to boot Node.js. If you test 1 project, you pay a 70ms penalty, if you test 1000 projects, it is still a 70ms penalty. We don’t think in practice it matters because most other CLIs (e.g,. yarn) have the same penalty. The real performance gains from both Nx and Turborepo are in how intelligently they reduce, cache, and in Nx's case, distribute tasks.
 
 **Nx and Turborepo often have different philosophies of how workspaces should be built.** Turborepo tends to think in terms of "packages", whereas Nx is focused on many lightweight projects. Large Nx Workspaces tend to be composed of hundreds or even thousands of projects, which helps the average build performance in three ways:
 

nx-dev/nx-dev/public/documentation/latest/angular/api-angular/generators/application.md

@@ -33,6 +33,20 @@ nx g application ... --dry-run
 
 ## Options
 
+### name (_**required**_)
+
+Type: `string`
+
+The name of the application.
+
+### addTailwind
+
+Default: `false`
+
+Type: `boolean`
+
+Whether to configure TailwindCSS for the application.
+
 ### backendProject
 
 Type: `string`
@@ -109,12 +123,6 @@ Possible values: `host`, `remote`
 
 Type of application to generate the Module Federation configuration for.
 
-### name
-
-Type: `string`
-
-The name of the application.
-
 ### port
 
 Type: `number`

nx-dev/nx-dev/public/documentation/latest/angular/api-angular/generators/library.md

@@ -33,6 +33,12 @@ nx g library ... --dry-run
 
 ## Options
 
+### name (_**required**_)
+
+Type: `string`
+
+The name of the library.
+
 ### addModuleSpec
 
 Default: `false`
@@ -41,6 +47,14 @@ Type: `boolean`
 
 Add a module spec file.
 
+### addTailwind
+
+Default: `false`
+
+Type: `boolean`
+
+Whether to configure TailwindCSS for the application. It can only be used with buildable and publishable libraries. Non-buildable libraries will use the application's Tailwind configuration.
+
 ### buildable
 
 Default: `false`
@@ -87,12 +101,6 @@ Possible values: `eslint`, `none`
 
 The tool to use for running lint checks.
 
-### name
-
-Type: `string`
-
-The name of the library.
-
 ### parentModule
 
 Type: `string`

nx-dev/nx-dev/public/documentation/latest/angular/api-angular/generators/setup-tailwind.md

@@ -0,0 +1,56 @@
+---
+title: '@nrwl/angular:setup-tailwind generator'
+description: 'Configures TailwindCSS for an application or a buildable/publishable library.'
+---
+
+# @nrwl/angular:setup-tailwind
+
+Configures TailwindCSS for an application or a buildable/publishable library.
+
+## Usage
+
+```bash
+nx generate setup-tailwind ...
+```
+
+By default, Nx will search for `setup-tailwind` in the default collection provisioned in `angular.json`.
+
+You can specify the collection explicitly as follows:
+
+```bash
+nx g @nrwl/angular:setup-tailwind ...
+```
+
+Show what will be generated without writing to disk:
+
+```bash
+nx g setup-tailwind ... --dry-run
+```
+
+## Options
+
+### project (_**required**_)
+
+Type: `string`
+
+The name of the project to add the TailwindCSS setup for.
+
+### buildTarget
+
+Default: `build`
+
+Type: `string`
+
+The name of the target used to build the project. This option only applies to buildable/publishable libraries.
+
+### skipFormat
+
+Type: `boolean`
+
+Skips formatting the workspace after the generator completes.
+
+### stylesEntryPoint
+
+Type: `string`
+
+Path to the styles entry point relative to the workspace root. If not provided the generator will do its best to find it and it will error if it can't. This option only applies to applications.

nx-dev/nx-dev/public/documentation/latest/map.json

@@ -498,6 +498,11 @@
             "id": "setup-mfe",
             "file": "angular/api-angular/generators/setup-mfe"
           },
+          {
+            "name": "setup-tailwind generator",
+            "id": "setup-tailwind",
+            "file": "angular/api-angular/generators/setup-tailwind"
+          },
           {
             "name": "stories generator",
             "id": "stories",
@@ -1857,6 +1862,11 @@
             "id": "setup-mfe",
             "file": "react/api-angular/generators/setup-mfe"
           },
+          {
+            "name": "setup-tailwind generator",
+            "id": "setup-tailwind",
+            "file": "react/api-angular/generators/setup-tailwind"
+          },
           {
             "name": "stories generator",
             "id": "stories",
@@ -3180,6 +3190,11 @@
             "id": "setup-mfe",
             "file": "node/api-angular/generators/setup-mfe"
           },
+          {
+            "name": "setup-tailwind generator",
+            "id": "setup-tailwind",
+            "file": "node/api-angular/generators/setup-tailwind"
+          },
           {
             "name": "stories generator",
             "id": "stories",

nx-dev/nx-dev/public/documentation/latest/node/api-angular/generators/application.md

@@ -33,6 +33,20 @@ nx g application ... --dry-run
 
 ## Options
 
+### name (_**required**_)
+
+Type: `string`
+
+The name of the application.
+
+### addTailwind
+
+Default: `false`
+
+Type: `boolean`
+
+Whether to configure TailwindCSS for the application.
+
 ### backendProject
 
 Type: `string`
@@ -109,12 +123,6 @@ Possible values: `host`, `remote`
 
 Type of application to generate the Module Federation configuration for.
 
-### name
-
-Type: `string`
-
-The name of the application.
-
 ### port
 
 Type: `number`

nx-dev/nx-dev/public/documentation/latest/node/api-angular/generators/library.md

@@ -33,6 +33,12 @@ nx g library ... --dry-run
 
 ## Options
 
+### name (_**required**_)
+
+Type: `string`
+
+The name of the library.
+
 ### addModuleSpec
 
 Default: `false`
@@ -41,6 +47,14 @@ Type: `boolean`
 
 Add a module spec file.
 
+### addTailwind
+
+Default: `false`
+
+Type: `boolean`
+
+Whether to configure TailwindCSS for the application. It can only be used with buildable and publishable libraries. Non-buildable libraries will use the application's Tailwind configuration.
+
 ### buildable
 
 Default: `false`
@@ -87,12 +101,6 @@ Possible values: `eslint`, `none`
 
 The tool to use for running lint checks.
 
-### name
-
-Type: `string`
-
-The name of the library.
-
 ### parentModule
 
 Type: `string`

nx-dev/nx-dev/public/documentation/latest/node/api-angular/generators/setup-tailwind.md

@@ -0,0 +1,56 @@
+---
+title: '@nrwl/angular:setup-tailwind generator'
+description: 'Configures TailwindCSS for an application or a buildable/publishable library.'
+---
+
+# @nrwl/angular:setup-tailwind
+
+Configures TailwindCSS for an application or a buildable/publishable library.
+
+## Usage
+
+```bash
+nx generate setup-tailwind ...
+```
+
+By default, Nx will search for `setup-tailwind` in the default collection provisioned in `workspace.json`.
+
+You can specify the collection explicitly as follows:
+
+```bash
+nx g @nrwl/angular:setup-tailwind ...
+```
+
+Show what will be generated without writing to disk:
+
+```bash
+nx g setup-tailwind ... --dry-run
+```
+
+## Options
+
+### project (_**required**_)
+
+Type: `string`
+
+The name of the project to add the TailwindCSS setup for.
+
+### buildTarget
+
+Default: `build`
+
+Type: `string`
+
+The name of the target used to build the project. This option only applies to buildable/publishable libraries.
+
+### skipFormat
+
+Type: `boolean`
+
+Skips formatting the workspace after the generator completes.
+
+### stylesEntryPoint
+
+Type: `string`
+
+Path to the styles entry point relative to the workspace root. If not provided the generator will do its best to find it and it will error if it can't. This option only applies to applications.

nx-dev/nx-dev/public/documentation/latest/react/api-angular/generators/application.md

@@ -33,6 +33,20 @@ nx g application ... --dry-run
 
 ## Options
 
+### name (_**required**_)
+
+Type: `string`
+
+The name of the application.
+
+### addTailwind
+
+Default: `false`
+
+Type: `boolean`
+
+Whether to configure TailwindCSS for the application.
+
 ### backendProject
 
 Type: `string`
@@ -109,12 +123,6 @@ Possible values: `host`, `remote`
 
 Type of application to generate the Module Federation configuration for.
 
-### name
-
-Type: `string`
-
-The name of the application.
-
 ### port
 
 Type: `number`

nx-dev/nx-dev/public/documentation/latest/react/api-angular/generators/library.md

@@ -33,6 +33,12 @@ nx g library ... --dry-run
 
 ## Options
 
+### name (_**required**_)
+
+Type: `string`
+
+The name of the library.
+
 ### addModuleSpec
 
 Default: `false`
@@ -41,6 +47,14 @@ Type: `boolean`
 
 Add a module spec file.
 
+### addTailwind
+
+Default: `false`
+
+Type: `boolean`
+
+Whether to configure TailwindCSS for the application. It can only be used with buildable and publishable libraries. Non-buildable libraries will use the application's Tailwind configuration.
+
 ### buildable
 
 Default: `false`
@@ -87,12 +101,6 @@ Possible values: `eslint`, `none`
 
 The tool to use for running lint checks.
 
-### name
-
-Type: `string`
-
-The name of the library.
-
 ### parentModule
 
 Type: `string`

nx-dev/nx-dev/public/documentation/latest/react/api-angular/generators/setup-tailwind.md

@@ -0,0 +1,56 @@
+---
+title: '@nrwl/angular:setup-tailwind generator'
+description: 'Configures TailwindCSS for an application or a buildable/publishable library.'
+---
+
+# @nrwl/angular:setup-tailwind
+
+Configures TailwindCSS for an application or a buildable/publishable library.
+
+## Usage
+
+```bash
+nx generate setup-tailwind ...
+```
+
+By default, Nx will search for `setup-tailwind` in the default collection provisioned in `workspace.json`.
+
+You can specify the collection explicitly as follows:
+
+```bash
+nx g @nrwl/angular:setup-tailwind ...
+```
+
+Show what will be generated without writing to disk:
+
+```bash
+nx g setup-tailwind ... --dry-run
+```
+
+## Options
+
+### project (_**required**_)
+
+Type: `string`
+
+The name of the project to add the TailwindCSS setup for.
+
+### buildTarget
+
+Default: `build`
+
+Type: `string`
+
+The name of the target used to build the project. This option only applies to buildable/publishable libraries.
+
+### skipFormat
+
+Type: `boolean`
+
+Skips formatting the workspace after the generator completes.
+
+### stylesEntryPoint
+
+Type: `string`
+
+Path to the styles entry point relative to the workspace root. If not provided the generator will do its best to find it and it will error if it can't. This option only applies to applications.

nx-dev/nx-dev/public/documentation/latest/shared/guides/turbo-and-nx.md

@@ -136,13 +136,13 @@ Benchmarking is hard because a lot depends on what you are trying to run, in wha
 This is the result:
 ![nx and turbo benchmark](/shared/turbo-nx-perf.gif)
 
-Nx is 5 times faster on the latest MBP. Nx is 7.5 times faster on a Windows laptop.
+Nx is 9.4 times faster on the latest MBP. Nx is 19.5 times faster on a Windows laptop.
 
-Why is it faster? Nx is in many ways akin to React in that it's doing tree diffing when restoring files from the cache. If the right files are in the right place, Nx won't touch them. Turbo blows everything away every time. Nx's version isn't just faster, it's also more useful (again similarly to tree diffing in React). Blowing everything away on every restoration means that if any tools watch the folders (which is common when you build large apps or build microfrontends), they are going to get confused or triggered for no reason. This is similar to how recreating the DOM from scratch isn't just slower, but results in worse UX. But even if you disable tree-diffing and make Nx do what Turbo does, it is still 1.5 times faster.
+Why is it faster? Nx is in many ways akin to React in that it's doing tree diffing when restoring files from the cache. If the right files are in the right place, Nx won't touch them. Turbo blows everything away every time. Nx's version isn't just faster, it's also more useful (again similarly to tree diffing in React). Blowing everything away on every restoration means that if any tools watch the folders (which is common when you build large apps or build microfrontends), they are going to get confused or triggered for no reason. This is similar to how recreating the DOM from scratch isn't just slower, but results in worse UX. But even if you disable tree-diffing and make Nx do what Turbo does, it is still 1.7 times faster.
 
 The cache restoration Turborepo provides might be fast enough for a lot of repos (3 seconds is still plenty fast). What matters for larger repos like this one is the ability to distribute any command across say 50 machines while preserving the dev ergonomics of running it on a single machine. Nx can do it. Bazel can do it (which Nx borrows some ideas from). Turbo can't.
 
-The one advantage Turbo's Go implementation has, is that any time you run an Nx command you pay a ~150ms penalty to boot Node.js. If you test 1 project, you pay a 150ms penalty, if you test 1000 projects, it is still a 150ms penalty. We don’t think in practice it matters because most other CLIs (e.g,. yarn) have the same penalty. The real performance gains from both Nx and Turborepo are in how intelligently they reduce, cache, and in Nx's case, distribute tasks.
+The one advantage Turbo's Go implementation has, is that any time you run an Nx command you pay a ~70ms penalty to boot Node.js. If you test 1 project, you pay a 70ms penalty, if you test 1000 projects, it is still a 70ms penalty. We don’t think in practice it matters because most other CLIs (e.g,. yarn) have the same penalty. The real performance gains from both Nx and Turborepo are in how intelligently they reduce, cache, and in Nx's case, distribute tasks.
 
 **Nx and Turborepo often have different philosophies of how workspaces should be built.** Turborepo tends to think in terms of "packages", whereas Nx is focused on many lightweight projects. Large Nx Workspaces tend to be composed of hundreds or even thousands of projects, which helps the average build performance in three ways: