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

Abierto
#2,120 2 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
typescript
Área
tooling

Línea de trabajo

Empieza reproduciendo el comportamiento de resolución de tipos informado con lib: ["dom"] y lib: ["dom", "dom.AsyncIterable"], comparando las declaraciones de DOM y Node para ReadableStream. Revisa cómo este repositorio genera los archivos de la biblioteca DOM y define una solución que proporcione referencias de tipos DOM estables sin copias de declaraciones mantenidas manualmente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
740
Forks
474
Merge medio
2 d 8 h
PR fusionados (30 d)
15

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/TypeScript-DOM-lib-generator

Todos los issues de microsoft/TypeScript-DOM-lib-generator

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.