docs(core): use -t and -p instead of --targets and --projects

docs/generated/cli/affected.md

@@ -20,49 +20,49 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Run custom target for all affected projects:
 
 ```shell
- nx affected --target=custom-target
+ nx affected -t custom-target
 ```
 
 Run tests in parallel:
 
 ```shell
- nx affected --target=test --parallel=5
+ nx affected -t test --parallel=5
 ```
 
 Run the test target for all projects:
 
 ```shell
- nx affected --target=test --all
+ nx affected -t test --all
 ```
 
 Run lint, test, and build targets for affected projects. Requires Nx v15.4+:
 
 ```shell
- nx affected --targets=lint,test,build
+ nx affected -t lint test build
 ```
 
 Run tests for all the projects affected by changing the index.ts file:
 
 ```shell
- nx affected --target=test --files=libs/mylib/src/index.ts
+ nx affected -t test --files=libs/mylib/src/index.ts
 ```
 
 Run tests for all the projects affected by the changes between main and HEAD (e.g., PR):
 
 ```shell
- nx affected --target=test --base=main --head=HEAD
+ nx affected -t test --base=main --head=HEAD
 ```
 
 Run tests for all the projects affected by the last commit on main:
 
 ```shell
- nx affected --target=test --base=main~1 --head=main
+ nx affected -t test --base=main~1 --head=main
 ```
 
 Use the currently executing project name in your command.:
 
 ```shell
- nx affected --target=build --tag=$NX_TARGET_TASK_PROJECT:latest
+ nx affected -t build --tag=$NX_TARGET_TASK_PROJECT:latest
 ```
 
 ## Options

docs/generated/cli/print-affected.md

@@ -32,19 +32,19 @@ Print information about the projects affected by the changes between main and HE
 Prints information about the affected projects and a list of tasks to test them:
 
 ```shell
- nx print-affected --target=test
+ nx print-affected -t test
 ```
 
 Prints the projects property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=projects
+ nx print-affected -t build --select=projects
 ```
 
 Prints the tasks.target.project property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=tasks.target.project
+ nx print-affected -t build --select=tasks.target.project
 ```
 
 ## Options

docs/generated/cli/run-many.md

@@ -20,37 +20,37 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Test all projects:
 
 ```shell
- nx run-many --target=test
+ nx run-many -t test
 ```
 
 Test proj1 and proj2 in parallel:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2
+ nx run-many -t test -p proj1 proj2
 ```
 
 Test proj1 and proj2 in parallel using 5 workers:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=5
+ nx run-many -t test -p proj1 proj2 --parallel=5
 ```
 
 Test proj1 and proj2 in sequence:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=false
+ nx run-many -t test -p proj1 proj2 --parallel=false
 ```
 
 Test all projects ending with `*-app` except `excluded-app`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=*-app --exclude=excluded-app
+ nx run-many -t test --projects=*-app --exclude excluded-app
 ```
 
 Test all projects with tags starting with `api-`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=tag:api-*
+ nx run-many -t test --projects=tag:api-*
 ```
 
 Run lint, test, and build targets for all projects. Requires Nx v15.4+:

docs/generated/cli/watch.md

@@ -26,7 +26,7 @@ Watch the "app" project and echo the project name and the files that changed:
 Watch "app1" and "app2" and echo the project name whenever a specified project or its dependencies change:
 
 ```shell
