DEV Community: Micael Levi L. C.

NestJS tip: how to run operations when the HTTP server is ready

Micael Levi L. C. — Fri, 15 Nov 2024 19:27:32 +0000

Let's say you want to perform few tasks right after your HTTP server is ready to handle connections. Starting from @nestjs/core v10.4.8, you can now do this in a idiomatic way like the following:

// app.module.ts
import { Module } from '@nestjs/common';
import { HttpAdapterHost } from '@nestjs/core';

@Module({})
export class AppModule {
  constructor(readonly httpAdapterHost: HttpAdapterHost) {
    httpAdapterHost.listen$.subscribe({
      complete: () => this.onHttpServerListening(),
    });
  }

  async onHttpServerListening(): Promise<void> {
    console.info('HTTP server is listening');
  }
}

That console.info statement will be called after app.listen() succeeds. If the onHttpServerListening throw any error, the application will crash due to that!

You can read more about this feature here: https://docs.nestjs.com/faq/http-adapter#listening-event

NestJS tip: how to attach decorators to all controllers at once

Micael Levi L. C. — Sun, 29 Sep 2024 19:11:12 +0000

What

In the official NestJS integration with OpenAPI (formerly Swagger) @nestjs/swagger we have a bunch of @Api* decorator factories such as @ApiBearerAuth().

Due to how TypeScript decorators works, you cannot bind those class decorators globally -- ie., for all the controllers that your entry module has discovered -- at once.

But using the built-in provider DiscoveryService (from @nestjs/core package exported by the DiscoveryModule NestJS module) we can do that!

DISCLAIMER: I'm not saying that this is good. I don't like the ideia of not having those decorators close to the controller.

How

For this demo, our controller will be as simple as this:

app.controller.ts

import { Controller, Get } from '@nestjs/common'

@Controller()
export class AppController { // No Api* decorators here!
  @Get()
  hello() {
    return 'Hello, World!'
  }
}

Our entry module would look like this:

app.module.ts

import { Module } from '@nestjs/common'
import { DiscoveryModule } from '@nestjs/core'
import { AppController } from './app.controller'

@Module({
  imports: [
    DiscoveryModule, // We'll use DiscoveryService later
  ],
  controllers: [
    AppController,
  ],
})
export class AppModule {}

And our entry file would look like this:

main.ts

import { DiscoveryService, NestFactory } from '@nestjs/core'
import { AppModule } from './app.module'
import { ApiBearerAuth, DocumentBuilder, SwaggerModule } from '@nestjs/swagger'

async function bootstrap() {
  const app = await NestFactory.create(AppModule)

  const makeDocument = () => {
    const discoveryService = app.get(DiscoveryService)
    const controllers = discoveryService.getControllers()
    for (const controller of controllers) {
      // All the ApiX decorators that you want to bind globally
      ApiBearerAuth()(controller.metatype) // (LA)
    }

    const config = new DocumentBuilder()
      .setTitle('Cats example')
      .build()
    return SwaggerModule.createDocument(app, config) // (LB)
  }

  SwaggerModule.setup('/api', app, makeDocument) // (LC)

  await app.listen(3000) // (LD)
}
bootstrap()

Why this works

The SwaggerModule.createDocument is responsible to compose the OpenAPI spec. and will be invoked by SwaggerModule.setup when this object is needed. In our case we are supplying a factory that returns the document, not the document itself. This is important!

Also, we must call SwaggerModule.setup before app.listen/app.init because this one is responsible to add a new route (the /api in this example) that exposes the OpenAPI spec. and the Swagger UI.

In order to enhance all the controllers with @Api* decorators, we must run the code at (LA) line before (LB).

Due to the lazy loading mode of SwaggerModule.setup when calling our makeDocument factory, everything will work as we want:

SwaggerModule.setup is being called before app.listen
SwaggerModule.createDocument is being called after our custom enhancement of all the controllers found from AppModule (including child modules); thus, after line (LA)

At http://localhost:3000/api we could see this:

To be fair, we don't need to rely on the lazy loading mode of SwaggerModule.setup as long as we call (LA) before SwaggerModule.createDocument, but I prefer this approach to avoid impacting the bootstrapping time.

Of course that you can find alternatives approaches such as relying on the on module init lifecycle hook instead of having to use the app inside the makeDocument factory function.

