Seite 2 - TypeScript

Alpine.js macht x-data bewusst ungetypt, was in kleinen Snippets kein Problem ist, aber in größeren Hyvä-Komponenten schnell zu stillen Bugs, falschen Property-Namen und schwer wartbarem Code führt. Dieser Artikel zeigt typisierte Factory-Functions, JSDoc-basierte Typisierung ohne Build-Step und ein leichtgewichtiges TypeScript-Pattern, das CSP-konform bleibt, Hyvä's No-Build-Philosophie respektiert und trotzdem echte Typsicherheit für Teams und komplexe Komponenten liefert.

TypeScript prüft Typen anhand ihrer Form, nicht anhand ihres Namens. Eine UserId und eine OrderId sind für den Compiler identisch, solange beide als string deklariert sind, und lassen sich deshalb versehentlich vertauschen. Branded Types schließen genau diese Lücke, indem sie einem strukturellen Typsystem eine nominale Unterscheidung hinzufügen, komplett ohne Laufzeitkosten.

Wer TypeScript in Node.js-Projekten einsetzt, stößt schnell auf widersprüchliche Ratschläge zu tsc, ts-node, ESM und CommonJS. Dieser Artikel zeigt die praktischen Optionen zum Ausführen von TypeScript in Node, klärt die Modul-Interop-Fallstricke zwischen ESM und CommonJS und liefert eine minimale, funktionierende tsconfig für CLI- und Build-Skript-Projekte, inklusive des nativen Type-Stripping-Supports neuerer Node-Versionen.

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.

Ein TypeScript-Review, das nur auf Syntax achtet, übersieht die eigentlichen Risiken: any-Creep, unnötige as-Assertions, unlesbare Generic-Konstruktionen und Non-Null Assertions, die echte Fehlerquellen maskieren. Dieser Artikel zeigt die wichtigsten Red Flags erfahrener Reviewer, eine praktische Checkliste und einen Weg, Typsicherheit und Review-Tempo im Gleichgewicht zu halten.

Wer TypeScript nur als PHP mit Typen begreift, stolpert schnell über strukturelle Typprüfung, Referenzsemantik bei Objekten und fehlende Nominal-Typisierung. Dieser Artikel erklärt den fundamentalen Unterschied zwischen primitiven und Object Types, zeigt TypeScripts Duck-Typing-Philosophie im direkten Vergleich zu PHP und macht die häufigsten Denkfehler beim Umstieg sichtbar.

Die paths-Option in tsconfig.json macht Importe wie @/components lesbar und stabil, löst aber nur die Typprüfung, nicht die Modulauflösung zur Laufzeit. Dieser Artikel zeigt, wie Aliase korrekt bis in Vite, Webpack, Node und Testrunner durchgezogen werden, damit nach dem Build kein Modul-nicht-gefunden-Fehler mehr auftaucht.

Wer Jest ohne saubere TypeScript-Anbindung einsetzt, verliert die entscheidenden Vorteile von Typsicherheit genau dort, wo Fehler am teuersten sind, nämlich in Tests und Mocks. Dieser Artikel zeigt, wie sich ts-jest und babel-jest unterscheiden, wie jest.config.ts typsicher aufgesetzt wird und wie Mock-Funktionen, Modul-Mocks und Klassen-Mocks mit echten Typen statt any geschrieben werden.

Wer TypeScript-Typen manuell parallel zu Objekten und Konstanten pflegt, produziert früher oder später Drift zwischen Code und Typdefinition. Die Operatoren keyof und typeof leiten Typen direkt aus vorhandenen Werten und Interfaces ab, sodass sich Objektschlüssel, Konfigurationswerte und literale Optionen automatisch synchron halten und der Compiler Tippfehler bei Property-Zugriffen zuverlässig ablehnt.

Template Literal Types kombinieren String-Literal-Typen zu neuen Literal-Typen und machen aus laxen string-Parametern präzise, überprüfbare Vertragsformen. Event-Namen, CSS-Klassenkombinationen, Routen-Pfade und Konfigurationsschlüssel lassen sich damit bereits beim Kompilieren validieren, lange bevor ein falscher String zur Laufzeit einen stillen Bug erzeugt oder ein Kunde einen kaputten Link anklickt.