- nx watch --projects=app1,app2 --includeDependentProjects -- echo \$NX_PROJECT_NAME
+ nx watch --projects=app1,app2 --includeDependencies -- echo \$NX_PROJECT_NAME
 ```
 
 Watch all projects (including newly created projects) in the workspace:

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

@@ -86,7 +86,7 @@ Snapshot files should be checked in with your code.
 
 ### Performance in CI
 
-Typically, in CI it's recommended to use `nx affected --target=test --parallel=[# CPUs] -- --runInBand` for the best performance.
+Typically, in CI it's recommended to use `nx affected -t test --parallel=[# CPUs] -- --runInBand` for the best performance.
 
 This is because each [jest process creates a workers based on system resources](https://jestjs.io/docs/cli#--maxworkersnumstring), running multiple projects via nx and using jest workers will create too many process overall causing the system to run slower than desired. Using the `--runInBand` flag tells jest to run in a single process.
 

docs/generated/packages/nx/documents/affected.md

@@ -20,49 +20,49 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Run custom target for all affected projects:
 
 ```shell
- nx affected --target=custom-target
+ nx affected -t custom-target
 ```
 
 Run tests in parallel:
 
 ```shell
- nx affected --target=test --parallel=5
+ nx affected -t test --parallel=5
 ```
 
 Run the test target for all projects:
 
 ```shell
- nx affected --target=test --all
+ nx affected -t test --all
 ```
 
 Run lint, test, and build targets for affected projects. Requires Nx v15.4+:
 
 ```shell
- nx affected --targets=lint,test,build
+ nx affected -t lint test build
 ```
 
 Run tests for all the projects affected by changing the index.ts file:
 
 ```shell
- nx affected --target=test --files=libs/mylib/src/index.ts
+ nx affected -t test --files=libs/mylib/src/index.ts
 ```
 
 Run tests for all the projects affected by the changes between main and HEAD (e.g., PR):
 
 ```shell
- nx affected --target=test --base=main --head=HEAD
+ nx affected -t test --base=main --head=HEAD
 ```
 
 Run tests for all the projects affected by the last commit on main:
 
 ```shell
- nx affected --target=test --base=main~1 --head=main
+ nx affected -t test --base=main~1 --head=main
 ```
 
 Use the currently executing project name in your command.:
 
 ```shell
- nx affected --target=build --tag=$NX_TARGET_TASK_PROJECT:latest
+ nx affected -t build --tag=$NX_TARGET_TASK_PROJECT:latest
 ```
 
 ## Options

docs/generated/packages/nx/documents/print-affected.md

@@ -32,19 +32,19 @@ Print information about the projects affected by the changes between main and HE
 Prints information about the affected projects and a list of tasks to test them:
 
 ```shell
- nx print-affected --target=test
+ nx print-affected -t test
 ```
 
 Prints the projects property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=projects
+ nx print-affected -t build --select=projects
 ```
 
 Prints the tasks.target.project property from the print-affected output:
 
 ```shell
- nx print-affected --target=build --select=tasks.target.project
+ nx print-affected -t build --select=tasks.target.project
 ```
 
 ## Options

docs/generated/packages/nx/documents/run-many.md

@@ -20,37 +20,37 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
 Test all projects:
 
 ```shell
- nx run-many --target=test
+ nx run-many -t test
 ```
 
 Test proj1 and proj2 in parallel:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2
+ nx run-many -t test -p proj1 proj2
 ```
 
 Test proj1 and proj2 in parallel using 5 workers:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=5
+ nx run-many -t test -p proj1 proj2 --parallel=5
 ```
 
 Test proj1 and proj2 in sequence:
 
 ```shell
- nx run-many --target=test --projects=proj1,proj2 --parallel=false
+ nx run-many -t test -p proj1 proj2 --parallel=false
 ```
 
 Test all projects ending with `*-app` except `excluded-app`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=*-app --exclude=excluded-app
+ nx run-many -t test --projects=*-app --exclude excluded-app
 ```
 
 Test all projects with tags starting with `api-`. Note: your shell may require you to escape the `*` like this: `\*`:
 
 ```shell
- nx run-many --target=test --projects=tag:api-*
+ nx run-many -t test --projects=tag:api-*
 ```
 
 Run lint, test, and build targets for all projects. Requires Nx v15.4+:

docs/generated/packages/nx/documents/watch.md

@@ -26,7 +26,7 @@ Watch the "app" project and echo the project name and the files that changed:
 Watch "app1" and "app2" and echo the project name whenever a specified project or its dependencies change:
 
 ```shell
- nx watch --projects=app1,app2 --includeDependentProjects -- echo \$NX_PROJECT_NAME
+ nx watch --projects=app1,app2 --includeDependencies -- echo \$NX_PROJECT_NAME
 ```
 
 Watch all projects (including newly created projects) in the workspace:

docs/generated/packages/storybook/documents/storybook-composition-setup.md

@@ -57,7 +57,7 @@ In order to get it working for you, you need to two things:
 1. Make sure your "composed" Storybook instances are running. For that you can do:
 
 ```shell
-nx run-many --target=storybook --projects=one-composed,two-composed,three-composed --parallel=3
+nx run-many -t storybook -p one-composed two-composed three-composed --parallel=3
 ```
 
 2. Start your host Storybook in another tab of your terminal:
@@ -94,7 +94,7 @@ In your project's targets, in the `storybook` target, you will notice that the d
 
 We can keep this port for the project which will serve as the host of our configuration, but we must change the port numbers of the other projects, the projects which will be composed/composed. The reason for that is the following:
 
-- When the `nx run-many --target=storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
+- When the `nx run-many -t storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
 - When it finds a port that it is already used, it will change the port number randomly (usually adding `1` until it finds an empty port).
 
 Since we are using the `--parallel` flag, and the commands are executed in parallel, we cannot know for sure the order that the `storybook` command will be executed. So, we cannot be sure which port will correspond to which of the projects.

docs/nx-cloud/reference/config.md

@@ -25,7 +25,7 @@ Only operations listed in `cacheableOperations` can be cached using Nx Cloud and
 By default, Nx Cloud requests will time out after 10 seconds. `NX_CLOUD_NO_TIMEOUTS` disables the timeout.
 
 ```shell
-NX_CLOUD_NO_TIMEOUTS=true nx run-many --target=build --all
+NX_CLOUD_NO_TIMEOUTS=true nx run-many -t build --all
 ```
 
 ## Logging

docs/nx-cloud/reference/nx-cloud-cli.md

@@ -35,10 +35,10 @@ target: `npx nx-cloud start-ci-run --stop-agents-after=e2e`.
 Invoking `npx nx-cloud start-ci-run` will tell Nx to distribute by default. You can enable/disable distribution for
 individual commands as follows:
 
-- `nx affected --target=build --dte` (explicitly enable distribution, Nx >= 14.7)
-- `nx affected --target=build --no-dte` (explicitly disable distribution, Nx >= 14.7)
-- `NX_CLOUD_DISTRIBUTED_EXECUTION=true nx affected --target=build` (explicitly enable distribution)
-- `NX_CLOUD_DISTRIBUTED_EXECUTION=false nx affected --target=build` (explicitly disable distribution)
+- `nx affected -t build --dte` (explicitly enable distribution, Nx >= 14.7)
+- `nx affected -t build --no-dte` (explicitly disable distribution, Nx >= 14.7)
+- `NX_CLOUD_DISTRIBUTED_EXECUTION=true nx affected -t build` (explicitly enable distribution)
+- `NX_CLOUD_DISTRIBUTED_EXECUTION=false nx affected -t build` (explicitly disable distribution)
 
 ## npx nx-cloud stop-all-agents
 

docs/shared/angular-standalone-tutorial/4-task-pipelines.md

@@ -257,7 +257,7 @@ The change made to the `cart` project is also affecting the `store` project. Thi
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.

docs/shared/angular-tutorial/4-workspace-optimization.md

@@ -31,7 +31,7 @@ The change made to the `common-ui` project is also affecting the `admin` and `st
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.

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

@@ -115,7 +115,7 @@ commands are identical from the caching perspective.
 
 ```shell
 npx nx build remixapp
-npx nx run-many --target=build --projects=remixapp
+npx nx run-many -t build -p remixapp
 ```
 
 In other words, Nx does not cache what the developer types into the terminal.
@@ -125,7 +125,7 @@ from
 cache or run. This means that from the caching point of view, the following command:
 
 ```shell
-npx nx run-many --target=build --projects=header,footer
+npx nx run-many -t build -p header footer
 ```
 
 is identical to the following two commands:

docs/shared/concepts/illustrated-dte-guide.md

@@ -12,7 +12,7 @@ A task, from Nx's perspective, is a target running on a project. i.e. The target
 
 ## Nx Cloud Schedules Your CI Tasks Automatically
 
-![when you turn on DTE, Nx will schedule your commands' tasks in CI.  for example, say you want to run these 3 commands to verify your code: nx affected --target=lint, nx affected --target=test and nx affected --target=build](../images/dte/schedule-tasks.jpeg)
+![when you turn on DTE, Nx will schedule your commands' tasks in CI.  for example, say you want to run these 3 commands to verify your code: nx affected -t lint, nx affected -t test and nx affected -t build](../images/dte/schedule-tasks.jpeg)
 
 Let's imagine for every PR in CI, you want to lint, test and build all affected projects. When you write your CI workflow, you have no way of knowing how many projects will be affected by each PR or how long each task will take. No matter how carefully you set things up, there will be wasted time if you manually assign a static number of agent machines for linting, testing and building. This approach is called binning.
 

docs/shared/concepts/improve-worst-case-ci-times.md

@@ -13,9 +13,9 @@ The CI setups we'll discuss are:
 Most organizations start their CI as a single job that is responsible for running any tasks that are required. The script for this CI setup using Nx would look something like this:
 
 ```yaml
-- nx affected --target=lint
-- nx affected --target=test
-- nx affected --target=build
+- nx affected -t lint
+- nx affected -t test
+- nx affected -t build
 ```
 
 This script will run all lint, test and build targets for projects that are affected by the current PR.
@@ -46,17 +46,17 @@ To improve the performance of the worst case CI time, you have to implement some
 
 ```yaml {% fileName="lint-agent.yml" %}
 # Run lint for all projects defined in PROJECTS
-- nx run-many --projects=$PROJECTS --target=lint
+- nx run-many --projects=$PROJECTS -t lint
 ```
 
 ```yaml {% fileName="test-agent.yml" %}
 # Run test for all projects defined in PROJECTS
-- nx run-many --projects=$PROJECTS --target=test
+- nx run-many --projects=$PROJECTS -t test
 ```
 
 ```yaml {% fileName="build-agent.yml" %}
 # Run build for all projects defined in PROJECTS
-- nx run-many --projects=$PROJECTS --target=build
+- nx run-many --projects=$PROJECTS -t build
 ```
 
 Here's a visualization of how this approach works:
@@ -90,7 +90,7 @@ The setup looks like this:
 # Coordinate the agents to run the tasks
 - npx nx-cloud start-ci-run
 # Run any commands you want here
-- nx affected --target=lint & nx affected --target=test & nx affected --target=build
+- nx affected -t lint & nx affected -t test & nx affected -t build
 # Stop any run away agents
 - npx nx-cloud stop-all-agents
 ```

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

@@ -108,7 +108,7 @@ machine. I.e., Nx Cloud doesn't manage your agents--you need to do it in your CI
 Nx Cloud is an orchestrator. The main job tells Nx Cloud what you want to run, and Nx Cloud will distribute those tasks
 across the agents. Nx Cloud will automatically move files from one agent to another, from the agents to the main job.
 
-The end result is that when say `nx affected --target=build` completes on the main job, all the file artifacts created
+The end result is that when say `nx affected -t build` completes on the main job, all the file artifacts created
 on agents are copied over to the main job, as if the main job had built everything locally.
 
 ## Running Things in Parallel

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

@@ -65,12 +65,12 @@ npx nx test header
 To run the `build` target for all projects in the repo, run:
 
 ```shell
-npx nx run-many --target=build
+npx nx run-many -t build
 ```
 
 This will build the projects in the right order: `footer` and `header` and then `myapp`.
 
-```{% command="npx nx run-many --target=build" %}
+```{% command="npx nx run-many -t build" %}
     ✔  nx run header:build (501ms)
     ✔  nx run footer:build (503ms)
     ✔  nx run myapp:build (670ms)
@@ -88,7 +88,7 @@ the name of the target.
 You can also run a command for all the projects affected by your PR like this:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 Learn more about the affected command [here](/concepts/affected).

docs/shared/core-tutorial/04-build-affected-projects.md

@@ -63,7 +63,7 @@ Update `packages/ascii/assets/cow.txt`:
 
 Printing the affected projects can be handy, but usually you want to do something with them. For instance, you may want to build everything that has been affected.
 
-**Run `nx affected --target=build` to rebuild only the projects affected by the change.**
+**Run `nx affected -t build` to rebuild only the projects affected by the change.**
 
 ```shell
     ✔  nx run blog:build (1s)
@@ -78,12 +78,12 @@ Printing the affected projects can be handy, but usually you want to do somethin
 
 Note that Nx only built `blog` and `cli`. It didn't build `ascii` because there is no build script created for it.
 
-## Affected --target=\*
+## Affected -t \*
 
 You can run any target against the affected projects in the graph like this:
 
 ```shell
-nx affected --target=test
+nx affected -t test
 ```
 
 ## What's Next

docs/shared/mental-model.md

@@ -47,7 +47,7 @@ A task is an invocation of a target. If you invoke the same target twice, you cr
 
 Nx uses the [project graph](#the-project-graph), but the task graph and project graph aren’t isomorphic, meaning they
 aren’t directly connected. In the case above, `app1` and `app2` depend on `lib`, but
-running `nx run-many --target=test --projects=app1,app2,lib`, the created task graph will look like this:
+running `nx run-many -t test -p app1 app2 lib`, the created task graph will look like this:
 {% side-by-side %}
 
 **Project Graph**
@@ -118,21 +118,21 @@ execution time.
 
 When you run `nx test app1`, you are telling Nx to run the `app1:test` task plus all the tasks it depends on.
 
-When you run `nx run-many --target=test --projects=app1,lib`, you are telling Nx to do the same for two
+When you run `nx run-many -t test -p app1 lib`, you are telling Nx to do the same for two
 tasks `app1:test`
 and `lib:test`.
 
-When you run `nx run-many --target=test --all`, you are telling Nx to do this for all the projects.
+When you run `nx run-many -t test --all`, you are telling Nx to do this for all the projects.
 
 As your workspace grows, retesting all projects becomes too slow. To address this Nx implements code change analysis to
 get the min set of projects that need to be retested. How does it work?
 
-When you run `nx affected --target=test`, Nx looks at the files you changed in your PR, it will look at the nature of
+When you run `nx affected -t test`, Nx looks at the files you changed in your PR, it will look at the nature of
 change (what exactly did you update in those files), and it uses this to figure the list of projects in the workspace
 that can be affected by this change. It then runs the `run-many` command with that list.
 
-For instance, if my PR changes `lib`, and I then run `nx affected --target=test`, Nx figures out that `app1` and `app2`
-depend on `lib`, so it will invoke `nx run-many --target=test --projects=app1,app2,lib`.
+For instance, if my PR changes `lib`, and I then run `nx affected -t test`, Nx figures out that `app1` and `app2`
+depend on `lib`, so it will invoke `nx run-many -t test -p app1 app2 lib`.
 
 ![affected](/shared/mental-model/affected.svg)
 

docs/shared/migration/adding-to-monorepo.md

@@ -69,7 +69,7 @@ In a package-based monorepo, Nx only manages the scheduling and caching of your
 For example, use Nx to run your builds:
 
 ```shell
-npx nx run-many --target=build
+npx nx run-many -t build
 ```
 
 But instead keep using NPM/Yarn/PNPM workspace commands for your tests and other scripts. Here's an example of using PNPM commands to run tests across packages

docs/shared/migration/lerna-and-nx.md

@@ -114,19 +114,19 @@ Here's an overview of some more Lerna commands and the corresponding Nx version:
   "private": true,
   "scripts": {
 -   "build:all": "lerna run build",
-+   "build:all": "nx run-many --target=build",
++   "build:all": "nx run-many -t build",
 -   "build:app1": "lerna run build --scope=app1",
 +   "build:app1": "nx build app1",
 -   "build:since": "lerna run build --since=main",
-+   "build:since": "nx affected --target=build",
++   "build:since": "nx affected -t build",
 -   "test:all": "lerna run test",
-+   "test:all": "nx run-many --target=test",
++   "test:all": "nx run-many -t test",
 -   "test:app1": "lerna run test --scope=app1",
 +   "test:app1": "nx test app1",
 -   "test:since": "lerna run test --since=main",
-+   "test:since": "nx affected --target=test",
++   "test:since": "nx affected -t test",
 -   "dev": "lerna run dev --stream --parallel",
-+   "dev": "nx run-many --target=dev",
++   "dev": "nx run-many -t dev",
 -   "dev:app1": "lerna run dev --stream --scope=app1",
 +   "dev:app1": "nx dev app1"
   },

docs/shared/node-server-tutorial/4-task-pipelines.md

@@ -212,7 +212,7 @@ The change made to the `products-api` project is also affecting the `e2e` projec
 To run the `lint` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=lint
+npx nx affected -t lint
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.

docs/shared/npm-tutorial/integrated.md

@@ -195,12 +195,12 @@ Done compiling TypeScript files for project "is-even".
 To run the `build` target for all the packages in the workspace, use:
 
 ```shell
-npx nx run-many --target=build
+npx nx run-many -t build
 ```
 
 What you would get is the following:
 
-```{% command="npx nx run-many --target=build" %}
+```{% command="npx nx run-many -t build" %}
     ✔  nx run is-even:build  [existing outputs match the cache, left as is]
     ✔  nx run is-odd:build (906ms)
 
@@ -216,7 +216,7 @@ Note how on the `is-even:build` it didn't run the build but rather pulled it out
 You can also only run tasks on packages that got changed by using
 
 ```shell
-npx nx affected --target=build
+npx nx affected -t build
 ```
 
 ## Learn More

docs/shared/npm-tutorial/package-based.md

@@ -195,7 +195,7 @@ Note that the cache for the `build` script was already populated when we ran it
 
 To run the `build` target for all the packages in the workspace, use:
 
-```{% command="npx nx run-many --target=build" %}
+```{% command="npx nx run-many -t build" %}
     ✔  nx run is-even:build  [existing outputs match the cache, left as is]
     ✔  nx run is-odd:build  [existing outputs match the cache, left as is]
 
@@ -208,7 +208,7 @@ To run the `build` target for all the packages in the workspace, use:
 
 Notice that both builds are replayed from cache. We can skip the cache by adding the `--skip-nx-cache` option:
 
-```{% command="npx nx run-many --target=build --skip-nx-cache" %}
+```{% command="npx nx run-many -t build --skip-nx-cache" %}
     ✔  nx run is-even:build (1s)
     ✔  nx run is-odd:build (1s)
 
@@ -221,7 +221,7 @@ Notice that using this method, the `is-even` build ran before the `is-odd` build
 
 You can also only run tasks on packages that got changed by using the command:
 
-```{% command="npx nx affected --target=build" %}
+```{% command="npx nx affected -t build" %}
 
  >  NX   Affected criteria defaulted to --base=main --head=HEAD
 

docs/shared/packages/jest/jest-plugin.md

@@ -86,7 +86,7 @@ Snapshot files should be checked in with your code.
 
 ### Performance in CI
 
-Typically, in CI it's recommended to use `nx affected --target=test --parallel=[# CPUs] -- --runInBand` for the best performance.
+Typically, in CI it's recommended to use `nx affected -t test --parallel=[# CPUs] -- --runInBand` for the best performance.
 
 This is because each [jest process creates a workers based on system resources](https://jestjs.io/docs/cli#--maxworkersnumstring), running multiple projects via nx and using jest workers will create too many process overall causing the system to run slower than desired. Using the `--runInBand` flag tells jest to run in a single process.
 

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

@@ -57,7 +57,7 @@ In order to get it working for you, you need to two things:
 1. Make sure your "composed" Storybook instances are running. For that you can do:
 
 ```shell
-nx run-many --target=storybook --projects=one-composed,two-composed,three-composed --parallel=3
+nx run-many -t storybook -p one-composed two-composed three-composed --parallel=3
 ```
 
 2. Start your host Storybook in another tab of your terminal:
@@ -94,7 +94,7 @@ In your project's targets, in the `storybook` target, you will notice that the d
 
 We can keep this port for the project which will serve as the host of our configuration, but we must change the port numbers of the other projects, the projects which will be composed/composed. The reason for that is the following:
 
-- When the `nx run-many --target=storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
+- When the `nx run-many -t storybook --parallel=3` command executes, it will go and look into your `project.json` file to see the port you have assigned for that project's Storybook.
 - When it finds a port that it is already used, it will change the port number randomly (usually adding `1` until it finds an empty port).
 
 Since we are using the `--parallel` flag, and the commands are executed in parallel, we cannot know for sure the order that the `storybook` command will be executed. So, we cannot be sure which port will correspond to which of the projects.

docs/shared/plugin-features/use-task-executors.md

@@ -5,7 +5,7 @@ Executors perform actions on your code. This can include building, linting, test
 There are two main differences between an executor and a shell script or an npm script:
 
 1. Executors encourage a consistent methodology for performing similar actions on unrelated projects. i.e. A developer switching between teams can be confident that `nx build project2` will build `project2` with the default settings, just like `nx build project1` built `project1`.
-2. Nx can leverage this consistency to run the same target across multiple projects. i.e. `nx affected --target=test` will run the `test` executor associated with the `test` target on every project that is affected by the current code change.
+2. Nx can leverage this consistency to run the same target across multiple projects. i.e. `nx affected -t test` will run the `test` executor associated with the `test` target on every project that is affected by the current code change.
 3. Executors provide metadata to define the available options. This metadata allows the Nx CLI to show prompts in the terminal and Nx Console to generate a GUI for the executor.
 
 ## Executor definitions

docs/shared/react-standalone-tutorial/4-task-pipelines.md

@@ -229,7 +229,7 @@ The change made to the `cart` project is also affecting the `store` project. Thi
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.

docs/shared/react-tutorial/4-workspace-optimization.md

@@ -31,7 +31,7 @@ The change made to the `common-ui` project is also affecting the `admin` and `st
 To run the `test` targets only for affected projects, run the command:
 
 ```shell
-npx nx affected --target=test
+npx nx affected -t test
 ```
 
 This can be particularly helpful in CI pipelines for larger repos, where most commits only affect a small subset of the entire workspace.

docs/shared/recipes/azure-last-successful-commit.md

@@ -76,7 +76,7 @@ jobs:
       - script: npx nx workspace-lint
       - script: npx nx format:check
 
-      - script: npx nx affected --base=$(BASE_SHA) --target=lint --parallel=3
-      - script: npx nx affected --base=$(BASE_SHA) --target=test --parallel=3 --ci --code-coverage
-      - script: npx nx affected --base=$(BASE_SHA) --target=build --parallel=3
+      - script: npx nx affected --base=$(BASE_SHA) -t lint --parallel=3
+      - script: npx nx affected --base=$(BASE_SHA) -t test --parallel=3 --ci --code-coverage
+      - script: npx nx affected --base=$(BASE_SHA) -t build --parallel=3
 ```

docs/shared/recipes/console-shortcuts.md

@@ -14,7 +14,7 @@ You can also set up custom tasks and assign keyboard shortcuts to them. In `.vsc
 {
   "label": "Test Affected",
   "type": "shell",
-  "command": "nx affected --target=test"
+  "command": "nx affected -t test"
 }
 ```
 
@@ -28,6 +28,6 @@ Then from the Command Palette (`⇧⌘P`) choose `Preferences: Open Keyboard Sho
 }
 ```
 
-Now, pressing `^⌘T` will run `nx affected --target=test`.
+Now, pressing `^⌘T` will run `nx affected -t test`.
 
 Here is more information on [VSCode tasks](https://code.visualstudio.com/docs/editor/tasks) and [keyboard shortcuts](https://code.visualstudio.com/docs/getstarted/keybindings).

docs/shared/reference/nx-json.md

@@ -210,7 +210,7 @@ pass `--buildable=true` when creating new libraries.
 > A task is an invocation of a target.
 
 Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner
-named "default" is used by default. Specify a different one like this `nx run-many --target=build --all --runner=another`.
+named "default" is used by default. Specify a different one like this `nx run-many -t build --all --runner=another`.
 
 Tasks runners can accept different options. The following are the options supported
 by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
@@ -226,4 +226,4 @@ by `"nx/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
 | selectivelyHashTsConfig | only hash the path mapping of the active project in the `tsconfig.base.json` (e.g., adding/removing projects doesn't affect the hash of existing projects) (defaults to `false`)                                                                                                                                                              |
 
 You can configure `parallel` in `nx.json`, but you can also pass them in the
-terminal `nx run-many --target=test --parallel=5`.
+terminal `nx run-many -t test --parallel=5`.

docs/shared/running-custom-commands.md

@@ -50,11 +50,11 @@ nx make my-app
 You can also run the `make` command for all projects it has been defined on:
 
 ```shell
-nx run-many --target=make
+nx run-many -t make
 ```
 
 Or just on a subset of projects that are [affected by a given change](/concepts/affected):
 
 ```shell
-nx affected --target=make
+nx affected -t make
 ```

docs/shared/using-nx/affected.md

@@ -8,20 +8,20 @@ Before reading this guide, [check out the mental model guide](/concepts/mental-m
 
 When you run `nx test app1`, you are telling Nx to run the app1:test task plus all the tasks it depends on.
 
-When you run `nx run-many --target=test --projects=app1,lib`, you are telling Nx to do the same for two tasks app1:test
+When you run `nx run-many -t test -p app1 lib`, you are telling Nx to do the same for two tasks app1:test
 and lib:test.
 
-When you run `nx run-many --target=test --all`, you are telling Nx to do this for all the projects.
+When you run `nx run-many -t test`, you are telling Nx to do this for all the projects.
 
 As your workspace grows, retesting all projects becomes too slow. To address this Nx implements code change analysis to
 get the min set of projects that need to be retested. How does it work?
 
-When you run `nx affected --target=test`, Nx looks at the files you changed in your PR, it will look at the nature of
+When you run `nx affected -t test`, Nx looks at the files you changed in your PR, it will look at the nature of
 change (what exactly did you update in those files), and it uses this to figure the list of projects in the workspace
 that can be affected by this change. It then runs the `run-many` command with that list.
 
-For instance, if my PR changes `lib`, and I then run `nx affected --target=test`, Nx figures out that `app1` and `app2`
-depend on `lib`, so it will invoke `nx run-many --target=test --projects=app1,app2,lib`.
+For instance, if my PR changes `lib`, and I then run `nx affected -t test`, Nx figures out that `app1` and `app2`
+depend on `lib`, so it will invoke `nx run-many -t test -p app1 app2 lib`.
 
 ![affected](/shared/mental-model/affected.svg)
 

docs/shared/workspace/creating-libraries.md

@@ -8,7 +8,7 @@ There are three main benefits to breaking your code up into more libraries.
 
 ### 1. Faster Commands
 
-The more granular your libraries are, the more effective `nx affected` and Nx's computation cache will be. For example, if `libraryA` contains 10 tests, but only 5 of them were affected by a particular code change, all 10 tests will be run by `nx affected --target=test`. If you can predict which 5 tests are usually run together, you can split all the related code into a separate library to allow the two groups of 5 tests to be executed independently.
+The more granular your libraries are, the more effective `nx affected` and Nx's computation cache will be. For example, if `libraryA` contains 10 tests, but only 5 of them were affected by a particular code change, all 10 tests will be run by `nx affected -t test`. If you can predict which 5 tests are usually run together, you can split all the related code into a separate library to allow the two groups of 5 tests to be executed independently.
 
 ### 2. Visualizing Architecture
 

packages/nx/src/command-line/examples.ts

@@ -16,56 +16,56 @@ export const examples: Record<string, Example[]> = {
         'Print information about the projects affected by the changes between main and HEAD (e.g,. PR)',
     },
     {
-      command: 'print-affected --target=test',
+      command: 'print-affected -t test',
       description:
         'Prints information about the affected projects and a list of tasks to test them',
     },
     {
-      command: 'print-affected --target=build --select=projects',
+      command: 'print-affected -t build --select=projects',
       description:
         'Prints the projects property from the print-affected output',
     },
     {
-      command: 'print-affected --target=build --select=tasks.target.project',
+      command: 'print-affected -t build --select=tasks.target.project',
       description:
         'Prints the tasks.target.project property from the print-affected output',
     },
   ],
   affected: [
     {
-      command: 'affected --target=custom-target',
+      command: 'affected -t custom-target',
       description: 'Run custom target for all affected projects',
     },
     {
-      command: 'affected --target=test --parallel=5',
+      command: 'affected -t test --parallel=5',
       description: 'Run tests in parallel',
     },
     {
-      command: 'affected --target=test --all',
+      command: 'affected -t test --all',
       description: 'Run the test target for all projects',
     },
     {
-      command: 'affected --targets=lint,test,build',
+      command: 'affected -t lint test build',
       description:
         'Run lint, test, and build targets for affected projects. Requires Nx v15.4+',
     },
     {
-      command: 'affected --target=test --files=libs/mylib/src/index.ts',
+      command: 'affected -t test --files=libs/mylib/src/index.ts',
       description:
         'Run tests for all the projects affected by changing the index.ts file',
     },
     {
-      command: 'affected --target=test --base=main --head=HEAD',
+      command: 'affected -t test --base=main --head=HEAD',
       description:
         'Run tests for all the projects affected by the changes between main and HEAD (e.g., PR)',
     },
     {
-      command: 'affected --target=test --base=main~1 --head=main',
+      command: 'affected -t test --base=main~1 --head=main',
       description:
         'Run tests for all the projects affected by the last commit on main',
     },
     {
-      command: 'affected --target=build --tag=$NX_TARGET_TASK_PROJECT:latest',
+      command: 'affected -t build --tag=$NX_TARGET_TASK_PROJECT:latest',
       description: 'Use the currently executing project name in your command.',
     },
   ],
@@ -289,28 +289,28 @@ export const examples: Record<string, Example[]> = {
   ],
   'run-many': [
     {
-      command: 'run-many --target=test',
+      command: 'run-many -t test',
       description: 'Test all projects',
     },
     {
-      command: 'run-many --target=test --projects=proj1,proj2',
+      command: 'run-many -t test -p proj1 proj2',
       description: 'Test proj1 and proj2 in parallel',
     },
     {
-      command: 'run-many --target=test --projects=proj1,proj2 --parallel=5',
+      command: 'run-many -t test -p proj1 proj2 --parallel=5',
       description: 'Test proj1 and proj2 in parallel using 5 workers',
     },
     {
-      command: 'run-many --target=test --projects=proj1,proj2 --parallel=false',
+      command: 'run-many -t test -p proj1 proj2 --parallel=false',
       description: 'Test proj1 and proj2 in sequence',
     },
     {
-      command: 'run-many --target=test --projects=*-app --exclude=excluded-app',
+      command: 'run-many -t test --projects=*-app --exclude excluded-app',
       description:
         'Test all projects ending with `*-app` except `excluded-app`.  Note: your shell may require you to escape the `*` like this: `\\*`',
     },
     {
-      command: 'run-many --target=test --projects=tag:api-*',
+      command: 'run-many -t test --projects=tag:api-*',
       description:
         'Test all projects with tags starting with `api-`.  Note: your shell may require you to escape the `*` like this: `\\*`',
     },
@@ -378,7 +378,7 @@ export const examples: Record<string, Example[]> = {
     },
     {
       command:
-        'watch --projects=app1,app2 --includeDependentProjects -- echo \\$NX_PROJECT_NAME',
+        'watch --projects=app1,app2 --includeDependencies -- echo \\$NX_PROJECT_NAME',
       description:
         'Watch "app1" and "app2" and echo the project name whenever a specified project or its dependencies change',
     },