sindresorhus

serialize-error

Serialize/deserialize an error into a plain object

by sindresorhus

JavaScript

JavaScript96.1%
TypeScript3.9%

Commit activity

Last 12 weeks · 4 commits

Full graph →

Community health

4 of 6 standards met

Community profile →
85
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template

Recent PRs & issues

Active · 1 discussion · Last activity 3w ago
See all on GitHub →
sindresorhus

You can throw anything in JS, but it's a bad practice. I'd like to have it fail rather than silently accept anything. Though, it's not a good default, so should be opt-in. Actually, there's 3 possible behaviors: 1. Always return an . (wanted default) 2. Passthrough non-object values. (current default) 3. Throw on non-object input. I'd like to be the default behavior, for consistency, but add an option to be able to opt into (which is the current behavior) or (which would be the strict behavior). This should be a single option. Another benefit of is that the TypeScript types can be better. We can guarantee it's an object and we can also guarantee that the , , and properties exist.

sindresorhus · 2mo ago
Strohutt

A thrown leaves the object in the recursion guard. Retrying serialization then skips the method, even when it would succeed: Reproduced against main at . The original exception should still propagate, while later calls should try again. A fix and regression test are available in 16a9626. Moving the guard cleanup into preserves recursive serialization and the original exception. All 63 AVA tests and the type tests pass on Node 24 and 26; XO passes for both changed files. The full script hits the same XO project-service errors for three unchanged files on Windows, including on unchanged main.

Strohutt · 3w ago
tjconcept

The fix seems simple if doing something akin to buffers (though the value could be embedded). Am I missing something? If fixed by a PR, could it be backported no a non-ESM version?

tjconcept · 1mo ago
fregante

An issue I found when throwing deserialized errors is that the thrown error has no reference to this point. I think the "correct" way to throw serialized errors would be something like: Two drawbacks: doesn't benefit from https://github.com/sindresorhus/serialize-error/pull/70 this isn't necessarily what people want or expect by default So how about:

fregante · 3mo ago
Structured data for AI agents

Repository: sindresorhus/serialize-error. Description: Serialize/deserialize an error into a plain object Stars: 607, Forks: 68. Primary language: JavaScript. Languages: JavaScript (96.1%), TypeScript (3.9%). License: MIT. Latest release: v13.0.2 (3w ago). Open PRs: 0, open issues: 1. Last activity: 3w ago. Community health: 85%. Top contributors: sindresorhus, fregante, BendingBender, flaviaan, rj-david, misozask, jackple, hec10r, braco, vladimiry and others.