Merge branch 'master' into fix-bull-config-names

Author: Patrick Acioli

.nvmrc

@@ -1 +1 @@
-18.15.0
+18.16.0

content/cli/usages.md

@@ -107,14 +107,14 @@ $ nest build <name> [options]
 
 ##### Options
 
-| Option            | Description                                            |
-| ----------------- | ------------------------------------------------------ |
-| `--path [path]`   | Path to `tsconfig` file. <br/>Alias `-p`               |
-| `--config [path]` | Path to `nest-cli` configuration file. <br/>Alias `-c` |
-| `--watch`         | Run in watch mode (live-reload) <br/>Alias `-w`        |
-| `--webpack`       | Use webpack for compilation.                           |
-| `--webpackPath`   | Path to webpack configuration.                         |
-| `--tsc`           | Force use `tsc` for compilation.                       |
+| Option            | Description                                                                                                                           |
+| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| `--path [path]`   | Path to `tsconfig` file. <br/>Alias `-p`                                                                                              |
+| `--config [path]` | Path to `nest-cli` configuration file. <br/>Alias `-c`                                                                                |
+| `--watch`         | Run in watch mode (live-reload). If you're using `tsc` for compilation, you can type `rs` to restart the application. <br/>Alias `-w` |
+| `--webpack`       | Use webpack for compilation.                                                                                                          |
+| `--webpackPath`   | Path to webpack configuration.                                                                                                        |
+| `--tsc`           | Force use `tsc` for compilation.                                                                                                      |
 
 #### nest start
 

content/cli/workspaces.md

@@ -5,7 +5,7 @@ Nest has two modes for organizing code:
 - **standard mode**: useful for building individual project-focused applications that have their own dependencies and settings, and don't need to optimize for sharing modules, or optimizing complex builds. This is the default mode.
 - **monorepo mode**: this mode treats code artifacts as part of a lightweight **monorepo**, and may be more appropriate for teams of developers and/or multi-project environments. It automates parts of the build process to make it easy to create and compose modular components, promotes code re-use, makes integration testing easier, makes it easy to share project-wide artifacts like `eslint` rules and other configuration policies, and is easier to use than alternatives like github submodules. Monorepo mode employs the concept of a **workspace**, represented in the `nest-cli.json` file, to coordinate the relationship between the components of the monorepo.
 
-It's important to note that virtually all of Nest's features are independent of your code organization mode. The **only** affect of this choice is how your projects are composed and how build artifacts are generated. All other functionality, from the CLI to core modules to add-on modules work the same in either mode.
+It's important to note that virtually all of Nest's features are independent of your code organization mode. The **only** effect of this choice is how your projects are composed and how build artifacts are generated. All other functionality, from the CLI to core modules to add-on modules work the same in either mode.
 
 Also, you can easily switch from **standard mode** to **monorepo mode** at any time, so you can delay this decision until the benefits of one or the other approach become more clear.
 

content/controllers.md

@@ -273,7 +273,7 @@ Routes with static paths won't work when you need to accept **dynamic data** as
 ```typescript
 @@filename()
 @Get(':id')
-findOne(@Param() params): string {
+findOne(@Param() params: any): string {
   console.log(params.id);
   return `This action returns a #${params.id} cat`;
 }

content/discover/who-uses.json

@@ -277,6 +277,7 @@
     "https://evershop.io",
     "https://e-design.ca",
     "https://growthmill.com",
-    "https://tarken.com.br"
+    "https://tarken.com.br",
+    "https://remato.com"
   ]
 }

content/recipes/async-local-storage.md

@@ -55,7 +55,7 @@ export class AppModule implements NestModule {
         const store = {
           userId: req.headers['x-user-id'],
         };
-        // and and pass the "next" function as callback
+        // and pass the "next" function as callback
         // to the "als.run" method together with the store.
         als.run(store, () => next());
       })
@@ -85,7 +85,7 @@ export class AppModule {
         const store = {
           userId: req.headers['x-user-id'],
         };
-        // and and pass the "next" function as callback
+        // and pass the "next" function as callback
         // to the "als.run" method together with the store.
         als.run(store, () => next());
       })

content/recipes/swc.md

