Merge branch 'master' of https://github.com/nestjs/docs.nestjs.com

Author: kamilmysliwiec

content/controllers.md

@@ -550,7 +550,7 @@ export class CatsController {
 }
 ```
 
-Though this approach works, and does in fact allow for more flexibility in some ways by providing full control of the response object (headers manipulation, library-specific features, and so on), it should be used with care. In general, the approach is much less clear and does have some disadvantages. The main disadvantage is that your code become platform-dependent (as underlying libraries may have different APIs on the response object), and harder to test (you'll have to mock the response object, etc.).
+Though this approach works, and does in fact allow for more flexibility in some ways by providing full control of the response object (headers manipulation, library-specific features, and so on), it should be used with care. In general, the approach is much less clear and does have some disadvantages. The main disadvantage is that your code becomes platform-dependent (as underlying libraries may have different APIs on the response object), and harder to test (you'll have to mock the response object, etc.).
 
 Also, in the example above, you lose compatibility with Nest features that depend on Nest standard response handling, such as Interceptors and `@HttpCode()` / `@Header()` decorators. To fix this, you can set the `passthrough` option to `true`, as follows:
 

content/fundamentals/unit-testing.md

@@ -349,6 +349,7 @@ providers: [
   {
     provide: APP_GUARD,
     useExisting: JwtAuthGuard,
+    // ^^^^^^^^ notice the use of 'useExisting' instead of 'useClass'
   },
   JwtAuthGuard,
 ],

content/graphql/resolvers-map.md

@@ -17,7 +17,7 @@ type Author {
   id: Int!
   firstName: String
   lastName: String
-  posts: [Post]
+  posts: [Post!]!
 }
 ```
 
