Revert "feat(core): remove leading arrow from output headlines (#21359)"

This reverts commit c2a09c5.

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

@@ -89,7 +89,7 @@ The command below uses the `as-provided` directory flag behavior, which is the d
 {% /callout %}
 
 ```{% command="nx g @nx/remix:app myapp --directory=apps/myapp" path="~/acme" %}
-NX  Generating @nx/remix:application
+>  NX  Generating @nx/remix:application
 
 ✔ What unit test runner should be used? · vitest
 
@@ -135,9 +135,9 @@ Building Remix app in production mode...
 
 Built in 857ms
 
-——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
+ ——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
 
-NX   Successfully ran target build for project myapp (3s)
+ >  NX   Successfully ran target build for project myapp (3s)
 ```
 
 2. To serve your application for use during development run:
@@ -155,18 +155,18 @@ Remix App Server started at http://localhost:3000 (http://192.168.0.14:3000)
 ```{% command="nx test myapp" path="~/acme" %}
 > nx run myapp:test
 
-RUN  v0.31.4 /Users/columferry/dev/nrwl/issues/remixguide/acme/apps/myapp
+ RUN  v0.31.4 /Users/columferry/dev/nrwl/issues/remixguide/acme/apps/myapp
 stderr | app/routes/index.spec.ts > test > should render
 Warning: Functions are not valid as a React child. This may happen if you return a Component instead of <Component /> from render. Or maybe you meant to call this function rather than return it.
-✓ app/routes/index.spec.ts  (1 test) 10ms
-Test Files  1 passed (1)
-     Tests  1 passed (1)
-Start at  16:15:45
-Duration  1.20s (transform 51ms, setup 139ms, collect 180ms, tests 10ms, environment 379ms, prepare 103ms)
+ ✓ app/routes/index.spec.ts  (1 test) 10ms
+ Test Files  1 passed (1)
+      Tests  1 passed (1)
+   Start at  16:15:45
+   Duration  1.20s (transform 51ms, setup 139ms, collect 180ms, tests 10ms, environment 379ms, prepare 103ms)
 
-——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
+ ——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
 
-NX   Successfully ran target test for project myapp (2s)
+ >  NX   Successfully ran target test for project myapp (2s)
 ```
 
 ## Generating an Nx Library
@@ -176,7 +176,7 @@ When developing your application, it often makes sense to split your codebase in
 To generate a library to use in your Remix application run:
 
 ```{% command="nx g @nx/remix:lib login --directory=libs/login" path="~/acme" %}
-NX  Generating @nx/remix:library
+>  NX  Generating @nx/remix:library
 
 ✔ What test runner should be used? · vitest
 UPDATE nx.json
@@ -223,7 +223,7 @@ You can also run test on your library:
 To generate a route for your application:
 
 ```{% command="nx g @nx/remix:route admin --path=apps/myapp/app/routes" path="~/acme" %}
-NX  Generating @nx/remix:route
+>  NX  Generating @nx/remix:route
 
 CREATE apps/myapp/app/routes/admin.tsx
 CREATE apps/myapp/app/styles/admin.css
@@ -236,7 +236,7 @@ To use a Route Loader where the logic lives in your library, follow the steps be
 1. Generate a loader for your route:
 
 ```{% command="nx g @nx/remix:loader admin --path=apps/myapp/app/routes" path="~/acme" %}
-NX  Generating @nx/remix:loader
+>  NX  Generating @nx/remix:loader
 
 UPDATE apps/myapp/app/routes/admin.tsx
 ```

docs/nx-cloud/tutorial/circle.md

