Type-Aliase und Namenstypen

Was Type-Aliase sind

Ein Type-Alias vergibt einen Namen für einen Typ-Ausdruck. Die Syntax startet mit dem Schlüsselwort type, gefolgt von einem Bezeichner, einem Gleichheitszeichen und dem zu benennenden Typ. Der Alias ist ein reines Compiler-Konstrukt — zur Laufzeit existiert er nicht und erzeugt keinen Code.

type T_UserId = string;
type T_Coord = { x: number; y: number };
type T_Status = "ok" | "error" | "pending";

Anders als interface, das ausschließlich Objektformen beschreibt, darf rechts vom Gleichheitszeichen jede beliebige Typ-Konstruktion stehen: Primitive, Unions, Intersections, Tuples, Funktionstypen, Mapped Types, Conditional Types. Diese Breite macht den Alias zum universellen Werkzeug der Typkomposition.

Wichtig: ein Alias ist strukturell. TypeScript prüft beim Vergleich nicht den Namen, sondern die Form. T_UserId und string sind aus Compiler-Sicht identisch — ein Wert vom Typ string lässt sich ohne Cast einer Variable vom Typ T_UserId zuweisen und umgekehrt.

Basis-Syntax

Aliase eignen sich für Primitives, für Literal-Unions und für jede Mischung daraus. Sie machen aus kryptischen Typ-Ausdrücken sprechende Namen.

type T_Email = string;
type T_Age = number;
type T_HttpMethod = "GET" | "POST" | "PUT" | "DELETE" | "PATCH";
type T_Result = T_Success | T_Failure;

type T_Success = { ok: true; value: number };
type T_Failure = { ok: false; reason: string };

Hoisting funktioniert auch für Typen: T_Result darf vor seinen Bestandteilen stehen — der Compiler löst zirkuläre Referenzen im Rahmen der weiter unten beschriebenen Regeln auf.

type T_Handler = (event: string, payload: unknown) => void;
type T_Predicate<T> = (value: T) => boolean;
type T_RgbTuple = readonly [number, number, number];
type T_Pair<K, V> = readonly [K, V];

Diese Kategorien sind mit interface schlicht nicht ausdrückbar — sie sind die Domäne des Type-Alias.

Aliase für Objekt-Typen

Für reine Objektformen ist ein Type-Alias semantisch nahezu gleichwertig zu interface. Beide sind strukturell, beide erlauben optionale und readonly-Properties, beide sind in extends-Klauseln und Generics einsetzbar.

type T_User = {
    readonly id: number;
    name: string;
    email?: string;
};

const u: T_User = { id: 1, name: "Anna" };

Zwei sichtbare Unterschiede bleiben: interface unterstützt Declaration Merging — derselbe Interface-Name darf mehrfach deklariert werden und die Felder addieren sich. Bei type ist das ein Duplicate-Identifier-Fehler. Umgekehrt erlaubt type Unions und Intersections direkt, was interface nicht kann.

type T_Identifiable = { id: number };
type T_Named = { name: string };

type T_Entity = T_Identifiable & T_Named;

const e: T_Entity = { id: 1, name: "Foo" };

Generische Type-Aliase

Type-Aliase nehmen Typ-Parameter entgegen — analog zu generischen Funktionen oder Klassen. Damit lassen sich Container-Strukturen einmal beschreiben und beliebig spezialisieren.

type T_Box<T> = { value: T };

const a: T_Box<string> = { value: "hello" };
const b: T_Box<number[]> = { value: [1, 2, 3] };

Mehrere Type-Parameter und Defaults sind möglich. Eine extends-Constraint schränkt die zulässigen Typ-Argumente ein.

type T_Result<TOk, TErr extends Error = Error> =
    | { ok: true; value: TOk }
    | { ok: false; error: TErr };

const r1: T_Result<number> = { ok: true, value: 42 };
const r2: T_Result<number, TypeError> = {
    ok: false,
    error: new TypeError("nope")
};

Generische Aliase sind das Fundament fast aller Utility-Types — Partial<T>, Pick<T, K> oder Record<K, V> sind nichts anderes als generische Type-Aliase mit Mapped-Type-Body.

type T_Nullable<T> = T | null;
type T_Maybe<T> = T | null | undefined;
type T_KeysOf<T> = keyof T;
type T_PromiseOr<T> = T | Promise<T>;

Rekursive Aliase

Seit TypeScript 3.7 darf ein Type-Alias sich selbst referenzieren — solange die Rekursion über einen Objekt- oder Array-Typ vermittelt wird. Direkter Self-Reference wie type T = T bleibt ein Fehler. Diese Lockerung erlaubt es, Baum- und JSON-Strukturen ohne Helfer-Interfaces auszudrücken.

type T_JsonValue =
    | string
    | number
    | boolean
    | null
    | T_JsonValue[]
    | { [key: string]: T_JsonValue };

const data: T_JsonValue = {
    name: "Anna",
    age: 30,
    roles: ["admin", "user"],
    meta: { active: true, score: null }
};

Vor TS 3.7 brauchte es einen Umweg über ein leeres Interface — heute gehört dieser Trick der Vergangenheit an.

type T_TreeNode<T> = {
    value: T;
    children: T_TreeNode<T>[];
};