NestJS tip: how to use Node.js built-in .env file reader with NestJS CLI

Micael Levi L. C. — Tue, 14 May 2024 18:52:43 +0000

Starting from Node.js v20.6.0 you can read dot env files into the process.env object using the --env-file=path nodejs option.

If you're using NestJS's CLI (@nestjs/cli package) you can turn on that Node.js option in two ways:

nest start --exec "node --env-file=.env"
For NestJS v11 or above: nest start --env-file .env

NestJS tip: how to change HTTP server timeouts

Micael Levi L. C. — Sun, 07 Apr 2024 00:00:40 +0000

What

If you don't know what those HTTP timeouts are, I recommend you to read the following articles:

How

When using the NestJS framework, sometimes you may need to change some default timeout. You can define them just like you'd do in a plain Node.js HTTP server like so:

import * as http from 'http'
import { NestFactory } from '@nestjs/core'
// import { FastifyAdapter  } from '@nestjs/platform-fastify'
import { AppModule } from './app.module'

async function bootstrap() {
  const app = await NestFactory.create(AppModule)
  // const app = await NestFactory.create(AppModule, new FastifyAdapter())

  const server = app.getHttpServer()

  console.log(server instanceof http.Server) // true

  // The timeout value for sockets
  server.setTimeout(2 * 60 * 1000)
  // The number of milliseconds of inactivity a server needs to wait for additional incoming data
  server.keepAliveTimeout = 30000
  // Limit the amount of time the parser will wait to receive the complete HTTP headers
  server.headersTimeout = 31000

  await app.listen(3000)
}
bootstrap()

That's all!

Here you can find all the docs about the http.server we used above:

NestJS tip: how to inject the native logger as any other provider

Micael Levi L. C. — Mon, 01 Jan 2024 17:37:38 +0000

for NestJS v8, v9, v10, v11

Why?

The Logger class from @nestjs/common is not a built-in provider. So we can't do this:

import { Module, Logger } from '@nestjs/common'

@Module({})
export class AppModule {
  constructor(private readonly logger: Logger) {}

  onModuleInit() {
    this.logger.debug('hi')
  }
}

So we should initialize that class by ourselves. This is good because we can define the context that the logger will have:

// ...
export class AppModule {
  private readonly logger = new Logger(AppModule.name)

  onModuleInit() {
    this.logger.debug('hi')
  }
}

but this is bad because we are not relying on DI (Dependency Injection) as we do for others native classes in our NestJS app, which looks a bit hacky. Also, if we want to ignore or change the behavior of that logger in some test suite, it would be harder than simply using the auto mocking feature from @nestjs/testing or using any other idiomatic approach.

What?

Now we can inject the Logger class as any other provider, like this:

import { Module, Logger, Scope, Inject } from '@nestjs/common'
import { INQUIRER } from '@nestjs/core'

@Module({
  providers: [
    {// Register this provider in the module that you want to inject the logger
      provide: Logger,
      scope: Scope.TRANSIENT,
      inject: [INQUIRER],
      useFactory: (parentClass: object) => new Logger(parentClass.constructor.name),
    }
  ],
})
export class AppModule {
  @Inject()
  private readonly logger: Logger

  // or via constructor-based injection
  //constructor(private readonly logger: Logger) {}

  onModuleInit() {
    this.logger.debug('hi')
  }
}

How?

In order to make that possible, we will have a new factory provider using the transient scope and the INQUIRER native provider.

As per the docs:

Transient providers are not shared across consumers. Each consumer that injects a transient provider will receive a new, dedicated instance.

It means a new instance of the Logger class will be created every time they are injected somewhere, instead of being a singleton as usual. This is good because we can then inject the INQUIRER provider (from @nestjs/core) into that factory provider.

The value of INQUIRER provider will be the class where a provider was constructed. So we can use that value to define the logger context (ie., the first argument on new Logger constructor).

And that's how we can move the initialization of the Logger class to the module definition instead of having them polluting our providers.

NestJS tip: how to inject multiple versions of the same provider into one module (e.g.: many Axios instances)

Micael Levi L. C. — Sun, 09 Jul 2023 23:23:12 +0000

for NestJS v8, v9, v10, v11

What?

Let's say you want to use multiple "versions" of the same NestJS provider that is created by a 3rd-party lib that you don't control.

