The first time I learned about Nest I was really excited. Coming from Symfony/PHP world, it seemed a good way of starting switching to JavaScript. But now, after a few weeks, all the shining things about the DI, services, injections seems to "glue" not very well in Nest.
First it was https://github.com/nestjs/nest/issues/897 and now I'm facing another issue. Take the logger, everyone needs it. So you may end up creating a service, even a module providing MyLogger
:
// logger.module.ts
import { Global , Module } from '@nestjs/common';
@Global()
@Module({ })
export class LoggerModule {
static forRoot(options: LoggerModuleOptions): DynamicModule {
// This is a dynamic module which accept options and provide a configured
// instance of MyLogger. Options maybe further manipulated.
}
}
// mylogger.service.ts
export class MyLogger {
// Complex options...
constructor (options: LoggerOptions) { }
}
So far so good you inject MyLogger
pretty everywhere and you are happy.
But then you realize that when the application starts, messages from Nest are not logged using MyLogger
, of course, but you may change this behavior:
const app = await NestFactory.create(ApplicationModule, {
logger: new MyLogger(),
});
await app.listen(3000);
... the only problem here is I can't use DI! I can't use the already configure instance of MyLogger
, I should pass a fresh new object, duplicating all the options used to build it.
The problem is that the first console output (like [NestFactory] Starting Nest application...
) appears before even one module is initialized. Thus, we cannot use an instance of a provided logger, because, in fact, it doesn't exist yet.
However, I fully understand your concerns, and therefore in v5.2.0
you'll be able to use the following construction:
const app = await NestFactory.create(ApplicationModule, {
logger: false,
});
app.useLogger(app.get(LoggerService));
await app.listen(3000);
That will hide initial logs (like x dependencies initialized
) but for the rest of them (route mappings, caught exceptions, and so on), Nest will use your custom logger implementation.
@kamilmysliwiec thanks, waiting for 5.2 then!
5.2.0 is published!
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
The problem is that the first console output (like
[NestFactory] Starting Nest application...
) appears before even one module is initialized. Thus, we cannot use an instance of a provided logger, because, in fact, it doesn't exist yet.However, I fully understand your concerns, and therefore in
v5.2.0
you'll be able to use the following construction:That will hide initial logs (like
x dependencies initialized
) but for the rest of them (route mappings, caught exceptions, and so on), Nest will use your custom logger implementation.