Kapitel 3 hat tsconfig.json mit einer schlanken Basis-Konfiguration eingerichtet. Jetzt, mit dem gesamten Sprachwissen dieses Tutorials, schauen wir uns die EINZELNEN strict-Flags genauer an – WAS sie konkret prüfen und WARUM.

Was strict: true tatsächlich aktiviert

"strict": true ist eine SAMMEL-Option, die mehrere EINZELNE Flags gleichzeitig aktiviert. Die wichtigsten davon einzeln betrachtet:

// strictNullChecks: OHNE dieses Flag wäre folgendes GÜLTIG (aber gefährlich):
function findeBuch(isbn: string): Buch | undefined { /* ... */ return undefined; }
const buch = findeBuch('123');
console.log(buch.titel); // MIT strictNullChecks: Fehler! buch könnte undefined sein
                          // OHNE strictNullChecks: kein Fehler, potenzieller Laufzeit-Crash

strictNullChecks ist WOHL das wichtigste Einzelflag – es erzwingt GENAU die Art von Prüfungen, die wir seit Kapitel 6 (optionale Parameter) durchgehend gemacht haben. OHNE dieses Flag wäre string | undefined praktisch bedeutungslos, da TypeScript den undefined-Fall NICHT erzwingen würde.

// noImplicitAny: OHNE dieses Flag wäre folgendes GÜLTIG:
function verarbeite(daten) { // Parameter OHNE Typ -> wird implizit 'any'
  return daten.irgendwas.tuDinge(); // KEINE Typprüfung, da 'any'
}
// MIT noImplicitAny (Teil von strict): Fehler - 'daten' braucht eine explizite Annotation

noImplicitAny verhindert GENAU das Problem aus Kapitel 4/5: Variablen/Parameter, die STILLSCHWEIGEND zu any werden, weil niemand eine Annotation hinzugefügt hat – ohne dieses Flag würde TypeScript SCHWEIGEND auf die Typprüfung verzichten, statt einen Fehler zu zeigen.

Weitere nützliche Flags außerhalb von strict

{
  "compilerOptions": {
    // ... bisherige Optionen aus Kapitel 3
    "noUnusedLocals": true,      // Fehler bei UNGENUTZTEN lokalen Variablen
    "noUnusedParameters": true,  // Fehler bei UNGENUTZTEN Funktionsparametern
    "noImplicitReturns": true,   // Fehler, wenn NICHT ALLE Codepfade einer Funktion einen Wert zurückgeben
    "noFallthroughCasesInSwitch": true // Fehler bei vergessenem 'break' in switch-Statements
  }
}

Diese Flags sind NICHT Teil von strict, aber in vielen professionellen Projekten zusätzlich aktiviert – sie fangen KEINE Typfehler im engeren Sinne, sondern häufige STIL- und LOGIK-Fehler, die TypeScript technisch erlauben würde.

tsconfig-Vererbung mit extends

Erinnern Sie sich an "extends": "expo/tsconfig.base" aus "React Native für Profis" Kapitel 12? Dasselbe Prinzip funktioniert für JEDE tsconfig.json, auch selbst erstellte:

{
  "compilerOptions": {
    "target": "ES2022",
    "strict": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "dist",
    "rootDir": "src"
  },
  "include": ["src/**/*"]
}

In größeren Projekten mit MEHREREN TypeScript-Konfigurationen (z. B. eine für Produktions-Code, eine für Tests mit anderen Einstellungen) vermeidet extends Duplikation der GEMEINSAMEN Basis-Optionen.

Bonus: typescript-eslint für zusätzliche Regeln

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

tsc --noEmit (Kapitel 2) prüft TYPFEHLER. typescript-eslint geht darüber hinaus und prüft zusätzlich CODE-STIL-Regeln, die TYPESKRIPT-spezifisch sind (z. B. "nutze type konsequent für Typ-Only-Importe", GENAU die Konvention aus Kapitel 24) – ein oft ergänzendes, nicht konkurrierendes Werkzeug zu tsc selbst.