Pino

Pino is a structured JSON logger for Node.js built around a single goal: log as fast as possible without slowing down the application doing the logging. It achieves this by keeping the hot path allocation-free, deferring expensive work like transport formatting to a separate worker thread, and serializing objects with a purpose-built fast stringifier instead of generic JSON.stringify calls.

Beyond raw speed, Pino ships the features production services actually need: child loggers that carry bound context without re-serializing it on every call, built-in redaction for sensitive fields, pluggable transports for shipping logs to files or external services, and first-class support for Fastify, Express, Koa, Hapi, and other Node web frameworks. Pretty-printing during development is handled by the companion pino-pretty module rather than baked into the core, keeping the production logger lean.

What You Get

• A pino() factory that returns a logger instance with trace/debug/info/warn/error/fatal level methods, each emitting a single JSON line
• Child loggers (logger.child({...})) that attach bound context to every log line without re-serializing the parent’s bindings on each call
• A worker-thread transport system (pino.transport()) for routing logs to files, pino-pretty, or third-party log destinations without blocking the main thread
• Built-in redaction (redact option) for stripping or censoring sensitive fields like passwords and tokens before they hit the log stream
• Standard and custom serializers for shaping how errors, requests, and responses are rendered in log output
• Multistream support (pino.multistream()) for fanning a single logger out to multiple destinations with independent level filtering
• A browser build (browser.js) so the same API can run client-side with a configurable transmit/write strategy

Common Use Cases

• High-throughput HTTP API logging in Fastify, Express, or Koa services where logging overhead directly affects request latency
• Structured, machine-parseable application logs feeding into log aggregation systems like Elasticsearch, Datadog, or Loki
• Multi-tenant or multi-request-context logging via child loggers that automatically attach request IDs, user IDs, or trace IDs
• Redacting PII or credentials from logs before they leave the process, for compliance-sensitive services
• Local development logging with human-readable, colorized output via the pino-pretty transport, switching to raw JSON in production

Under The Hood

Architecture — Pino’s entry point, pino.js, wires together a small set of internal modules under lib/: proto.js defines the logger prototype (the trace/debug/info/etc. methods and child()), tools.js builds the safe JSON stringifier and formatters, levels.js manages level comparison and the level-name-to-number mapping, redaction.js compiles redaction paths, and transport.js/transport-stream.js spawn a node:worker_threads worker that owns the actual write destination. Because the worker thread does the formatting/writing work, a slow transport (e.g. shipping to a remote log service) does not block the event loop the application logic runs on. Child loggers are implemented as prototype-chained instances that concatenate pre-serialized “chindings” strings rather than re-walking parent bindings on every call, which is central to Pino’s low per-call overhead.

Tech Stack — Pure JavaScript (CommonJS, type: commonjs in package.json) with a bundled pino.d.ts for TypeScript consumers; no build step is required to consume the package. Runtime dependencies are itself a family of small, single-purpose packages maintained by the same team: @pinojs/redact, pino-abstract-transport, pino-std-serializers, sonic-boom (the fast writable stream Pino writes to), thread-stream (the worker-thread transport machinery), safe-stable-stringify, atomic-sleep, and on-exit-leak-free. This decomposition keeps the core package’s dependency surface small and lets each concern be tested and versioned independently.

Code Quality — The repo has an extensive test suite (46 files under test/, including dedicated browser-mode tests, redaction tests, transport tests, and TypeScript type tests run via tstyche and ts-node), plus eslint with the neostandard config enforced via npm run lint. The test script chains lint, TypeScript transpilation, borp (with 95% coverage thresholds for lines/functions/branches/statements), Jest for a subset of tests, and a separate test-types step — a notably rigorous CI gate for a package this size.

API Design — The core API is deliberately minimal: pino(options, destination) returns a logger, and the six level methods plus child() cover the vast majority of usage. Getting started requires zero configuration (require('pino')() works immediately), while advanced behavior (custom levels, redaction, mixins, formatters, transports) is opt-in via the options object rather than requiring subclassing or plugins. This keeps the common case boilerplate-free while still supporting complex production setups.