fix(fetch): type SDK responses from parseAs option#4075
Conversation
|
|
|
@Dexter2099 is attempting to deploy a commit to the Hey API Team on Vercel. A member of the Team first needs to authorize it. |
|
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — threads parseAs through the fetch client's RequestResult and SDK function generics so callers get the right data type for each parse mode.
- Add
ParsedResponse<TData, TParseAs>conditional type — maps eachparseAsliteral to its runtime data type (Blob,string,ArrayBuffer,FormData,ReadableStream<Uint8Array> | nullforstream, orTData[keyof TData]forjson/auto). - Thread
TParseAsthroughRequestResult,MethodFn,RequestFn,RequestOptions,ResolvedRequestOptions,Client— all the fetch client surface types gain aTParseAsgeneric defaulting to'auto'. - Gate SDK emission behind
isFetchClientand!isSse—operationStatements(),operationReturnType(),operationOptionsType(),createTypeOptions(), andv1/node.tsall use$if(isFetchClient, ...)andsupportsParseAs = isFetchClient && !isSseso non-fetch clients and SSE operations are untouched. - Add
Configto SDK imports — the generatedOptionstype usesNonNullable<Config['parseAs']>as theTParseAsconstraint. - Add compile-time type assertions —
types.test.tsverifiesRequestResultproducesBlob,string,ArrayBuffer, and the JSON-shaped response type for the correspondingparseAsvalues. - Update 30 snapshot files — all mechanical propagation of the new generic across 10
client-fetchsnapshot variants.
DeepSeek Pro (free via Pullfrog for OSS) | 𝕏
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4075 +/- ##
==========================================
+ Coverage 38.68% 38.73% +0.05%
==========================================
Files 626 626
Lines 21864 21894 +30
Branches 6406 6431 +25
==========================================
+ Hits 8458 8481 +23
- Misses 10922 10928 +6
- Partials 2484 2485 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
e9ae2d5 to
c1f7775
Compare
@hey-api/codegen-core
@hey-api/json-schema-ref-parser
@hey-api/nuxt
@hey-api/openapi-ts
@hey-api/shared
@hey-api/spec-types
@hey-api/types
@hey-api/vite-plugin
commit: |

Summary
Fixes #3835.
Threads the fetch client's request-level
parseAsoption through generated SDK function types so callers get the runtime response shape indata.For example,
parseAs: 'blob'now producesBlobdata instead of the OpenAPI schema response type. The defaultparseAs: 'auto'behavior keeps the existing schema-derived response type.Most of the diff is generated fixture output from the client, plugin, and example matrices.
Cause
The fetch client runtime already parses responses according to
parseAs, but generated SDK functions only passed schema-derived response types intoRequestResult. The request-level parse mode was not part of the SDK function generic, client method call, or return type.Fix
TParseAsthrough fetch SDK options, return types, and client method calls.Tests
corepack pnpm ty @hey-api/openapi-tscorepack pnpm ty @test/openapi-tscorepack pnpm exec vitest run --project @hey-api/openapi-ts packages/openapi-ts/src/plugins/@hey-api/client-fetch/__tests__corepack pnpm exec vitest run --project @test/openapi-ts packages/openapi-ts-tests/main/test/clients.test.tscorepack pnpm exec vitest run --project @test/openapi-ts packages/openapi-ts-tests/main/test/plugins.test.tssh ./scripts/examples-check.sheslinton touched source/test filesoxfmt --checkon package diff files