@@ -212,31 +212,31 @@ pnpm nx build landing-page
 Clearly this is not a scalable solution as it requires us to manually add every new app to the pipeline (and it doesn't include other tasks like `lint`, `test` etc). To improve this we can change the command to run the `build` for all projects like
 
 ```{% command="nx run-many -t build" %}
-✔  nx run shared-product-types:build (429ms)
-✔  nx run shared-product-ui:build (455ms)
-✔  nx run shared-header:build (467ms)
-✔  nx run landing-page:build:production (3s)
-✔  nx run admin:build:production (3s)
-✔  nx run cart:build:production (3s)
+    ✔  nx run shared-product-types:build (429ms)
+    ✔  nx run shared-product-ui:build (455ms)
+    ✔  nx run shared-header:build (467ms)
+    ✔  nx run landing-page:build:production (3s)
+    ✔  nx run admin:build:production (3s)
+    ✔  nx run cart:build:production (3s)
 
-————————————————————————————————————————————————————————————————
+ ————————————————————————————————————————————————————————————————
 
-NX   Successfully ran target build for 6 projects (10s)
+ >  NX   Successfully ran target build for 6 projects (10s)
 ```
 
 This change makes our CI pipeline configuration more maintainable. For a small repository, this might be good enough, but after a little bit of growth this approach will cause your CI times to become unmanageable.
 
 Nx comes with a dedicated ["affected" command](/ci/features/affected) to help with that by only running tasks for projects that were affected by the changes in a given PR.
 
 ```{% command="nx affected -t build" %}
-✔  nx run shared-product-types:build (404ms)
-✔  nx run shared-product-ui:build (445ms)
-✔  nx run shared-header:build (465ms)
-✔  nx run cart:build:production (3s)
+    ✔  nx run shared-product-types:build (404ms)
+    ✔  nx run shared-product-ui:build (445ms)
+    ✔  nx run shared-header:build (465ms)
+    ✔  nx run cart:build:production (3s)
 
-——————————————————————————————————————————————————————————————————————————————————————
+ ——————————————————————————————————————————————————————————————————————————————————————
 
-NX   Successfully ran target build for project cart and 3 tasks it depends on (4s)
+ >  NX   Successfully ran target build for project cart and 3 tasks it depends on (4s)
 ```
 
 ### Configuring the Comparison Range for Affected Commands
@@ -336,14 +336,8 @@ This wires up all the CI for you and configures access. Folks who can see your r
 
 To manually connect your workspace to Nx Cloud, run the following command in your repository:
 
-```{% command="pnpm nx connect" %}
-$ nx g nx:connect-to-nx-cloud --quiet --no-interactive
-
-NX   Your Nx Cloud workspace is public
-
-To restrict access, connect it to your Nx Cloud account:
-- Push your changes
-- Login at https://cloud.nx.app to connect your repository
+```shell
+pnpm nx connect
 ```
 
 Click the link in the terminal to claim your workspace on [nx.app](https://nx.app).
@@ -366,18 +360,18 @@ What is more, if you run tasks locally, you will also get cache hits:
 
 ```{% command="nx run-many -t build" %}
 ...
-✔  nx run express-legacy:build  [remote cache]
-✔  nx run nx-plugin-legacy:build  [remote cache]
-✔  nx run esbuild-legacy:build  [remote cache]
-✔  nx run react-native-legacy:build  [remote cache]
-✔  nx run angular-legacy:build  [remote cache]
-✔  nx run remix-legacy:build  [remote cache]
+    ✔  nx run express-legacy:build  [remote cache]
+    ✔  nx run nx-plugin-legacy:build  [remote cache]
+    ✔  nx run esbuild-legacy:build  [remote cache]
+    ✔  nx run react-native-legacy:build  [remote cache]
+    ✔  nx run angular-legacy:build  [remote cache]
+    ✔  nx run remix-legacy:build  [remote cache]
 
-————————————————————————————————————————————————
+ ————————————————————————————————————————————————
 
-NX   Successfully ran target build for 58 projects and 62 tasks they depend on (1m)
+ >  NX   Successfully ran target build for 58 projects and 62 tasks they depend on (1m)
 
-Nx read the output from the cache instead of running the command for 116 out of 120 tasks.
+   Nx read the output from the cache instead of running the command for 116 out of 120 tasks.
 ```
 
 You might also want to learn more about [how to fine-tune caching](/recipes/running-tasks/configure-inputs) to get even better results.

docs/nx-cloud/tutorial/github-actions.md

@@ -207,31 +207,31 @@ pnpm nx build landing-page
 Clearly this is not a scalable solution as it requires us to manually add every new app to the pipeline (and it doesn't include other tasks like `lint`, `test` etc). To improve this we can change the command to run the `build` for all projects like
 
 ```{% command="nx run-many -t build" %}
-✔  nx run shared-product-types:build (429ms)
-✔  nx run shared-product-ui:build (455ms)
-✔  nx run shared-header:build (467ms)
-✔  nx run landing-page:build:production (3s)
-✔  nx run admin:build:production (3s)
-✔  nx run cart:build:production (3s)
+    ✔  nx run shared-product-types:build (429ms)
+    ✔  nx run shared-product-ui:build (455ms)
+    ✔  nx run shared-header:build (467ms)
+    ✔  nx run landing-page:build:production (3s)
+    ✔  nx run admin:build:production (3s)
+    ✔  nx run cart:build:production (3s)
 
-————————————————————————————————————————————————————————————————
+ ————————————————————————————————————————————————————————————————
 
-NX   Successfully ran target build for 6 projects (10s)
+ >  NX   Successfully ran target build for 6 projects (10s)
 ```
 
 This change makes our CI pipeline configuration more maintainable. For a small repository, this might be good enough, but after a little bit of growth this approach will cause your CI times to become unmanageable.
 
 Nx comes with a dedicated ["affected" command](/ci/features/affected) to help with that by only running tasks for projects that were affected by the changes in a given PR.
 
 ```{% command="nx affected -t build" %}
-✔  nx run shared-product-types:build (404ms)
-✔  nx run shared-product-ui:build (445ms)
-✔  nx run shared-header:build (465ms)
-✔  nx run cart:build:production (3s)
+    ✔  nx run shared-product-types:build (404ms)
+    ✔  nx run shared-product-ui:build (445ms)
+    ✔  nx run shared-header:build (465ms)
+    ✔  nx run cart:build:production (3s)
 
-——————————————————————————————————————————————————————————————————————————————————————
+ ——————————————————————————————————————————————————————————————————————————————————————
 
-NX   Successfully ran target build for project cart and 3 tasks it depends on (4s)
+ >  NX   Successfully ran target build for project cart and 3 tasks it depends on (4s)
 ```
 
 ### Configuring the Comparison Range for Affected Commands
@@ -345,18 +345,18 @@ What is more, if you run tasks locally, you will also get cache hits:
 
 ```{% command="nx run-many -t build" %}
 ...
-✔  nx run express-legacy:build  [remote cache]
-✔  nx run nx-plugin-legacy:build  [remote cache]
-✔  nx run esbuild-legacy:build  [remote cache]
-✔  nx run react-native-legacy:build  [remote cache]
-✔  nx run angular-legacy:build  [remote cache]
-✔  nx run remix-legacy:build  [remote cache]
+    ✔  nx run express-legacy:build  [remote cache]
+    ✔  nx run nx-plugin-legacy:build  [remote cache]
+    ✔  nx run esbuild-legacy:build  [remote cache]
+    ✔  nx run react-native-legacy:build  [remote cache]
+    ✔  nx run angular-legacy:build  [remote cache]
+    ✔  nx run remix-legacy:build  [remote cache]
 
-————————————————————————————————————————————————
+ ————————————————————————————————————————————————
 
-NX   Successfully ran target build for 58 projects and 62 tasks they depend on (1m)
+ >  NX   Successfully ran target build for 58 projects and 62 tasks they depend on (1m)
 
-Nx read the output from the cache instead of running the command for 116 out of 120 tasks.
+   Nx read the output from the cache instead of running the command for 116 out of 120 tasks.
 ```
 
 You might also want to learn more about [how to fine-tune caching](/recipes/running-tasks/configure-inputs) to get even better results.