Some `.rbi` type definitions are incomplete or incorrect

[Tom-Bonnike]

Is your feature request related to a problem? Please describe.

Some .rbi type definitions for the gem are incomplete or incorrect. Here is a non-exhaustive list of issues:

• 1. Stripe::StripeObject includes ::Enumerable, but doing a find on a Stripe::ListObject (which inherits from Stripe::StripeObject) does not narrow the type like it usually does for other enumerables like T::Array. I think because the each type needs to be defined explicitly? See: https://sorbet.org/docs/stdlib-generics#implementing-the-enumerable-interface

• 2. the type for a Stripe::Event data.object is incorrectly typed to only a simple T::Hash which forces us to use T.cast:
  Notice how the description says it is a full object as value, which is indeed the case 🤔 Should it be typed to a Stripe::StripeObject instead? Ideally the event itself could be narrowed down with a generic to a Stripe::Event[Stripe::PaymentIntent], for example… Then event.data.object would automatically be typed to a Stripe::PaymentIntent.

• 3. Stripe::Account#external_accounts is typed as a simple Stripe::ListObject, but ideally it would be narrowed to a list of T.any(Stripe::BankAccount, Stripe::Card), like it’s already the case in external account related operations. I wonder if again a generic would be the right solution here so that you can express what kind of objects a list contains 🤔 Maybe T.any(Stripe::BankAccount, Stripe::Card) could even be exposed as a Stripe::Account::ExternalAccount type alias?

• 4. Stripe::Account.retrieve returns T.untyped instead of a Stripe::Account

• 5. Stripe::Account.create_login_link returns T.untyped instead of a Stripe::LoginLink

• 6. Stripe::Transfer.create_reversal is wrongly typed to return a Stripe::Transfer object with a nested reversal object instead of a top-level Stripe::Reversal

• 7. Error types seem to be incomplete:

  • Stripe::StripeError#error returns T.untyped instead of a Stripe::ErrorObject
  • Stripe::ErrorObject#payment_intent returns T.untyped instead of a T.nilable(Stripe::PaymentIntent) (I assume there are other objects than a payment intent); currently it actually is an instance of Stripe::StripeObject, it doesn’t get serialized to a Stripe::PaymentIntent.
  • Stripe::ErrorObject#code returns T.untyped instead of a String

Also see #1579; maybe some of it has already been fixed in recent updates.

---

And, I don’t know if you’re aiming for full .rbi type coverage, but:

• Stripe::Object.construct_from (e.g. Stripe::Event.construct_from(…)) isn’t typed and returns T.untyped. I think it should return T.self instead?
• Similarly, Stripe::Webhook.construct_event isn’t typed. We have a shim for it:

module Stripe::Webhook
  sig {
    params(payload: String, signature_header: String, endpoint_secret: String, tolerance: T.nilable(Integer))
      .returns(Stripe::Event)
  }
  def self.construct_event(payload, signature_header, endpoint_secret, tolerance: Stripe::Webhook::DEFAULT_TOLERANCE)
  end
end

Are these kind of types something you’d rather goes into https://github.com/Shopify/rbi-central/blob/main/rbi/annotations/stripe.rbi? In an ideal world, the annotations in rbi-central would not be necessary since you now ship your own type annotations.

Describe the solution you'd like

There are simple workarounds (type assertions, shims) around most of these issues, but ideally they would be fixed. Since Stripe created & maintains Sorbet, it was a bit surprising to see that the gem is not better typed! I realize some improvements have been made in recent versions, thank you for that! :)

I think the rbi-central topic is also something you should look at, it’s confusing that some types are maintained there instead of directly contributed into this gem’s .rbi file.

Describe alternatives you've considered

No response

Additional context

No response

[jar-stripe]

Hi @Tom-Bonnike , thanks for the report! We've added this our ruby backlog and will keep the issue open until we have a chance to address it.

[Tom-Bonnike]

I’ll be updating that list as we find more stuff FYI