FAQ

Why does UniversalError extend Error instead of being a plain object?

A plain object would be simpler to serialize, but it would break the moment you do what every JS developer eventually does with a caught error: throw it again, check instanceof Error, hand it to console.error, or forward it to an error-reporting SDK. Extending Error keeps all of that working for free. toJSON() is defined explicitly, so JSON.stringify(error) still produces the clean structured shape instead of Error's near-empty default serialization.

Do I need an adapter, or does the core package work alone?

parseError() from the core package works standalone, with zero dependencies, via duck-typing — it recognizes Axios's { response: { status, data } } shape, Node's error codes, and the browser fetch network-failure message family without importing any of those libraries. The Axios and fetch adapters exist for the nuance the generic parser genuinely can't infer (see each guide for specifics).

Is the core package really zero runtime dependencies?

Yes, including no dependency on Axios's types. That's what makes it usable standalone and tree-shakeable.

Why is parseFetchError async, but parseAxiosError isn't?

fetch never throws for HTTP error statuses — only for genuine network failures. Reading the error information out of a failed Response means reading its body, which is inherently asynchronous. Every other parser in this ecosystem is synchronous; fetch's is the one exception, for that reason.

How is this different from just checking error.response?.status myself?

Nothing stops you from doing that today — this library exists because that check looks different for every backend (error.response.status vs error.statusCode vs a nested error.data.error.code, ...), and because status alone doesn't tell you whether an error is retryable, whether it's a validation error with field-level detail, or whether the request even reached the server. universal-api-errors computes all of that once, consistently, instead of each project re-deriving it.

Does this support strict TypeScript?

Yes — the whole library is built with exactOptionalPropertyTypes and noUncheckedIndexedAccess on, and there's no any in the public API.

Is this stable / production ready?

The shipped packages (core, axios, fetch) are real, tested code — not a preview or a stub — but the project is still pre-1.0 (0.x versions), so the API may still change before a stable 1.0.0. Pin exact versions if you depend on it in production.