For example, when using the HttpModule module from @nestjs/axios we can use the dynamic module HttpModule.register() to configure our Axios instance. That module exposes a HttpService that has such configuration. But what if we want to have many Axios instances, each one with its own config and import everything in one module?

We can't do the following because there's no way to distinguish between the two HttpService providers registered since they live under the same injection token, the class reference HttpService, although we have two instances of that HttpService class:

@Module({
  imports: [
    HttpModule.register({
      baseURL: 'https://api.example.com',
    }),
    HttpModule.register({
      baseURL: 'https://api.another.example.com',
    }),
  ],
})
export class AppModule {
  constructor(
    private readonly httpService: HttpService,
  ) {
    console.log(this.httpService.axiosRef.defaults.baseURL) // https://api.example.com
  }
}

The only idiomatic way to achieve that AFIAK is by creating a wrapper module for each configuration. That module will import HttpModule.register() and expose the HttpService provider via another injection token, so we could inject that provider along with others instances of HttpService as usual.

How?

Like this:

app.module.ts -- we want to inject multiple HTTP services here

import { Module } from '@nestjs/common'
import { CatApiModule, CatApiHttpService } from './cat-api'

@Module({
  imports: [
    CatApiModule,
    DogApiModule,
  ],
})
export class AppModule {
  constructor(
    private catApi: CatApiHttpService,
    private dogApi: DogApiHttpService,
  ) {}
}

cat-api.module.ts -- our wrapper module. Responsible for creating a HTTP service client for the cats API

import { Module, OnModuleInit } from '@nestjs/common'
import { HttpModule, HttpService } from '@nestjs/axios'
import { CatApiHttpService } from './cat-api-http.service'

@Module({
  imports: [
    HttpModule.register({ // line A
      timeout: 1000,
      maxRedirects: 2,
      baseURL: 'https://http.cat',
    }),
  ],
  providers: [
    {
      provide: CatApiHttpService,
      useExisting: HttpService, // line B
    }
  ],
  exports: [CatApiHttpService], // line C
})
export class CatApiModule implements OnModuleInit {
  constructor(private readonly httpService: HttpService) {}

  // Defining others configuration for our Axios instance
  onModuleInit() {
    this.httpService.axiosRef.defaults.headers.common['Accept'] = 'application/json'
  }
}

cat-api-http.service.ts -- the interface on which consumers of CatApiModule will rely on. The implementation itself is up to HttpService

import { HttpService } from '@nestjs/axios'

export abstract class CatApiHttpService extends HttpService {}

The DogApiHttpService one would follow the same pattern as shown above.

How it works

When importing the dynamic module HttpModule.register() (line A), we'll have the HttpService provider available to use in the CatApiModule module.

Since we don't want to expose that provider with the same injection token due to posible name collisions, we can leverage on the useExisting alias provider (line B) to tell to NestJS that we now have 2 providers, one is just an alias to the other.

Then we are exposing the CatApiHttpService token instead of HttpService as a proxy to consume the HttpService provider (line C).

You can see that CatApiHttpService is an abstract class (a TypeScript feature). This is a way to tell to developers that that class isn't supposed to be initialized. Also, we are using concrete classes here to avoid using the @Inject() utility while injecting the HttpService.

NestJS tip: fine-grained exception filtering for the same exception class!

Micael Levi L. C. — Sat, 17 Jun 2023 21:08:35 +0000

for NestJS v8, v9, v10, v11

What

We can now have multiple exception filters for the same error class like this:

class MongoDbDuplicatedKeyConstraintErrorToCatch {
  static [Symbol.hasInstance](instance: unknown): boolean {
    // Any condition here:
    return instance instanceof MongoError && instance.code === 11000
  }
}

// This only catches `MongoError` errors that has the error code '11000'
@Catch(MongoDbDuplicatedKeyConstraintErrorToCatch)
export class MongoDbDuplicatedKeyConstraintFilter implements ExceptionFilter {
  catch(exception: MongoError, host: ArgumentsHost) {
    // Your exception handler code here ...
  }
}

or using the nestjs-conditional-exception-filter package to make it generic:

import { Catch, ExceptionFilter } from '@nestjs/common'
import { filter } from 'nestjs-conditional-exception-filter'

