Error subclasses are lost when deserializing

[fregante]

const {serializeError, deserializeError} = require('serialize-error');

class MyError extends Error {
    constructor(message) {
        super(message);
        this.name = 'MyError'
    }
}

const original = new MyError('This is my error');
const serialized = serializeError(original);
const deserialized = deserializeError(serialized);

original will be a MyError but deserialized will be a plain Error

Live example: https://runkit.com/embed/f46ewcgxyxqg

I think deserializeError should support custom error types, if passed as an argument (so they are known and explicit):

const deserialized = deserializeError(serialized, {constructors: [MyError, BusinessError, ErrorError]});

Native errors also should be automatically supported, like TypeError

[fregante]

The good part is that name is preserved as 'MyError' even though it's not an instance of it.

[sindresorhus]

Good idea 👍

[fregante]

I think this could have an internal list of known constructors that could be extended/overridden by the user. Some can be found at: https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/error

Actually supporting all those error correctly might not be possible, but a plain if error.name === TypeError.name, then new TypeError(error.message) would go a long way.

[fregante]

What do you think about exporting a global set of supported errors? This would avoid having to manually pass this around (and potentially forget to), as well enabling support across modules (and sub dependencies)

import {errorClasses} from 'serialize-error';

errorClasses.push(MyError, CoolError, APIError);

👆 Maybe an array is better because Set does not allow adding multiple items (or an array) at once.

[sindresorhus]

Sure. I don't think it should contain the built-in error types though. We don't want users to be able to remove those. So maybe it should be named customErrorClasses? I would go with Set. It's the correct data structure for this.

[StevenLangbroek]

Hey @sindresorhus! Would you be open to another PR adding support for AggregateError?

[fregante]

You can open a new issue. Given it’s a complex error, it first needs proper serialization support.