Antwort.

Hintergrund

TypeScript wurde ursprünglich mit der Möglichkeit entwickelt, einen möglichst nahtlosen Übergang von JavaScript zu ermöglichen, weshalb Variablen oder Parameter ohne explizit angegebenen Typ standardmäßig den Typ any erhielten. Dies erleichterte die Migration, verringerte jedoch die Vorteile der statischen Typisierung. Um die Zuverlässigkeit und Vorhersehbarkeit des Codes zu erhöhen, hat das TypeScript-Team das Compiler-Flag noImplicitAny eingeführt, das erfordert, dass die Typen explizit angegeben werden oder dass TypeScript in der Lage ist, sie korrekt abzuleiten.

Problem

Wenn noImplicitAny deaktiviert ist, können Entwickler versehentlich das explizite Angeben des Typs einer Variablen, eines Parameters oder eines Rückgabewerts einer Funktion übersehen. Dies macht den Code weniger sicher und erschwert das Refactoring: Alle typbezogenen Fehler werden zur Laufzeit und nicht während der Kompilierung erkannt.

Lösung

Das Aktivieren von noImplicitAny in der Datei tsconfig.json zwingt den TypeScript-Compiler, bei jeder impliziten Verwendung des Typs any einen Fehler auszugeben. Dies erfordert von den Entwicklern, dass sie auf die Typen achten, macht die Refactoring-Prozesse weniger riskant und den Code zuverlässiger.

Beispielcode:

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// Beispiel für eine Funktion ohne Typangabe des Parameters
function printUser(user) {
  console.log(user.name); // Kompilierungsfehler, wenn kein Typ angegeben
}

// Korrekt:
function printUser(user: { name: string }) {
  console.log(user.name);
}

Wesentliche Merkmale:

Erfordert das explizite Angeben der Typen an allen mehrdeutigen Stellen.
Ermöglicht die Auffindung der meisten Typfehler zur Kompilierungszeit.
Gewährleistet hohe Vorhersehbarkeit und Sicherheit des Codes in großen Projekten.

Trickfragen.

Verhindert das Aktivieren von noImplicitAny immer alle potenziellen Typfehler im Projekt?

Nein, dieses Flag beseitigt nur implizite any. Die explizite Verwendung von any ist weiterhin erlaubt. Für vollständigen Schutz sollte auch das explizite any durch Linting und Reviews eingeschränkt werden.

Wenn der Typ automatisch abgeleitet wird, gibt es trotzdem eine Fehlermeldung von noImplicitAny?

Nein, wenn TypeScript den Typ korrekt ableiten konnte (z.B. durch Initialisierung), gibt es keinen Fehler. Beispiel:

let n = 123; // Typ number, nicht any

Aktiviert strict automatisch noImplicitAny?

Ja, das Flag strict aktiviert viele strenge Prüfungen, einschließlich noImplicitAny. Es kann jedoch manuell deaktiviert werden, wenn erforderlich.

Typische Fehler und Antipatterns

An vielen Stellen explizites any zu belassen — der Sinn der strengen Typisierung geht verloren.
In großem Code das Projekt nicht mit noImplicitAny auszuführen und sich auf "wird schon gutgehen" zu verlassen — viele versteckte Fehler.
Typen "irgendwie, Hauptsache es kompiliert" hinzuzufügen, ohne über die Richtigkeit nachzudenken.

Fallbeispiel aus der Praxis

Negativer Fall

Im Projekt ist noImplicitAny deaktiviert, die meisten API-Handler akzeptieren Parameter ohne expliziten Typ. Bei der Implementierung neuer Geschäftslogiken machen Entwickler Fehler bei den Eigenschaftsnamen, die Fehler treten jedoch erst in der Produktionsumgebung auf.

Vorteile:

Einfacher und schneller Start des Codes.
Einfachere Migration von JS.

Nachteile:

In der Produktionsumgebung tauchen Fehler auf, die statisch gefunden werden könnten.
Refactoring und Skalierung werden komplizierter.

Positiver Fall

Nach der Aktivierung von noImplicitAny wurde der gesamte Code schrittweise refaktoriert, implizite any wurden beseitigt. Ein Editor mit Typhighlighting und Autovervollständigung wurde verwendet. Neu auftretende Fehler werden sofort während des Builds behoben.