@Catch(
  filter({
    for: MongoError,
    when: error => error.code === 11000,
  })
)
export class MongoDbDuplicatedKeyConstraintFilter implements ExceptionFilter {
  catch(exception: MongoError, host: ArgumentsHost) {
    // Your exception handler code here ...
  }
}

I don't know about you but I'd rather use the above approach than the following one:

Why

Let's say you want to handle exceptions raised by some 3rd-party package but such exceptions are somewhat too generic, they use the same error class to represent different errors.

A real world example would be the QueryFailedError from typeorm, or MongoError from mongodb package. Both of them are wrappers. The error object may have some discriminated field that holds the underlying platform error code.

We could use exception filters from @nestjs/common to handle them but such abstraction doesn't allows us to conditionally catch the exception. This missing feature was requested in 2020 here: https://github.com/nestjs/nest/issues/4516 and in 2023 here: https://discord.com/channels/520622812742811698/1085108578257489970/1085108578257489970 (and few other times)

Thus if we want to handle some specific error raised by mongodb lib, we would have to catch all objects that are instance of MongoError to later conditionally treat it, like this:

@Catch(MongoError)
export class MongoErrorFilter extends BaseExceptionFilter {
  catch(exception: MongoError, host: ArgumentsHost) {
    if (exception.code === 11000) {
      // Your exception handling code here ...
    } else {
      return super.catch(exception, host)
    }
  }
}

Imagine how fast that code would grow when you starting handling others error codes for the same MongoError exception. And how confusing it will look like since it violates the Single Responsibility Principle and the Open-Closed Principle.

Of course that you could split the code into several files and use the Strategy design pattern but you could also follow that other approach I just showed you here. Keep reading to understand how that works.

How