@@ -95,3 +95,99 @@ If your ORM does not provide a similar workaround, you can define the wrapper ty
  */
 export type WrapperType<T> = T; // WrapperType === Relation
 ```
+
+### Vitest
+
+[Vitest](https://vitest.dev/) is a fast and lightweight test runner designed to work with Vite. It provides a modern, fast, and easy-to-use testing solution that can be integrated with NestJS projects.
+
+#### Installation
+
+To get started, first install the required packages:
+
+```bash
+$ npm i --save-dev vitest unplugin-swc @swc/core @vitest/coverage-c8
+```
+
+#### Configuration
+
+Create a `vitest.config.ts` file in the root directory of your application with the following content:
+
+```ts
+import swc from 'unplugin-swc';
+import { defineConfig } from 'vitest/config';
+
+export default defineConfig({
+  test: {
+    globals: true,
+    root: './',
+  },
+  plugins: [swc.vite()], // This is required to build the test files with SWC
+});
+```
+
+This configuration file sets up the Vitest environment, root directory, and SWC plugin. You should also create a separate configuration
+file for e2e tests, with an additional `include` field that specifies the test path regex:
+
+```ts
+import swc from 'unplugin-swc';
+import { defineConfig } from 'vitest/config';
+
+export default defineConfig({
+  test: {
+    include: ['**/*.e2e-spec.ts'],
+    globals: true,
+    root: './',
+  },
+  plugins: [swc.vite()],
+});
+```
+
+Additionally, you can set the `alias` options to support TypeScript paths in your tests:
+
+```ts
+import swc from 'unplugin-swc';
+import { defineConfig } from 'vitest/config';
+
+export default defineConfig({
+  test: {
+    include: ['**/*.e2e-spec.ts'],
+    globals: true,
+    alias: {
+      '@src': './src',
+      '@test': './test',
+    },
+    root: './',
+  },
+  resolve: {
+    alias: {
+      '@src': './src',
+      '@test': './test',
+    },
+  },
+  plugins: [swc.vite()],
+});
+```
+
+#### Update imports in E2E tests
+
+Change any E2E test imports using `import * as request from 'supertest'` to `import request from 'supertest'`. This is necessary because Vitest, when bundled with Vite, expects a default import for supertest. Using a namespace import may cause issues in this specific setup.
+
+Lastly, update the test scripts in your package.json file to the following:
+
+```json
+{
+  "scripts": {
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "test:cov": "vitest run --coverage",
+    "test:debug": "vitest --inspect-brk --inspect --logHeapUsage --threads=false",
+    "test:e2e": "vitest run --config ./vitest.config.e2e.ts"
+  }
+}
+```
+
+These scripts configure Vitest for running tests, watching for changes, generating code coverage reports, and debugging. The test:e2e script is specifically for running E2E tests with a custom configuration file.
+
+With this setup, you can now enjoy the benefits of using Vitest in your NestJS project, including faster test execution and a more modern testing experience.
+
+> info **Hint** You can check out a working example in this [repository](https://github.com/TrilonIO/nest-vitest)

content/security/helmet.md

@@ -20,6 +20,21 @@ import helmet from 'helmet';
 app.use(helmet());
 ```
 
+> warning **Warning** When using `helmet`, `@apollo/server` (4.x), and the [Apollo Sandbox](https://docs.nestjs.com/graphql/quick-start#apollo-sandbox), there may be a problem with [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) on the Apollo Sandbox. To solve this issue configure the CSP as shown below:
+>
+> ```typescript
+> app.use(helmet({
+>   crossOriginEmbedderPolicy: false,
+>   contentSecurityPolicy: {
+>     directives: {
+>       imgSrc: [`'self'`, 'data:', 'apollo-server-landing-page.cdn.apollographql.com'],
+>       scriptSrc: [`'self'`, `https: 'unsafe-inline'`],
+>       manifestSrc: [`'self'`, 'apollo-server-landing-page.cdn.apollographql.com'],
+>       frameSrc: [`'self'`, 'sandbox.embed.apollographql.com'],
+>     },
+>   },
+> }));
+
 #### Use with Fastify
 
 If you are using the `FastifyAdapter`, install the [@fastify/helmet](https://github.com/fastify/fastify-helmet) package:

content/techniques/queues.md

@@ -99,8 +99,8 @@ With this in place, you can now point to this configuration in the `registerQueu
 
 ```typescript
 BullModule.registerQueue({
-  configKey: 'alternative-config'
-  name: 'video',
+  configKey: 'alternative-config',
+  name: 'video'
 });
 ```
 
@@ -428,7 +428,7 @@ BullModule.forRootAsync({
   useFactory: async (configService: ConfigService) => ({
     redis: {
       host: configService.get('QUEUE_HOST'),
-      port: +configService.get('QUEUE_PORT'),
+      port: configService.get('QUEUE_PORT'),
     },
   }),
   inject: [ConfigService],