Merge pull request #1588 from johannesschobel/fix-typo

Fix Typos and minor Formatting Issues

Author: kamilmysliwiec

content/cli/libraries.md

@@ -2,9 +2,9 @@
 
 Many applications need to solve the same general problems, or re-use a modular component in several different contexts. Nest has a few ways of addressing this, but each works at a different level to solve the problem in a way that helps meet different architectural and organizational objectives.
 
-Nest [modules](/modules) are useful for providing an execution context that enables sharing components within a single application. Modules can also be packaged with [npm](https://npmjs.com) to create a reusable library that can be installed in different projects. This can be an effective way to distribute configurable, re-usable libraries that can be used by different, loosely connected or unafilliated organizations (e.g., by distributing/installing 3rd party libraries).
+Nest [modules](/modules) are useful for providing an execution context that enables sharing components within a single application. Modules can also be packaged with [npm](https://npmjs.com) to create a reusable library that can be installed in different projects. This can be an effective way to distribute configurable, re-usable libraries that can be used by different, loosely connected or unaffiliated organizations (e.g., by distributing/installing 3rd party libraries).
 
-For sharing code within closely organized groups (e.g., within company/project boundaries), it can be useful to have a more lightweight approach to sharing components. Monorepo's have arisen as a construct to enable that, and within a monorepo, a **library** provides a way to share code in an easy, lightweight fashion. In a Nest monorepo, using libraries enables easy assembly of applications that share components. In fact, this encourages decomposition of monolithic applications and development processes to focus on building and composing modular components.
+For sharing code within closely organized groups (e.g., within company/project boundaries), it can be useful to have a more lightweight approach to sharing components. Monorepos have arisen as a construct to enable that, and within a monorepo, a **library** provides a way to share code in an easy, lightweight fashion. In a Nest monorepo, using libraries enables easy assembly of applications that share components. In fact, this encourages decomposition of monolithic applications and development processes to focus on building and composing modular components.
 
 #### Nest libraries
 

content/faq/errors.md

@@ -40,4 +40,4 @@ Scope [<module_import_chain>]
 # example chain AppModule -> FooModule
 ```
 
-Circular dependencies can arise from both providers depending on each other, or typescript files depending on each other for constants, such as exporting constants from a module file and importing them in a service file. In the latter case, it is advised to create a separate file for your constants. In the former case, please follow the guide on ciruclar dependencies and make sure that both the modules **and** the providers are marked with `forwardRef`.
+Circular dependencies can arise from both providers depending on each other, or typescript files depending on each other for constants, such as exporting constants from a module file and importing them in a service file. In the latter case, it is advised to create a separate file for your constants. In the former case, please follow the guide on circular dependencies and make sure that both the modules **and** the providers are marked with `forwardRef`.

content/faq/hybrid-application.md

@@ -39,7 +39,7 @@ To bind `@MessagePattern()` to only one transport strategy (for example, MQTT) i
 
 ```typescript
 @@filename()
-@MessagePattern('time.us.*', Transport.NAST)
+@MessagePattern('time.us.*', Transport.NATS)
 getDate(@Payload() data: number[], @Ctx() context: NatsContext) {
   console.log(`Subject: ${context.getSubject()}`); // e.g. "time.us.east"
   return new Date().toLocaleTimeString(...);
@@ -50,7 +50,7 @@ getTCPDate(@Payload() data: number[]) {
 }
 @@switch
 @Bind(Payload(), Ctx())
-@MessagePattern('time.us.*', Transport.NAST)
+@MessagePattern('time.us.*', Transport.NATS)
 getDate(data, context) {
   console.log(`Subject: ${context.getSubject()}`); // e.g. "time.us.east"
   return new Date().toLocaleTimeString(...);

content/faq/request-lifecycle.md

@@ -67,22 +67,22 @@ Filters are the only component that do not resolve global first. Instead, filter
 In general, the request lifecycle looks like the following:
 
 1. Incoming request
-1. Globally bound middleware
-1. Module bound middleware
-1. Global guards
-1. Controller guards
-1. Route guards
-1. Global interceptors (pre-controller)
-1. Controller interceptors (pre-controller)
-1. Route interceptors (pre-controller)
-1. Global pipes
-1. Controller pipes
-1. Route pipes
-1. Route parameter pipes
-1. Controller (method handler)
-1. Service (if exists)
-1. Route interceptor (post-request)
-1. Controller interceptor (post-request)
-1. Global interceptor (post-request)
-1. Exception filters (route, then controller, then global)
-1. Server response
+2. Globally bound middleware
+3. Module bound middleware
+4. Global guards
+5. Controller guards
+6. Route guards
+7. Global interceptors (pre-controller)
+8. Controller interceptors (pre-controller)
+9. Route interceptors (pre-controller)
+10. Global pipes
+11. Controller pipes
+12. Route pipes
+13. Route parameter pipes
+14. Controller (method handler)
+15. Service (if exists)
+16. Route interceptor (post-request)
+17. Controller interceptor (post-request)
+18. Global interceptor (post-request)
+19. Exception filters (route, then controller, then global)
+20. Server response

content/fundamentals/dependency-injection.md

@@ -89,7 +89,6 @@ export class AppModule {}
 What exactly is happening under the covers to make this work? There are three key steps in the process:
 
 1. In `cats.service.ts`, the `@Injectable()` decorator declares the `CatsService` class as a class that can be managed by the Nest IoC container.
-
 2. In `cats.controller.ts`, `CatsController` declares a dependency on the `CatsService` token with constructor injection:
 
 ```typescript

content/graphql/extensions.md

@@ -20,7 +20,7 @@ Note, in addition to setting metadata on fields, you can use the `@Extensions()`
 
 #### Using custom metadata
 
-The logic that leverages the custom metatada can be as complex as needed. For example, you can create a simple interceptor that stores/logs events per method invocation, or create a sophisticated guard that **analyzes requested fields**, iterates through the `GraphQLObjectType` definition, and matches the roles required to retrieve specific fields with the caller permissions (field-level permissions system).
+The logic that leverages the custom metadata can be as complex as needed. For example, you can create a simple interceptor that stores/logs events per method invocation, or create a sophisticated guard that **analyzes requested fields**, iterates through the `GraphQLObjectType` definition, and matches the roles required to retrieve specific fields with the caller permissions (field-level permissions system).
 
 Let's define a `FieldRolesGuard` that implements a basic version of such a field-level permissions system.
 

content/graphql/federation.md

@@ -203,7 +203,7 @@ import { PostsResolvers } from './posts.resolvers';
 export class AppModule {}
 ```
 
-##### Code first
+#### Code first
 
 We will need to create a class representing our `User` entity. Even though it lives in another service, we will be using and extending it. Note the `@extends` and `@external` directives.
 

content/graphql/resolvers-map.md

@@ -48,7 +48,7 @@ export class Author {
 
 The `Author` object type, like any class, is made of a collection of fields, with each field declaring a type. A field's type corresponds to a [GraphQL type](https://graphql.org/learn/schema/). A field's GraphQL type can be either another object type or a scalar type. A GraphQL scalar type is a primitive (like `ID`, `String`, `Boolean`, or `Int`) that resolves to a single value.
 
-> info **Hint** In addition to GraphQL's built-in scalar types, you can define custom scalar types (read [more](/graphql/scalars)).
+> info **Hint** In addition to GraphQLs built-in scalar types, you can define custom scalar types (read [more](/graphql/scalars)).
 
 The above `Author` object type definition will cause Nest to **generate** the SDL we showed above:
 

content/guards.md

@@ -243,7 +243,7 @@ export class RolesGuard {
 }
 ```
 
-> info **Hint** In the node.js world, it's common practice to attach the authorized user to the `request` object. Thus, in our sample code above, we are assuming that `request.user` contains the user instance and allowed roles. In your app, you will probably make that association in your custom **authentication guard** (or middleware). Check [this chapter](/security/authentication) for more infomration on this topic.
+> info **Hint** In the node.js world, it's common practice to attach the authorized user to the `request` object. Thus, in our sample code above, we are assuming that `request.user` contains the user instance and allowed roles. In your app, you will probably make that association in your custom **authentication guard** (or middleware). Check [this chapter](/security/authentication) for more information on this topic.
 
 > warning **Warning** The logic inside the `matchRoles()` function can be as simple or sophisticated as needed. The main point of this example is to show how guards fit into the request/response cycle.
 

content/openapi/introduction.md

@@ -88,7 +88,7 @@ The `SwaggerModule` automatically reflects all of your endpoints. Note that the
 
 ### Document options
 
-When creating a document, it is possible to provide some extra options to finetune the library's behavior. These options should be of type `SwaggerDocumentOptions`, which can be the following:
+When creating a document, it is possible to provide some extra options to fine tune the library's behavior. These options should be of type `SwaggerDocumentOptions`, which can be the following:
 
 ```TypeScript
 export interface SwaggerDocumentOptions {