Deno fetch type error: client from Deno.createHttpClient() not recognized by TypeScript / VSCode

[Lqm1]

Question
When I call fetch(url, { client }) with a client created by Deno.createHttpClient(), VSCode / TypeScript reports a type error even though the runtime supports this option. @types/node is not explicitly installed but is present transitively (e.g. via nodemailer). How do I make the editor recognize Deno's client type?

Reproduction steps

1. Create a Deno script using Deno.createHttpClient() and fetch(url, { client }).
2. Open the project in VSCode (no explicit @types/node install).
3. Observe a TypeScript error on the fetch call.

Environment

• Deno runtime (version 2.5.1)
• VSCode with TypeScript language features (may or may not have Deno extension)
• Some @types/* present transitively (e.g. nodemailer)

[nayeemrmn]

Can you share your compilerOptions? You might have to replace some instance of deno.ns with deno.window in your compilerOptions.lib. Also please share a screenshot of the error so we can confirm it's coming from Deno.

[mgkvibez]

The runtime behavior is right — fetch(url, { client }) with a Deno.createHttpClient() client works in Deno — so what you're seeing is a type-space problem: the fetch signature being checked is the browser dom one, which has no client option, instead of Deno's.

Deno's own fetch declaration overloads client (that's the only way this API could exist at all), so the question is why your project resolves the wrong declaration. The two usual causes:

1. compilerOptions.lib pulls in the DOM. A deno.json/tsconfig with "lib": [..., "dom"] (or an editor workspace where VS Code's TS server is using a browser tsconfig) makes TS check against dom.fetch. Deno projects should use Deno's libs (in newer versions that's "deno.ns" plus the worker/window variants as needed — or simply omit lib entirely in deno.json and let Deno supply its own).

2. The editor isn't using the Deno language server for that file. With the Deno VS Code extension, make sure the workspace has "Deno: Enable" on for that project, and that this file isn't being handled by a vanilla TS server via an ambient tsconfig.json — if one exists at the project root, either delete it or let the extension generate the config. If it's a mixed repo (which yours might be given the ESLint thread you also opened), scope the non-Deno TS setup away from the Deno files.

Quick discrimination test: run deno check file.ts in the terminal. If that passes (it should — Deno's checker uses the right libs) and the red squiggle only exists in VS Code, it's the editor's TS server; if deno check fails too, it's a lib/config issue in deno.json.

Posting your compilerOptions (per the request above) plus the exact error text would let someone pinpoint it in one reply — but the checklist above resolves this class of error in the vast majority of cases.