fix(client): sanitize Request init for Deno and Bun compatibility#4178
fix(client): sanitize Request init for Deno and Bun compatibility#4178jwulf wants to merge 1 commit into
Conversation
The client-fetch and core SSE runtimes spread their internal options object into new Request(url, init). Node, undici and browsers ignore unknown RequestInit keys, but Deno and Bun validate the init strictly (Deno treats client as a Deno.HttpClient) and throw on every request: TypeError: Failed to construct 'Request': Argument 2 `client` must be a Deno.HttpClient Add a toRequestInit() helper that keeps only standard RequestInit fields and use it before constructing the Request in the fetch and SSE clients. No-op on Node and in the browser. Co-authored-by: Copilot <[email protected]>
|
|
🦋 Changeset detectedLatest commit: 9a82aa0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
@jwulf is attempting to deploy a commit to the Hey API Team on Vercel. A member of the Team first needs to authorize it. |
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — the PR adds a toRequestInit() sanitizer in @hey-api/client-core and uses it wherever the generated fetch client or core SSE runtime constructs a Request, dropping internal keys like client, fetch, and serializers that Deno/Bun reject.
- Add
toRequestInit()sanitizer toclient-core/bundle/utils.ts - Sanitize
RequestInitinclient-fetchbefore constructing the main request - Sanitize
RequestInitin core SSE runtime before constructing the request and handing it toonRequestcallbacks - Add tests covering standard-key retention, non-standard-key removal,
undefinedfiltering, and a stub of a strict runtime emulating Deno/Bun - Include changeset for
@hey-api/openapi-ts
@v0 or keep the SHA fresh with Dependabot ｜ View workflow run ｜ Using Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
1 participant
What
Fixes the generated fetch and SSE clients throwing on Deno and Bun:
Closes #4177. Related: #554.
Why
The
client-fetchruntime and the core SSE runtime spread their internal options object intonew Request(url, init). Node, undici and browsers ignore unknownRequestInitkeys, but Deno and Bun validate the init strictly (Deno treatsclientas aDeno.HttpClient) and throw on every request. A customfetchcannot work around it because theRequestis constructed beforefetchruns.How
toRequestInit()helper toclient-core/bundle/utils.tsthat returns aRequestInitcontaining only standard fields (method,headers,body,signal,redirect,cache,credentials,mode,referrer,referrerPolicy,integrity,keepalive,duplex,priority,window).new Request(...)sites:client-fetch/bundle/client.ts(main request path)client-core/bundle/serverSentEvents.ts(SSE path; this also sanitizes theinithanded to theonRequestcallbacks of the fetch / ofetch / ky / next clients)client-ofetchandclient-kyalready build clean inits on their main paths, so they need no change there.Behaviour on Node and in the browser is unchanged — the removed keys were already ignored by those runtimes.
Tests
client-core/__tests__/utils.test.tsaddstoRequestInitcoverage, including a test that stubsglobalThis.Requestto reject the non-standardclientkey (emulating Deno/Bun) and asserts the sanitized init constructs successfully. Runs in the normal vitest suite (no Deno/Bun runtime needed). A changeset is included.Downstream
Found while making
@camunda8/orchestration-cluster-apirun on Deno (camunda/orchestration-cluster-api-js#283 / #284). Once this lands, the downstream post-gen workaround can be removed.