DEV.co
Open-Source Observability · ehmicky

modern-errors

modern-errors is a lightweight JavaScript library for creating and handling custom error classes with consistent patterns across Node.js and browsers. It provides utilities to wrap errors, normalize invalid errors, aggregate errors, and extend functionality via plugins.

Source: GitHub — github.com/ehmicky/modern-errors
1.5k
GitHub stars
20
Forks
JavaScript
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryehmicky/modern-errors
Ownerehmicky
Primary languageJavaScript
LicenseMIT — OSI-approved
Stars1.5k
Forks20
Open issues2
Latest release7.1.4 (2025-10-09)
Last updated2026-06-23
Sourcehttps://github.com/ehmicky/modern-errors

What modern-errors is

ES module library offering error class factories via `.subclass()`, error property management (enumerable and non-enumerable), error cause wrapping with automatic message merging, normalization of non-Error types, and a plugin architecture for serialization, HTTP responses, logging, and stack trace manipulation.

Quickstart

Get the modern-errors source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/ehmicky/modern-errors.gitcd modern-errors# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Structured error handling in Node.js/browser applications

Create a domain-specific error hierarchy (BaseError, InputError, AuthError, etc.) for consistent error classification and handling across your codebase. Enables type-safe error catching and custom logic per error class.

Error aggregation and wrapping in async workflows

Wrap inner errors with context while preserving stack traces and error properties. Useful in Promise chains, API handlers, and CLI applications where you need to add semantic information without losing root cause.

Cross-platform error serialization and logging

Use plugins (modern-errors-serialize, modern-errors-winston, modern-errors-http) to normalize error output across Node.js and browser environments, enabling consistent error reporting, monitoring, and API responses.

Implementation considerations

  • Plan your error class hierarchy upfront (BaseError → domain-specific subclasses) to avoid fragmentation and enable consistent `instanceof` checks across modules.
  • Decide on property naming convention for internal/secret properties (prefix with `_` to make non-enumerable) to prevent accidental logging or serialization of sensitive data.
  • Test error normalization behavior in your catch blocks, especially if third-party libraries throw non-Error objects (strings, objects) that need conversion.
  • Evaluate which plugins are needed (serialize, winston, http, etc.) early; add them only if they solve a real requirement to keep bundle size minimal.
  • Ensure all error classes are exported and documented so downstream code and consumers can rely on `instanceof` checks and error recovery strategies.

When to avoid it — and what to weigh

  • Already using a mature error framework — If your project heavily depends on a framework with built-in error handling (e.g., Express error middleware, NestJS exception filters), adding modern-errors may introduce redundant abstraction unless you need cross-platform consistency.
  • Minimal error handling needs — For simple scripts or prototypes with few error types, the overhead of defining error classes and subclasses may outweigh the benefit. Standard Error or lightweight custom classes may suffice.
  • Strong legacy CommonJS codebase — modern-errors is ES-module-only and requires Node.js >=18.18.0 with ESM output. Migrating a large CommonJS project solely to use this library is likely not cost-effective.
  • Incompatible plugin ecosystem — If none of the available plugins match your logging, monitoring, or serialization stack, you would need to author custom plugins, which may negate the convenience benefit.

License & commercial use

MIT License. Permissive OSI-approved license allowing commercial use, modification, and distribution with no restrictions beyond attributing the original creator.

MIT License clearly permits commercial use without restrictions. However, verify that plugins used (if separate npm packages) also have compatible licenses. The library itself imposes no constraints on commercial applications.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

Library itself does not perform encryption, authentication, or network operations—it is a data structuring tool. Primary concerns: (1) Internal error properties (prefixed `_`) are not enumerable but still accessible; ensure no secrets are stored as error properties. (2) Error messages and stacks may leak file paths or code details if serialized and exposed; use modern-errors-serialize with caution in public APIs. (3) Plugin ecosystem—vet plugins for injection vulnerabilities or unsafe serialization.

Alternatives to consider

Verror (Node.js only, older maintenance)

Lightweight error wrapping with cause chains, but smaller plugin ecosystem, slower maintenance, and no browser support compared to modern-errors.

HTTP status code + custom error classes (custom implementation)

Manual error hierarchy avoids a dependency but requires more boilerplate, testing, and lacks battle-tested patterns like error normalization and property merging.

Express/NestJS/Fastify built-in error handling

Framework-specific error handling is familiar to users but less portable across Node.js/browser boundaries and often cannot be easily reused in non-HTTP contexts.

Software development agency

Build on modern-errors with DEV.co software developers

If your team manages multiple error types across Node.js and browser environments, modern-errors can streamline error classification and reporting. Our engineers can help you design an error hierarchy and integrate monitoring plugins.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

modern-errors FAQ

Does modern-errors replace my logging library?
No. modern-errors structures and classifies errors; it does not log them. Use modern-errors-winston or modern-errors-serialize plugins to integrate with logging systems like Winston, Pino, or Sentry.
Can I use modern-errors in browsers?
Yes. It is dual-target (Node.js >=18.18.0 and browsers via unpkg). Useful for consistent error handling in frontend applications, APIs, and isomorphic code.
What happens if I throw a non-Error object?
Use `BaseError.normalize(error)` to convert strings, objects, or other types to proper error instances. This prevents undefined behavior in try-catch blocks.
How do I avoid exposing sensitive data in error objects?
Prefix properties with `_` (e.g., `_userId`, `_token`) to make them non-enumerable. They remain accessible but won't appear in JSON serialization or iteration unless explicitly accessed.

Software developers & web developers for hire

DEV.co helps companies turn open-source tools like modern-errors into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source observability stack.

Ready to Improve Your Error Handling?

If your team manages multiple error types across Node.js and browser environments, modern-errors can streamline error classification and reporting. Our engineers can help you design an error hierarchy and integrate monitoring plugins.