evlog vs other loggers
Choose a logger around the code and delivery pipeline you want to maintain. evlog combines individual structured logs with accumulated request events, structured errors, plugins, and drain adapters. Other libraries provide different configuration and extension models that may already fit your application.
Choose the comparison for your stack
| You need to decide about | Start here | Evaluate before migrating |
|---|---|---|
| Pino JSON logging | evlog vs Pino | Child bindings, serializers, custom levels, worker transports, existing HTTP logging |
| Winston formats and transports | evlog vs Winston | Format composition, per-transport levels, custom transports, exception handling |
| Consola in Nuxt, Nitro, or a CLI | evlog vs Consola | Reporters, terminal interaction, output formatting, request context |
| LogTape in a library or application | evlog vs LogTape | Consumer-owned configuration, categories, explicit and implicit context, testing |
| An existing OpenTelemetry Collector | evlog and OpenTelemetry | OTLP logs, active span correlation, separate sampling policies |
What adopting evlog changes
For an accumulated event, application code calls set() as work progresses and emits at the end. Wide Events explains that lifecycle. Other loggers can also receive one completed object, so the difference is which accumulation and lifecycle code the library supplies.
The global API handles individual messages. Its signatures do not make evlog a drop-in replacement for Pino, Winston, or Consola. Review call sites and output envelopes using Simple Logging.
Check the constraints
| Concern | evlog contract |
|---|---|
| Severity | Four levels: debug, info, warn, error |
| Filtering | Global minLevel for individual logs, sampling for wide events |
| Extensibility | Plugins, enrichers, and drains. Pino serializers and Winston formats need an explicit port. |
| Redaction | Configured paths and recognized patterns, enabled by default in production. Not a guarantee that all personal data is identified. |
| Delivery | Choose an adapter and its pipeline configuration, then handle pending delivery in the runtime you deploy. |
| Testing | Capture emitted events with the memory drain and assert required fields. |
Keeping an existing logger is reasonable when its integrations already satisfy your requirements. If you migrate, first preserve the fields used by dashboards and alerts, then verify success, failure, and shutdown behavior.
Compare costs on the same workload
The Performance reference describes the repository's unequal output configurations and the limits of its historical comparisons. Do not turn those measurements into a general ranking of loggers.
For deployment, choose a drain adapter. For a script or library without framework lifecycle management, follow Standalone TypeScript.