Request: better logger middleware

[jansepke]

What is the feature you are proposing?

I would like to improve the logger middleware of hono. The current logger middleware is very basic and likely only intented for development purpose. For production application I would like to add a logger library (e.g. pino or winston) and was not able to find any or good middlewares for those.

I started to wrap pino-http (pino's express middleware) to make it work with hono (see PR pinojs/pino#2136) but it did not felt so nice. I would prefer a more native way of using a logging library together with hono.

So what do you think about adapting the existing logger middleware (backwards compatible) or creating a new logger middleware that is flexible enough to support any logging library and handles this features:

• providing a request bound logger instance on the context
• allow any logger library
• measures response times
• could log request/response details
• is used as the error handler
• (optional) integration with hono's request-id middleware

it could be used like this

import { Hono } from 'hono';
import { requestId } from 'hono/request-id';
import { pino } from 'pino';

const logger = pino();

const app = new Hono();
app.use(requestId());
app.use(loggerV2({
  createRequestLogger: (c) => logger.child({ requestId: c.var.requestId }),
  onRequest: (c) => c.var.logger.info({ userAgent: c.req.header('User-Agent') }, "request start"),
  onResponse: (c, responseTime) => c.var.logger.info({ responseTime }, "request end"),
}));

app.get('/', (c) => {
  c.var.logger.info('something');

  return c.text('Hello Node.js!');
});

Do you think something like this would be usefull or should every logger library build its own middleware for hono? I would also be intested to work on this feature.

[atoko]

I think there's the matter of context here, there are two things at play:

• Create a function that satisfies Hono<{ Variables: logger: ReturnType createRequestLogger }>
• Middleware hooks for before/after request

I think the first one is more useful, but when you consider the framework, it interacts in a lot of places with the client API. Take for example, nested routers. Remember that these are created with

import { Hono } from "hono";

app.route( new Hono() ) // I want to use the logger inside nested router, but if I use() the middleware, I'll have 2 logger instances :(

This is a contrived example, (I think the current approach is to merge the inner app context with the outer router, via typeof).

Hono context is still a new paradigm but with some more work it really could be great, IMO.

Just my unrelated 2 cents.