Preserve error constructor

[fregante]

Previous notes about native-only support

Partially fix for #48.

Includes and is blocked by #69

Custom constructors will need extra logic, because what happens when CustomError’s signature requires a second parameter?

• Deserialization should catch that and use a regular Error, and/or
• The user should pass .set(MyError, object => new MyError(object.message, object.otherProp))

But this might require further bikeshedding, so I'm leaving it out of this PR

Fixes #48

[sindresorhus]

Merge conflict

[sindresorhus]

The behavior needs to be documented.

[fregante]

The behavior has been documented.

[fregante]

This should be good to go. Do you think this is a breaking change?

  deserializeError({name: 'TypeError'})
- //=> [Error: 🟣] // v9
+ //=> [TypeError: 🟣] // next

[fregante]

This adds support for custom error constructors to be added. This only supports simple errors so I mentioned this in the docs and in the types. A new issue can be created to add support for such error constructors.

Also, instead of adding error-constructors.js to the exports map, I just added another export here. It's cleaner anyway.

[fregante]

I tried ?? but it fails in Node 12. If desired, Node 12 support can probably be dropped separately so it appears in the changelog

[sindresorhus]

https://github.com/sindresorhus/serialize-error/releases/tag/v10.0.0

[ghost]

@sindresorhus @fregante Looks like we have a wrong type definition for this feature,

#78

Not every Error objects would have the same constructor types

[fregante]

It seems that constructors like DOMExceptions don't match ErrorConstructor. While therefore the types are incorrect, it doesn't affect the final user. If you have a solution please send a PR, but otherwise I don’t think it's important here.

I think potentially the solution would be to replace ErrorConstructor with new (string, ...anything[]) => {message: string, ...anything} so it matches any constructors that accepts a string and return an ErrorLike