const tree: T_TreeNode<string> = {
    value: "root",
    children: [
        { value: "a", children: [] },
        { value: "b", children: [{ value: "b1", children: [] }] }
    ]
};

Wichtig: die Rekursion muss durch Objekt- oder Array-Indirection laufen. Eine direkte Union wie type T_X = string | T_X wird vom Compiler verweigert, weil die Auflösung nicht terminiert.

Aliase vs. interface

Die Unterschiede sind in der Praxis überschaubar — beide sind strukturell, beide unterstützen Generics, beide tauchen im Tooling saüber auf. Die Entscheidung fällt meist nach Stil-Präferenz und Use-Case.

Faustregel: interface für exportierte, von Konsumenten erweiterbare Verträge; type für Komposition, Unions und alles, was kein reines Objekt ist. Eine vertiefte Gegenüberstellung steht im Artikel type vs. interface.

Branded Types

TypeScript ist structural — das bedeutet: type T_UserId = string und type T_OrderId = string sind aus Compiler-Sicht identisch und beliebig austauschbar. Für Domänen-Modelle ist das oft zu lax: man möchte verhindern, dass eine OrderId versehentlich dort landet, wo eine UserId hingehört. Die Lösung heißt Branded Types (auch „Nominal Types simulieren"): an einen Strukturtyp wird ein Phantom-Property gehängt, das nur im Typ existiert.

type T_UserId = string & { readonly __brand: "UserId" };
type T_OrderId = string & { readonly __brand: "OrderId" };

const u: T_UserId = "u_123" as T_UserId;
const o: T_OrderId = "o_456" as T_OrderId;

function loadUser(id: T_UserId): void { /* ... */ }

loadUser(u);                    // + ok
loadUser(o);                    // − Fehler: OrderId ist nicht UserId
loadUser("u_123");              // − Fehler: rohe Strings verboten

Das __brand-Feld existiert zur Laufzeit nicht — es ist ein reines Typ-Konstrukt. Beim Erzeugen ist eine as-Assertion unvermeidbar; sauberer als verstreute Casts ist eine Factory-Funktion, die Validierung und Branding kapselt.

function makeUserId(raw: string): T_UserId {
    if (!/^u_[a-z0-9]+$/.test(raw)) {
        throw new Error(`Invalid UserId: ${raw}`);
    }
    return raw as T_UserId;
}

const id = makeUserId("u_42");
loadUser(id);                   // + saüber gebrandet

Branded Types sind ideal für IDs, Einheiten (Meter, Seconds), sanitisierte Strings (HtmlSafeString) oder validierte Werte. Sie kosten an der Konstruktionsstelle minimal Aufwand und schaffen dafür eine Typ-Grenze, die der Compiler durchsetzt.

Re-Export von Type-Aliasen

Type-Aliase lassen sich wie Werte exportieren — mit dem Unterschied, dass export type und import type rein typseitig sind und im emittierten JavaScript keinerlei Spur hinterlassen. Das ist besonders wichtig, wenn isolatedModules oder verbatimModuleSyntax aktiv sind, weil der Compiler dann nicht raten muss, welche Imports Werte und welche Typen sind.

// user.ts
export type T_User = {
    id: number;
    name: string;
};

export type T_UserRole = "admin" | "editor" | "viewer";

// consumer.ts
import type { T_User, T_UserRole } from "./user";

const u: T_User = { id: 1, name: "Anna" };
const r: T_UserRole = "admin";

Mit import type ist garantiert, dass kein Runtime-Import entsteht — der Bundler kann das Statement vollständig elidieren. Wer Werte und Typen aus demselben Modul importiert, kann inline annotieren.

import { createUser, type T_User } from "./user";

const u: T_User = createUser("Anna");

Seit TypeScript 5.0 erzwingt die Option verbatimModuleSyntax diesen expliziten Stil — jedes Typ-Import muss als type markiert sein, andernfalls bleibt es ein Werte-Import mit Runtime-Auswirkung.

Aliasing als Doku

Der praktische Mehrwert eines Type-Alias liegt oft weniger im Typsystem als in der Lesbarkeit. Ein wiederkehrender Typ-Ausdruck wie string | number | null verbraucht Aufmerksamkeit; ein Alias T_Scalar macht aus dem Rauschen einen Begriff.

function format(value: string | number | null): string { /* ... */ }
function parse(input: string): string | number | null { /* ... */ }
function isEmpty(v: string | number | null): boolean { /* ... */ }

type T_Scalar = string | number | null;

function format(value: T_Scalar): string { /* ... */ }
function parse(input: string): T_Scalar { /* ... */ }
function isEmpty(v: T_Scalar): boolean { /* ... */ }

Faustregel: wenn derselbe Typ-Ausdruck zweimal im Code vorkommt, bekommt er einen Namen. Aliase sind kostenlos zur Laufzeit, machen Refactoring trivial und liefern bei Fehlern eine sprechende Marke in der Compiler-Ausgabe.

Weiterführende Ressourcen

Externe Quellen

• Type Aliases – TypeScript Handbook
• TypeScript 3.7 Release Notes (Recursive Aliases)
• verbatimModuleSyntax – tsconfig

Verwandte Artikel

• type vs. interface
• Type System – Übersicht
• Interfaces – Grundlagen
• Komplexe Typen – Übersicht
• Utility Types – Übersicht