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

Author: kamilmysliwiec

content/cli/usages.md

@@ -55,7 +55,7 @@ $ nest g <schematic> <name> [options]
 
 | Name          | Alias | Description                                                                                         |
 | ------------- | ----- | --------------------------------------------------------------------------------------------------- |
-| `application` |       | Generate a new application within a monorepo (converting to monorepo if it's a standard structure). |
+| `app`         |       | Generate a new application within a monorepo (converting to monorepo if it's a standard structure). |
 | `library`     | `lib` | Generate a new library within a monorepo (converting to monorepo if it's a standard structure).     |
 | `class`       | `cl`  | Generate a new class.                                                                               |
 | `controller`  | `co`  | Generate a controller declaration.                                                                  |

content/cli/workspaces.md

@@ -93,7 +93,7 @@ The `generate app` schematic has reorganized the code - moving each **applicatio
 
 #### Workspace projects
 
-A mono repo uses the concept of a workspace to manage its member entities. Workspaces are composed of **projects**. A project may be either:
+A monorepo uses the concept of a workspace to manage its member entities. Workspaces are composed of **projects**. A project may be either:
 
 - an **application**: a full Nest application including a `main.ts` file to bootstrap the application. Aside from compile and build considerations, an application-type project within a workspace is functionally identical to an application within a _standard mode_ structure.
 - a **library**: a library is a way of packaging a general purpose set of features (modules, providers, controllers, etc.) that can be used within other projects. A library cannot run on its own, and has no `main.ts` file. Read more about libraries [here](/cli/libraries).

content/components.md

@@ -203,3 +203,11 @@ This is how our directory structure should look now:
 <div class="item">main.ts</div>
 </div>
 </div>
+
+#### Manual instantiation
+
+Thus far, we've discussed how Nest automatically handles most of the details of resolving dependencies.  In certain circumstances, you may need to step outside of the built-in Dependency Injection system and manually retrieve or instantiate providers. We briefly discuss two such topics below.
+
+ To get existing instances, or instantiate providers dynamically, you can use [Module reference](https://docs.nestjs.com/fundamentals/module-ref).
+ 
+ To get providers within the `bootstrap()` function (for example for standalone applications without controllers, or to utilize a configuration service during bootstrapping) see [Standalone applications](https://docs.nestjs.com/standalone-applications).

content/discover/who-uses.json

@@ -141,6 +141,11 @@
       "logo": "/assets/logo/zeoagency.svg",
       "url": "https://zeo.org/tr/",
       "width": "80px"
+    },
+    {
+      "logo": "/assets/logo/valueadd.png",
+      "url": "https://valueadd.pl/",
+      "width": "120px"
     }
   ],
   "Body": [

content/faq/hybrid-application.md

@@ -1,6 +1,6 @@
 ### Hybrid application
 
-A hybrid application is one that both listens for HTTP requests, as well as makes use of connected microservices. The `INestApplication` instance can be connected with `INestMicroservice` instances through the `connectMicroservice()` method. To connect multiple microservice instances, simply pass additional microservice configuration objects as arguments in a comma-separated list.
+A hybrid application is one that both listens for HTTP requests, as well as makes use of connected microservices. The `INestApplication` instance can be connected with `INestMicroservice` instances through the `connectMicroservice()` method.
 
 ```typescript
 const app = await NestFactory.create(AppModule);
@@ -11,3 +11,26 @@ const microservice = app.connectMicroservice({
 await app.startAllMicroservicesAsync();
 await app.listen(3001);
 ```
+
+To connect multiple microservice instances, issue the call to `connectMicroservice()` for each microservice:
+
+```typescript
+const app = await NestFactory.create(AppModule);
+// microservice #1
+const microserviceTcp = app.connectMicroservice<MicroserviceOptions>({
+  transport: Transport.TCP,
+  options: {
+    port: 3001,
+  },
+});
+// microservice #2
+const microserviceRedis = app.connectMicroservice<MicroserviceOptions>({
+  transport: Transport.REDIS,
+  options: {
+    url: 'redis://localhost:6379',
+  },
+});
+
+await app.startAllMicroservicesAsync();
+await app.listen(3001);
+```

content/fundamentals/dependency-injection.md

@@ -272,7 +272,7 @@ export class AppModule {}
 
 #### Alias providers: `useExisting`
 
-The `useExisting` syntax allows you to create aliases for existing providers. This creates two ways to access the same provider. In the example below, the (string-based) token `'AliasedLoggerService'` is an alias for the (class-based) token `LoggerService`. Assume we have two different dependencies, one for `'AlilasedLoggerService'` and one for `LoggerService`. If both dependencies are specified with `SINGLETON` scope, they'll both resolve to the same instance.
+The `useExisting` syntax allows you to create aliases for existing providers. This creates two ways to access the same provider. In the example below, the (string-based) token `'AliasedLoggerService'` is an alias for the (class-based) token `LoggerService`. Assume we have two different dependencies, one for `'AliasedLoggerService'` and one for `LoggerService`. If both dependencies are specified with `SINGLETON` scope, they'll both resolve to the same instance.
 
 ```typescript
 @Injectable()

content/fundamentals/execution-context.md

@@ -15,14 +15,17 @@ The `ArgumentsHost` class provides methods for retrieving the arguments being pa
 When building generic [guards](/guards), [filters](/exception-filters), and [interceptors](/interceptors) which are meant to run across multiple application contexts, we need a way to determine the type of application that our method is currently running in. Do this with the `getType()` method of `ArgumentsHost`:
 
 ```typescript
-const type = host.getType();
-if (type === 'http') {
-  // HTTP application
-} else if (type === 'rpc') {
-  // Microservice
+if (host.getType() === 'http') {
+  // do something that is only important in the context of regular HTTP requests (REST)
+} else if (host.getType() === 'rpc') {
+  // do something that is only important in the context of Microservice requests
+} else if (host.getType<GqlContextType>() === 'graphql') {
+  // do something that is only important in the context of GraphQL requests
 }
 ```
 
+> info **Hint** The `GqlContextType` is imported from the `@nestjs/graphql` package.
+
 With the application type available, we can write more generic components, as shown below.
 
 #### Host handler arguments

content/fundamentals/lifecycle-events.md

@@ -15,7 +15,7 @@ The following diagram depicts the sequence of key application lifecycle events,
 Lifecycle events happen during application bootstrapping and shutdown. Nest calls registered lifecycle hook methods on `modules`, `injectables` and `controllers` at each of the following lifecycle events (**shutdown hooks** need to be enabled first, as described [below](https://docs.nestjs.com/fundamentals/lifecycle-events#application-shutdown)). As shown in the diagram above, Nest also calls the appropriate underlying methods to begin listening for connections, and to stop listening for connections.
 
 | Lifecycle hook method         | Lifecycle event triggering the hook method call                                                                                                                                                                   |
-| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|-------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `onModuleInit()`              | Called once the host module's dependencies have been resolved.                                                                                                                                                    |
 | `onApplicationBootstrap()`    | Called once all modules have been initialized, but before listening for connections.                                                                                                                              |
 | `onModuleDestroy()`           | Called after a termination signal (e.g., `SIGTERM`) has been received.                                                                                                                                            |
@@ -66,6 +66,8 @@ async onModuleInit() {
 
 The `beforeApplicationShutdown()` and `onApplicationShutdown()` hooks are called in the **terminating** phase (in response to system signals such as `SIGTERM`). This feature is often used with [Kubernetes](https://kubernetes.io/), [Heroku](https://www.heroku.com/) or similar services.
 
+> warning **warning** Due to inherent platform limitations, NestJS has limited support for application shutdown hooks on Windows. You can expect `SIGINT` to work, as well as `SIGBREAK` and to some extent `SIGHUP` - [read more](https://nodejs.org/api/process.html#process_signal_events). However `SIGTERM` will never work on Windows because killing a process in the task manager is unconditional, "i.e., there's no way for an application to detect or prevent it". Here's some [relevant documentation](http://docs.libuv.org/en/v1.x/signal.html) from libuv to learn more about how `SIGINT`, `SIGBREAK` and others are handled on Windows. Also, see Node.js documentation of [Process Signal Events](https://nodejs.org/api/process.html#process_signal_events)
+
 To use these hooks you must activate a listener which listens to shutdown signals.
 
 ```typescript
@@ -81,6 +83,8 @@ async function bootstrap() {
 bootstrap();
 ```
 
+> info **Info** `enableShutdownHooks` consumes memory by starting listeners. In cases where you are running multiple Nest apps in a single Node process (e.g., when running parallel tests with Jest), Node may complain about excessive listener processes. For this reason, `enableShutdownHooks` is not enabled by default. Be aware of this condition when you are running multiple instances in a single Node process.
+
 When the application receives a termination signal it will call any registered `beforeApplicationShutdown()`, then `onApplicationShutdown()` methods (in the sequence described above) with the corresponding signal as the first parameter. If a registered function awaits an asynchronous call (returns a promise), Nest will not continue in the sequence until the promise is resolved or rejected.
 
 ```typescript

content/graphql/enums.md

@@ -64,16 +64,22 @@ export enum AllowedColor {
 }
 ```
 
-Sometimes a backend forces a different value for an enum internally than in the public API. In this example the API contains `RED`, however in resolvers we may use `#f00` instead (read more [here](https://www.apollographql.com/docs/apollo-server/schema/scalars-enums/#internal-values)). To accomplish this, declare a resolver class for the `AllowedColor` enum:
+Sometimes a backend forces a different value for an enum internally than in the public API. In this example the API contains `RED`, however in resolvers we may use `#f00` instead (read more [here](https://www.apollographql.com/docs/apollo-server/schema/scalars-enums/#internal-values)). To accomplish this, declare a resolver object for the `AllowedColor` enum:
 
 ```typescript
-@Resolver('AllowedColor')
-export class AllowedColorResolver {
-  @ResolveField('RED')
-  getRedColor() {
-    return '#f00';
-  }
+export const allowedColorResolver: Record<keyof typeof AllowedColor, any> = {
+  RED: '#f00',
 }
 ```
 
 > info **Hint** All decorators are exported from the `@nestjs/graphql` package.
+
+Then use this resolver object together with the `resolvers` property of the `GraphQLModule#forRoot()` method, as follows:
+
+```typescript
+GraphQLModule.forRoot({
+  resolvers: {
+    AllowedColor: allowedColorResolver,
+  },
+})
+```

content/graphql/resolvers-map.md

@@ -203,7 +203,7 @@ export class AuthorsResolver {
   ) {}
 
   @Query(returns => Author, { name: 'author' })
-  async getAuthor(@Args('id', {type: () => Int }) id: number) {
+  async getAuthor(@Args('id', { type: () => Int }) id: number) {
     return this.authorsService.findOneById(id);
   }
 
@@ -236,7 +236,7 @@ The `@Query()` decorator's options object (where we pass `{{ '{' }}name: 'author
 
 Use the `@Args()` decorator to extract arguments from a request for use in the method handler. This works in a very similar fashion to [REST route parameter argument extraction](/controllers#route-parameters).
 
-Usually your `@Args()` decorator will be simple, and not require an object argument as seen with the `getAuthor()` method above. For example, if an identifier's type is string, the following construction is sufficient, and simply plucks the named field from the inbound GraphQL request for use as a method argument.
+Usually your `@Args()` decorator will be simple, and not require an object argument as seen with the `getAuthor()` method above. For example, if the type of an identifier is string, the following construction is sufficient, and simply plucks the named field from the inbound GraphQL request for use as a method argument.
 
 ```typescript
 @Args('id') id: string
@@ -245,10 +245,10 @@ Usually your `@Args()` decorator will be simple, and not require an object argum
 In the `getAuthor()` case, the `number` type is used, which presents a challenge. The `number` TypeScript type doesn't give us enough information about the expected GraphQL representation (e.g., `Int` vs. `Float`). Thus we have to **explicitly** pass the type reference. We do that by passing a second argument to the `Args()` decorator, containing argument options, as shown below:
 
 ```typescript
-  @Query(returns => Author, { name: 'author' })
-  async getAuthor(@Args('id', { type: () => Int }) id: number) {
-    return this.authorsService.findOneById(id);
-  }
+@Query(returns => Author, { name: 'author' })
+async getAuthor(@Args('id', { type: () => Int }) id: number) {
+  return this.authorsService.findOneById(id);
+}
 ```
 
 The options object allows us to specify the following optional key value pairs: