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

Author: kamilmysliwiec

content/components.md

@@ -4,9 +4,9 @@ Providers are a fundamental concept in Nest. Many of the basic Nest classes may
 
 <figure><img class="illustrative-image" src="/assets/Components_1.png" /></figure>
 
-In the previous chapter, we built a simple `CatsController`. Controllers should handle HTTP requests and delegate more complex tasks to **providers**. Providers are plain JavaScript classes that are declared as `providers` in a [module](/modules).
+In the previous chapter, we built a simple `CatsController`. Controllers should handle HTTP requests and delegate more complex tasks to **providers**. Providers are plain JavaScript classes that are declared as `providers` in a NestJS module. For more information, see the "Modules" chapter.
 
-> info **Hint** Since Nest enables the possibility to design and organize dependencies in a more OO way, we strongly recommend following the [SOLID](https://en.wikipedia.org/wiki/SOLID) principles.
+> info **Hint** Since Nest enables the possibility to design and organize dependencies in a more OO way, we strongly recommend following the [SOLID principles](https://en.wikipedia.org/wiki/SOLID).
 
 #### Services
 
@@ -112,7 +112,7 @@ The `CatsService` is **injected** through the class constructor. Notice the use
 
 #### Dependency injection
 
-Nest is built around the strong design pattern commonly known as **Dependency injection**. We recommend reading a great article about this concept in the official [Angular](https://angular.dev/guide/di) documentation.
+Nest is built around the strong design pattern commonly known as **Dependency injection**. We recommend reading a great article about this concept in the official [Angular documentation](https://angular.dev/guide/di).
 
 In Nest, thanks to TypeScript capabilities, it's extremely easy to manage dependencies because they are resolved just by type. In the example below, Nest will resolve the `catsService` by creating and returning an instance of `CatsService` (or, in the normal case of a singleton, returning the existing instance if it has already been requested elsewhere). This dependency is resolved and passed to your controller's constructor (or assigned to the indicated property):
 
@@ -122,13 +122,13 @@ constructor(private catsService: CatsService) {}
 
 #### Scopes
 
-Providers normally have a lifetime ("scope") synchronized with the application lifecycle. When the application is bootstrapped, every dependency must be resolved, and therefore every provider has to be instantiated. Similarly, when the application shuts down, each provider will be destroyed. However, there are ways to make your provider lifetime **request-scoped** as well. You can read more about these techniques [here](/fundamentals/injection-scopes).
+Providers normally have a lifetime ("scope") synchronized with the application lifecycle. When the application is bootstrapped, every dependency must be resolved, and therefore every provider has to be instantiated. Similarly, when the application shuts down, each provider will be destroyed. However, there are ways to make your provider lifetime **request-scoped** as well. You can read more about these techniques in the [Injection Scopes](/fundamentals/injection-scopes) chapter.
 
 <app-banner-courses></app-banner-courses>
 
 #### Custom providers
 
-Nest has a built-in inversion of control ("IoC") container that resolves relationships between providers. This feature underlies the dependency injection feature described above, but is in fact far more powerful than what we've described so far. There are several ways to define a provider: you can use plain values, classes, and either asynchronous or synchronous factories. More examples are provided [here](/fundamentals/dependency-injection).
+Nest has a built-in inversion of control ("IoC") container that resolves relationships between providers. This feature underlies the dependency injection feature described above, but is in fact far more powerful than what we've described so far. There are several ways to define a provider: you can use plain values, classes, and either asynchronous or synchronous factories. More examples of defining providers can be found in the [Dependency Injection](/fundamentals/dependency-injection) chapter.
 
 #### Optional providers
 
@@ -145,7 +145,7 @@ export class HttpService<T> {
 }
 ```
 
-Note that in the example above we are using a custom provider, which is the reason we include the `HTTP_OPTIONS` custom **token**. Previous examples showed constructor-based injection indicating a dependency through a class in the constructor. Read more about custom providers and their associated tokens [here](/fundamentals/custom-providers).
+Note that in the example above we are using a custom provider, which is the reason we include the `HTTP_OPTIONS` custom **token**. Previous examples showed constructor-based injection indicating a dependency through a class in the constructor. You can read more about custom providers and their associated tokens in the [Custom Providers](/fundamentals/custom-providers) chapter.
 
 #### Property-based injection
 

content/graphql/resolvers-map.md

@@ -67,7 +67,7 @@ The type function is required when there's the potential for ambiguity between t
 
 The options object can have any of the following key/value pairs:
 
-- `nullable`: for specifying whether a field is nullable (in SDL, each field is non-nullable by default); `boolean`
+- `nullable`: for specifying whether a field is nullable (in `@nestjs/graphql`, each field is non-nullable by default); `boolean`
 - `description`: for setting a field description; `string`
 - `deprecationReason`: for marking a field as deprecated; `string`
 

content/graphql/subscriptions.md

@@ -34,7 +34,7 @@ GraphQLModule.forRoot<ApolloDriverConfig>({
 
 To create a subscription using the code first approach, we use the `@Subscription()` decorator (exported from the `@nestjs/graphql` package) and the `PubSub` class from the `graphql-subscriptions` package, which provides a simple **publish/subscribe API**.
 
-The following subscription handler takes care of **subscribing** to an event by calling `PubSub#asyncIterator`. This method takes a single argument, the `triggerName`, which corresponds to an event topic name.
+The following subscription handler takes care of **subscribing** to an event by calling `PubSub#asyncIterableIterator`. This method takes a single argument, the `triggerName`, which corresponds to an event topic name.
 
 ```typescript
 const pubSub = new PubSub();
@@ -44,7 +44,7 @@ export class AuthorResolver {
   // ...
   @Subscription(() => Comment)
   commentAdded() {
-    return pubSub.asyncIterator('commentAdded');
+    return pubSub.asyncIterableIterator('commentAdded');
   }
 }
 ```
@@ -68,7 +68,7 @@ Note that subscriptions, by definition, return an object with a single top level
   name: 'commentAdded',
 })
 subscribeToCommentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -111,7 +111,7 @@ To filter out specific events, set the `filter` property to a filter function. T
     payload.commentAdded.title === variables.title,
 })
 commentAdded(@Args('title') title: string) {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -124,7 +124,7 @@ To mutate the published event payload, set the `resolve` property to a function.
   resolve: value => value,
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -140,7 +140,7 @@ If you need to access injected providers (e.g., use an external service to valid
   }
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -154,7 +154,7 @@ The same construction works with filters:
   }
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -170,7 +170,7 @@ export class AuthorResolver {
   // ...
   @Subscription()
   commentAdded() {
-    return pubSub.asyncIterator('commentAdded');
+    return pubSub.asyncIterableIterator('commentAdded');
   }
 }
 ```
@@ -183,7 +183,7 @@ To filter out specific events based on context and arguments, set the `filter` p
     payload.commentAdded.title === variables.title,
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -194,7 +194,7 @@ To mutate the published payload, we can use a `resolve` function.
   resolve: value => value,
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -208,7 +208,7 @@ If you need to access injected providers (e.g., use an external service to valid
   }
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -222,7 +222,7 @@ The same construction works with filters:
   }
 })
 commentAdded() {
-  return pubSub.asyncIterator('commentAdded');
+  return pubSub.asyncIterableIterator('commentAdded');
 }
 ```
 
