docs(misc): update description field for SEO

Author: juristr

docs/shared/concepts/buildable-and-publishable-libraries.md

@@ -1,3 +1,8 @@
+---
+title: Publishable and Buildable Nx Libraries
+description: Learn about buildable and publishable libraries in Nx, when to use them, and how they adjust your project configuration for distribution.
+---
+
 # Publishable and Buildable Nx Libraries
 
 The `--buildable` and `--publishable` options are available on the Nx library generators for the following plugins:
@@ -13,23 +18,23 @@ This document will look to explain the motivations for why you would use either
 
 You might use the `--publishable` option when generating a new Nx library if your intention is to distribute it outside the monorepo.
 
-One typical scenario for this may be that you use Nx to develop your organizations UI design system component library (maybe using its Storybook integration), which should be available also to your organizations’ apps that are not hosted within the same monorepo.
+One typical scenario for this may be that you use Nx to develop your organizations UI design system component library (maybe using its Storybook integration), which should be available also to your organizations' apps that are not hosted within the same monorepo.
 
-A normal Nx library - let’s call it "workspace library" - is not made for building or publishing. Rather it only includes common lint and test targets in its `project.json` file. These libraries are directly referenced from one of the monorepo’s applications and built together with them.
+A normal Nx library - let's call it "workspace library" - is not made for building or publishing. Rather it only includes common lint and test targets in its `project.json` file. These libraries are directly referenced from one of the monorepo's applications and built together with them.
 
 Keep in mind that the `--publishable` flag does not enable automatic publishing. Rather it adds to your Nx workspace library a builder target that **compiles** and **bundles** your app. The resulting artifact will be ready to be published to some registry (e.g. [npm](https://npmjs.com/)). By having that builder, you can invoke the build via a command like: `nx build mylib` (where "mylib" is the name of the lib) which will then produce an optimized bundle in the `dist/mylib` folder.
 
 One particularity when generating a library with `--publishable` is that it requires you to also provide an `--importPath`. Your import path is the actual scope of your distributable package (e.g.: `@myorg/mylib`) - which needs to be a [valid npm package name](https://docs.npmjs.com/files/package.json#name).
 
-To publish the library (for example to npm) you can run the CLI command: `npm publish` from the artifact located in the `dist` directory. Setting up some automated script in Nx’s `tools` folder may also come in handy.
+To publish the library (for example to npm) you can run the CLI command: `npm publish` from the artifact located in the `dist` directory. Setting up some automated script in Nx's `tools` folder may also come in handy.
 
 For more details on the mechanics, remember that Nx is an open source project, so you can see the actual impact of the generator by looking at the source code (the best starting point is probably `packages/<framework>/src/generators/library/library.ts`).
 
 ## Buildable libraries
 
 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 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.

docs/shared/concepts/common-tasks.md

@@ -1,4 +1,6 @@
 ---
+title: Common Tasks
+description: Learn about standard task naming conventions in Nx projects, including build, serve, test, and lint tasks, for consistent project configuration.
 keywords: [build, serve, test, lint]
 ---
 

docs/shared/concepts/daemon.md

@@ -1,3 +1,8 @@
+---
+title: Nx Daemon
+description: Learn about the Nx Daemon, a background process that speeds up project graph computation in large workspaces by maintaining state between commands.
+---
+
 # Nx Daemon
 
 In version 13 we introduced the opt-in Nx Daemon which Nx can leverage to dramatically speed up project graph computation, particularly for large workspaces.

docs/shared/concepts/decisions/code-ownership.md

@@ -1,3 +1,8 @@
+---
+title: Code Ownership
+description: Learn about code ownership challenges in monorepos and how Nx helps manage shared code with tools like CODEOWNERS and module boundary rules.
+---
+
 # Code Ownership
 
 One of the most obvious benefits of having a monorepo is that you can easily share code across projects. This enables you to apply the Don't Repeat Yourself principle across the whole codebase. Code sharing could mean using a function or a component in multiple projects. Or code sharing could mean using a typescript interface to define the network API interface for both the front end and back end applications.

docs/shared/concepts/decisions/dependency-management.md

@@ -1,3 +1,8 @@
+---
+title: Dependency Management Strategies
+description: Compare independently maintained dependencies versus single version policy approaches for monorepos, with guidance on choosing the right strategy for your team.
+---
+
 # Dependency Management Strategies
 
 When working with a monorepo, one of the key architectural decisions is how to manage dependencies across your projects. This document outlines two main strategies and helps you choose the right approach for your team.

docs/shared/concepts/decisions/folder-structure.md

@@ -1,3 +1,8 @@
+---
+title: Folder Structure
+description: Learn about organizing your Nx monorepo with effective folder structures, and how to easily move or remove projects as your organization evolves.
+---
+
 # Folder Structure
 
 Nx can work with any folder structure you choose, but it is good to have a plan in place for the folder structure of your monorepo.
@@ -51,7 +56,7 @@ libs/
 
 One of the main advantages of using a monorepo is that there is more visibility into code that can be reused across many different applications. Shared projects are a great way to save developers time and effort by reusing a solution to a common problem.
 
-Let’s consider our reference monorepo. The `shared-data-access` project contains the code needed to communicate with the back-end (for example, the URL prefix). We know that this would be the same for all libs; therefore, we should place this in the shared lib and properly document it so that all projects can use it instead of writing their own versions.
+Let's consider our reference monorepo. The `shared-data-access` project contains the code needed to communicate with the back-end (for example, the URL prefix). We know that this would be the same for all libs; therefore, we should place this in the shared lib and properly document it so that all projects can use it instead of writing their own versions.
 
 ```text
   libs/

docs/shared/concepts/decisions/monorepo-polyrepo.md

@@ -1,3 +1,8 @@
+---
+title: Monorepo or Polyrepo
+description: Evaluate the organizational considerations for choosing between monorepo and polyrepo approaches, including team agreements on code management and workflows.
+---
+
 # Monorepo or Polyrepo
 
 Monorepos have a lot of benefits, but there are also some costs involved. We feel strongly that the [technical challenges](/concepts/decisions/why-monorepos) involved in maintaining large monorepos are fully addressed through the efficient use of Nx and Nx Cloud. Rather, the limiting factors in how large your monorepo grows are interpersonal.

docs/shared/concepts/decisions/monorepos.md

@@ -1,3 +1,8 @@
+---
+title: Monorepos
+description: Understand the benefits of monorepos including shared code, atomic changes, developer mobility, and consistent dependencies across your organization.
+---
+
 # Monorepos
 
 A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them.
@@ -8,7 +13,7 @@ A monorepo is a single git repository that holds the source code for multiple ap
 
 - **Atomic changes** - Change a server API and modify the downstream applications that consume that API in the same commit. You can change a button component in a shared library and the applications that use that component in the same commit. A monorepo saves the pain of trying to coordinate commits across multiple repositories.
 
-- **Developer mobility** - Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe.
+- **Developer mobility** - Get a consistent way of building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams' applications and verify that their changes are safe.
 
 - **Single set of dependencies** - [Use a single version of all third-party dependencies](/concepts/decisions/dependency-management), reducing inconsistencies between applications. Less actively developed applications are still kept up-to-date with the latest version of a framework, library, or build tool.
 
@@ -34,7 +39,7 @@ Nx provides tools to give you the benefits of a monorepo without the drawbacks o
 
 - **Consistent Code Generation** - Generators allow you to customize and standardize organizational conventions and structure, removing the need to perform the same manual setup tasks repetitively.
 
-- **Affected Commands** - [Nx’s affected commands](/nx-api/nx/documents/affected) analyze your source code, the context of the changes, and only runs tasks on the affected projects impacted by the source code changes.
+- **Affected Commands** - [Nx's affected commands](/nx-api/nx/documents/affected) analyze your source code, the context of the changes, and only runs tasks on the affected projects impacted by the source code changes.
 
 - **Remote Caching** - Nx provides local caching and support for remote caching of command executions. With remote caching, when someone on your team runs a command, everyone else gets access to those artifacts to speed up their command executions, bringing them down from minutes to seconds. Nx helps you scale your development to massive applications and libraries even more with distributed task execution and incremental builds.
 

docs/shared/concepts/decisions/project-dependency-rules.md

@@ -1,3 +1,8 @@
+---
+title: Project Dependency Rules
+description: Learn how to organize your Nx workspace with library types like feature, UI, data-access, and utility libraries, and enforce dependency rules between them.
+---
+
 # Project Dependency Rules
 
 There are many types of libraries in a workspace. You can identify the type of a library through a naming convention and/or by using the project tagging system. With explicitly defined types, you can also use Nx to enforce project dependency rules based on the types of each project. This article explains one possible way to organize your repository projects by type. Every repository is different and yours may need a different set of types.

docs/shared/concepts/decisions/project-size.md

@@ -1,3 +1,8 @@
+---
+title: Project Size
+description: Understand the trade-offs of project granularity in Nx, including benefits like faster commands, clearer boundaries, and improved developer experience.
+---
+
 # Project Size
 
 Like a lot of decisions in programming, deciding to make a new Nx project or not is all about trade-offs. Each organization will decide on their own conventions, but here are some trade-offs to bear in mind as you have the conversation.

docs/shared/concepts/executors-and-configurations.md

@@ -1,3 +1,8 @@
+---
+title: Executors and Configurations
+description: Learn about Nx executors, pre-packaged node scripts that run tasks consistently across projects, and how to configure them in project.json files.
+---
+
 # Executors and Configurations
 
 Executors are pre-packaged node scripts that can be used to run tasks in a consistent way.

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

@@ -1,3 +1,8 @@
+---
+title: How Caching Works
+description: Learn how Nx's computation hashing enables powerful caching, including what factors determine cache validity and how local and remote caches work together.
+---
+
 # How Caching Works
 
 Before running any cacheable task, Nx computes its computation hash. As long as the computation hash is the same, the output of
@@ -18,11 +23,11 @@ By default, the computation hash for something like `nx test remixapp` includes:
 
 After Nx computes the hash for a task, it then checks if it ran this exact computation before. First, it checks locally, and then if it is missing, and if a remote cache is configured, it checks remotely. If a matching computation is found, Nx retrieves and replays it. This includes restoring files.
 
-Nx places the right files in the right folders and prints the terminal output. From the user’s point of view, the command ran the same, just a lot faster.
+Nx places the right files in the right folders and prints the terminal output. From the user's point of view, the command ran the same, just a lot faster.
 
 ![cache](/shared/images/caching/cache.svg)
 
-If Nx doesn’t find a corresponding computation hash, Nx runs the task, and after it completes, it takes the outputs and the terminal logs and stores them locally (and, if configured, remotely as well). All of this happens transparently, so you don’t have to worry about it.
+If Nx doesn't find a corresponding computation hash, Nx runs the task, and after it completes, it takes the outputs and the terminal logs and stores them locally (and, if configured, remotely as well). All of this happens transparently, so you don't have to worry about it.
 
 ## Optimizations
 
@@ -96,8 +101,7 @@ Nx cache works on the process level. Regardless of the tools used to build/test/
 
 {% /tab %}
 
-If the `outputs` property for a given target isn't defined in the project'
-s `package.json` file, Nx will look at the global, workspace-wide definition in the `targetDefaults` section of `nx.json`:
+If the `outputs` property for a given target isn't defined in the project's `package.json` file, Nx will look at the global, workspace-wide definition in the `targetDefaults` section of `nx.json`:
 
 ```jsonc {% fileName="nx.json"%}
 {

docs/shared/concepts/inferred-tasks.md

@@ -1,3 +1,8 @@
+---
+title: Inferred Tasks (Project Crystal)
+description: Learn how Nx plugins automatically infer tasks from tool configurations, enabling caching, task dependencies, and optimized execution without manual setup.
+---
+
 # Inferred Tasks (Project Crystal)
 
 In Nx version 18, Nx plugins can automatically infer tasks for your projects based on the configuration of different tools. Many tools have configuration files which determine what a tool does. Nx is able to cache the results of running the tool. Nx plugins use the same configuration files to infer how Nx should [run the task](/features/run-tasks). This includes [fine-tuned cache settings](/features/cache-task-results) and automatic [task dependencies](/concepts/task-pipeline-configuration).

docs/shared/concepts/mental-model.md

@@ -1,3 +1,8 @@
+---
+title: Mental Model
+description: Understand how Nx works with project graphs, task graphs, affected commands, and caching to efficiently manage your monorepo development workflow.
+---
+
 # Mental Model
 
 Nx is a VSCode of build tools, with a powerful core, driven by metadata, and extensible through [plugins](/concepts/nx-plugins). Nx works with a
@@ -6,13 +11,13 @@ with project graphs, task graphs, affected commands, computation hashing and cac
 
 ## The project graph
 
-A project graph is used to reflect the source code in your repository and all the external dependencies that aren’t
+A project graph is used to reflect the source code in your repository and all the external dependencies that aren't
 authored in your repository, such as Webpack, React, Angular, and so forth.
 
 ![project-graph](/shared/mental-model/project-graph.svg)
 
 Nx analyzes your file system to detect projects. Projects are identified by the presence of a `package.json` file or `project.json` file. Projects identification can also be customized through plugins. You can manually define dependencies between
-the project nodes, but you don’t have to do it very often. Nx analyzes files’ source code, your installed dependencies, TypeScript
+the project nodes, but you don't have to do it very often. Nx analyzes files' source code, your installed dependencies, TypeScript
 files, and others figuring out these dependencies for you. Nx also stores the cached project graph, so it only
 reanalyzes the files you have changed.
 
@@ -43,8 +48,8 @@ For instance `nx test lib` creates a task graph with a single node:
 
 A task is an invocation of a target. If you invoke the same target twice, you create two tasks.
 
-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
+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 -t test -p app1 app2 lib`, the created task graph will look like this:
 {% side-by-side %}
 
@@ -62,11 +67,11 @@ running `nx run-many -t test -p app1 app2 lib`, the created task graph will look
 {% /graph %}
 {% /side-by-side %}
 
-Even though the apps depend on `lib`, testing `app1` doesn’t depend on the testing `lib`. This means that the two tasks
+Even though the apps depend on `lib`, testing `app1` doesn't depend on the testing `lib`. This means that the two tasks
 can
 run in parallel.
 
-Let’s look at the test target relying on its dependencies.
+Let's look at the test target relying on its dependencies.
 
 ```json
 {
@@ -161,12 +166,12 @@ After Nx computes the hash for a task, it then checks if it ran this exact compu
 and then if it is missing, and if a remote cache is configured, it checks remotely.
 
 If Nx finds the computation, Nx retrieves it and replay it. Nx places the right files in the right folders and prints
-the terminal output. So from the user’s point of view, the command ran the same, just a lot faster.
+the terminal output. So from the user's point of view, the command ran the same, just a lot faster.
 
 ![cache](/shared/mental-model/cache.svg)
 
-If Nx doesn’t find this computation, Nx runs the task, and after it completes, it takes the outputs and the terminal
-output and stores it locally (and if configured remotely). All of this happens transparently, so you don’t have to worry
+If Nx doesn't find this computation, Nx runs the task, and after it completes, it takes the outputs and the terminal
+output and stores it locally (and if configured remotely). All of this happens transparently, so you don't have to worry
 about it.
 
 Although conceptually this is fairly straightforward, Nx optimizes this to make this experience good for you. For
@@ -209,7 +214,7 @@ it locally.
 ## In summary
 
 - Nx is able to analyze your source code to create a Project Graph.
-- Nx can use the project graph and information about projects’ targets to create a Task Graph.
+- Nx can use the project graph and information about projects' targets to create a Task Graph.
 - Nx is able to perform code-change analysis to create the smallest task graph for your PR.
 - Nx supports computation caching to never execute the same computation twice. This computation cache is pluggable and
   can be distributed.

docs/shared/concepts/module-federation/faster-builds.md

@@ -1,3 +1,8 @@
+---
+title: Faster Builds with Module Federation
+description: Learn how Module Federation in Nx enables faster builds by splitting large SPAs into smaller remote applications while minimizing common downsides.
+---
+
 # Faster Builds with Module Federation
 
 As applications grow, builds can become unacceptably slow, which leads to slow CI/CD pipelines and long dev-server