@@ -57,7 +57,7 @@ type Author {
   id: Int!
   firstName: String
   lastName: String
-  posts: [Post]
+  posts: [Post!]!
 }
 ```
 

content/recipes/mikroorm.md

@@ -233,6 +233,7 @@ export class AppModule {}
 
 // register the request context middleware
 const app = await NestFactory.create(AppModule, { ... });
+const orm = app.get(MikroORM);
 
 app.use((req, res, next) => {
   storage.run(orm.em.fork(true, true), next);

content/recipes/nest-commander.md

@@ -0,0 +1,157 @@
+### Nest Commander
+
+Expanding on the [standalone application](/standalone-applications) docs there's also the [nest-commander](https://jmcdo29.github.io/nest-commander) package for writing command line applications in a structure similar to your typical Nest application.
+
+> info **info** `nest-commander` is a third party package and is not managed by the entirety of the NestJS core team. Please, report any issues found with the library in the [appropriate repository](https://github.com/jmcdo29/nest-commander/issues/new/choose)
+
+#### Installation
+
+Just like any other package, you've got to install it before you can use it.
+
+```bash
+$ npm i nest-commander
+```
+
+#### A Command file
+
+`nest-commander` makes it easy to write new command-line applications with [decorators](https://www.typescriptlang.org/docs/handbook/decorators.html) via the `@Command()` decorator for classes and the `@Option()` decorator for methods of that class. Every command file should implement the `CommandRunner` interface and should be decorated with a `@Command()` decorator.
+
+Every command is seen as an `@Injectable()` by Nest, so your normal Dependency Injection still works as you would expect it to. The only thing to take note of is the interface `CommandRunner`, which should be implemented by each command. The `CommandRunner` interface ensures that all commands have a `run` method that returns a `Promise<void>` and takes in the parameters `string[], Record<string, any>`. The `run` command is where you can kick all of your logic off from, it will take in whatever parameters did not match option flags and pass them in as an array, just in case you are really meaning to work with multiple parameters. As for the options, the `Record<string, any>`, the names of these properties match the `name` property given to the `@Option()` decorators, while their value matches the return of the option handler. If you'd like better type safety, you are welcome to create an interface for your options as well.
+
+#### Running the Command
+
+Similar to how in a NestJS application we can use the `NestFactory` to create a server for us, and run it using `listen`, the `nest-commander` package exposes a simple to use API to run your server. Import the `CommandFactory` and use the `static` method `run` and pass in the root module of your application. This would probably look like below
+
+```ts
+import { CommandFactory } from 'nest-commander';
+import { AppModule } from './app.module';
+
+async function bootstrap() {
+  await CommandFactory.run(AppModule);
+}
+
+bootstrap();
+```
+
+By default, Nest's logger is disabled when using the `CommandFactory`. It's possible to provide it though, as the second argument to the `run` function. You can either provide a custom NestJS logger, or an array of log levels you want to keep - it might be useful to at least provide `['error']` here, if you only want to print out Nest's error logs.
+
+```ts
+import { CommandFactory } from 'nest-commander';
+import { AppModule } from './app.module';
+import { LogService } './log.service';
+
+async function bootstrap() {
+  await CommandFactory.run(AppModule, new LogService());
+
+  // or, if you only want to print Nest's warnings and errors
+  await CommandFactory.run(AppModule, ['warn', 'error']);
+}
+
+bootstrap();
+```
+
+And that's it. Under the hood, `CommandFactory` will worry about calling `NestFactory` for you and calling `app.close()` when necessary, so you shouldn't need to worry about memory leaks there. If you need to add in some error handling, there's always `try/catch` wrapping the `run` command, or you can chain on some `.catch()` method to the `bootstrap()` call.
+
+#### Testing
+
+So what's the use of writing a super awesome command line script if you can't test it super easily, right? Fortunately, `nest-commander` has some utilities you can make use of that fits in perfectly with the NestJS ecosystem, it'll feel right at home to any Nestlings out there. Instead of using the `CommandFactory` for building the command in test mode, you can use `CommandTestFactory` and pass in your metadata, very similarly to how `Test.createTestingModule` from `@nestjs/testing` works. In fact, it uses this package under the hood. You're also still able to chain on the `overrideProvider` methods before calling `compile()` so you can swap out DI pieces right in the test.
+
+#### Putting it all together
+
+The following class would equate to having a CLI command that can take in the subcommand `basic` or be called directly, with `-n`, `-s`, and `-b` (along with their long flags) all being supported and with custom parsers for each option. The `--help` flag is also supported, as is customary with commander.
+
+```ts
+import { Command, CommandRunner, Option } from 'nest-commander';
+import { LogService } from './log.service';
+
+interface BasicCommandOptions {
+  string?: string;
+  boolean?: boolean;
+  number?: number;
+}
+
+@Command({ name: 'basic', description: 'A parameter parse' })
+export class BasicCommand implements CommandRunner {
+  constructor(private readonly logService: LogService) {}
+
+  async run(
+    passedParam: string[],
+    options?: BasicCommandOptions,
+  ): Promise<void> {
+    if (options?.boolean !== undefined && options?.boolean !== null) {
+      this.runWithBoolean(passedParam, options.boolean);
+    } else if (options?.number) {
+      this.runWithNumber(passedParam, options.number);
+    } else if (options?.string) {
+      this.runWithString(passedParam, options.string);
+    } else {
+      this.runWithNone(passedParam);
+    }
+  }
+
+  @Option({
+    flags: '-n, --number [number]',
+    description: 'A basic number parser',
+  })
+  parseNumber(val: string): number {
+    return Number(val);
+  }
+
+  @Option({
+    flags: '-s, --string [string]',
+    description: 'A string return',
+  })
+  parseString(val: string): string {
+    return val;
+  }
+
+  @Option({
+    flags: '-b, --boolean [boolean]',
+    description: 'A boolean parser',
+  })
+  parseBoolean(val: string): boolean {
+    return JSON.parse(val);
+  }
+
+  runWithString(param: string[], option: string): void {
+    this.logService.log({ param, string: option });
+  }
+
+  runWithNumber(param: string[], option: number): void {
+    this.logService.log({ param, number: option });
+  }
+
+  runWithBoolean(param: string[], option: boolean): void {
+    this.logService.log({ param, boolean: option });
+  }
+
+  runWithNone(param: string[]): void {
+    this.logService.log({ param });
+  }
+}
+```
+
+Make sure the command class is added to a module
+
+```ts
+@Module({
+  providers: [LogService, BasicCommand],
+})
+export class AppModule {}
+```
+
+And now to be able to run the CLI in your main.ts you can do the following
+
+```ts
+async function bootstrap() {
+  await CommandFactory.run(AppModule);
+}
+
+bootstrap();
+```
+
+And just like that, you've got a command line application.
+
+#### More Information
+
+Visit the [nest-commander docs site](https://jmcdo29.github.io/nest-commander) for more information, examples, and API documentation.

content/recipes/prisma.md

@@ -247,7 +247,7 @@ When setting up your NestJS application, you'll want to abstract away the Prisma
 Inside the `src` directory, create a new file called `prisma.service.ts` and add the following code to it:
 
 ```typescript