Under the hood, NestJS will look up for the exception filter that, for a given exception raised from your app, matches the following condition: exception instanceof ExceptionMetaType (here's the code)

Knowing that, we can use the well-known JavaScript symbol Symbol.hasInstance to create a class that will act like a 'attribute-based exception filter' that Nest will invoked later:

class FooError {
  static [Symbol.hasInstance](instance: any) {
    // Any condition here:
    return typeof instance.bar !== 'undefined'
  }
}

to later use that as the error being caught by our exception filter like so:

import { Catch, ExceptionFilter } from '@nestjs/common'

@Catch(FooError)
export class MyFooErrorFilter implements ExceptionFilter {
  catch(exception, host) {
    // ...
  }
}

now, for that FooError, any error raised with a field bar in it will be caught by our exception filter. If the error does not meet this condition, another filter could catch it, as usual.

NestJS tip: how to disable initialization logging

Micael Levi L. C. — Fri, 09 Jun 2023 00:44:17 +0000

for NestJS v8, v9, v10, v11

For big NestJS apps we might see a bunch of initialization logs like the following:

In some environments those messages are nothing but noise to the log management tool. Note that I'm referring to those emitted with the .log method of the built-in Logger class from @nestjs/common

By following the nestjs docs on Logger: https://docs.nestjs.com/techniques/logger we can find out on how to omit such logs, as follows:

Create a custom logger that inherits from the built-in ConsoleLogger and declare that it will do nothing if the supplied context is a internal one (ie, from @nestjs/core)

// ...
import { ConsoleLogger } from '@nestjs/common'

/**
 * A custom logger that disables all logs emitted by calling `log` method if
 * they use one of the following contexts:
 * - `InstanceLoader`
 * - `RoutesResolver`
 * - `RouterExplorer`
 * - `NestFactory`
 */
export class InternalDisabledLogger extends ConsoleLogger {
  static contextsToIgnore = [
    'InstanceLoader',
    'RoutesResolver',
    'RouterExplorer',
    'NestFactory', // I prefer not including this one
  ]

  log(_: any, context?: string): void {
    if (!InternalDisabledLogger.contextsToIgnore.includes(context)) {
      super.log.apply(this, arguments)
    }
  }
}

Then, at your bootstrap function, use that logger instead

// ...
const app = await NestFactory.create(AppModule, {
  logger: new InternalDisabledLogger(),
})

NestJS tip: type safety on parameter decorators

Micael Levi L. C. — Sat, 20 May 2023 16:52:14 +0000

for NestJS v8, v9, v10, v11

In NestJS we can create specialized kind of parameters decorators using the createParamDecorator function from @nestjs/common. For example:

import { createParamDecorator, ExecutionContext } from '@nestjs/common'

export const CurrentUser = createParamDecorator<
  keyof User | undefined, // the type of `data`
  ExecutionContext, // the type of `ctx`
>(
  (data, ctx) => {
    const request = ctx.switchToHttp().getRequest()
    const user = request.user
    return typeof data === 'undefined'
      ? user[data]
      : user
  }
)

And then you can use that CurrentUser parameter decorator later in controller class's method, as follows:

// ...
@Get()
getCurrentUser(
  @CurrentUser() user: User,
  @CurrentUser('name') username: string,
) {
  return { user, username }
}

The issue

If your project has a bunch of those decorators, it might be hard to know what would be the type of their resolved values, right? I mean, how do you know that @CurrentUser() is a "bind" for request.user without some documentation or by reading the source? Also, what is the type of that request.user? Due to how TypeScript legacy decorators works, there's no way to typescript compiler infer some type from such param decorator.

My solution

You could see in my other article that I've leverage on TypeScript declaration merging feature like this:

Along with generics, we can now easily couple the decorator with "its" type.

We just need to declare and export a type alias with the same name of our param decorator. See:

import { createParamDecorator, ExecutionContext } from '@nestjs/common'

export const CurrentUser = createParamDecorator<
  keyof User | undefined, // the type of `data`
  ExecutionContext, // the type of `ctx`
>(
  (data, ctx) => {
    const request = ctx.switchToHttp().getRequest()
    const user = request.user
    return typeof data === 'undefined'
      ? user[data]
      : user
  }
)

// -------- THIS IS NEW:
export type CurrentUser<Prop extends keyof User | undefined = undefined> =
  Prop extends keyof User ? User[Prop] : User

@Get()
getCurrentUser(
  @CurrentUser() user: CurrentUser,
  @CurrentUser('name') username: CurrentUser<'name'>
) {
  return { user, username }
}

Advantages

The ones I've seen so far:

No one needs to recall what is the expected type of the resolved value by those parameters decorators. Just use the same name of the decorator.
One source of truth of the expected type of such param decorator. If we change the implementation of that decorator in the future (and also the type of the returned object), we won't have to touch other parts of our codebase (unless we got some breaking change, of course).
No need to import multiple types just for the sake of type safety.

Disadvantages

The ones I've seen so far:

I didn't see this pattern often in the wild, so I won't expect it to be intuitive.
If you use some pipe like this: @CurrentUser(MyPipe) somethingElse: any, that somethingElse parameter might not have the CurrentUser type anymore. So this pattern is restrict to those decorators that are not meant to use with pipes.
User type is clear than CurrentUser one if you are familiar with User entity already. Thus, by reading the code outside of some code editor, it migth be a bit hard to find what that CurrentUser mean. But I think that this is just a matter of getting used of.

Enable/disable NestJS devtools integration without changing your code!

Micael Levi L. C. — Sat, 11 Mar 2023 22:24:12 +0000

Don't know what NestJS Devtools is? check this out: Introduction to NestJS Devtools with Kamil Mysliwiec

What?

You can use the devtools integration without changing anything in your code! Just use the package nestjs-devtools-loader like this:

npm i --save-dev @nestjs/devtools-integration nestjs-devtools-loader
#      ^^^ No need to pollute the production environment

## then:
nest start --watch --exec "node -r nestjs-devtools-loader/register"
## or:
export NODE_OPTIONS="-r nestjs-devtools-loader/register"
nest start --watch

That's all! Now go to https://devtools.nestjs.com (port 8000) as usual :)

Why?

In order to enable the Devtools integration, we are supposed to make the following changes to our source code:

1) Enable the snapshot generation:

// ...
const app = await NestFactory.create(AppModule, {
  snapshot: true,
})

2) Import the DevtoolsModule dynamic module into the root module:

@Module({
  imports: [
    DevtoolsModule.register({
      http: process.env.NODE_ENV !== 'production',
    }),
  ],
  // ...
})
export class AppModule {}

To me, this is too intrusive since most of the time I won't use the devtools. Also, I believe that having snapshot always enabled will affect the bootstrapping time (so we should use process.env.NODE_ENV !== 'production' in there as well).

How?

Instead, we can leveraging on monkey patching and on the --require (or -r) Node's CLI option to perform those changes for us only when we need.

