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

Add `DOM` namespace to prevent shadowing by Node global types (e.g. `ReadableStream`)?

Open
#2,120 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
typescript
Domain
tooling

Research direction

Start by reproducing the reported type-resolution behavior with lib: ["dom"] and lib: ["dom", "dom.AsyncIterable"], comparing the DOM and Node declarations for ReadableStream. Review how this repository generates DOM library files and define a solution that provides stable DOM type references without manually maintained declaration copies.

Written by the indexing model from the issue text.

Description

I'm maintaining libs that target both browsers and Node (through different bundles, but the source code is shared).
I'm bumping into problems specifically with the type definitions of streams, e.g. ReadableStream, which are declared globally both by @types/node and the dom lib.
While I can specify access to the Node declaration via NodeJS.ReadableStream, the same is not true for the dom one, which results in non-deterministic behavior about whether ReadableStream gets resolved as dom or Node (which are not compatible). I need a way to reference a ReadableStream type that will always resolve to the DOM types, and I thought adding the option to refer to it by namespace could be a simple solution.

As an example of the issue I am experiencing: if I use lib: ["dom"] in the tsconfig, the dom declaration is picked up, but if I instead declare lib: ["dom", "dom.AsyncIterable"], then the Node types take precedence. I assume this has to do with types/dependency order resolution, but it is obviously problematic, esp. when it comes to dependents of my libs, who will also have to deal with type resolution issues based on their tsconfigs.

I'd love to see a solution around this that does not involve copying the DOM types to .d.ts files I manually maintain in the repo; I have done this in the past and it is quite disruptive, as I'd like to support several typescript versions.

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.