Seite 5 - TypeScript

Mit TypeScript 5.2 hielten using und await using Einzug, basierend auf dem TC39-Vorschlag für Explicit Resource Management. Ressourcen wie Dateihandles, Datenbankverbindungen oder Sperren werden damit automatisch und deterministisch freigegeben, sobald der Gültigkeitsbereich verlassen wird.

Ein einzelner Import aus einer schlecht strukturierten TypeScript-Bibliothek kann trotz moderner Bundler mehrere hundert Kilobyte ungenutzten Code ins Konsumenten-Bundle ziehen. Tree Shaking ist keine automatische Bundler-Magie, sondern hängt entscheidend davon ab, wie die Bibliothek selbst gebaut, exportiert und im sideEffects-Feld deklariert wurde.

Ein gutes Onboarding in einer TypeScript-Codebasis unterscheidet sich von klassischer Einarbeitung: Der Compiler ist Lehrer und Gatekeeper zugleich. Wer Onboarding als strukturierten Prozess mit Editor-Setup, tsconfig-Walkthrough und begleitetem Pairing gestaltet, spart Wochen an stiller Verwirrung und macht neue Teammitglieder messbar schneller produktiv.

Der mit TypeScript 4.9 eingeführte satisfies Operator schließt eine Lücke zwischen expliziten Typannotationen und as Type Assertions. Er prüft, ob ein Ausdruck zu einem Typ passt, behält dabei aber den konkreten, engeren Typ des Ausdrucks bei.

Die Context API wirkt auf den ersten Blick einfach, produziert aber in der Praxis eine der häufigsten TypeScript-Fallen in React-Projekten: ein Context ohne echten Default-Wert liefert bei jedem useContext-Aufruf potenziell undefined zurück, und der Compiler zwingt danach an jeder Verwendungsstelle zu Null-Checks, die eigentlich unnötig wären. Dieser Artikel zeigt, wie man die Context API von Anfang an so typisiert, dass fehlende Provider bereits beim Testen auffallen statt erst beim Nutzer.

Lose Markdown Dateien ohne Schema führen dazu, dass ein Tippfehler im Frontmatter erst live auf der Website auffällt, oft an unerwarteter Stelle. Content Collections in Nuxt Content v3 bringen Zod basierte Schema Validierung und automatisch generierte TypeScript Typen mit, sodass genau diese Fehler bereits beim Build sichtbar werden, lange bevor ein Nutzer die Seite sieht.

Eine reine Validierungsfunktion, die nur true oder false zurückgibt, verwirft die einzige Information, die sie durch die Prüfung gewonnen hat, und zwingt den restlichen Code, dieselbe Prüfung an jeder weiteren Stelle zu wiederholen. Dieser Artikel erklärt das Prinzip Parsing statt Validieren, bekannt als Parse, Don't Validate, und zeigt anhand von Refinement Types, verschachtelten Parsern und praktischen TypeScript-Beispielen, wie sich unknown-Zustände dauerhaft aus einer Codebasis entfernen lassen, statt sie immer wieder neu zu prüfen.

Wer Strg-Klick auf einen importierten Typ macht und in einer generierten .d.ts-Datei landet statt im eigenen Quellcode, verliert wertvolle Zeit beim Debugging. Declaration Maps schließen genau diese Lücke und machen aus einer TypeScript-Bibliothek eine Bibliothek, die sich in der IDE anfühlt, als läge der Quellcode direkt im eigenen Projekt.

Hono baut konsequent auf Web-Standard-APIs wie Request und Response statt auf Node-spezifische Typen und laeuft dadurch unveraendert auf Cloudflare Workers, Deno, Bun und Node.js. Der eingebaute RPC-Modus leitet Client-Typen direkt aus der Server-Definition ab, ganz ohne Codegenerierung oder separates Schema.

Wer in TypeScript any verwendet, gewinnt kurzfristig Tempo und verliert dauerhaft Typsicherheit. Wer stattdessen für jeden Typ eine eigene Funktion schreibt, produziert Duplizierung und Wartungsaufwand. Generics lösen dieses Dilemma: eine einzige Funktion, ein einziges Interface, eine einzige Klasse bleibt für beliebige Typen wiederverwendbar und behält dabei die volle Typprüfung des Compilers.