Sources

Custom framework integration

Build evlog support for an HTTP framework that doesn't ship a built-in integration — Medusa, AdonisJS, h3 directly, custom dispatchers, queue workers.

When the framework you use doesn't have an evlog/<framework> package yet, you build the integration yourself. evlog ships a small toolkit (createMiddlewareLogger, defineFrameworkIntegration) that handles the request-context plumbing — you only write the framework-specific glue.

Canonical guide

The complete walkthrough lives in Custom integration:

The mental model (request lifecycle → logger creation → enrich → drain)
defineFrameworkIntegration() to declaratively wire request extraction and logger attachment
createMiddlewareLogger() for the imperative path
A worked example for a hypothetical framework

This page exists in the build-on-top section as a pointer — it's the same content, just classified by axis.

When you're really off the rails

If you're integrating a non-HTTP runtime (queue worker, CLI driver, cron job, durable execution engine), see Middleware toolkit for the lower-level primitives.

Going further

Once your integration is solid, package it as an npm library so the next person hitting the same framework doesn't have to re-do the work.

Edit this pageorReport an issue

Overview

Sources are how events enter the evlog pipeline — framework integrations, custom middleware, ingest endpoints. Where to extend when you support a new runtime.

Middleware toolkit

createMiddlewareLogger and the lower-level primitives — for non-HTTP runtimes (queue workers, CLIs, durable engines) or when defineFrameworkIntegration is too declarative for your case.