Error subclasses are lost when deserializing about serialize-error

[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.

[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.

[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.