Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Web API type definition issue] `exactOptionalPropertyTypes` makes working with most of the interfaces a nightmare

Open
#2,119 5 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
typescript
Domain
api, web-dev

Research direction

Start by examining the generated lib.dom.d.ts and the Web API dictionary definitions related to RequestInit, using the provided Playground example with exactOptionalPropertyTypes enabled. Done means optional Web API properties correctly accept undefined where the Web IDL rules treat it like an omitted property, without breaking the generated definitions.

Written by the indexing model from the issue text.

Description

lib.d.ts bug
Summary

Optional fields in lib.dom.d.ts do not explicity have undefined in their types, which makes their construction needlessly difficult

Expected vs. Actual Behavior

Expected following code to just work:

function fetchUsers(params?: { signal?: AbortSignal | undefined }) {
  return fetch("/api/v1/user/", { signal: params?.signal });
}

But instead the following error is shown:

Argument of type '{ signal: AbortSignal | undefined; }' is not assignable to parameter of type 'RequestInit' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
  Types of property 'signal' are incompatible.
    Type 'AbortSignal | undefined' is not assignable to type 'AbortSignal | null'.
      Type 'undefined' is not assignable to type 'AbortSignal | null'. (2379)

Following is required to be done instead (let's pretend that RequestInit.signal cannot be set to null):

function fetchUsers(params?: { signal?: AbortSignal | undefined }) {
  const init: RequestInit = {};
  if (params?.signal) {
    init.signal = params.signal;
  }

  return fetch("/api/v1/user/", init);
}
Playground Link

https://www.typescriptlang.org/play/?exactOptionalPropertyTypes=true#code/GYVwdgxgLglg9mABMAplCALAqgZxQJxwAoAHAQ3zIFscB+ALkQG9EcYBzMMgGwcQEEARnHxQAyhy7dEAH0TgAJimAwwKBYgC+ASmYAoRInxoQ+JKnQYiAIgD0ZEjFsA3AIy2QefLesAaZqySPIzklDS0AHRsnDxa2gDceppAA

Browser Support
  • This API is supported in at least two major browser engines (not two Chromium-based browsers).
Have Tried The Latest Releases
  • This issue applies to the latest release of TypeScript.
  • This issue applies to the latest release of @types/web.
Additional Context

See https://webidl.spec.whatwg.org/#idl-dictionaries:

In the JavaScript binding, a value of undefined for the property corresponding to a dictionary member is treated the same as omitting that property.

I have not found a single | undefined on an optional interface field in the entire lib.dom.d.ts of Typescript 5.9.2.

Dominant language
TypeScript
Stars
740
Forks
474
Avg merge
2d 8h
Merged PRs (30d)
15

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/TypeScript-DOM-lib-generator

All issues in microsoft/TypeScript-DOM-lib-generator

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.