Seite 5 - TypeScript

tsconfig.json ist die zentrale Steuerzentrale jedes Projekts mit TypeScript und entscheidet über Kompatibilität, Fehlerstrenge und Buildgeschwindigkeit. Dieser Artikel erklärt die wichtigsten Optionen wie target, module, strict, esModuleInterop und skipLibCheck im Detail, liefert eine sinnvolle Basiskonfiguration für neue Projekte und zeigt, wie sich Konfiguration mit extends sauber über ein Monorepo teilen lässt.

TypeScript leitet die meisten Typen automatisch aus Literalen, Rückgabewerten und dem umgebenden Kontext ab, ohne dass Entwickler jede Variable manuell annotieren müssen. Dieser Artikel zeigt, wie die Inferenz-Engine des Compilers tatsächlich arbeitet, wann automatisch abgeleitete Typen ausreichen und wann explizite Annotationen die Codequalität und Wartbarkeit spürbar verbessern.

Wer document.querySelector Ergebnisse pauschal mit as any oder as HTMLInputElement erzwingt, verliert genau die Typsicherheit, die TypeScript eigentlich verspricht. Dieser Artikel zeigt, wie DOM-Elemente, Events, Formulare und Custom-Data-Attribute mit den eingebauten lib.dom.d.ts Typen, echten Null-Prüfungen, sauberen Type Guards und typisierten Event-Listenern korrekt abgesichert werden, damit der Compiler echte Fehler findet statt sie mit any zu verstecken.

Wer aus der Magento- oder Symfony-Welt kommt, kennt Dependency Injection bereits aus di.xml und dem Service Container. Dieser Artikel zeigt, wie sich dasselbe Prinzip in TypeScript-Projekten umsetzen lässt, mit Constructor Injection als Standardpattern, Interfaces als Verträgen für testbaren Code und der Entscheidung, wann ein DI-Container wie InversifyJS wirklich nötig ist.

Ein uneingeschränkter Generic-Typparameter erlaubt fast alles und verhindert dadurch jeden sinnvollen Zugriff auf Eigenschaften oder Methoden. Mit dem extends Schlüsselwort, keyof und durchdachten Default-Werten lassen sich Typparameter gezielt eingrenzen, sodass der Compiler echte Fehler findet und Entwickler beim Schreiben von Code verlässliche Autovervollständigung erhalten. Der Artikel zeigt anhand einer typsicheren pick-fields Funktion, wie diese Konzepte zusammenspielen.

Wer Testdaten als lose getippte Objektliterale schreibt, riskiert stillen Verfall, sobald sich der zugrunde liegende Domain-Type ändert und ein neues Pflichtfeld entsteht. Typsichere Factory-Funktionen mit Partial-T und sinnvollen Defaults zentralisieren Testdaten an einer Stelle, erzwingen Synchronität mit dem echten Interface und halten Vitest-Suiten über hunderte Testdateien hinweg wartbar und konsistent.

Das infer Schlüsselwort ist der Schlüssel zu vielen TypeScript Utility Types und erlaubt es, Teiltypen wie das Resultat eines Promise oder die Parameter einer Funktion direkt aus einem bestehenden Typ zu extrahieren, ohne sie manuell zu duplizieren. Wer versteht, wie infer innerhalb conditional types arbeitet, kann eigene Utility Types bauen, Duplikate vermeiden und Typen automatisch synchron zu ihrer Quelle halten.

Die Wahl der TypeScript Laufzeit entscheidet direkt über Entwicklerproduktivität und Build Geschwindigkeit im Alltag. Dieser Artikel vergleicht die drei gängigsten Optionen für Node.js Projekte anhand von Startzeit, Typprüfung und Watch Mode Unterstützung und zeigt, wann eine vollständige Typprüfung während der Ausführung wirklich nötig ist und wann ein schneller Feedback Zyklus für einmalige Skripte, lokale Entwicklung und CI Pipelines die bessere Wahl ist.

Wer any unkontrolliert im Code verteilt, hebelt die Typprüfung genau an den Stellen aus, an denen sie am wichtigsten wäre. Dieser Artikel zeigt den praktischen Weg zu einer typsicheren Codebase: noImplicitAny gezielt aktivieren, ESLint-Regeln schrittweise verschärfen, unknown und Generics als Ersatz nutzen und den Fortschritt mit type-coverage messbar machen, ohne die laufende Entwicklung zu blockieren.

Conditional Types erlauben es, den Typ eines Ausdrucks von einer Bedingung über einen anderen Typ abhängig zu machen. Sie stecken hinter fast jedem eingebauten Utility-Type wie Exclude, ReturnType oder Awaited und lösen Probleme, die sonst nur mit Type Assertions oder doppeltem Code lösbar wären. Dieser Artikel zeigt Syntax, Praxisfälle und die Grenze zur Lesbarkeit.