docs: v10 changes

Author: kamilmysliwiec

content/first-steps.md

@@ -10,7 +10,7 @@ We'll mostly use TypeScript in the examples we provide, but you can always **swi
 
 #### Prerequisites
 
-Please make sure that [Node.js](https://nodejs.org) (version >= 12, except for v13) is installed on your operating system.
+Please make sure that [Node.js](https://nodejs.org) (version >= 16) is installed on your operating system.
 
 #### Setup
 

content/fundamentals/unit-testing.md

@@ -177,19 +177,19 @@ describe('CatsController', () => {
     const moduleRef = await Test.createTestingModule({
       controllers: [CatsController],
     })
-    .useMocker((token) => {
-      const results = ['test1', 'test2'];
-      if (token === CatsService) {
-        return { findAll: jest.fn().mockResolvedValue(results) };
-      }
-      if (typeof token === 'function') {
-        const mockMetadata = moduleMocker.getMetadata(token) as MockFunctionMetadata<any, any>;
-        const Mock = moduleMocker.generateFromMetadata(mockMetadata);
-        return new Mock();
-      }
-    })
-    .compile();
-    
+      .useMocker((token) => {
+        const results = ['test1', 'test2'];
+        if (token === CatsService) {
+          return { findAll: jest.fn().mockResolvedValue(results) };
+        }
+        if (typeof token === 'function') {
+          const mockMetadata = moduleMocker.getMetadata(token) as MockFunctionMetadata<any, any>;
+          const Mock = moduleMocker.generateFromMetadata(mockMetadata);
+          return new Mock();
+        }
+      })
+      .compile();
+
     controller = moduleRef.get(CatsController);
   });
 });
