Commit activity
Last 12 weeks · 0 commits
Community health
4 of 6 standards met
85
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Quiet · 2 discussions · Last activity 7mo ago
See all on GitHub →
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.
Recent fixes
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:
Fixes #98 Summary Add a option to that returns a new error with the deserialized error set as . Preserve the resolved error constructor for the wrapper and capture a current stack when is available. Document the option and cover runtime and type tests. Verification Disclosure This contribution was prepared with AI assistance and reviewed before submission.
Closes #98. Adds an option to . When enabled, the deserialized error is wrapped as the of a new error, so a thrown error carries a stack pointing at the current call site while the original (with its serialized stack) is kept on : The wrapper is built with the resolved error constructor, so still works and it reuses the known-constructor handling. The stack is set via , so the wrapper's own frames don't leak into it. On the name: the thread didn't land on one. I went with since that's what @fregante leaned toward, but it's a one-line change if you'd prefer or — happy to switch. Docs and tests included; (xo + ava + tsd) passes. Written with AI assistance (Claude). I've reviewed the whole change and can walk through any of it.
Structured data for AI agents
Repository: sindresorhus/serialize-error. Description: Serialize/deserialize an error into a plain object Stars: 602, Forks: 69. Primary language: JavaScript. Languages: JavaScript (96%), TypeScript (4%). License: MIT. Latest release: v13.0.1 (7mo ago). Open PRs: 0, open issues: 2. Last activity: 7mo ago. Community health: 85%. Top contributors: sindresorhus, fregante, BendingBender, Weakky, rj-david, misozask, jackple, hec10r, braco, vladimiry and others.