body property missing from Options type in Deno

[leizha]

Description

When using ky in Deno with deno check, the body property is not recognized on the Options type, even though Options extends Omit<RequestInit, 'headers'> which should include it.

Reproduction

import ky from 'npm:ky'

const api = ky.create({
  prefixUrl: 'https://api.example.com',
  headers: { authorization: 'Bearer test' },
})

const form = new URLSearchParams({ key: 'value' })
api.post('endpoint', { body: form })

$ deno eval --check "
import ky from 'npm:ky'
const api = ky.create({ prefixUrl: 'https://example.com' })
const form = new URLSearchParams({ a: 'b' })
api.post('test', { body: form })
"

TS2353 [ERROR]: Object literal may only specify known properties, and 'body' does not exist in type 'Options'.
api.post('test', { body: form })
                   ~~~~

Assigning Options directly also fails:

import type { Options } from 'npm:ky'
const o: Options = { body: 'test' }
// TS2353: 'body' does not exist in type 'Options'

Meanwhile, the base type works fine in Deno:

const o: Omit<RequestInit, 'headers'> = { body: 'test' }
// OK - no error

Environment

• ky 1.14.3 (via npm:ky)
• Deno 2.1.9

Suspected root cause

Options is defined as:

export interface Options extends KyOptions, Omit<RequestInit, 'headers'> { ... }

Deno's RequestInit type has body defined, and Omit<RequestInit, 'headers'> retains it. But when the interface merges KyOptions and Omit<RequestInit, 'headers'>, Deno's type checker loses the body property. This doesn't happen under Node/browser TypeScript — only under Deno's type checker. Likely a difference in how Deno's built-in RequestInit (from lib.deno.fetch.d.ts) interacts with the interface merge compared to the DOM lib RequestInit that ky was developed against.

At runtime, body works correctly — the issue is type-checking only.

[sindresorhus]

Maybe Deno is not using the latest TypeScript version or some TypeScript config is not strict. Hard to say.

[sholladay]

What happens if you import Ky from esm.sh instead of npm?

I realize it's not the canonical way to import in Deno anymore, but historically that has solved a lot of TS issues for me.

Should probably open a Deno issue too, since this seems to imply an inconsistency with browser types.

[leizha]

What happens if you import Ky from esm.sh instead of npm?

Importing from esh.sh indeed passed deno check. I'm not a js expert. Claude to root cause

Options in ky is typed as:
interface Options extends KyOptions, Omit<RequestInit, 'headers'> { ... }

body, signal, mode etc. all come from RequestInit. But the RequestInit that ky sees is different between the two import paths:

npm:ky — Deno type-checks npm packages in a Node.js compatibility context. @types/node is injected automatically, which defines:
type _RequestInit = typeof globalThis extends { onmessage: any } ? {} : undici.RequestInit
interface RequestInit extends _RequestInit {}
In the npm package type-checking environment, Deno does not include lib.dom.d.ts. There's no DOM RequestInit declaration to merge with. So
RequestInit ends up as just {}. Omit<{}, 'headers'> = {}, and all RequestInit fields (body, signal, mode…) vanish from Options.

https://esm.sh/ky — Deno type-checks URL imports in Deno's own context, which includes Deno's built-in fetch types (DOM-like). Here
RequestInit has body?: BodyInit | null, so Omit<RequestInit, 'headers'> is complete, and Options gets all the fetch fields.

Summary

┌────────────────────┬──────────────────────────────┬─────────────────────────────────────┐
│                    │            npm:ky            │          https://esm.sh/ky          │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┤
│ Version            │ 1.14.3                       │ 1.14.3                              │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┤
│ Type file          │ same distribution/index.d.ts │ same distribution/index.d.ts        │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┤
│ RequestInit source │ @types/node → {}             │ Deno's built-in lib → full DOM type │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┤
│ body in Options    │ ✗                            │ ✓                                   │
└────────────────────┴──────────────────────────────┴─────────────────────────────────────┘

The npm:ky error is arguably correct behavior from ky's design perspective — body isn't a ky-specific option, it's inherited from
RequestInit. The esm.sh path silently allows it because Deno's DOM RequestInit leaks through. At runtime both work fine since ky does handle
 body (it passes it to fetch).

[sholladay]

I'm not sure why the type checking for npm: imports wouldn't have RequestInit, as opposed to undici.RequestInit, but either way, this seems like a Deno bug.