npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@hyperfrontend/logging

v1.0.1

Published

Structured logging with configurable severity levels and error-resilient execution.

Readme

Structured logging with configurable severity levels and error-resilient execution.

• 👉 See documentation • 👉 See guides & tutorials

What is @hyperfrontend/logging?

@hyperfrontend/logging provides a production-grade logging abstraction that wraps console-like log functions from any backend (console, Winston, Bunyan) with runtime log level control and automatic error handling. Unlike basic console wrappers, this library enables dynamic severity filtering without code changes or environment restarts - adjust verbosity in running production systems via the setLogLevel() API.

The core createLogger() factory accepts custom log functions for each severity level (error, warn, log, info, debug), wrapping them with conditional execution based on current log level and automatic error suppression to prevent logging failures from crashing applications. A pre-configured logger instance using console methods is available for immediate use.

Key Features

  • Runtime Log Level Control - Adjust logging verbosity dynamically via setLogLevel() without restarting processes
  • Priority-Based Filtering - Log levels follow standard hierarchy (error > warn > log > info > debug) with automatic filtering
  • Error-Resilient Execution - All log functions wrapped with error handlers to prevent logging failures from propagating
  • Console Abstraction - Accepts one console-like function per level, from console, Winston, Bunyan or a custom implementation
  • Conditional Execution - Log functions only execute when current severity meets or exceeds configured threshold
  • Frozen Interfaces - Logger instances are immutable to prevent runtime modification
  • Zero External Dependencies - Self-contained implementation with no third-party runtime dependencies
  • Type-Safe API - Full TypeScript support with strongly-typed log functions and levels

Why Use @hyperfrontend/logging?

Production Observability Without Restarts

Debugging production issues requires adjusting log verbosity on running systems without downtime. Traditional logging requires environment variable changes and process restarts, delaying issue resolution. This library exposes setLogLevel() APIs that adjust verbosity at runtime - increase debug output during incidents, then return to error-only logging once resolved. Integrate with admin endpoints or monitoring tools to control logging remotely.

Prevent Logging Failures from Cascading

Logging operations can fail (network issues for remote transports, serialization errors for complex objects, disk space for file logs). Standard console methods throw synchronously, potentially crashing applications during log operations. This library wraps every log function with error suppression - if logging fails, the error is swallowed and execution continues. Your application stays stable even when logging infrastructure fails.

Uniform Logging Interface Across Environments

Applications often use different logging libraries in different environments (console in development, Winston in Node.js production, browser-specific loggers in frontend). This creates environment-specific code branches and inconsistent log formats. Pass any backend's log functions to createLogger() and receive a uniform API across all environments. Switch underlying implementations without changing application code.

Testable Logging Logic with Dependency Injection

Testing code with direct console.log() calls requires mocking global objects or capturing stdout, creating brittle tests. This library uses dependency injection - pass mock functions to createLogger() during tests to capture log output programmatically. Verify log messages, assert call counts, and test conditional logging behavior without environment manipulation.

Minimize Production Log Volume Costs

Cloud logging services charge per log entry and storage volume. Applications using console.log() everywhere generate excessive logs, inflating costs without proportional debugging value. Set default log level to 'error' in production to capture only critical issues, then selectively enable verbose logging during investigations. Reduce log volume by 90%+ while maintaining debugging capabilities when needed.

Installation

npm install @hyperfrontend/logging

Quick Start

Using the Pre-Configured Logger

import { logger } from '@hyperfrontend/logging'

// Default level is 'error' - only error logs execute
logger.error('Critical failure', { code: 500 }) // ✅ Logged
logger.warn('Deprecation notice') // ❌ Filtered
logger.info('Request completed') // ❌ Filtered

// Increase verbosity at runtime
logger.setLogLevel('info')
logger.info('Request completed') // ✅ Now logged

// Check current level
console.log(logger.getLogLevel()) // 'info'

// Disable all logging
logger.setLogLevel('none')

Creating Custom Loggers

import { createLogger } from '@hyperfrontend/logging'
import winston from 'winston'

// Wrap Winston logger
const winstonLogger = createLogger(
  winston.error.bind(winston),
  winston.warn.bind(winston),
  winston.log.bind(winston),
  winston.info.bind(winston),
  winston.debug.bind(winston)
)

