TS Fixes: arrays of subobjects, emptyStringable fields

[richardm-stripe]

r? @ob-stripe
cc @jlomas-stripe @stripe/api-libraries

1. More consistently encode "emptyStringable" types (described in the openapi spec as anyOf(X, enum([''])) as X | null instead of X | ''.
2. Fixes issue Update 'custom_fields' type to match documentation #766
3. A little bit of churn re: ordering of things because of codegen changes.
   Fixes Incorrect typings custom_fields when  #794

[ob-stripe]

Many fields that were typed as a union with null are changed to a union with '' to better reflect the input expected by the API.

This is correct at the API level, but in many of our client libraries we prevent users from passing '' and require them to pass null, which we then encode as an empty string in the request. I don't know offhand if that's the case in stripe-node, could you double-check?

[richardm-stripe]

@ob-stripe - Good point. We don't actively prevent setting an empty string in node.js, but ultimately API Requests are urlencoded null and '' are urlencoded identically over the wire. So we should decide solely on the basis of what type seems more natural to the user.

I think that's | null rather than | '' in most cases, so I've modified the codegen accordingly, but this has resulted in a new set of changes because the existing code generation did not consistently produce | null either (it did | null for anyOf(class, enum([''])), but did | '' in cases like

• anyOf(array<...>, enum(['']))
• anyOf(primitive, enum(['']))
• anyOf(sharedClass, enum([''])).

[richardm-stripe]

The other possibility would be defining
type EmptyParam = null | '' which would be backwards compatible but I think it is better to standardize on null.

[ob-stripe]

Agree that null is a better choice than ''.

LGTM!