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

Aperta
#2,120 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
typescript
Ambito
tooling

Direzione di ricerca

Inizia riproducendo il comportamento di risoluzione dei tipi segnalato con lib: ["dom"] e lib: ["dom", "dom.AsyncIterable"], confrontando le dichiarazioni DOM e Node per ReadableStream. Esamina come questo repository genera i file della libreria DOM e definisci una soluzione che fornisca riferimenti ai tipi DOM stabili senza copie di dichiarazioni mantenute manualmente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
740
Fork
474
Merge medio
2g 8h
PR unite (30g)
15

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/TypeScript-DOM-lib-generator

Tutte le issue di microsoft/TypeScript-DOM-lib-generator

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.