[feat] Automatically provide context based on INQUIRER #533
Conversation
| @@ -55,7 +55,7 @@ describe('no context', () => { | |||
|
|
|||
| const ctrlLog = logs.find((v) => v.msg === msg); | |||
| expect(ctrlLog).toBeTruthy(); | |||
| expect(ctrlLog).not.toHaveProperty('context'); | |||
| expect(ctrlLog?.context).toEqual(TestController.name); | |||
There was a problem hiding this comment.
does this work only when using InjectPinoLogger? will it work for constructor(private logger: PinoLogger) {}? if yes let's add the test for this
There was a problem hiding this comment.
It won't work. Though, adding dependency on Inquirer to PinoLogger is possible.
There was a problem hiding this comment.
hm, let me think. In such case, we can get rid of this decorator, I believe in 95% it's called with the name of the class, so if we can add Inquirer to PinoLogger almost everyone can just drop decorator, and the rest who need to redefine context to different name will use .setContext.
So, in the current major we can add Inquirer to PinoLogger, after that deprecate the usage of @InjectPinoLogger. And drop it in the next major. This should simplify the API of this lib. So let's move this way.
So, what we need right now:
- add inquirer to PinoLogger, add/change test to 1) check that context is set automatically and 2) can be redefined in constructor.
- add warn log about deprecation of usage of decorator in
createDecoratedLoggerProviderfunction - add docs on this feature and a note that decorator is deprecated and context for
PinoLoggeris set automatically - change usage of decorator from
example/, and add the comment which value will be forcontextfield by default
@Ginden wdyt?
There was a problem hiding this comment.
That sounds like a great idea. <3
I will try to implement it when I have time.
There was a problem hiding this comment.
@iamolegga I think this approach is infeasible, because it breaks other things.
PinoLogger instances request by Loggers (either from @nestjs/common or src/Logger.ts) ends with context being Logger. There is no workaround for that, because it would require changing @nestjs/common.
There was a problem hiding this comment.
@Ginden let me check this in the next couple of weeks, maybe I could find any workaround, if not let's merge this as is
There was a problem hiding this comment.
@iamolegga maybe we can provide different logger classes for user-injected PinoLogger and for @nestjs/common (e.g. name it PinoLoggerAdapter)?
@Ginden what do you think?
There was a problem hiding this comment.
I'm not sure that I would like to extends codebase with one more class, this became a complex project already for just a logger.
If there is no easy way to implement this feature, maybe complex solution doesn't worth skipping one simple line of code this.logger.setContext(MyService.name)
There was a problem hiding this comment.
@iamolegga i think a good, easy to use and performant logger is a bit more complex than just a logger (see pino repo :) ) I'm willing to try to create dumb class class PinoLoggerInjected extends PinoLogger {} and try to inject that one to @nestjs/common.
|
Added docs. |
|
@iamolegga Any updates? |
|
@iamolegga any chance of this getting merged into the main project ? |
Resolves #532