What is the problem this feature would solve?

Me as all Elysia users will frequently need basic request/response logging for debugging, profiling, and production visibility.

• every project re-implements its own logger
• the implementations differ slightly (format, timing, status extraction, middleware hooks)
• many users rely on third-party loggers when they only need simple request logs
• newcomers expect logging out of the box like other frameworks (Hono, Express, Fastify)

imo this creates duplication, inconsistent patterns, and makes debugging harder for new users.
a built-in logger would standardize this essential functionality and improve the developer experience.

What is the feature you are proposing to solve the problem?

what if we introduce a first-class logger middleware built into Elysia, with the following capabilities:

• log HTTP method, path, status code, and response duration
• integrate cleanly with Elysia’s existing lifecycle (derive, onBeforeHandle, onAfterHandle, etc.)
• minimal performance overhead
• zero dependencies
• fully typed with Elysia’s typings

something simple. something that looks like this:

import { logger } from "elysia/logger"

const app = new Elysia()
  .use(logger())
  .get("/", () => "hello world")

What alternatives have you considered?

1. Using third-party logging libraries

These are useful for advanced logging, but overkill for simple request logs.
They also fragment the ecosystem and introduce additional dependencies.

2. Manually implementing logging in every project

This leads to copy-pasted logic, inconsistent timing measurements, and slightly different formatting across apps.

3. Adding logging only via plugins

Plugins solve part of the problem but don’t address the fact that logging is a core capability expected from a backend framework and should be discoverable out of the box.