Now I have one npm-script that will start the app with devtools integration enabled thanks to nestjs-devtools-loader package! Note that that package allows us to define the arguments of DevtoolsModule.register() call.

Check out the full code here: https://github.com/micalevisk/nestjs-devtools-loader/blob/main/lib/loader.js#L43

NestJS tip: multi-value providers almost like `multi` from Angular

Micael Levi L. C. — Sun, 05 Feb 2023 17:17:13 +0000

for NestJS v8, v9, v10, v11

You can see and play with the full code here.

Angular's dependency injection mechanism has a feature called Multi Providers, which looks like this:

// =============== Angular code  =============== //
import { Component, InjectionToken, Inject } from '@angular/core'
const TOKEN = new InjectionToken<string>('MyToken')
@Component({
  // ...
  providers: [
    { provide: TOKEN, useValue: 'foo', multi: true },
    { provide: TOKEN, useValue: 'bar', multi: true },
  ],
})
class AppComponent {
  constructor(@Inject(TOKEN) public myValues: string[]) {
    console.log(myValues) // outputs ["foo", "bar"]
  }
}

NestJS doesn't come with that capability but we can implement it (kinda).

The final version I'm proposing here looks like this:

we have a factory function called provide that receives an array of 'enhanced' providers and return providers array but registering all providers with the same token under a multi-value provider as long as it has multi: true.

Disclaimer

The solution I'm about to show is intended to be as simple as possible, thus it doesn't work exactly like multi providers from Angular. I encourage you to use this mental model to build a better solution :)

Known limitations:

Only merges providers registered within the same module
Does not validate if there is a multi provider with the same token as one non-multi
Does not take in count providers with scopes other than the default (singleton lifestyle). I didn't tested such scenario
Dependency not found errors may look a bit cryptic now due to how the provider is being registered under the hood
Not work with forwardRef, but it should be feasible to have
as mentioned in the comments of this post, you cannot use this when sharing the same provider token for multiple modules

Problem