// Custom logger with structured output
const structuredLogger = createLogger(
  (msg, meta) => console.error(JSON.stringify({ level: 'error', msg, meta })),
  (msg, meta) => console.warn(JSON.stringify({ level: 'warn', msg, meta })),
  (msg, meta) => console.log(JSON.stringify({ level: 'log', msg, meta })),
  (msg, meta) => console.info(JSON.stringify({ level: 'info', msg, meta })),
  (msg, meta) => console.debug(JSON.stringify({ level: 'debug', msg, meta }))
)

Dynamic Log Level Control

import { createLogger } from '@hyperfrontend/logging'
import express from 'express'

const { error, warn, log, info, debug } = console
const logger = createLogger(error, warn, log, info, debug)

// Admin endpoint to control log level
const app = express()
app.post('/admin/log-level', (req, res) => {
  const { level } = req.body
  logger.setLogLevel(level)
  res.json({ level: logger.getLogLevel() })
})

// Automatically increase verbosity during errors
process.on('uncaughtException', () => {
  logger.setLogLevel('debug') // Enable debug logs for debugging
})

Testing Logging Behavior

import { createLogger } from '@hyperfrontend/logging'

test('logs only errors at error level', () => {
  const error = jest.fn()
  const warn = jest.fn()
  const logger = createLogger(error, warn)

  logger.setLogLevel('error')
  logger.error('Critical')
  logger.warn('Warning')

  expect(error).toHaveBeenCalledWith('Critical')
  expect(warn).not.toHaveBeenCalled()
})

Channels and Timing

import { createLogger } from '@hyperfrontend/logging'

const { error, warn, log, info, debug } = console
const logger = createLogger(error, warn, log, info, debug)
logger.setLogLevel('debug')

// channel() returns a sub-logger that prepends `[prefix]` to every emission.
// Nested channels chain with `:`; channel('build').channel('rollup') emits `[build:rollup]`.
const build = logger.channel('build')
build.info('starting') // [build] starting
build.channel('rollup').warn(':') // [build:rollup] :

// timed() wraps a sync call: success -> debug "<label> completed in Nms",
// failure -> error "<label> failed after Nms: <message>" then rethrows.
const value = build.timed('compute', () => expensiveSync())

// timedAsync() does the same for promise-returning calls and additionally
// dumps the stack trace to debug on rejection.
await build.timedAsync('bundle', async () => bundleAsync())

API Overview

One factory and one ready-made instance. createLogger takes five plain sink functions in severity order (error, warn, log, info, debug) and hands back a frozen logger; only the first is required, and the rest fall back to no-ops. Each sink you pass is wrapped twice on the way in: once so that a sink which throws (a dead socket, an unserializable object) can never surface at your call site, and once by a level check shared with every other method on the logger. The exported logger is that same factory already applied to the console methods, for when you do not need your own sinks.

Verbosity is one dial rather than a build-time constant. setLogLevel and getLogLevel read and write state shared by the whole logger, so an admin endpoint or a signal handler can open the tap on a running process. A LogLevel is one of 'none', 'error', 'warn', 'log', 'info' or 'debug', and setting one admits it plus everything more severe. Note that log outranks info here, so a logger at 'log' still prints warnings and summaries while dropping the play-by-play. A fresh logger starts at 'error'.

Two affordances do the structuring. channel returns a sub-logger that prepends [prefix] as its own leading argument; channels nest and join with a colon, so logger.channel('release').channel('npm') emits [release:npm]. timed and timedAsync wrap a call and return whatever it returned, emitting <label> completed in <n>ms at debug on success and <label> failed after <n>ms: <message> at error on failure before rethrowing, so timing instrumentation never changes control flow. On a rejection timedAsync also sends the stack trace to debug.

Beside those sit two predicates and a lower-level piece: isValidLogger and isValidLogLevel for guarding values that arrive from configuration or a request body, and createLogLevelConfig when you want the priority machinery on its own without any sinks attached.

Every type, parameter and return shape is in the API reference.

Compatibility

Output Formats

| Format | File | Tree-Shakeable | | ------ | -------------------------- | :------------: | | ESM | index.esm.js | ✅ | | CJS | index.cjs.js | ❌ | | IIFE | bundle/index.iife.min.js | ❌ | | UMD | bundle/index.umd.min.js | ❌ |

CDN Usage

<!-- unpkg -->
<script src="https://unpkg.com/@hyperfrontend/logging"></script>

<!-- jsDelivr -->
<script src="https://cdn.jsdelivr.net/npm/@hyperfrontend/logging"></script>

<script>
  const { createLogger } = HyperfrontendLogging
</script>

Global variable: HyperfrontendLogging

Part of hyperfrontend

This library is part of the hyperfrontend monorepo.

📖 Full documentation

License

MIT