Add option to decide behavior

[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 object. (wanted default)
2. Passthrough non-object values. (current default)
3. Throw on non-object input.

I'd like 1 to be the default behavior, for consistency, but add an option to be able to opt into 2 (which is the current behavior) or 3 (which would be the strict behavior). This should be a single option.

Another benefit of 1 is that the TypeScript types can be better. We can guarantee it's an object and we can also guarantee that the name, message, and stack properties exist.

[sindresorhus]

// @OsoianMarcel @samchon @semmel I could use some opinions on this.

[semmel]

Yes, in practice all sorts of crap is thrown. Other than non-objects, e.g. objects which contain a collection of several errors and root level name, message nor stack.

My expectation from serialize-error would be that it produces something "serializable" from my input. If that is possible it should not fail. Thus I don't like option 3.

Another benefit of 1 is that ... we can also guarantee that the name, message, and stack properties exist.

Yes, but the values of name and stack would not be very useful, would they?

I can imagine some mapping from non-object primitives to .message simply like serializableError.message = String(nonObject) That would work for non-objects like Strings (non-empty), Numbers, Symbols, Dates ...

But what would the message property be for {foo: "bar", doc: window.document}?

[sindresorhus]

Yes, but the values of name and stack would not be very useful, would they?

They would be useful in the sense that they would indicate that an invalid error was passed.

But what would the message property be for {foo: "bar", doc: window.document}?

It would use util.inspect, same as:

serialize-error/index.js

Line 76 in 480ed36

return new NonError(value);

[semmel]

Requiring the Node.js built-in util package for util.inspect means that serialize-error no longer works in a browser?

Otherwise I would be polite to add a build step to generate some distribution files for the browser using a util shim?

[jcald1]

@semmel , you can install util in package.json for the browser.

[DominicRoyStang]

1. Always return an object. (wanted default)

I'd like 1 to be the default behavior, for consistency, but add an option to be able to opt into 2 (which is the current behavior) or 3 (which would be the strict behavior). This should be a single option.

Looks like 1 was implemented in version 13.0.0, but there's no option to switch between the three behaviors. Is that still planned?

If so, I implemented it here DominicRoyStang#1. It adds an onNonObject option to serializeError (I'm open to other names, naming is hard 😐)

I can't open pull requests targeting this repository so it's currently targeting my own fork's main branch