@@ -286,9 +286,7 @@ describe('Cats', () => {
 > let app: NestFastifyApplication;
 >
 > beforeAll(async () => {
->   app = moduleRef.createNestApplication<NestFastifyApplication>(
->     new FastifyAdapter(),
->   );
+>   app = moduleRef.createNestApplication<NestFastifyApplication>(new FastifyAdapter());
 >
 >   await app.init();
 >   await app.getHttpAdapter().getInstance().ready();
@@ -315,18 +313,29 @@ In this example, we build on some of the concepts described earlier. In addition
 
 We simulate HTTP tests using the `request()` function from Supertest. We want these HTTP requests to route to our running Nest app, so we pass the `request()` function a reference to the HTTP listener that underlies Nest (which, in turn, may be provided by the Express platform). Hence the construction `request(app.getHttpServer())`. The call to `request()` hands us a wrapped HTTP Server, now connected to the Nest app, which exposes methods to simulate an actual HTTP request. For example, using `request(...).get('/cats')` will initiate a request to the Nest app that is identical to an **actual** HTTP request like `get '/cats'` coming in over the network.
 
-In this example, we also provide an alternate (test-double) implementation of the `CatsService` which simply returns a hard-coded value that we can test for. Use `overrideProvider()` to provide such an alternate implementation. Similarly, Nest provides methods to override guards, interceptors, filters and pipes with the`overrideGuard()`, `overrideInterceptor()`, `overrideFilter()`, and `overridePipe()` methods respectively.
+In this example, we also provide an alternate (test-double) implementation of the `CatsService` which simply returns a hard-coded value that we can test for. Use `overrideProvider()` to provide such an alternate implementation. Similarly, Nest provides methods to override modules, guards, interceptors, filters and pipes with the `overrideModule()`, `overrideGuard()`, `overrideInterceptor()`, `overrideFilter()`, and `overridePipe()` methods respectively.
 
-Each of the override methods returns an object with 3 different methods that mirror those described for [custom providers](https://docs.nestjs.com/fundamentals/custom-providers):
+Each of the override methods (except for `overrideModule()`) returns an object with 3 different methods that mirror those described for [custom providers](https://docs.nestjs.com/fundamentals/custom-providers):
 
 - `useClass`: you supply a class that will be instantiated to provide the instance to override the object (provider, guard, etc.).
 - `useValue`: you supply an instance that will override the object.
 - `useFactory`: you supply a function that returns an instance that will override the object.
 
+On the other hand, `overrideModule()` returns an object with the `useModule()` method, which you can use to supply a module that will override the original module, as follows:
+
+```typescript
+const moduleRef = await Test.createTestingModule({
+  imports: [AppModule],
+})
+  .overrideModule(CatsModule)
+  .useModule(AlternateCatsModule)
+  .compile();
+```
+
 Each of the override method types, in turn, returns the `TestingModule` instance, and can thus be chained with other methods in the [fluent style](https://en.wikipedia.org/wiki/Fluent_interface). You should use `compile()` at the end of such a chain to cause Nest to instantiate and initialize the module.
 
 Also, sometimes you may want to provide a custom logger e.g. when the tests are run (for example, on a CI server). Use the `setLogger()` method and pass an object that fulfills the `LoggerService` interface to instruct the `TestModuleBuilder` how to log during tests (by default, only "error" logs will be logged to the console).
-  
+
 > warning **Warning** The `@nestjs/core` package exposes unique provider tokens with the `APP_` prefix to help on define global enhancers. Those tokens cannot be overridden since they can represent multiple providers. Thus you can't use `.overrideProvider(APP_GUARD)` (and so on). If you want to override some global enhancer, follow [this workaround](https://github.com/nestjs/nest/issues/4053#issuecomment-585612462).
 
 The compiled module has several useful methods, as described in the following table:
@@ -430,9 +439,7 @@ To accomplish this, use `jest.spyOn()` on the `ContextIdFactory`:
 
 ```typescript
 const contextId = ContextIdFactory.create();
-jest
-  .spyOn(ContextIdFactory, 'getByRequest')
-  .mockImplementation(() => contextId);
+jest.spyOn(ContextIdFactory, 'getByRequest').mockImplementation(() => contextId);
 ```
 
 Now we can use the `contextId` to access a single generated DI container sub-tree for any subsequent request.

content/microservices/redis.md

@@ -58,6 +58,10 @@ The `options` property is specific to the chosen transporter. The <strong>Redis<
     <td><code>retryDelay</code></td>
     <td>Delay between message retry attempts (ms) (default: <code>0</code>)</td>
   </tr>
+   <tr>
+    <td><code>wildcards</code></td>
+    <td>Enables Redis wilcard subscriptions, instructing transporter to use <code>psubscribe</code>/<code>pmessage</code> under the hood. (default: <code>false</code>)</td>
+  </tr>
 </table>
 
 All the properties supported by the official [ioredis](https://luin.github.io/ioredis/index.html#RedisOptions) client are also supported by this transporter.

content/migration.md

@@ -1,105 +1,25 @@
 ### Migration guide
 
-This article provides a set of guidelines for migrating from Nest version 8 to version 9.
-To learn more about the new features we've added in v9, check out this [link](https://github.com/nestjs/nest/pull/9588).
+This article provides a set of guidelines for migrating from Nest version 9 to version 10.
+To learn more about the new features we've added in v10, check out this [article](https://trilon.io/blog/nestjs-10-is-now-available).
+There were some very minor breaking changes that shouldn't affect most users - you can find the full list of them [here](https://github.com/nestjs/nest/pull/11517).
 
-#### Redis strategy (microservices)
+### Cache module
 
-[Redis](/microservices/redis) strategy uses the [ioredis](https://github.com/luin/ioredis) driver instead of `redis` now.
+The `CacheModule` has been removed from the `@nestjs/common` package and is now available as a standalone package - `@nestjs/cache-manager`. This change was made to avoid unnecessary dependencies in the `@nestjs/common` package. You can learn more about the `@nestjs/cache-manager` package [here](https://docs.nestjs.com/techniques/caching).
 
-```typescript
-// Before
-const app = await NestFactory.createMicroservice<MicroserviceOptions>(
-  AppModule,
-  {
-    transport: Transport.REDIS,
-    options: {
-      url: 'redis://localhost:6379',
-    },
-  },
-);
-
-// Now
-const app = await NestFactory.createMicroservice<MicroserviceOptions>(
-  AppModule,
-  {
-    transport: Transport.REDIS,
-    options: {
-      host: 'localhost',
-      port: 6379,
-    },
-  },
-);
-```
-
-Also, make sure to install the `ioredis` package:
-
-```bash
-$ npm i ioredis
-```
-
-#### gRPC client interceptors
-
-In the previous version, the `interceptors` configuration property was exposed in the wrong location. In v9, make sure to pass `interceptors` as part of the `channelOptions` object, see example [here](https://github.com/nestjs/nest/issues/9079#issuecomment-1078744758).
-
-#### Testing module
-
-Previously, if you wanted to supply the configuration object to the `TestingModule#createNestApplication` method, and if you were using the default HTTP driver (express), you had to do this as follows:
-
-```typescript
-app = moduleFixture.createNestApplication<NestExpressApplication>(undefined, {
-  rawBody: true,
-});
-```
-
-In v9, you can skip the first argument (`undefined`):
-
-```typescript
-app = moduleFixture.createNestApplication<NestExpressApplication>({
-  rawBody: true,
-});
-```
-
-#### Kafka message/event handlers
-
-Previously, Kafka message and event handlers were receiving payloads as wrapped Kafka messages with `key`, `value`, `headers`, and a few other properties. In v9, those payloads are automatically unwrapped and your handlers will only receive the `value` attribute's value. To retrieve the original Kafka message, you can use the `KafkaContext` object (read more [here](/microservices/kafka#context)).
-
-```typescript
-// Before
-@MessagePattern('hero.kill.dragon')
-killDragon(@Payload() message: KillDragonMessage, @Ctx() context: KafkaContext) {
-  console.log(`Dragon ID: ${message.value.dragonId}`);
-}
-
-// Now
-@MessagePattern('hero.kill.dragon')
-killDragon(@Payload() message: KillDragonMessage, @Ctx() context: KafkaContext) {
-  console.log(`Dragon ID: ${message.dragonId}`);
-  // Original message: "context.getMessage()"
-}
-```
-
-#### Kafka retriable errors
-
-In v9, we introduced the **[Retriable exceptions](/microservices/kafka#retriable-exceptions)** feature. Note: for event handlers (**event-based communication**) all unhandled exceptions become "retriable exceptions" by default, and so they will be auto-delivered.
-
-#### Fastify
-
-Fastify has been upgraded to v4. Also, all of the core Fastify plugins that were prefixed with `fastify-` are now renamed and published under the `@fastify` scope (for example, `fastify-cookie` becomes `@fastify/cookie`, `fastify-helmet` becomes `@fastify/helmet`, etc.). Read more [here](https://github.com/fastify/fastify/issues/3856).
-
-#### `@nestjs/swagger` package
+#### Deprecations
 
-There are a few minor breaking changes in the `@nestjs/swagger` package (`swagger-ui-express` and `fastify-swagger` packages are no longer required). See this [PR](https://github.com/nestjs/swagger/pull/1886) for more details.
+All deprecated methods & modules have been removed.
 
-#### Deprecations
+### CLI Plugins and TypeScript >= 4.8
 
-All deprecated methods & modules have been removed (e.g., the deprecated `listenAsync()` method).
+NestJS CLI Plugins (available for `@nestjs/swagger` and `@nestjs/graphql` packages) will now require TypeScript >= v4.8 and so older versions of TypeScript will no longer be supported. The reason for this change is that in [TypeScript v4.8 introduced several breaking changes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-8.html#decorators-are-placed-on-modifiers-on-typescripts-syntax-trees) in its Abstract Syntax Tree (AST) which we use to auto-generate OpenAPI and GraphQL schemas.
 
-#### Node.js
+### Dropping support for Node.js v12
 
-This release drops support for Node v10. We strongly recommend using the latest LTS version.
+As of NestJS 10, we no longer support Node.js v12, as [v12 went EOL](https://twitter.com/nodejs/status/1524081123579596800) on April 30, 2022. This means that NestJS 10 requires Node.js v16 or higher. This decision was made to allow us to finally set target to `ES2021` in our TypeScript configuration, instead of shipping polyfills as we did in the past.
 
-#### CLI
+From now on, every official NestJS package will be compiled to `ES2021` by default, which should result in a smaller library size and sometimes even (slightly) better performance.
 
-Due to stability issues, the command `update` was removed in the v9 of `@nestjs/cli`.  
-You can use dedicated tools like [`ncu`](https://www.npmjs.com/package/npm-check-updates), `npm update`, [`yarn upgrade-interactive`](https://classic.yarnpkg.com/en/docs/cli/upgrade-interactive), etc., if you want to upgrade your dependencies.
+We also strongly recommend using the latest LTS version.

content/techniques/configuration.md

@@ -342,8 +342,6 @@ To use Joi, we must install Joi package:
 $ npm install --save joi
 ```
 
-> warning **Notice** The latest version of `joi` requires you to be running Node v12 or later. For older versions of node, please install `v16.1.8`. This is mainly after the release of `v17.0.2` which causes errors during build time. For more information, please refer to [their 17.0.0 release notes](https://github.com/sideway/joi/issues/2262).
-
 Now we can define a Joi validation schema and pass it via the `validationSchema` property of the `forRoot()` method's options object, as shown below:
 
 ```typescript