fix: strip client selector from request options (breaks Deno / edge runtimes)

[Ooscaar]

Why

Every SDK call throws on Deno-based runtimes (Supabase Edge Functions, Deno Deploy) before any network I/O:

TypeError: Failed to construct 'Request': Argument 2 `client` must be a Deno.HttpClient

_bind injects the per-instance client into each operation's options under the client key, and @hey-api/client-fetch spreads that whole options object into the fetch RequestInit. Node's undici silently ignores the unknown field (which is why the Node-only suite never caught it), but Deno defines its own client init option (a Deno.HttpClient) and validates it, so new Request(...) throws. The SDK is effectively unusable on those runtimes.

This was reported with an excellent diagnosis in #8 (thanks @henrikra!). This PR lands the same fix with two changes:

• Regeneration safety: src/client.ts is generated by scripts/generate-client.ts, so a fix applied only to client.ts (as in fix: stop leaking the client selector into RequestInit (breaks Deno / edge runtimes) #8) would be silently wiped on the next npm run generate. This PR applies the fix in the generator template as well.
• No monkey-patching: instead of reassigning methods on the hey-api client object in place, _bind injects a thin wrapper that leaves the third-party object untouched.

Upstream tracking: this is a known hey-api bug (hey-api/hey-api#4177) with an unmerged fix (hey-api/hey-api#4178). No released version of @hey-api/client-fetch (deprecated at 0.13.1) or the bundled-client architecture fixes it, so a downstream workaround is currently the only option. A TODO marks it for removal once upstream ships.

What

• Added _stripClientSelector() + _dispatchClient to src/client.ts: a wrapper around the per-instance client that delegates everything to it but strips the client selector from request options before hey-api builds the Request; _bind now injects the wrapper. Config and interceptors stay on the real client, per-instance isolation is unchanged.
• Applied the identical change to the template in scripts/generate-client.ts so regeneration preserves the fix.
• Added tests/request-init.test.ts: captures the RequestInit at new Request time (the only way to observe this on Node), asserts the selector never leaks, and verifies auth-header routing and two-instance isolation. Fails on main, passes with this change.

Verification:

• Full suite: 178/178 passing; tsc --noEmit and eslint clean.
• Real Deno 2.9.5 with stubbed fetch: the main build reproduces the exact TypeError; this build succeeds with the auth header intact.
• Live end-to-end on both Node and Deno: accounts.listAccounts and profiles.listProfiles return 200 with byte-identical payloads.

Closes #8 (supersedes it — see regeneration note above; happy to defer to it instead if preferred).

Follow-ups

• Add a small Deno (or workerd) CI job running one call against a stubbed fetch, as suggested in fix: stop leaking the client selector into RequestInit (breaks Deno / edge runtimes) #8 — the whole bug class is invisible to a Node-only matrix.
• Watch fix(client): sanitize Request init for Deno and Bun compatibility hey-api/hey-api#4178; once released, bump the dependency, remove _stripClientSelector/_dispatchClient (marked with a TODO), and keep the regression test.
• The local openapi.yaml is stale relative to the committed src/client.ts (regenerating today would drop ~700 lines of operations) — refresh the spec before the next npm run generate.

🤖 Generated with Claude Code