✅ Other logger library

[bobgubko]

Is there a way or whether you planning to add support for using other logger library than winston? First thing I learned about winston is their core issues which are pinned in their issues. Also initially I used pino logger but had to switch to winston because I haven't found a way to make it work with express-zod-api.

[RobinTail]

I didn't think about it yet.
To me winston looks a pretty solid solution having a large community and it's widely used, which made it possible to discover the issues you mentioned and promising that most likely they will be fixed.
However, I agree that it can be challenging to configure it right.
Technically, express-zod-api could support any logger complying the type:

type AbstractLogger = Record<
  "info" | "warn" | "debug" | "error",
  (message: string, meta?: any) => any
>

However, it might be a breaking change to the CommonConfig in order to do that without keeping winston a required peer dependency.

I need to think on it. Thanks for idea, @bobgubko

[RobinTail]

I think I found a way, @bobgubko
Check this out:
#1314

Let me know what you think

[bobgubko]

That looks good to me overall. I'm not sure whether logger arguments should be limited to message: string, meta?: any. Wouldn't it make more sense to make it ...msgs: any[]?

One more question regarding the logger. Is it possible in existing implementation to use child feature of winston / pino loggers?

[RobinTail]

I'm not sure whether logger arguments should be limited to message: string, meta?: any. Wouldn't it make more sense to make it ...msgs: any[]?

The narrow type of the arguments message: string, meta?: any is the abstract type which actual logger extends from.
The loose type ...msgs: any[] you mentioned is compatible with it, because it extends it, allowing first argument to be string and optional second argument to be any.
Basically it means, that any logger that supports at least this form of arguments is acceptable.
The narrow type I specified is actually one of the overloads from winston which is being used within the library, that's why it needs it to operate.

Check out this example, @bobgubko :

I use the loose type you mentioned and assign it to in config — and it works.

[RobinTail]

Is it possible in existing implementation to use child feature of winston / pino loggers?

As long as your implementation is aware of the actual logger you can use every feature that this logger provides.
I made it possible to make Endpoint's handler to be aware of actual logger type, when config is supplied upon creating EndpointsFactory.

I didn't make the same for the handlers of Middleware and ResultHandler, so they provide logger typed as AbstractLogger (having only 4 methods). But you can override its type using as winston.Logger syntax (or similar) if needed.

Will that work for you, @bobgubko ?

[bobgubko]

That's not what I meant about the child feature. I was thinking about something that allows to create child logger instance for each request so I have requestId automatically added for each log entry. Basically call logger.child({ requestId: Date.now().toString(36) }) before each incoming request and use returned logger in middlewares chain. I hope my explanation makes sense

[RobinTail]

You can make a middleware that return { childLogger: logger.child() } and then take childLogger from options argument of Endpoint's handler, @bobgubko

[bobgubko]

Ah right. That works. Thanks!

[RobinTail]

Ah right. That works. Thanks!

Great. Knowing that (how to pass over the childLogger having winston), would you still need the pino logger instead of it, @bobgubko ?

[bobgubko]

Yea, eventually I'll switch to pino I think. Having AbstractLogger is a nice-to-have feature IMO.

[RobinTail]

Dear @bobgubko ,

I'd like to inform you that after a series of some serious considerations and revisions of the general concept,
I decided to simplify the approach on informing consumer methods on the type of the actual logger used.

For that purpose I'm going to offer module augmentation technique, which, however, turned out to be very robust and for your case will work even better. Here is an example:

import pino, { Logger } from "pino";
import { createConfig } from "express-zod-api";

const logger = pino({
  transport: {
    target: "pino-pretty",
    options: { colorize: true },
  },
});
const config = createConfig({ logger });

// Setting the type of logger used
declare module "express-zod-api" {
  interface LoggerOverrides extends Logger {}
}

When you set the LoggerOverrides that way, AbstractLogger type will be extended and provide you with all methods of the chosen logger in every place of your code.

All that I'm going to introduce in v15 in december.

[bobgubko]

Looks good. Thank you!

[RobinTail]

@bobgubko , I'm glad to inform you that the feature is now available for you in recently released version 15.

[bobgubko]

Thanks! I'll check it out