## Current Behavior - Documentation pages under "technologies" and "core-api" sections with "introduction"/"overview" IDs lack H1 titles after front matter - Some remote caching package links point to parent sections instead of overview pages ## Expected Behavior - All affected documentation pages should have H1 titles for consistency - Links should point directly to overview pages ## Related Issue(s) Fixes # ## Changes Made ### 1. Updated Remote Caching Links (commit fae9055f8c) Updated links in 3 files to point directly to overview pages: - `docs/blog/2025-01-06-nx-update-20-3.md` - `docs/shared/deprecated/custom-tasks-runner.md` - `docs/shared/recipes/running-tasks/self-hosted-caching.md` Changed links from: - `/reference/core-api/azure-cache` → `/reference/core-api/azure-cache/overview` - `/reference/core-api/gcs-cache` → `/reference/core-api/gcs-cache/overview` - `/reference/core-api/s3-cache` → `/reference/core-api/s3-cache/overview` - `/reference/core-api/shared-fs-cache` → `/reference/core-api/shared-fs-cache/overview` ### 2. Added H1 Titles to Documentation Pages Added H1 titles to 29 documentation files that were missing them: #### Core API Overview Pages (6 files) - `docs/shared/packages/azure-cache/azure-cache-plugin.md` → `# @nx/azure-cache` - `docs/shared/packages/conformance/conformance-plugin.md` → `# @nx/conformance` - `docs/shared/packages/gcs-cache/gcs-cache-plugin.md` → `# @nx/gcs-cache` - `docs/shared/packages/owners/owners-plugin.md` → `# @nx/owners` - `docs/shared/packages/s3-cache/s3-cache-plugin.md` → `# @nx/s3-cache` - `docs/shared/packages/shared-fs-cache/shared-fs-cache-plugin.md` → `# @nx/shared-fs-cache` #### Technology Introduction Pages (23 files) - `docs/shared/packages/angular/angular-plugin.md` → `# @nx/angular` - `docs/shared/packages/esbuild/esbuild-plugin.md` → `# @nx/esbuild` - `docs/shared/packages/rspack/rspack-plugin.md` → `# @nx/rspack` - `docs/shared/packages/vite/vite-plugin.md` → `# @nx/vite` - `docs/shared/packages/webpack/plugin-overview.md` → `# @nx/webpack` - `docs/shared/packages/eslint/eslint.md` → `# @nx/eslint` - `docs/shared/packages/gradle/gradle-plugin.md` → `# @nx/gradle` - `docs/shared/packages/express/express-plugin.md` → `# @nx/express` - `docs/shared/packages/node/node-plugin.md` → `# @nx/node` - `docs/shared/packages/nest/nest-plugin.md` → `# @nx/nest` - `docs/shared/packages/expo/expo-plugin.md` → `# @nx/expo` - `docs/shared/packages/react/react-plugin.md` → `# @nx/react` - `docs/shared/packages/next/plugin-overview.md` → `# @nx/next` - `docs/shared/packages/react-native/react-native-plugin.md` → `# @nx/react-native` - `docs/shared/packages/remix/remix-plugin.md` → `# @nx/remix` - `docs/shared/packages/cypress/cypress-plugin.md` → `# @nx/cypress` - `docs/shared/packages/detox/detox-plugin.md` → `# @nx/detox` - `docs/shared/packages/jest/jest-plugin.md` → `# @nx/jest` - `docs/shared/packages/playwright/playwright-plugin.md` → `# @nx/playwright` - `docs/shared/packages/storybook/plugin-overview.md` → `# @nx/storybook` - `docs/shared/packages/js/js-plugin.md` → `# @nx/js` - `docs/shared/packages/vue/vue-plugin.md` → `# @nx/vue` - `docs/shared/packages/nuxt/nuxt-plugin.md` → `# @nx/nuxt` Note: The Angular Rspack introduction page (`docs/shared/guides/angular-rspack/introduction.md`) already had an appropriate H1 title "# Introduction" and was left unchanged. All changes improve documentation consistency and navigation by ensuring proper titles and direct links to overview pages.
209 lines
7.1 KiB
Markdown
209 lines
7.1 KiB
Markdown
---
|
|
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.
|
|
keywords: [nest, nestjs]
|
|
---
|
|
|
|
# @nx/nest
|
|
|
|
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.
|
|
- Its dependency injection system is similar to the one in Angular.
|
|
- It emphasises testability.
|
|
- Its configuration APIs are similar to Angular as well.
|
|
|
|
Many conventions and best practices used in Angular applications can be also be used in Nest.
|
|
|
|
## Setting Up @nx/nest
|
|
|
|
### Generating a new workspace
|
|
|
|
To create a new workspace with Nest, run the following command:
|
|
|
|
```shell
|
|
npx create-nx-workspace my-workspace --preset=nest
|
|
```
|
|
|
|
Yarn users can use the following command instead:
|
|
|
|
```shell
|
|
yarn create nx-workspace my-workspace --preset=nest
|
|
```
|
|
|
|
### Installation
|
|
|
|
{% callout type="note" title="Keep Nx Package Versions In Sync" %}
|
|
Make sure to install the `@nx/nest` version that matches the version of `nx` in your repository. If the version numbers get out of sync, you can encounter some difficult to debug errors. You can [fix Nx version mismatches with this recipe](/recipes/tips-n-tricks/keep-nx-versions-in-sync).
|
|
{% /callout %}
|
|
|
|
In any Nx workspace, you can install `@nx/nest` by running the following command:
|
|
|
|
```shell {% skipRescope=true %}
|
|
nx add @nx/nest
|
|
```
|
|
|
|
This will install the correct version of `@nx/nest`.
|
|
|
|
### Create Applications
|
|
|
|
You can add a new Nest application with the following command:
|
|
|
|
```shell
|
|
nx g @nx/nest:app apps/my-nest-app
|
|
```
|
|
|
|
#### Application Proxies
|
|
|
|
Generating Nest applications has an option to configure other projects in the workspace to proxy API requests. This can be done by passing the `--frontendProject` with the project name you wish to enable proxy support for.
|
|
|
|
```shell
|
|
nx g @nx/nest:app apps/my-nest-app --frontendProject my-angular-app
|
|
```
|
|
|
|
### Create Libraries
|
|
|
|
You can add a new Nest library with the following command:
|
|
|
|
```shell
|
|
nx g @nx/nest:lib libs/my-nest-lib
|
|
```
|
|
|
|
To make the library `buildable`, use the following command:
|
|
|
|
```shell
|
|
nx g @nx/nest:lib libs/my-nest-lib --buildable
|
|
```
|
|
|
|
To make the library `publishable`, use the following command:
|
|
|
|
```shell
|
|
nx g @nx/nest:lib libs/my-nest-lib --publishable --importPath=@my-workspace/my-nest-lib
|
|
```
|
|
|
|
> Read more about [building and publishing libraries here](/concepts/buildable-and-publishable-libraries).
|
|
|
|
### Nest Generators
|
|
|
|
The Nest plugin for Nx extends the generators provided by Nest. Any commands that can be used with the Nest CLI can also be used with the `nx` command. The `--project` flag should be used for all Nest generators.
|
|
|
|
> `--project` is used to infer the root of the project where the generators will generate the files.
|
|
|
|
## Using Nest
|
|
|
|
### Build
|
|
|
|
You can build an application with the following command:
|
|
|
|
```shell
|
|
nx build my-nest-app
|
|
```
|
|
|
|
This applies to `buildable` libraries as well
|
|
|
|
```shell
|
|
nx build my-nest-lib
|
|
```
|
|
|
|
#### Waiting for other builds
|
|
|
|
Setting the `waitUntilTargets` option with an array of projects (with the following format: `"project:target"`) will execute those commands before serving the Nest application.
|
|
|
|
### Serve
|
|
|
|
You can serve an application with the following command:
|
|
|
|
```shell
|
|
nx serve my-nest-app
|
|
```
|
|
|
|
The `serve` command runs the `build` target, and executes the application.
|
|
|
|
By default, the serve command will run in `watch` mode. This allows code to be changed, and the Nest application to be rebuilt automatically.
|
|
|
|
#### Debugging
|
|
|
|
Nest applications also have the `inspect` flag set, so you can attach your debugger to the running instance.
|
|
|
|
Debugging is set to use a random port that is available on the system. The port can be changed by setting the port option in the `serve` target in the `project.json`. Or by running the serve command with `--port <number>`.
|
|
|
|
For additional information on how to debug Node applications, see the [Node.js debugging getting started guide](https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients).
|
|
|
|
### Lint
|
|
|
|
You can lint an application with the following command:
|
|
|
|
```shell
|
|
nx lint my-nest-app
|
|
```
|
|
|
|
You can lint a library with the following command:
|
|
|
|
```shell
|
|
nx lint my-nest-lib
|
|
```
|
|
|
|
### Unit Test
|
|
|
|
You can run unit test for an application with the following command:
|
|
|
|
```shell
|
|
nx test my-nest-app
|
|
```
|
|
|
|
You can run unit test for a library with the following command:
|
|
|
|
```shell
|
|
nx test my-nest-lib
|
|
```
|
|
|
|
## Using CLI Plugins
|
|
|
|
Nest supports the use of various CLI plugins to enhance the development experience. Plugins can be configured via **transformers** property in NxWebpackPlugin.
|
|
As an example, to set up a [Swagger plugin](https://docs.nestjs.com/openapi/cli-plugin), modify the Nest application's Webpack configuration as follows:
|
|
|
|
```javascript
|
|
const { NxWebpackPlugin } = require('@nx/webpack');
|
|
|
|
module.exports = {
|
|
// ...
|
|
plugins: [
|
|
new NxWebpackPlugin({
|
|
// ...
|
|
transformers: [
|
|
{
|
|
name: '@nestjs/swagger/plugin',
|
|
options: {
|
|
dtoFileNameSuffix: ['.dto.ts', '.entity.ts'],
|
|
},
|
|
},
|
|
],
|
|
}),
|
|
],
|
|
};
|
|
```
|
|
|
|
## Deployment
|
|
|
|
Ensuring a smooth and reliable deployment of a Nest.js application in a production environment requires careful planning and the right strategy. Depending on your specific needs and infrastructure, you can choose from several deployment approaches. Below are four commonly used methods:
|
|
|
|
1. **Using Docker:**
|
|
Create a Dockerfile that specifies the application's environment and dependencies. Build a Docker image and optionally push it to a container registry. Deploy and run the Docker container on the server. Utilize the `@nx/node:setup-docker` generator to streamline the Docker setup process.
|
|
|
|
2. **Installing Dependencies on the Server:**
|
|
Transfer the build artifacts to the server, install all dependencies using the package manager of your choice, and start the application. Ensure that [NxAppWebpackPlugin](/technologies/build-tools/webpack/recipes/webpack-plugins#nxappwebpackplugin) is configured with `generatePackageJson: true` so that the build artifacts directory includes `package.json` and `package-lock.json` (or the equivalent files for other package managers).
|
|
|
|
3. **Transferring Pre-installed Dependencies:**
|
|
Install dependencies during the build process, and transfer the build artifacts along with the `node_modules` directory to the server. Typically, the artifacts are archived for faster transfer and then unarchived on the server.
|
|
|
|
4. **Bundling Dependencies:**
|
|
By default, Nx/Nest creates a setup that externalizes all dependencies, meaning they are not included in the bundle. This behavior can be adjusted using the `externalDependencies` parameter in the webpack configuration with [NxAppWebpackPlugin](/technologies/build-tools/webpack/recipes/webpack-plugins#nxappwebpackplugin). After bundling, transfer the package to the server and start the application.
|
|
|
|
{% callout type="note" title="Bundling Dependencies" %}
|
|
Bundling dependencies is typically not recommended for Node applications.
|
|
{% /callout %}
|
|
|
|
## More Documentation
|
|
|
|
- [Using Jest](/technologies/test-tools/jest/introduction)
|