NestJS providers consists of two main parts: a value and a unique token. We can see that with custom providers, which are just objects that have the properties provide (provider's token) and some value that will be defined based on which kind of provider you got (namely: useClass, useExisting, useValue or useFactory). You can learn more on this subject here.

To retrieve some provider NestJS's DI system uses its token (in a given context). So although we can declare multiple providers with the same token, only the latest one will be returned when we inject that provider into others providers.

We want to register multiple providers under the same token, and we should have an easy API for this. When retrieving that provider, we should get an array of values.

Solution

Leverage on multi: true API from Angular and implement one version of that feature by using the useFactory custom provider as suggested by Kamil here.

The overall ideia here is:

Group all providers marked with multi: true by their common token
For each provider in that group, register it using some unique token to avoid naming collisions. And save this token in that group for later usage
For each entry in that group, register a new provider with useFactory that injects all of the collected providers at step (2) and return an array of them

I'll do only 2 iterations for performance sake: one to collect and save multi-value providers while registering non-multi ones, as usual; and other to create the final factory provider for each group.

The provide helper function is defined as follows:

// provide.util.ts
import type {
  Type,
  ClassProvider,
  ValueProvider,
  FactoryProvider,
  ExistingProvider,
  Provider,
  InjectionToken,
} from "@nestjs/common"

type EnhancedProvider<T = any> =
  Type<T>
| ((
    ClassProvider<T> |
    ValueProvider<T> |
    FactoryProvider<T> |
    ExistingProvider<T>
  ) & { multi?: true })

export function provide(providers: EnhancedProvider[]): Provider[] {
  /** The final providers list that we should pass to some module. */
  const providersToRegister: Provider[] = []
  /** A map with all multi-value providers with their common token. */
  const multiValueProviderTokensByGroupToken = new Map<InjectionToken, InjectionToken[]>()

  for (const provider of providers) {
    if ('multi' in provider && provider.multi) {
      const currProviderToken = provider.provide

      const providerTokens = multiValueProviderTokensByGroupToken.get(currProviderToken) || []

      // Create a unique token for this provider so that it can be injected later
      const uniqueToken: InjectionToken = `multi-provider at idx ${providerTokens.length + 1} with token ${currProviderToken.toString()}`
      providerTokens.push(uniqueToken)
      multiValueProviderTokensByGroupToken.set(currProviderToken, providerTokens)

      // Register the provider but using the unique token instead
      providersToRegister.push({
        ...provider,
        provide: uniqueToken,
      })
    } else {
      // Non-multi provider, so just register it as-is
      providersToRegister.push(provider)
    }
  }

  for (const [providerGroupToken, tokensToInject] of multiValueProviderTokensByGroupToken) {
      providersToRegister.push({
      provide: providerGroupToken,
      inject: tokensToInject,
      useFactory: (...providers) => providers,
    })
  }

  return providersToRegister
}

NestJS tip: how to always use your custom logger

Micael Levi L. C. — Sun, 15 Jan 2023 18:22:36 +0000

TL;DR

for NestJS v8, v9, v10, v11

Since we always want to use our own logger instead of falling back to Nest's native logger in case of initialization errors, you'll need to create the logger instance outside of your root module like this:

// ...
async function createLogger() {
  @Module({
    imports: [LoggerModule.forRoot()],
  })
  class TempModule {}

  const tempApp = await NestFactory.createApplicationContext(TempModule, {
    logger: false,
    abortOnError: false,
  })
  await tempApp.close()
  return tempApp.get(Logger)
}

async function bootstrap() {
  const app = await NestFactory.create(AppModule, {
    logger: await createLogger(),
  })
  // ...
  await app.listen(3000)
}

Odd behavior for custom loggers that are defined too late

When we replace Nest's native logger with another one (like nestjs-pino), we might still could face log messages that uses the native one due to some error on creating the application!

Check this out:

import { Module } from '@nestjs/common'
import { NestFactory } from '@nestjs/core'
import { Logger, LoggerModule } from 'nestjs-pino'

@Module({
  imports: [LoggerModule.forRoot()],
})
export class AppModule {
  // This will cause a 'provider not found' error
  constructor(private foo: number) {} 

  onModuleInit() {
    console.log('This will not be invoked due to the initialization error!')
  }
}


async function bootstrap() {
  const app = await NestFactory.create(AppModule, {
    bufferLogs: true, // So we could hijack our own logger
  })
  app.useLogger( app.get(Logger) ) // (A)
  await app.listen(3000)
}
bootstrap()

As you can see above, although we're using our own logger (line (A)), since we got an initilization error, ie., the app couldn't be created due to some error while resolving its modules, the error log still uses the native logger.

When the app do start with success, the output would look like this:

How to always use our custom logger

To fix that, we should supply our custom logger to the logger option of NestFactory.create. The limitation here is that that option requires an instance of the logger, see:

In order to create that instance using NestJS DI container, we'll use NestFactory.createApplicationContext method. Its has the same interface as the NestFactory.create method but it only returns the app context instead of the whole app itself, then it will take less steps to finish its job.

The root (or 'entry') module should be minimal as possible. In this example it will only import the module that creates the logger itself. I will use the nestjs-pino because Pino is an amazing logger lib.

Let's say we have the following AppModule:

import { Module } from '@nestjs/common'
import { LoggerModule } from 'nestjs-pino'

@Module({
  imports: [LoggerModule.forRoot()],
})
export class AppModule {}

1) Add a function that will start and return the logger instance created by NestJS DI system:

// ...
import { Logger, LoggerModule } from 'nestjs-pino'

async function createLogger(): Promise<Logger> {
  @Module({
    imports: [LoggerModule.forRoot()],
    //        ^ Make sure you're using the same logger config
    //          that you've used in your AppModule
  })
  class TempModule {}

  const tempApp = await NestFactory.createApplicationContext(TempModule, {
    // Disable the native logger entirely
    // to avoid falling back to the initial problem
    logger: false,
    // thus we must not crash the app on errors at TempModule
    // initialization, otherwise we won't see any error messages
    abortOnError: false,
  })
  await tempApp.close()
  return tempApp.get(Logger) // retrieve the created instance
}

2) Supply that logger instance to NestFactory.create:

async function bootstrap() {
  const app = await NestFactory.create(AppModule, {
    logger: await createLogger(),
  })

  await app.listen(3000)
}
bootstrap()

now there's no need to buffer logs (which is good for memory consumption btw), and no need to call app.useLogger too!

Now my app's initialization errors would look like this:

or, with pino-pretty: