Add V2List and V2ListPromise types for v2 list endpoints#2717
Conversation
V2 list API responses return {data, next_page_url, previous_page_url}
but the SDK typed them as ApiList<T> which has v1-only fields
{object, data, has_more, url}. This adds correct types so users can
access v2 pagination fields without type assertions.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Committed-By-Agent: claude
There was a problem hiding this comment.
Pull request overview
Adds dedicated TypeScript types (V2List<T> and V2ListPromise<T>) modeling the v2 list response shape (data, next_page_url, previous_page_url) so consumers can access pagination URLs without type assertions. Existing v1 ApiList/ApiListPromise are unchanged. Generated v2 resource files are left on ApiListPromise pending a follow-up codegen update.
Changes:
- Define
V2List<T>andV2ListPromise<T>insrc/lib.tsparallel to the v1 equivalents. - Re-export both types from the
Stripenamespace insrc/stripe.core.ts. - Add tests in
test/resources/V2/Core/Events.spec.jsasserting the new response shape (including null pagination URLs).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/lib.ts | Adds V2List<T> interface and V2ListPromise<T> async iterator/promise type. |
| src/stripe.core.ts | Imports and re-exports the new types from the Stripe namespace. |
| test/resources/V2/Core/Events.spec.js | Adds two tests verifying v2 list shape and null pagination URLs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
mbroshi-stripe
left a comment
There was a problem hiding this comment.
Looks good to me, but adding @prathmesh-stripe in case there is some export edge case I'm not aware of (I know we've seen issues with, e.g., Stripe.Decimal recently).
xavdid
left a comment
There was a problem hiding this comment.
I'll leave to prathmesh for final approval since he has the most context. Approach looks good though.
One thing to add: a block in typescriptTest that verifies the types are correct. I believe these runtime tests would pass today, since the API shape hasn't changed.
Lastly, this is definitely a breaking change (and the PR title should reflect that). If we're settled on doing an out-of-band major release for it, we should write the migration docs and things.
checks; this enables type support for v2 pagination urls without changing behavior around incorrect v1 list fields
fixerd issues in test code and white space in comments
into V2List; marked them deprecated and moved the TODO to remove them
xavdid
left a comment
There was a problem hiding this comment.
approving to unblock- I think the shim will work.
Still should add the typescript test mentioned above- we rely on those for regression checking!
Why?
V2 list API responses have a different shape than v1 lists — they return
{data, next_page_url, previous_page_url}instead of{object, data, has_more, url}. The SDK was usingApiList<T>(the v1 type) for both, meaning users couldn't accessnext_page_urlorprevious_page_urlwithout type assertions.What?
V2List<T>interface withdata,next_page_url, andprevious_page_urlfieldsV2ListPromise<T>promise wrapper with auto-pagination methods, parallel toApiListPromise<T>StripenamespaceV2ListPromiseinstead ofApiListPromiseNote to the reviewer
To avoid introducing a breaking change,
V2Listtemporarily includes the deprecated properties fromApiList(object,has_more,url). This means existing code that expects anApiListfrom v2 list endpoints will continue to compile without errors. These properties are not populated at runtime for v2 lists (this was already the case before this PR) and should be removed at the next major release.See Also
N/A
Changelog
V2ListandV2ListPromisetypes to represent API v2 list responses. These types include deprecated fields from the previously returned list shapes. These fields will be removed in the next major release.