-
Notifications
You must be signed in to change notification settings - Fork 751
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
Throw an error if options are provided inside the data argument #306
Conversation
cf658d2
to
2381c2e
Compare
Oops. :) |
Relates to #307. |
Hi @jlomas-stripe, thank you so much for the hard work here and my apologies for not getting back to you about this sooner! So I kind of feel like including Just to think about alternatives, what would you think about instead erroring/warning when it looks like a user has accidentally mixed together data and options? It seems like this might allow for a similar level of ergonomics by giving people better feedback on what went wrong, but avoid bad patterns around name/object mangling. |
@brandur-stripe Very good points, and I agree on all of them. I'd also considered the error approach, so I'm totally fine with switching to that to enforce the separation. I'll ping again when I've switched this up. :) |
@jlomas-stripe Awesome! Thank you :) |
2381c2e
to
087dca4
Compare
fc7c415
to
82305e4
Compare
@brandur-stripe I brought this back from the edge of death, and switched it over to just throwing an error if you provide a combined options/data argument. |
Small lurk: this will need a major version change. Multiple users/integrations (over 100) incorrectly pass |
I will double-check that the following is true for But good point. :) |
Well it's not broken. It does not do what they ask, but it charges customers successfully, which is fairly different from returning an error on all requests until they fix their code. |
Ohhhhh. I can't read. Good point. Thanks. :) Fully agreed: taking this approach will require a major version bump. |
@jlomas-stripe Thanks for bringing this back to life! Seems like a pretty great improvement. One thing I noticed is that the wiki page that you link to: Describes how to pass "data" (according to our vocabulary here), but doesn't really describe how to use "options". We sort of have the information in our API reference, but it might be a good idea to include it there too given that it's in a link. Would you be up for throwing something up there instructing how to use options like |
@brandur-stripe That ... is a great point. 😂 I can absolutely tweak that page - it doesn't seem to cover off what we consider EDIT: And by |
@brandur-stripe 👋 Just wanted to follow up. I don't think there's anything left to do here, since I did update the Wiki page. Can you take another peek when you have a chance? |
lib/utils.js
Outdated
return OPTIONS_KEYS.indexOf(key) > -1; | ||
}); | ||
|
||
if (argKeys.length > optionKeysInArgs.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this conditional be a little more intuitive if we just compare optionKeysInargs.length > 0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Yes it would. 😂
Nice! And thank you for updating that wiki. One other relatively minor comment: I think I mentioned in another PR that we did essentially this exact same thing for stripe-ruby, except for that we emit a warning to stderr instead of throwing an error. In the long run, I think that throwing the error might be better, but the warning is superior for backwards compatibility (people might be doing this today by accident and will get an error on upgrade if they are). Thoughts on switching over to a warning instead? |
82305e4
to
4ec6955
Compare
@brandur-stripe I (finally 😂) updated this to |
Love it @jlomas-stripe. Thanks again for the fix! |
Released as 5.1.0 along with a few other minor things. |
If you include any of
stripe_account
,api_key
oridempotency_key
in thedata
object, that object will be treated as theoptions
object and so only the options will be processed - i.e., the data will be discarded.With this change, the first argument object will be stripped of the
options
keys and returned, allowing for bothdata
andoptions
to come from the same object.Also added some Charge creation tests to ensure that this works - at least in terms of adding a
Stripe-Account
header.