@@ -369,7 +369,7 @@ GraphQLModule.forRoot<MercuriusDriverConfig>({
 
 To create a subscription using the code first approach, we use the `@Subscription()` decorator (exported from the `@nestjs/graphql` package) and the `PubSub` class from the `mercurius` package, which provides a simple **publish/subscribe API**.
 
-The following subscription handler takes care of **subscribing** to an event by calling `PubSub#asyncIterator`. This method takes a single argument, the `triggerName`, which corresponds to an event topic name.
+The following subscription handler takes care of **subscribing** to an event by calling `PubSub#asyncIterableIterator`. This method takes a single argument, the `triggerName`, which corresponds to an event topic name.
 
 ```typescript
 @Resolver(() => Author)

content/techniques/queues.md

@@ -500,7 +500,7 @@ The `forRoot()` method is used to register a `bull` package configuration object
 - `limiter: RateLimiter` - Options to control the rate at which the queue's jobs are processed. See [RateLimiter](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queue) for more information. Optional.
 - `redis: RedisOpts` - Options to configure the Redis connection. See [RedisOpts](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queue) for more information. Optional.
 - `prefix: string` - Prefix for all queue keys. Optional.
-- `defaultJobOptions: JobOpts` - Options to control the default settings for new jobs. See [JobOpts](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queueadd) for more information. Optional.
+- `defaultJobOptions: JobOpts` - Options to control the default settings for new jobs. See [JobOpts](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queueadd) for more information. Optional. **Note: These do not take effect if you schedule jobs via a FlowProducer. See [bullmq#1034](https://github.com/taskforcesh/bullmq/issues/1034) for explanation.**
 - `settings: AdvancedSettings` - Advanced Queue configuration settings. These should usually not be changed. See [AdvancedSettings](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queue) for more information. Optional.
 
 All the options are optional, providing detailed control over queue behavior. These are passed directly to the Bull `Queue` constructor. Read more about these options [here](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queue).