docs(misc): add description frontmatter for better SEO
This commit is contained in:
parent
d428eec060
commit
437bad4aac
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx and Angular Versions
|
||||||
|
description: A comprehensive compatibility matrix showing which Nx versions work with different Angular versions, including recommended versions and supported ranges.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx and Angular Versions
|
# Nx and Angular Versions
|
||||||
|
|
||||||
The latest version of Nx supports the [actively supported versions of Angular (current and LTS versions)](https://angular.dev/reference/releases#actively-supported-versions). Workspaces in any of those versions are recommended to use the latest version of Nx to benefit from all the new features and fixes.
|
The latest version of Nx supports the [actively supported versions of Angular (current and LTS versions)](https://angular.dev/reference/releases#actively-supported-versions). Workspaces in any of those versions are recommended to use the latest version of Nx to benefit from all the new features and fixes.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx and the Angular CLI
|
||||||
|
description: Compare Nx and Angular CLI features, understand similarities and differences, and learn how Nx enhances Angular development with improved caching, monorepo support, and advanced tooling.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx and the Angular CLI
|
# Nx and the Angular CLI
|
||||||
|
|
||||||
{% youtube
|
{% youtube
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx Devkit and Angular Devkit
|
||||||
|
description: Compare Nx Devkit and Angular Devkit for creating generators and executors, understand key differences in implementation, and learn how to convert between the two approaches.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx Devkit and Angular Devkit
|
# Nx Devkit and Angular Devkit
|
||||||
|
|
||||||
{% callout type="note" title="Nx & Angular" %}
|
{% callout type="note" title="Nx & Angular" %}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Detox Plugin for Nx
|
||||||
|
description: Learn how to set up and use Detox for end-to-end testing of mobile applications in your Nx workspace, including environment setup and configuration options.
|
||||||
|
---
|
||||||
|
|
||||||
Detox is gray box end-to-end testing and automation library for mobile apps. It has a lot of great features:
|
Detox is gray box end-to-end testing and automation library for mobile apps. It has a lot of great features:
|
||||||
|
|
||||||
- Cross Platform
|
- Cross Platform
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Dependency Checks ESLint Rule
|
||||||
|
description: Learn how to use the @nx/dependency-checks ESLint rule to identify mismatches between dependencies in package.json and actual project dependencies.
|
||||||
|
---
|
||||||
|
|
||||||
# Dependency Checks rule
|
# Dependency Checks rule
|
||||||
|
|
||||||
The `@nx/dependency-checks` ESLint rule enables you to discover mismatches between dependencies specified in a project's `package.json` and the dependencies that your project depends on. If your project is using, for example, the `axios`, but the `package.json` does not specify it as a dependency, your library might not work correctly. This rule helps catch these problems before your users do.
|
The `@nx/dependency-checks` ESLint rule enables you to discover mismatches between dependencies specified in a project's `package.json` and the dependencies that your project depends on. If your project is using, for example, the `axios`, but the `package.json` does not specify it as a dependency, your library might not work correctly. This rule helps catch these problems before your users do.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Enforce Module Boundaries ESLint Rule
|
||||||
|
description: Learn how to use the @nx/enforce-module-boundaries ESLint rule to define strict rules for accessing resources between different projects in your Nx workspace.
|
||||||
|
---
|
||||||
|
|
||||||
# Enforce module boundaries rule
|
# Enforce module boundaries rule
|
||||||
|
|
||||||
The `@nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between
|
The `@nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx ESLint Plugin
|
||||||
|
description: An overview of the @nx/eslint-plugin package, which provides recommended ESLint configurations and Nx-specific rules for enforcing module boundaries and dependency checks.
|
||||||
|
---
|
||||||
|
|
||||||
The `@nx/eslint-plugin` package is an ESLint plugin that contains a collection of recommended ESLint rule configurations which you can extend from in your own ESLint configs, as well as the following Nx-specific ESLint rules:
|
The `@nx/eslint-plugin` package is an ESLint plugin that contains a collection of recommended ESLint rule configurations which you can extend from in your own ESLint configs, as well as the following Nx-specific ESLint rules:
|
||||||
|
|
||||||
- [enforce-module-boundaries](#enforce-module-boundaries-rule)
|
- [enforce-module-boundaries](#enforce-module-boundaries-rule)
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: ESLint Plugin for Nx
|
||||||
|
description: Learn how to set up and use the @nx/eslint plugin to integrate ESLint with Nx, enabling caching and providing code generators for ESLint configuration.
|
||||||
|
---
|
||||||
|
|
||||||
The ESLint plugin integrates [ESLint](https://eslint.org/) with Nx. It allows you to run ESLint through Nx with caching enabled. It also includes code generators to help you set up ESLint in your workspace.
|
The ESLint plugin integrates [ESLint](https://eslint.org/) with Nx. It allows you to run ESLint through Nx with caching enabled. It also includes code generators to help you set up ESLint in your workspace.
|
||||||
|
|
||||||
## Setting Up @nx/eslint
|
## Setting Up @nx/eslint
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Expo Plugin for Nx
|
||||||
|
description: Learn how to use the @nx/expo plugin to manage Expo applications and libraries within an Nx workspace, including setup, configuration, and task inference.
|
||||||
|
---
|
||||||
|
|
||||||
Expo is an open-source framework for apps that run natively on Android, iOS, and the web. Expo brings together the best of mobile and the web and enables many important features for building and scaling an app.
|
Expo is an open-source framework for apps that run natively on Android, iOS, and the web. Expo brings together the best of mobile and the web and enables many important features for building and scaling an app.
|
||||||
|
|
||||||
Expo is a set of tools built on top of React Native. The Nx Plugin for Expo contains generators for managing Expo applications and libraries within an Nx workspace.
|
Expo is a set of tools built on top of React Native. The Nx Plugin for Expo contains generators for managing Expo applications and libraries within an Nx workspace.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Express Plugin for Nx
|
||||||
|
description: Learn how to use the @nx/express plugin to create and manage Express applications in your Nx workspace, including setup and common recipes.
|
||||||
|
---
|
||||||
|
|
||||||
[Express](https://expressjs.com/) is a mature, minimal, and an open source web framework for making web applications and
|
[Express](https://expressjs.com/) is a mature, minimal, and an open source web framework for making web applications and
|
||||||
apis.
|
apis.
|
||||||
|
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nest.js Plugin for Nx
|
||||||
|
description: Learn how to use the @nx/nest plugin to create and manage Nest.js applications and libraries in your Nx workspace, including setup and generators.
|
||||||
|
---
|
||||||
|
|
||||||
Nest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers:
|
Nest.js is a framework designed for building scalable server-side applications. In many ways, Nest is familiar to Angular developers:
|
||||||
|
|
||||||
- It has excellent TypeScript support.
|
- It has excellent TypeScript support.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Node.js Plugin for Nx
|
||||||
|
description: Learn how to use the @nx/node plugin to create and manage Node.js applications and libraries in your Nx workspace, including setup, building, and testing.
|
||||||
|
---
|
||||||
|
|
||||||
The Node Plugin contains generators and executors to manage Node applications within an Nx workspace. It provides:
|
The Node Plugin contains generators and executors to manage Node applications within an Nx workspace. It provides:
|
||||||
|
|
||||||
## Setting Up @nx/node
|
## Setting Up @nx/node
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx Plugin Development
|
||||||
|
description: Learn about the @nx/plugin package, which provides tooling to help create and maintain Nx plugins with generators and executors.
|
||||||
|
---
|
||||||
|
|
||||||
Nx plugins are npm packages that contain [generators](/features/generate-code) and [executors](/concepts/executors-and-configurations) to extend a Nx workspace.
|
Nx plugins are npm packages that contain [generators](/features/generate-code) and [executors](/concepts/executors-and-configurations) to extend a Nx workspace.
|
||||||
|
|
||||||
This package contains tooling to help plugin authors create and maintain plugins.
|
This package contains tooling to help plugin authors create and maintain plugins.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: React Plugin for Nx
|
||||||
|
description: Learn how to use the @nx/react plugin to create and manage React applications and libraries in your Nx workspace, including components, hooks, and more.
|
||||||
|
---
|
||||||
|
|
||||||
The React plugin contains executors and generators for managing React applications and libraries within an Nx workspace.
|
The React plugin contains executors and generators for managing React applications and libraries within an Nx workspace.
|
||||||
It provides:
|
It provides:
|
||||||
|
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Web Plugin for Nx
|
||||||
|
description: Learn how to use the @nx/web plugin to create and manage Web Component applications and libraries in your Nx workspace, including testing and building.
|
||||||
|
---
|
||||||
|
|
||||||
The Nx Plugin for Web Components contains generators for managing Web Component applications and libraries within an Nx workspace. It provides:
|
The Nx Plugin for Web Components contains generators for managing Web Component applications and libraries within an Nx workspace. It provides:
|
||||||
|
|
||||||
- Integration with libraries such as Jest, Cypress, and Storybook.
|
- Integration with libraries such as Jest, Cypress, and Storybook.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx, NodeJS and TypeScript Compatibility Matrix
|
||||||
|
description: A reference table showing which versions of Node.js and TypeScript are compatible with different major versions of Nx.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx, NodeJS and TypeScript Compatibility Matrix
|
# Nx, NodeJS and TypeScript Compatibility Matrix
|
||||||
|
|
||||||
Below is a reference table that matches versions the latest major versions of Nx to the version TypeScript that it uses
|
Below is a reference table that matches versions the latest major versions of Nx to the version TypeScript that it uses
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Workspace Plugin for Nx
|
||||||
|
description: Learn about the core workspace plugin that provides essential executors and generators for any Nx workspace, including tools for project management.
|
||||||
|
---
|
||||||
|
|
||||||
The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it.
|
The workspace plugin contains executors and generators that are useful for any Nx workspace. It should be present in every Nx workspace and other plugins build on it.
|
||||||
|
|
||||||
## Creating Local Generators
|
## Creating Local Generators
|
||||||
|
|||||||
@ -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
|
# Publishable and Buildable Nx Libraries
|
||||||
|
|
||||||
The `--buildable` and `--publishable` options are available on the Nx library generators for the following plugins:
|
The `--buildable` and `--publishable` options are available on the Nx library generators for the following plugins:
|
||||||
@ -13,15 +18,15 @@ 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.
|
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.
|
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).
|
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`).
|
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`).
|
||||||
|
|
||||||
@ -29,7 +34,7 @@ For more details on the mechanics, remember that Nx is an open source project, s
|
|||||||
|
|
||||||
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 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" %}
|
{% 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.
|
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.
|
||||||
|
|||||||
@ -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]
|
keywords: [build, serve, test, lint]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
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
|
```text
|
||||||
libs/
|
libs/
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
||||||
|
|||||||
@ -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
|
# Monorepos
|
||||||
|
|
||||||
A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them.
|
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.
|
- **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.
|
- **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.
|
- **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.
|
- **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.
|
||||||
|
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
||||||
|
|||||||
@ -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
|
# 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.
|
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.
|
||||||
|
|||||||
@ -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 and Configurations
|
||||||
|
|
||||||
Executors are pre-packaged node scripts that can be used to run tasks in a consistent way.
|
Executors are pre-packaged node scripts that can be used to run tasks in a consistent way.
|
||||||
|
|||||||
@ -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
|
# 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
|
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.
|
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.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
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
|
## Optimizations
|
||||||
|
|
||||||
@ -96,8 +101,7 @@ Nx cache works on the process level. Regardless of the tools used to build/test/
|
|||||||
|
|
||||||
{% /tab %}
|
{% /tab %}
|
||||||
|
|
||||||
If the `outputs` property for a given target isn't defined in the project'
|
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`:
|
||||||
s `package.json` file, Nx will look at the global, workspace-wide definition in the `targetDefaults` section of `nx.json`:
|
|
||||||
|
|
||||||
```jsonc {% fileName="nx.json"%}
|
```jsonc {% fileName="nx.json"%}
|
||||||
{
|
{
|
||||||
|
|||||||
@ -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)
|
# 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).
|
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).
|
||||||
|
|||||||
@ -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
|
# 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
|
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
|
## 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.
|
authored in your repository, such as Webpack, React, Angular, and so forth.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
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
|
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
|
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.
|
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.
|
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
|
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
|
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:
|
running `nx run-many -t test -p app1 app2 lib`, the created task graph will look like this:
|
||||||
{% side-by-side %}
|
{% side-by-side %}
|
||||||
|
|
||||||
@ -62,11 +67,11 @@ running `nx run-many -t test -p app1 app2 lib`, the created task graph will look
|
|||||||
{% /graph %}
|
{% /graph %}
|
||||||
{% /side-by-side %}
|
{% /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
|
can
|
||||||
run in parallel.
|
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
|
```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.
|
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
|
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.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
If Nx doesn’t find this computation, Nx runs the task, and after it completes, it takes the outputs and the terminal
|
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
|
output and stores it locally (and if configured remotely). All of this happens transparently, so you don't have to worry
|
||||||
about it.
|
about it.
|
||||||
|
|
||||||
Although conceptually this is fairly straightforward, Nx optimizes this to make this experience good for you. For
|
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
|
## In summary
|
||||||
|
|
||||||
- Nx is able to analyze your source code to create a Project Graph.
|
- 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 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
|
- Nx supports computation caching to never execute the same computation twice. This computation cache is pluggable and
|
||||||
can be distributed.
|
can be distributed.
|
||||||
|
|||||||
@ -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
|
# Faster Builds with Module Federation
|
||||||
|
|
||||||
As applications grow, builds can become unacceptably slow, which leads to slow CI/CD pipelines and long dev-server
|
As applications grow, builds can become unacceptably slow, which leads to slow CI/CD pipelines and long dev-server
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Manage Library Versions with Module Federation
|
||||||
|
description: Learn how Module Federation's Shared API prevents dependency conflicts and reduces bundle size by managing shared library versions across federated modules.
|
||||||
|
---
|
||||||
|
|
||||||
# Manage Library Versions with Module Federation
|
# Manage Library Versions with Module Federation
|
||||||
|
|
||||||
Federated modules are bundled and packaged independently with all the dependencies they need to run smoothly in federated applications called _remotes_. This means that if you have a federated module that depends on a library, the library will be bundled with the federated module within a remote. This independence provides much flexibility, allowing individual federated modules to function without relying on external resources.
|
Federated modules are bundled and packaged independently with all the dependencies they need to run smoothly in federated applications called _remotes_. This means that if you have a federated module that depends on a library, the library will be bundled with the federated module within a remote. This independence provides much flexibility, allowing individual federated modules to function without relying on external resources.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Micro Frontend Architecture
|
||||||
|
description: Explore how Nx supports Micro Frontend architecture with Module Federation, enabling independent deployment while managing associated challenges.
|
||||||
|
---
|
||||||
|
|
||||||
# Micro Frontend Architecture
|
# Micro Frontend Architecture
|
||||||
|
|
||||||
Nx provides out-of-the-box [Module Federation](/concepts/module-federation/faster-builds-with-module-federation) support to both
|
Nx provides out-of-the-box [Module Federation](/concepts/module-federation/faster-builds-with-module-federation) support to both
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Module Federation and Nx
|
||||||
|
description: Learn how Nx provides out-of-the-box support for Module Federation, making it easier to share code between applications in a monorepo environment.
|
||||||
|
---
|
||||||
|
|
||||||
# Module Federation and Nx
|
# Module Federation and Nx
|
||||||
|
|
||||||
Module Federation is a technique that allows developers to share code and resources across multiple applications. It has become more popular in recent years since the addition of the [ModuleFederationPlugin](https://webpack.js.org/plugins/module-federation-plugin/) in [Webpack](https://webpack.js.org).
|
Module Federation is a technique that allows developers to share code and resources across multiple applications. It has become more popular in recent years since the addition of the [ModuleFederationPlugin](https://webpack.js.org/plugins/module-federation-plugin/) in [Webpack](https://webpack.js.org).
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx Module Federation Technical Overview
|
||||||
|
description: Understand the technical details of how Nx implements Module Federation through executors and webpack configuration utilities.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx Module Federation Technical Overview
|
# Nx Module Federation Technical Overview
|
||||||
|
|
||||||
Nx's Module Federation support is provided through a mixture of `executors` and the `withModuleFederation()` util that is used in you `webpack.config` file. Understanding what is happening under the hood can help when developing applications that use Module Federation as well as debugging any potential issues you run into.
|
Nx's Module Federation support is provided through a mixture of `executors` and the `withModuleFederation()` util that is used in you `webpack.config` file. Understanding what is happening under the hood can help when developing applications that use Module Federation as well as debugging any potential issues you run into.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: What Are Nx Plugins?
|
||||||
|
description: Learn how Nx plugins help developers integrate tools and frameworks with Nx by providing automated configuration, code generation, and dependency management.
|
||||||
|
---
|
||||||
|
|
||||||
# What Are Nx Plugins?
|
# What Are Nx Plugins?
|
||||||
|
|
||||||
Nx plugins help developers use a tool or framework with Nx. They allow the plugin author who knows the best way to use a tool with Nx to codify their expertise and allow the whole community to reuse those solutions.
|
Nx plugins help developers use a tool or framework with Nx. They allow the plugin author who knows the best way to use a tool with Nx to codify their expertise and allow the whole community to reuse those solutions.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Sync Generators
|
||||||
|
description: Learn how to use Nx sync generators to maintain repository state and update configuration files based on the project graph before tasks are run.
|
||||||
|
---
|
||||||
|
|
||||||
# Sync Generators
|
# Sync Generators
|
||||||
|
|
||||||
In Nx 19.8, you can use sync generators to ensure that your repository is maintained in a correct state. One specific application is to use the project graph to update files. These can be global configuration files or scripts, or at the task level to ensure that files are in sync before a task is run.
|
In Nx 19.8, you can use sync generators to ensure that your repository is maintained in a correct state. One specific application is to use the project graph to update files. These can be global configuration files or scripts, or at the task level to ensure that files are in sync before a task is run.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'What is a Task Pipeline'
|
||||||
|
description: 'Learn how Nx manages task dependencies and execution order in monorepo workspaces, ensuring proper build sequences for interconnected projects.'
|
||||||
|
---
|
||||||
|
|
||||||
# What is a Task Pipeline
|
# What is a Task Pipeline
|
||||||
|
|
||||||
If you have a monorepo workspace (or modularized app), you rarely just run one task. Almost certainly there are relationships among the projects in the workspace and hence tasks need to follow a certain order.
|
If you have a monorepo workspace (or modularized app), you rarely just run one task. Almost certainly there are relationships among the projects in the workspace and hence tasks need to follow a certain order.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Managing Configuration Files'
|
||||||
|
description: 'Learn how Nx helps manage different types of configuration files in your workspace, including both Nx-specific and tool-specific configurations at global and project levels.'
|
||||||
|
---
|
||||||
|
|
||||||
# Managing Configuration Files
|
# Managing Configuration Files
|
||||||
|
|
||||||
Besides providing caching and task orchestration, Nx also helps incorporate numerous tools and frameworks into your repo. With all these pieces of software commingling, you can end up with a lot of configuration files. Nx plugins help to abstract away some of the difficulties of managing this configuration, but the configuration is all still accessible, in case there is a particular setting that you need to change.
|
Besides providing caching and task orchestration, Nx also helps incorporate numerous tools and frameworks into your repo. With all these pieces of software commingling, you can end up with a lot of configuration files. Nx plugins help to abstract away some of the difficulties of managing this configuration, but the configuration is all still accessible, in case there is a particular setting that you need to change.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'TypeScript Project Linking'
|
||||||
|
description: 'Learn how to efficiently reference code between TypeScript projects in your monorepo using project linking instead of relative paths.'
|
||||||
|
---
|
||||||
|
|
||||||
# Typescript Project Linking
|
# Typescript Project Linking
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/D9D8KNffyBk" title="TypeScript Monorepos Done Right!" /%}
|
{% youtube src="https://youtu.be/D9D8KNffyBk" title="TypeScript Monorepos Done Right!" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Angular Schematics and Builders'
|
||||||
|
description: 'Learn about the deprecation of Angular schematics and builders in Nx 17, and how to handle interoperability between Nx and Angular CLI tools.'
|
||||||
|
---
|
||||||
|
|
||||||
# Angular Schematics and Builders
|
# Angular Schematics and Builders
|
||||||
|
|
||||||
As of Nx 17, official Nx plugins no longer export [schematics](https://angular.dev/tools/cli/schematics) and [builders](https://angular.dev/tools/cli/cli-builder) that can be directly consumed by the Angular CLI. Since Angular CLI users are not a large portion of Nx's user base, it made sense to stop maintaining that code.
|
As of Nx 17, official Nx plugins no longer export [schematics](https://angular.dev/tools/cli/schematics) and [builders](https://angular.dev/tools/cli/cli-builder) that can be directly consumed by the Angular CLI. Since Angular CLI users are not a large portion of Nx's user base, it made sense to stop maintaining that code.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'As Provided vs. Derived Generator Path Options'
|
||||||
|
description: 'Learn about the transition from derived to as-provided path options in Nx generators, improving transparency and predictability in code generation.'
|
||||||
|
---
|
||||||
|
|
||||||
# As Provided vs. Derived Generator Path Options
|
# As Provided vs. Derived Generator Path Options
|
||||||
|
|
||||||
Nx is moving toward a more transparent and predictable way of determining where code will be generated when you run a generator. The new behavior is to take generator options _as provided_ and place the generated code in the exact folder that you specify. Nx will only use the new behavior in Nx version 20. The directory can be specified with a `--directory` flag or use a fully specified path (i.e. `libs/shared/my-lib/src/my-component`). The `--directory` flag will be calculated relative to where you run the command.
|
Nx is moving toward a more transparent and predictable way of determining where code will be generated when you run a generator. The new behavior is to take generator options _as provided_ and place the generated code in the exact folder that you specify. Nx will only use the new behavior in Nx version 20. The directory can be specified with a `--directory` flag or use a fully specified path (i.e. `libs/shared/my-lib/src/my-component`). The `--directory` flag will be calculated relative to where you run the command.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Cacheable Operations'
|
||||||
|
description: 'Learn about the transition from cacheableOperations array to the cache property in Nx 17 for defining which tasks are cacheable.'
|
||||||
|
---
|
||||||
|
|
||||||
# cacheableOperations
|
# cacheableOperations
|
||||||
|
|
||||||
In Nx < 17, the way to define which tasks were cacheable was to add the task name to the `cacheableOperations` array in `nx.json`. This way of defining cacheable tasks required all tasks named `test` to be either cacheable or not cacheable.
|
In Nx < 17, the way to define which tasks were cacheable was to add the task name to the `cacheableOperations` array in `nx.json`. This way of defining cacheable tasks required all tasks named `test` to be either cacheable or not cacheable.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Deprecating Custom Tasks Runner'
|
||||||
|
description: 'Learn about the transition from Custom Tasks Runner to the new plugin-based API in Nx, including pre and post task execution hooks and self-hosted remote cache options.'
|
||||||
|
---
|
||||||
|
|
||||||
# Deprecating Custom Tasks Runner
|
# Deprecating Custom Tasks Runner
|
||||||
|
|
||||||
The Nx core has been migrated to Rust. However, the Custom Tasks Runner API is not compatible with this rewrite because it allows modifications to the lifecycle of the Nx command execution, which could break important invariants that Nx depends on.
|
The Nx core has been migrated to Rust. However, the Custom Tasks Runner API is not compatible with this rewrite because it allows modifications to the lifecycle of the Nx command execution, which could break important invariants that Nx depends on.
|
||||||
@ -8,7 +13,7 @@ The custom task runners API was created many years ago and has not been supporte
|
|||||||
|
|
||||||
### Custom Tasks Runner Version
|
### Custom Tasks Runner Version
|
||||||
|
|
||||||
Let’s imagine that you have implemented a custom task runner as follows:
|
Let's imagine that you have implemented a custom task runner as follows:
|
||||||
|
|
||||||
```typescript
|
```typescript
|
||||||
function serializeTasksResults(taskResults: { [taskId: string]: TaskResult }) {
|
function serializeTasksResults(taskResults: { [taskId: string]: TaskResult }) {
|
||||||
@ -193,7 +198,7 @@ We recognize that many organizations have been using DIY remote cache solutions.
|
|||||||
|
|
||||||
### Example Configuration Change
|
### Example Configuration Change
|
||||||
|
|
||||||
Enabling a Nx Powerpack plugin will configure it in `nx.json`. The specific modification depends on your repository’s configuration. The following is one example, where a custom tasks runner configuration in `nx.json` will be removed:
|
Enabling a Nx Powerpack plugin will configure it in `nx.json`. The specific modification depends on your repository's configuration. The following is one example, where a custom tasks runner configuration in `nx.json` will be removed:
|
||||||
|
|
||||||
```json
|
```json
|
||||||
{
|
{
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Global Implicit Dependencies'
|
||||||
|
description: 'Learn about the transition from global implicit dependencies to inputs and namedInputs in Nx, and how to properly configure project dependencies on global files.'
|
||||||
|
---
|
||||||
|
|
||||||
# Global Implicit Dependencies
|
# Global Implicit Dependencies
|
||||||
|
|
||||||
Since v14.4, Nx supports [`inputs` and `namedInputs`](/recipes/running-tasks/configure-inputs) for setting up implicit dependencies. As of Nx v16, the `implicitDependencies` defined in `nx.json` are ignored and do not influence the affected graph. This field will be removed in v17. The [`implicitDependencies` in the project configuration](/reference/project-configuration#implicitdependencies) are still the best way to manually set up a dependency between two projects that Nx is not able to detect automatically.
|
Since v14.4, Nx supports [`inputs` and `namedInputs`](/recipes/running-tasks/configure-inputs) for setting up implicit dependencies. As of Nx v16, the `implicitDependencies` defined in `nx.json` are ignored and do not influence the affected graph. This field will be removed in v17. The [`implicitDependencies` in the project configuration](/reference/project-configuration#implicitdependencies) are still the best way to manually set up a dependency between two projects that Nx is not able to detect automatically.
|
||||||
|
|||||||
@ -1,4 +1,7 @@
|
|||||||
# Integrated Repos vs. Package-Based Repos vs. Standalone Apps
|
---
|
||||||
|
title: 'Integrated Repos vs. Package-Based Repos vs. Standalone Apps'
|
||||||
|
description: 'Understand the historical differences between integrated, package-based, and standalone repositories in Nx, and how to choose the right approach for your needs.'
|
||||||
|
---
|
||||||
|
|
||||||
{% callout type="note" title="" %}
|
{% callout type="note" title="" %}
|
||||||
As of Nx 20, it is no longer useful to draw a distinction between integrated and package-based repositories. We've removed references to these terms in the rest of the documentation, but this page is kept here to describe the terms for historical reasons.
|
As of Nx 20, it is no longer useful to draw a distinction between integrated and package-based repositories. We've removed references to these terms in the rest of the documentation, but this page is kept here to describe the terms for historical reasons.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Legacy Cache'
|
||||||
|
description: 'Learn about the transition from legacy file system cache to the new database cache in Nx 21, including migration options for custom task runners and shared caches.'
|
||||||
|
---
|
||||||
|
|
||||||
# Legacy Cache
|
# Legacy Cache
|
||||||
|
|
||||||
In Nx 21, the legacy file system cache will be removed in favor of a new database cache. The new database cache stores metadata in a database, rather than blindly trusting the file system. The database cache has the following benefits:
|
In Nx 21, the legacy file system cache will be removed in favor of a new database cache. The new database cache stores metadata in a database, rather than blindly trusting the file system. The database cache has the following benefits:
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'NPM Scope'
|
||||||
|
description: 'Learn about the deprecation of npmScope property in nx.json and how to properly configure organization prefixes using package.json name property.'
|
||||||
|
---
|
||||||
|
|
||||||
# NPM Scope
|
# NPM Scope
|
||||||
|
|
||||||
The `npmScope` property of the `nx.json` file is deprecated as of version 16.2.0. `npmScope` was used as a prefix for the names of newly created projects. The new recommended way to define the organization prefix is to set the `name` property in the root `package.json` file to `@my-org/root`. Then `@my-org/` will be used as a prefix for all newly created projects.
|
The `npmScope` property of the `nx.json` file is deprecated as of version 16.2.0. `npmScope` was used as a prefix for the names of newly created projects. The new recommended way to define the organization prefix is to set the `name` property in the root `package.json` file to `@my-org/root`. Then `@my-org/` will be used as a prefix for all newly created projects.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Rescoping Packages from @nrwl to @nx'
|
||||||
|
description: 'Learn about the transition of official Nx plugins from @nrwl to @nx npm scope, and how to update your dependencies accordingly.'
|
||||||
|
---
|
||||||
|
|
||||||
# Rescope Packages from @nrwl to @nx
|
# Rescope Packages from @nrwl to @nx
|
||||||
|
|
||||||
As of version 16, all the official Nx plugins moved from the `@nrwl` npm scope to `@nx`. The goal is for anyone looking through a list of dependencies to easily make the connection between the `nx` package and the `@nx` plugins that are associated with it.
|
As of version 16, all the official Nx plugins moved from the `@nrwl` npm scope to `@nx`. The goal is for anyone looking through a list of dependencies to easily make the connection between the `nx` package and the `@nx` plugins that are associated with it.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Runtime Cache Inputs'
|
||||||
|
description: 'Learn about the transition from runtimeCacheInputs in tasksRunnerOptions to the new inputs and namedInputs configuration for runtime cache inputs.'
|
||||||
|
---
|
||||||
|
|
||||||
# runtimeCacheInputs
|
# runtimeCacheInputs
|
||||||
|
|
||||||
The `runtimeCacheInputs` property was used as a way to add extra inputs to the Nx cache, like the version of node on that particular machine.
|
The `runtimeCacheInputs` property was used as a way to add extra inputs to the Nx cache, like the version of node on that particular machine.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Extending the Project Graph (v1 API)'
|
||||||
|
description: 'Learn about the deprecated v1 API for extending the Nx project graph through project inference and project graph plugins.'
|
||||||
|
---
|
||||||
|
|
||||||
# Extending the Project Graph of Nx (v1 API)
|
# Extending the Project Graph of Nx (v1 API)
|
||||||
|
|
||||||
{% callout type="caution" title="Experimental" %}
|
{% callout type="caution" title="Experimental" %}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Workspace Executors'
|
||||||
|
description: 'Learn how to migrate from workspace executors to local executors in Nx plugins for better build process management.'
|
||||||
|
---
|
||||||
|
|
||||||
# Workspace Executors
|
# Workspace Executors
|
||||||
|
|
||||||
In Nx 13.10+, local nx plugins can contain executors that are used in the workspace. When creating a custom executor for your workspace, look into the [local executor guide](/extending-nx/recipes/local-executors) to simplify the build process.
|
In Nx 13.10+, local nx plugins can contain executors that are used in the workspace. When creating a custom executor for your workspace, look into the [local executor guide](/extending-nx/recipes/local-executors) to simplify the build process.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Workspace Generators'
|
||||||
|
description: 'Learn how to migrate from workspace generators to local generators in Nx plugins for better code generation management.'
|
||||||
|
---
|
||||||
|
|
||||||
# Workspace Generators
|
# Workspace Generators
|
||||||
|
|
||||||
In Nx 13.10, we introduced the ability to run generators from Nx plugins in the workspace they were created in.
|
In Nx 13.10, we introduced the ability to run generators from Nx plugins in the workspace they were created in.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'workspace.json'
|
||||||
|
description: 'Learn about the deprecation of workspace.json in Nx and how to migrate to project.json files for better project configuration management.'
|
||||||
|
---
|
||||||
|
|
||||||
# workspace.json
|
# workspace.json
|
||||||
|
|
||||||
Nx used to have a `workspace.json` file at the root of the repo that at various points performed these functions:
|
Nx used to have a `workspace.json` file at the root of the repo that at various points performed these functions:
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Configuring ESLint with TypeScript'
|
||||||
|
description: 'Learn how to properly configure ESLint with TypeScript in your Nx workspace, including setting up type-checking and managing parser options for optimal performance.'
|
||||||
|
---
|
||||||
|
|
||||||
# Configuring ESLint with TypeScript
|
# Configuring ESLint with TypeScript
|
||||||
|
|
||||||
ESLint is powerful linter by itself, able to work on the syntax of your source files and assert things about based on the rules you configure. It gets even more powerful, however, when TypeScript type-checker is layered on top of it when analyzing TypeScript files, which is something that `@typescript-eslint` allows us to do.
|
ESLint is powerful linter by itself, able to work on the syntax of your source files and assert things about based on the rules you configure. It gets even more powerful, however, when TypeScript type-checker is layered on top of it when analyzing TypeScript files, which is something that `@typescript-eslint` allows us to do.
|
||||||
|
|||||||
@ -1,6 +1,11 @@
|
|||||||
|
---
|
||||||
|
title: 'Using Apollo GraphQL with React'
|
||||||
|
description: 'Learn how to set up and use Apollo GraphQL with React in an Nx workspace, including API creation with NestJS and code generation from GraphQL schemas.'
|
||||||
|
---
|
||||||
|
|
||||||
# Using Apollo GraphQL with React in an Nx Workspace
|
# Using Apollo GraphQL with React in an Nx Workspace
|
||||||
|
|
||||||
In this article, you’ll learn how to:
|
In this article, you'll learn how to:
|
||||||
|
|
||||||
- Create an Nx workspace for both frontend and backend applications
|
- Create an Nx workspace for both frontend and backend applications
|
||||||
- Create a GraphQL API using NestJS
|
- Create a GraphQL API using NestJS
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Large Next.js Apps Made Faster with Nx'
|
||||||
|
description: 'Explore how Nx optimizes and speeds up large Next.js applications with shared components, buildable packages, and efficient caching strategies.'
|
||||||
|
---
|
||||||
|
|
||||||
# File Large Next.js Apps Made Faster by Using Nx
|
# File Large Next.js Apps Made Faster by Using Nx
|
||||||
|
|
||||||
Repo contains:
|
Repo contains:
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Nx Agents at Scale'
|
||||||
|
description: 'Learn how Nx distributed task execution can dramatically improve CI performance in large monorepos with multiple applications and shared libraries.'
|
||||||
|
---
|
||||||
|
|
||||||
# Nx Agents at Scale
|
# Nx Agents at Scale
|
||||||
|
|
||||||
Repo contains:
|
Repo contains:
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Nx Micro-Frontend Example'
|
||||||
|
description: 'Explore a real-world example of a micro-frontend architecture using Nx, combining React and Angular apps with shared web components.'
|
||||||
|
---
|
||||||
|
|
||||||
# Nx Micro-Frontend Example
|
# Nx Micro-Frontend Example
|
||||||
|
|
||||||
This repository contains a single book store website that serves a React app for some routes and an Angular app for other routes. Both apps make use of web components to share UI.
|
This repository contains a single book store website that serves a React app for some routes and an Angular app for other routes. Both apps make use of web components to share UI.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'TSC Batch Mode'
|
||||||
|
description: 'Learn how Nx TSC batch mode dramatically improves TypeScript compilation speed by leveraging project references and incremental builds while maintaining DX.'
|
||||||
|
---
|
||||||
|
|
||||||
# TSC Batch Mode
|
# TSC Batch Mode
|
||||||
|
|
||||||

|

|
||||||
|
|||||||
@ -1,4 +1,6 @@
|
|||||||
---
|
---
|
||||||
|
title: Automate Updating Dependencies
|
||||||
|
description: Learn how to use Nx migrate to automatically update package dependencies, configuration files, and source code to match new package versions.
|
||||||
keywords: [update]
|
keywords: [update]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Cache Task Results'
|
||||||
|
description: 'Learn how to use Nx computation caching to speed up task execution and reduce CI/CD costs by never rebuilding the same code twice.'
|
||||||
|
---
|
||||||
|
|
||||||
# Cache Task Results
|
# Cache Task Results
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/o-6jb78uuP0" title="Remote Caching with Nx Replay" /%}
|
{% youtube src="https://youtu.be/o-6jb78uuP0" title="Remote Caching with Nx Replay" /%}
|
||||||
|
|||||||
@ -1,4 +1,6 @@
|
|||||||
---
|
---
|
||||||
|
title: 'Distribute Task Execution (Nx Agents)'
|
||||||
|
description: 'Learn how to use Nx Agents to distribute task execution across multiple machines, optimizing CI pipeline speed and efficiency through intelligent task allocation.'
|
||||||
keywords: [distributed tasks]
|
keywords: [distributed tasks]
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Enforce Module Boundaries'
|
||||||
|
description: 'Learn how to use Nx module boundaries to maintain a clean architecture by controlling dependencies between projects using tags and ESLint rules.'
|
||||||
|
---
|
||||||
|
|
||||||
# Enforce Module Boundaries
|
# Enforce Module Boundaries
|
||||||
|
|
||||||
If you partition your code into well-defined cohesive units, even a small organization will end up with a dozen apps and dozens or hundreds of libs. If all of them can depend on each other freely, chaos will ensue, and the workspace will become unmanageable.
|
If you partition your code into well-defined cohesive units, even a small organization will end up with a dozen apps and dozens or hundreds of libs. If all of them can depend on each other freely, chaos will ensue, and the workspace will become unmanageable.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Enhance Your LLM'
|
||||||
|
description: 'Learn how Nx enhances your AI assistant by providing rich workspace metadata, architectural insights, and project relationships to make your LLM smarter and more context-aware.'
|
||||||
|
---
|
||||||
|
|
||||||
# Enhance Your LLM
|
# Enhance Your LLM
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/RNilYmJJzdk?si=et_6zWMMxJPa7lp2" title="We Just Made Your LLM Way Smarter!" /%}
|
{% youtube src="https://youtu.be/RNilYmJJzdk?si=et_6zWMMxJPa7lp2" title="We Just Made Your LLM Way Smarter!" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Generate Code'
|
||||||
|
description: 'Learn how to use Nx code generators to automate repetitive tasks, scaffold new projects, and maintain consistency in your codebase.'
|
||||||
|
---
|
||||||
|
|
||||||
# Generate Code
|
# Generate Code
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/hSM6MgWOYr8" title="Generate Code" /%}
|
{% youtube src="https://youtu.be/hSM6MgWOYr8" title="Generate Code" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Maintain TypeScript Monorepos'
|
||||||
|
description: 'Learn how Nx simplifies TypeScript monorepo maintenance by auto-configuring tools, managing project references, and enhancing tooling for better monorepo support.'
|
||||||
|
---
|
||||||
|
|
||||||
# Maintain TypeScript Monorepos
|
# Maintain TypeScript Monorepos
|
||||||
|
|
||||||
Keeping all the industry-standard tools involved in a large TypeScript monorepo correctly configured and working well together is a difficult task. And the more tools you add, the more opportunity there is for tools to conflict with each other in some way.
|
Keeping all the industry-standard tools involved in a large TypeScript monorepo correctly configured and working well together is a difficult task. And the more tools you add, the more opportunity there is for tools to conflict with each other in some way.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Manage Releases'
|
||||||
|
description: 'Learn how to use Nx release tools to version, generate changelogs, and publish your projects with confidence using conventional commits.'
|
||||||
|
---
|
||||||
|
|
||||||
# Manage Releases - `nx release`
|
# Manage Releases - `nx release`
|
||||||
|
|
||||||
Once you have leveraged Nx's powerful code generation and task running capabilities to build your libraries and applications, you will want to share them with your users.
|
Once you have leveraged Nx's powerful code generation and task running capabilities to build your libraries and applications, you will want to share them with your users.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Run Language-Agnostic Conformance Rules'
|
||||||
|
description: 'Learn how to use Nx Powerpack conformance rules to enforce organizational standards, maintain consistency, and ensure security across your workspace.'
|
||||||
|
---
|
||||||
|
|
||||||
# Run Language-Agnostic Conformance Rules
|
# Run Language-Agnostic Conformance Rules
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/6wg23sLveTQ" title="Nx Powerpack workspace conformance" /%}
|
{% youtube src="https://youtu.be/6wg23sLveTQ" title="Nx Powerpack workspace conformance" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Self-Host the Remote Cache'
|
||||||
|
description: 'Learn how to use Nx Powerpack plugins to self-host your remote cache on Amazon S3, Google Cloud Storage, Azure, or a shared network drive.'
|
||||||
|
---
|
||||||
|
|
||||||
# Self-Host the Remote Cache
|
# Self-Host the Remote Cache
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/vRGAa5SuiTM" title="Nx Powerpack self-hosted cache storage" /%}
|
{% youtube src="https://youtu.be/vRGAa5SuiTM" title="Nx Powerpack self-hosted cache storage" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Free Licenses and Trials'
|
||||||
|
description: 'Learn about Nx Powerpack free licenses for small teams and open source projects, as well as trial options and extended evaluation periods.'
|
||||||
|
---
|
||||||
|
|
||||||
# Powerpack Free Licenses and Trials
|
# Powerpack Free Licenses and Trials
|
||||||
|
|
||||||
## Free Licenses Enabling Self-Hosted Remote Cache
|
## Free Licenses Enabling Self-Hosted Remote Cache
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Nx Powerpack Features'
|
||||||
|
description: 'Explore the enterprise-focused features available in Nx Powerpack, including conformance rules, code ownership management, and self-hosted remote caching solutions.'
|
||||||
|
---
|
||||||
|
|
||||||
# Powerpack Features
|
# Powerpack Features
|
||||||
|
|
||||||
Nx PowerPack is a suite of paid extensions for the Nx CLI specifically designed for enterprises. Powerpack is available for Nx version 19.8 and higher.
|
Nx PowerPack is a suite of paid extensions for the Nx CLI specifically designed for enterprises. Powerpack is available for Nx version 19.8 and higher.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Define Code Ownership at the Project Level'
|
||||||
|
description: 'Learn how to use Nx Powerpack owners plugin to manage code ownership at the project level and automatically generate CODEOWNERS files for GitHub, Bitbucket, or GitLab.'
|
||||||
|
---
|
||||||
|
|
||||||
# Define Code Ownership at the Project Level
|
# Define Code Ownership at the Project Level
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/mor6urvw-L0" title="Nx Powerpack Codeowners" /%}
|
{% youtube src="https://youtu.be/mor6urvw-L0" title="Nx Powerpack Codeowners" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Remote Caching (Nx Replay)'
|
||||||
|
description: 'Learn how to use Nx Replay to share computation caches across your team and CI, speeding up builds and saving CI costs.'
|
||||||
|
---
|
||||||
|
|
||||||
# Use Remote Caching (Nx Replay)
|
# Use Remote Caching (Nx Replay)
|
||||||
|
|
||||||
{% youtube
|
{% youtube
|
||||||
@ -31,7 +36,7 @@ See the [connect to Nx Cloud recipe](/ci/intro/connect-to-nx-cloud) for all the
|
|||||||
|
|
||||||
Nx Replay directly benefits your organization by:
|
Nx Replay directly benefits your organization by:
|
||||||
|
|
||||||
- **Speeding up CI pipelines:** With Nx Replay, tasks that have already been executed in a PR’s initial CI pipeline run can **reuse cached results in subsequent runs**. This reduces the need to re-run unaffected tasks, significantly speeding up the CI process for modified PRs. This benefit complements the [affected command](/ci/features/affected), which optimizes pipelines by only running tasks for projects that could be impacted by code changes.
|
- **Speeding up CI pipelines:** With Nx Replay, tasks that have already been executed in a PR's initial CI pipeline run can **reuse cached results in subsequent runs**. This reduces the need to re-run unaffected tasks, significantly speeding up the CI process for modified PRs. This benefit complements the [affected command](/ci/features/affected), which optimizes pipelines by only running tasks for projects that could be impacted by code changes.
|
||||||
|
|
||||||
- **Boosting local developer efficiency:** Depending on [how cache permissions](/ci/recipes/security/access-tokens) are set for your workspace, developers can reuse cached results from CI on their local machines. As a result, tasks like builds and tests can complete instantly if they were already executed in CI. This accelerates developer workflows without any extra steps required.
|
- **Boosting local developer efficiency:** Depending on [how cache permissions](/ci/recipes/security/access-tokens) are set for your workspace, developers can reuse cached results from CI on their local machines. As a result, tasks like builds and tests can complete instantly if they were already executed in CI. This accelerates developer workflows without any extra steps required.
|
||||||
|
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 'Run Tasks'
|
||||||
|
description: 'Learn how to use Nx task runner to efficiently manage and execute tasks across multiple projects in your monorepo, including parallel execution and caching.'
|
||||||
|
---
|
||||||
|
|
||||||
# Run Tasks
|
# Run Tasks
|
||||||
|
|
||||||
{% youtube src="https://youtu.be/aEdfYiA5U34" title="Run tasks with Nx" /%}
|
{% youtube src="https://youtu.be/aEdfYiA5U34" title="Run tasks with Nx" /%}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Editor Setup
|
||||||
|
description: Learn how to set up your editor with Nx Console extensions to enhance your developer experience with features like task visualization, cache management, and generator UI.
|
||||||
|
---
|
||||||
|
|
||||||
# Editor Setup
|
# Editor Setup
|
||||||
|
|
||||||
Nx Console editor extensions make your developer experience richer. The extensions
|
Nx Console editor extensions make your developer experience richer. The extensions
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Installation
|
||||||
|
description: Learn how to install Nx in a new workspace, add it to an existing repository, install it globally, or set it up in a non-JavaScript repository with step-by-step instructions.
|
||||||
|
---
|
||||||
|
|
||||||
# Installation
|
# Installation
|
||||||
|
|
||||||
Create a new Nx workspace using the following command:
|
Create a new Nx workspace using the following command:
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Intro to Nx
|
||||||
|
description: Nx is a powerful open-source build system that enhances developer productivity, optimizes CI performance, and maintains code quality with features like task caching and distribution.
|
||||||
|
---
|
||||||
|
|
||||||
# Intro to Nx
|
# Intro to Nx
|
||||||
|
|
||||||
Nx is a powerful open-source build system that provides tools and techniques for enhancing developer productivity, optimizing CI performance, and maintaining code quality. [Check out our video](/getting-started/why-nx) to learn more about what Nx is about.
|
Nx is a powerful open-source build system that provides tools and techniques for enhancing developer productivity, optimizing CI performance, and maintaining code quality. [Check out our video](/getting-started/why-nx) to learn more about what Nx is about.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Why Nx?
|
||||||
|
description: Discover how Nx helps developers speed up computation, integrate tooling, and scale projects from small teams to entire organizations with powerful caching and CI capabilities.
|
||||||
|
---
|
||||||
|
|
||||||
# Why Nx?
|
# Why Nx?
|
||||||
|
|
||||||
{% youtube
|
{% youtube
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Adding Images, Fonts, and Files
|
||||||
|
description: Learn how to import and use assets like images, fonts, and files directly in your Nx projects, including special handling for SVGs in React, Next.js, and Vite applications.
|
||||||
|
---
|
||||||
|
|
||||||
# Adding Images, Fonts, and Files
|
# Adding Images, Fonts, and Files
|
||||||
|
|
||||||
With Nx, you can **`import` assets directly from your TypeScript/JavaScript code**.
|
With Nx, you can **`import` assets directly from your TypeScript/JavaScript code**.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Configuring Browser Support
|
||||||
|
description: Learn how to configure browser compatibility for your Nx applications using browserslist, optimize bundle size with modern browser targets, and debug your browser support configuration.
|
||||||
|
---
|
||||||
|
|
||||||
# Configuring Browser Support
|
# Configuring Browser Support
|
||||||
|
|
||||||
The official Nx plugins rely on [browserslist](https://github.com/browserslist/browserslist) for configuring application browser support. This affects builds, both production and development, and will decide on which transformations will be run on the code when built.
|
The official Nx plugins rely on [browserslist](https://github.com/browserslist/browserslist) for configuring application browser support. This affects builds, both production and development, and will decide on which transformations will be run on the code when built.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Define Environment Variables
|
||||||
|
description: Learn how to set and use environment variables in Nx projects, including file-based configuration, custom env files, and ad-hoc variable definition across different operating systems.
|
||||||
|
---
|
||||||
|
|
||||||
# Define Environment Variables
|
# Define Environment Variables
|
||||||
|
|
||||||
Environment variables are global system variables accessible by all the processes running under the Operating System (OS).
|
Environment variables are global system variables accessible by all the processes running under the Operating System (OS).
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: JavaScript and TypeScript
|
||||||
|
description: Learn how to use Nx with both JavaScript and TypeScript, including how to generate JS files, mix languages in your workspace, and build TypeScript packages with advanced features.
|
||||||
|
---
|
||||||
|
|
||||||
# JavaScript and TypeScript
|
# JavaScript and TypeScript
|
||||||
|
|
||||||
Nx is a general-purpose build system and a general-purpose CLI. It works with JavaScript, TypeScript, Java, C#, Go, etc.. The core plugins Nx comes with do work best with JavaScript or TypeScript.
|
Nx is a general-purpose build system and a general-purpose CLI. It works with JavaScript, TypeScript, Java, C#, Go, etc.. The core plugins Nx comes with do work best with JavaScript or TypeScript.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx and the Angular CLI
|
||||||
|
description: Compare Nx and Angular CLI features, understand similarities and differences, and learn how Nx enhances Angular development with improved caching, monorepo support, and advanced tooling.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx and the Angular CLI
|
# Nx and the Angular CLI
|
||||||
|
|
||||||
{% youtube
|
{% youtube
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Nx Devkit and Angular Devkit
|
||||||
|
description: Compare Nx Devkit and Angular Devkit for creating generators and executors, understand key differences in implementation, and learn how to convert between the two approaches.
|
||||||
|
---
|
||||||
|
|
||||||
# Nx Devkit and Angular Devkit
|
# Nx Devkit and Angular Devkit
|
||||||
|
|
||||||
{% callout type="note" title="Nx & Angular" %}
|
{% callout type="note" title="Nx & Angular" %}
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Profiling Performance
|
||||||
|
description: Learn how to profile and optimize Nx task execution performance using Chrome DevTools and environment variables to identify bottlenecks and improve build times.
|
||||||
|
---
|
||||||
|
|
||||||
# Profiling Performance
|
# Profiling Performance
|
||||||
|
|
||||||
When running an Nx command, many tasks are run at different times in different processes.
|
When running an Nx command, many tasks are run at different times in different processes.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: React Compiler with Nx
|
||||||
|
description: Learn how to enable and configure React Compiler in Nx projects to automatically optimize your React code with memoization for better performance.
|
||||||
|
---
|
||||||
|
|
||||||
# React Compiler with Nx
|
# React Compiler with Nx
|
||||||
|
|
||||||
React 19 comes with an experimental compiler that optimizes application code to automatically memoize code. Read the [official React Compiler documentation](https://react.dev/learn/react-compiler) for more information.
|
React 19 comes with an experimental compiler that optimizes application code to automatically memoize code. Read the [official React Compiler documentation](https://react.dev/learn/react-compiler) for more information.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: React Native with Nx
|
||||||
|
description: Learn how to develop React Native applications with Nx, including workspace setup, running on simulators, testing, and leveraging Nx's powerful tooling.
|
||||||
|
---
|
||||||
|
|
||||||
# React Native with Nx
|
# React Native with Nx
|
||||||
|
|
||||||
Nx provides a holistic dev experience powered by an advanced CLI and editor plugins. It provides rich support for common tools like [Detox](/nx-api/detox), Storybook, Jest, and more.
|
Nx provides a holistic dev experience powered by an advanced CLI and editor plugins. It provides rich support for common tools like [Detox](/nx-api/detox), Storybook, Jest, and more.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Remix with Nx
|
||||||
|
description: Learn how to create, build, serve, and test Remix applications within an Nx workspace, leveraging Nx's powerful tooling for modern web development.
|
||||||
|
---
|
||||||
|
|
||||||
# Remix with Nx
|
# Remix with Nx
|
||||||
|
|
||||||
In this recipe, we'll show you how to create a [Remix](https://remix.run) application with Nx.
|
In this recipe, we'll show you how to create a [Remix](https://remix.run) application with Nx.
|
||||||
|
|||||||
@ -1,6 +1,11 @@
|
|||||||
|
---
|
||||||
|
title: Setup Incremental Builds for Angular Applications
|
||||||
|
description: Learn how to configure your Angular applications in Nx to use incremental builds, improving build performance by only rebuilding what changed.
|
||||||
|
---
|
||||||
|
|
||||||
# Setup incremental builds for Angular applications
|
# Setup incremental builds for Angular applications
|
||||||
|
|
||||||
In this guide we’ll specifically look into which changes need to be made to enable incremental builds for Angular
|
In this guide we'll specifically look into which changes need to be made to enable incremental builds for Angular
|
||||||
applications.
|
applications.
|
||||||
|
|
||||||
## Use buildable libraries
|
## Use buildable libraries
|
||||||
@ -59,7 +64,7 @@ Angular's build time with Esbuild already provides a great performance boost and
|
|||||||
warrant using incremental builds with Esbuild for Angular
|
warrant using incremental builds with Esbuild for Angular
|
||||||
{% /callout %}
|
{% /callout %}
|
||||||
|
|
||||||
Change your Angular application’s "build" target executor to Nx's version of builder you're currently using and the "
|
Change your Angular application's "build" target executor to Nx's version of builder you're currently using and the "
|
||||||
serve" target executor to `@nx/angular:dev-server` as shown below.
|
serve" target executor to `@nx/angular:dev-server` as shown below.
|
||||||
|
|
||||||
- `@angular-devkit/build-angular:application` -> `@nx/angular:application`
|
- `@angular-devkit/build-angular:application` -> `@nx/angular:application`
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Troubleshoot Convert to Inferred Migration
|
||||||
|
description: Learn how to resolve common issues when migrating from executor-based tasks to inferred tasks in Nx, with specific solutions for Next.js, Remix, and other frameworks.
|
||||||
|
---
|
||||||
|
|
||||||
# Troubleshoot Convert to Inferred Migration
|
# Troubleshoot Convert to Inferred Migration
|
||||||
|
|
||||||
Nx comes with plugins that automatically [infer tasks](/concepts/inferred-tasks) (i.e. Project Crystal) for your
|
Nx comes with plugins that automatically [infer tasks](/concepts/inferred-tasks) (i.e. Project Crystal) for your
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Unknown Local Cache Error
|
||||||
|
description: Learn how to troubleshoot and resolve Nx cache errors related to machine ID changes, network drives, and understand how Nx ensures cache security.
|
||||||
|
---
|
||||||
|
|
||||||
# Unknown Local Cache Error
|
# Unknown Local Cache Error
|
||||||
|
|
||||||
This document will explain why the following errors happen and how to address them.
|
This document will explain why the following errors happen and how to address them.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Using Environment Variables in Angular Applications
|
||||||
|
description: Learn how to configure and use environment variables in Angular applications with Nx, including setup for ESBuild and TypeScript type definitions.
|
||||||
|
---
|
||||||
|
|
||||||
# Using environment variables in Angular applications
|
# Using environment variables in Angular applications
|
||||||
|
|
||||||
## For Angular applications using ESBuild
|
## For Angular applications using ESBuild
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Using Environment Variables in React Applications
|
||||||
|
description: Learn how to configure and use environment variables in React applications with Nx, including setup for Vite and Webpack, and handling conflicts between Nx and Vite.
|
||||||
|
---
|
||||||
|
|
||||||
# Using environment variables in React applications
|
# Using environment variables in React applications
|
||||||
|
|
||||||
## For React applications using Vite
|
## For React applications using Vite
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Using Tailwind CSS in React and Next.js
|
||||||
|
description: Learn how to set up and configure Tailwind CSS in your React and Next.js applications within an Nx workspace, with both automated and manual installation options.
|
||||||
|
---
|
||||||
|
|
||||||
# Using Tailwind CSS in React and Next.js
|
# Using Tailwind CSS in React and Next.js
|
||||||
|
|
||||||
This guide serves as a quickstart to installing [Tailwind CSS](https://tailwindcss.com) in your React and Next.js app.
|
This guide serves as a quickstart to installing [Tailwind CSS](https://tailwindcss.com) in your React and Next.js app.
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Using Tailwind CSS with Angular Projects
|
||||||
|
description: Learn how to set up and configure Tailwind CSS in Angular applications and libraries within an Nx workspace, including dependency management and Module Federation support.
|
||||||
|
---
|
||||||
|
|
||||||
# Using Tailwind CSS with Angular projects
|
# Using Tailwind CSS with Angular projects
|
||||||
|
|
||||||
The purpose of this page is to cover how to use and configure [Tailwind CSS](https://tailwindcss.com/)
|
The purpose of this page is to cover how to use and configure [Tailwind CSS](https://tailwindcss.com/)
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Troubleshoot Nx Installations
|
||||||
|
description: Learn how to resolve common Nx installation issues, including native module problems, platform compatibility, and Node.js architecture mismatches.
|
||||||
|
---
|
||||||
|
|
||||||
# Troubleshoot Nx Installations
|
# Troubleshoot Nx Installations
|
||||||
|
|
||||||
Here are some common scenarios we came across while trying to run Nx on CIs
|
Here are some common scenarios we came across while trying to run Nx on CIs
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Adding Nx to your Existing Project
|
||||||
|
description: Learn how to integrate Nx into an existing non-monorepo project to leverage caching capabilities, speed up CI, and improve your development workflow.
|
||||||
|
---
|
||||||
|
|
||||||
# Adding Nx to your Existing Project
|
# Adding Nx to your Existing Project
|
||||||
|
|
||||||
Nx can be added to any type of project, not just monorepos. A large benefit of Nx is its caching feature for package
|
Nx can be added to any type of project, not just monorepos. A large benefit of Nx is its caching feature for package
|
||||||
|
|||||||
@ -1,3 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: Adding Nx to NPM/Yarn/PNPM Workspace
|
||||||
|
description: Learn how to integrate Nx into an existing NPM, Yarn, or PNPM workspace monorepo to gain task scheduling, caching, and improved CI performance.
|
||||||
|
---
|
||||||
|
|
||||||
# Adding Nx to NPM/Yarn/PNPM Workspace
|
# Adding Nx to NPM/Yarn/PNPM Workspace
|
||||||
|
|
||||||
{% callout type="note" title="Migrating from Lerna?" %}
|
{% callout type="note" title="Migrating from Lerna?" %}
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user