-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support plain objects #3
Support plain objects #3
Conversation
c5c03b7
to
3ba0093
Compare
3ba0093
to
f70af5c
Compare
f70af5c
to
1407996
Compare
@sindresorhus would you mind taking a look at this? |
I'm on the fence about this one as it feels wrong to accept arbitrary objects, but JS is arbitrary, so I guess it's ok. |
This will also need readme updates. |
Duck typing FTW 🦆 |
Updated the README |
Speaking of typing, would you accept a TypeScript declarations file? |
Yup, just ensure you follow https://github.com/sindresorhus/typescript-definition-style-guide |
Sorry, this PR got lost in my open tabs... |
Love the idea of this module.
I currently have a lot of code that does REST or GraphQL API calls, where in error cases the API usually returns one or multiple error objects with a
message
property and possibly others likename
,code
etc. They are of course notError
instances, and currently get treated asnew Error(err)
, which creates anError
with message[object Object]
.This PR makes it so that if the passed error is not an
Error
instance, but an object, anError
is created witherr.message
as the message and all metadata properties copied over to theError
object.