-import { INestApplication, Injectable, OnModuleInit, OnModuleDestroy } from '@nestjs/common';
+import { INestApplication, Injectable, OnModuleInit } from '@nestjs/common';
 import { PrismaClient } from '@prisma/client';
 
 @Injectable()
@@ -530,12 +530,13 @@ Prisma interferes with NestJS `enableShutdownHooks`. Prisma listens for shutdown
 ...
 import { PrismaService } from './services/prisma/prisma.service';
 ...
-bootstrap() {
+async function bootstrap() {
   ...
   const prismaService: PrismaService = app.get(PrismaService);
   prismaService.enableShutdownHooks(app)
   ...
 }
+bootstrap()
 ```
 
 You can [read more](https://github.com/prisma/prisma/issues/2917#issuecomment-708340112) about Prisma handling of shutdown signal, and `beforeExit` event.

content/recipes/sql-typeorm.md

@@ -11,7 +11,7 @@
 To start the adventure with this library we have to install all required dependencies:
 
 ```bash
-$ npm install --save typeorm mysql
+$ npm install --save typeorm mysql2
 ```
 
 The first step we need to do is to establish the connection with our database using `createConnection()` function imported from the `typeorm` package. The `createConnection()` function returns a `Promise`, and therefore we have to create an [async provider](/fundamentals/async-components).

content/techniques/caching.md

@@ -118,7 +118,7 @@ export class AppModule {}
 
 #### Customize caching
 
-All cached data has its own expiration time (TTL). To customize default values, pass the options object to the `register()` method.
+All cached data has its own expiration time ([TTL](https://en.wikipedia.org/wiki/Time_to_live)). To customize default values, pass the options object to the `register()` method.
 
 ```typescript
 CacheModule.register({
@@ -127,6 +127,16 @@ CacheModule.register({
 });
 ```
 
+#### Use module globally
+
+When you want to use `CacheModule` in other modules, you'll need to import it (as is standard with any Nest module). Alternatively, declare it as a [global module](https://docs.nestjs.com/modules#global-modules) by setting the options object's `isGlobal` property to `true`, as shown below. In that case, you will not need to import `CacheModule` in other modules once it's been loaded in the root module (e.g., `AppModule`).
+
+```typescript
+CacheModule.register({
+  isGlobal: true,
+});
+```
+
 #### Global cache overrides
 
 While global cache is enabled, cache entries are stored under a `CacheKey` that is auto-generated based on the route path. You may override certain cache settings (`@CacheKey()` and `@CacheTTL()`) on a per-method basis, allowing customized caching strategies for individual controller methods. This may be most relevant while using [different cache stores.](https://docs.nestjs.com/techniques/caching#different-stores)

content/techniques/queues.md

@@ -447,7 +447,7 @@ The construction above will instantiate `BullConfigService` inside `BullModule`
 ```typescript
 @Injectable()
 class BullConfigService implements SharedBullConfigurationFactory {
-  createSharedConfiguration(): SharedBullConfigurationFactory {
+  createSharedConfiguration(): BullModuleOptions {
     return {
       redis: {
         host: 'localhost',

src/app/common/social-wrapper/social-wrapper.component.html

@@ -1,11 +1,17 @@
 <div class="social-wrapper">
-  <a href="https://twitter.com/nestframework" target="_blank">
+  <a href="https://twitter.com/nestframework"
+     title="Twitter account"
+     target="_blank">
     <i class="fab fa-twitter"></i>
   </a>
-  <a href="https://github.com/nestjs/nest" target="_blank">
+  <a href="https://github.com/nestjs/nest"
+     title="Github repository"
+     target="_blank">
     <i class="fab fa-github"></i>
   </a>
-  <a href="https://stackoverflow.com/questions/tagged/nestjs" target="_blank">
+  <a href="https://stackoverflow.com/questions/tagged/nestjs"
+     title="Stackoverflow"
+     target="_blank">
     <i class="fab fa-stack-overflow"></i>
   </a>
   <a
@@ -15,7 +21,10 @@
   >
     <i class="fa fa-globe"></i>
   </a>
-  <a href="https://discord.gg/G7Qnnhy" target="_blank" rel="nofollow">
+  <a href="https://discord.gg/G7Qnnhy"
+     title="Discord"
+     target="_blank"
+     rel="nofollow">
     <i class="fab fa-discord"></i>
   </a>
 </div>