fix(core): align terminal output padding and remove leading arrow

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,8 +336,14 @@ 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:
 
-```shell
-pnpm nx connect
+```{% 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
 ```
 
 Click the link in the terminal to claim your workspace on [nx.app](https://nx.app).
@@ -360,18 +366,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.