express-winston

express-winston provides two Express.js middlewares — logger() and errorLogger() — that connect the Express request/response/error lifecycle to Winston, the widely-used Node.js logging library. It formats HTTP requests (and, optionally, response metadata) into structured log entries, using either Winston’s own transports/formats or a pre-configured Winston logger instance you already maintain elsewhere in your app.

The logger middleware supports Morgan-style default formatting, colorized output, per-status-code log levels, request/response property whitelisting and filtering, and customizable message templates. The error logger middleware sits after your router and before your custom error handlers, logging exceptions with full request context without intercepting or altering error-handling flow.

What You Get

• expressWinston.logger(options) middleware for structured HTTP request logging
• expressWinston.errorLogger(options) middleware for logging errors with full request context
• Configurable log level per status code via statusLevels, or dynamic levels via a level function
• Request/response property whitelisting, blacklisting, and custom filter functions to control what’s logged
• Morgan-style expressFormat output and colorized console logging option

Common Use Cases

• Adding structured, Winston-formatted HTTP access logs to an existing Express.js application
• Centralizing request and error logging output to the same transports (files, syslog, cloud logging services) already configured for Winston elsewhere in the app
• Filtering sensitive request/response fields (auth headers, tokens) out of log output via whitelist/blacklist options
• Assigning different log severities to different HTTP status code ranges (e.g. 5xx as error, 4xx as warn)

Under The Hood

Architecture — The entire library lives in a single index.js file exporting the logger and errorLogger factory functions. Each factory closes over the passed options, returning a standard Express middleware (req, res, next) (or (err, req, res, next) for the error logger) that extracts whitelisted request/response properties, applies any requestFilter/responseFilter/dynamicMeta functions, and passes the assembled metadata object to either a caller-supplied winstonInstance or a Winston logger constructed from the given transports/format options.

Tech Stack — Plain JavaScript (with accompanying index.d.ts TypeScript definitions), depending on winston as its core logging engine (accepted as a peer/direct dependency) plus small internal helpers for header/body filtering. No build step is required for consumers; it’s a direct middleware import.

Code Quality — Tests live in test/test.js (JavaScript) and test/express-winston-tests.ts (TypeScript, validating the type definitions), covering both the logger and errorLogger middlewares across their many configuration options. The project has been effectively feature-frozen since 2021 and carries an open ‘CALL FOR MAINTAINERS’ notice in its README, so while functionally stable and widely used, it should be evaluated for long-term maintenance risk before adoption in a new project.

API Design — Two functions (logger, errorLogger) cover the whole public surface, following Express’s standard middleware signature so integration is a single app.use() call. The extensive but consistently-named options (whitelist/blacklist pairs, metaField, dynamicMeta, statusLevels) give fine-grained control without requiring boilerplate for the common case — reasonable defaults mean app.use(expressWinston.logger({ transports: [...] })) is enough to get working request logs.