TypeScript meldet einen Fehler, sobald Entwickler Browser-Schnittstellen nutzen, die bisher nur Chrome ausliefert. Der Google-Ingenieur Philip Walton schließt diese Lücke mit dem quelloffenen Paket modern-web-types, das 433 zusätzliche DOM-Interfaces mitbringt. Ob Safari und Firefox eine Schnittstelle kennen, muss danach allein der eigene Code prüfen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
„Property ‚fetchLater‘ does not exist on type ‚Window & typeof globalThis’“: Mit dieser TypeScript-Fehlermeldung scheiterte Philip Walton an einer Schnittstelle, die Chrome seit Version 135 ausliefert. Am 14. September stellte der Google-Ingenieur modern-web-types vor, einen Ersatz für die DOM-Typen von TypeScript.[1]
Das Wichtigste in Kürze
- Das Paket modern-web-types ergänzt jede Web-Schnittstelle, die mindestens ein Browser stabil ausliefert.
- Die Typen stehen unter Apache-2.0-Lizenz und werden jeden Montag automatisch erneuert.
- Für Safari und Firefox braucht der Code weiterhin eine Feature-Abfrage.
Warum kennt TypeScript viele neue Web-APIs nicht?
TypeScript nimmt eine Browser-Schnittstelle erst in seine mitgelieferten DOM-Typen auf, sobald mindestens zwei der drei Engines Blink, Gecko und WebKit sie unterstützen. Microsoft begründet diese Regel mit dem nötigen Konsens der Browserhersteller.[2]
Die Regel trifft gerade die Neuheiten, die Chrome im Alleingang einführt. Nach den Kompatibilitätsdaten von MDN beherrschen nur Chrome und Edge die Funktion fetchLater() für gebündelte Analyse-Anfragen, die Long Animation Frames API zum Messen langer Skripte und View Transitions auf einzelnen Elementen.[3] Die seitenweiten View Transitions unterstützen dagegen alle drei Engines.
Als Notlösung schreiben Teams eigene Typdeklarationen oder schalten die Prüfung mit @ts-ignore ab. Walton hält beides für fehleranfälliger als korrekte, maschinell erzeugte Typen.[1]
Wie arbeitet modern-web-types?
Das Paket modern-web-types lässt Microsofts eigenen Typgenerator zweimal laufen: einmal mit der Zwei-Engine-Regel, einmal mit der Schwelle von einer Engine. Ausgeliefert wird die größere Fassung samt allen offiziellen Typen.[4]
Laut dem Lückenbericht vom 23. September kommen 433 neue Interfaces für das DOM hinzu, dazu 311 Eigenschaften und Methoden an vertrauten Interfaces wie Document, Element oder Navigator.[5] Ein GitHub-Workflow erzeugt die Typen jeden Montag neu und legt Änderungen als Pull Request vor.[4]
Für die Installation genügt ein npm-Alias namens @typescript/lib-dom, nach dem TypeScript seit Version 4.5 für Ersatzbibliotheken sucht.[6] Ab TypeScript 6 schalten Teams zusätzlich die Option libReplacement in der tsconfig.json ein. Das Projekt prüft seine Typen auch gegen den Go-Compiler aus TypeScript 7.[4]
Die etablierte Alternative stammt von Microsoft: @types/web liefert die offiziellen Typen als eigenes npm-Paket und kam in der Woche bis 1. Oktober auf rund 717.000 Downloads.[7] Das Paket modern-web-types zählte im selben Zeitraum 62 Downloads und hat 90 GitHub-Sterne.[4]
Browser-Anteile in Deutschland, September 2026 (alle Geräte)
fetchLater()
Bündelt Analyse-Anfragen für den Versand
Chrome und Edge ab Version 135
Firefox und Safari: nicht unterstützt
Long Animation Frames
Misst lange Skripte für die Ladezeit-Analyse
Chrome und Edge ab Version 123
Firefox und Safari: nicht unterstützt
Element-View-Transitions
Animiert Übergänge innerhalb einzelner Elemente
Chrome und Edge ab Version 147
Firefox und Safari: nicht unterstützt
Die Zwei-Engine-Regel hat Chrome-Neuheiten nie aus dem Produktivcode ferngehalten, nur ihre Typen. Mit modern-web-types kehrt die Typprüfung zurück, die Prüfung im Browser bleibt Handarbeit.
Markus Seyfferth, Chefredakteur Dr. Web
Was müssen Webteams in Deutschland beachten?
Die Typen bestätigen nur, dass mindestens ein Browser die Schnittstelle kennt. In Deutschland liefen im September rund 25 % der Seitenaufrufe über Safari und Firefox, deshalb gehört vor jeden Aufruf einer Chrome-Schnittstelle eine Feature-Abfrage.[8]
Als Vorbild nennt Walton die Core Web Vitals, deren Messschnittstellen viele Websites schon nutzten, als nur Chrome sie kannte.[1] Largest Contentful Paint unterstützt Chrome seit Version 77, Firefox seit Version 122 und Safari seit Version 26.2. Die Layout-Shift-Messung läuft bis heute nur in Chromium.[3] Ein Skript ohne Abfrage wie if ('fetchLater' in window) bricht in Safari mit einem Fehler ab.
Agenturen und Inhouse-Teams koppeln das Paket am besten mit dem Linter eslint-plugin-baseline-js, der Code außerhalb des gewählten Baseline-Ziels meldet.[9] Wie Baseline-Stufen in der Praxis aussehen, zeigen die Beispiele der CSS-Funktionen ohne Build-Schritt und der Randnotizen per Anchor Positioning. Welche Browser in die Testmatrix gehören, verrät der Browser-Vergleich für den DACH-Raum.
Quellen
[1] Philip Walton: „Modern Web Types“
[2] GitHub, microsoft/TypeScript-DOM-lib-generator: „Why is my fancy API still not available here?“
[3] GitHub, MDN: „browser-compat-data“
[4] GitHub: „philipwalton/modern-web-types“
[5] GitHub, philipwalton/modern-web-types: „Gap report“
[6] TypeScript: „TSConfig Option: libReplacement“
[7] npm: „@types/web“
[8] StatCounter: „Browser Market Share Germany“
[9] GitHub: „3ru/eslint-plugin-baseline-js“
Mehr Newshunger?
- vgpu: eine WebGPU-Bibliothek, gebaut für Coding-Agenten
- Sidenotes mit CSS Anchor Positioning: Randnotizen ohne JavaScript
- 12 CSS-Funktionen, die Sie ohne Build-Schritt nutzen können
- GitHub verbessert die Website-Performance mit mehr CSS statt CSS-in-JS
- Firefox 157 im Nova-Design: Mozilla holt den Kompaktmodus aus dem Versteck
