Strict Mode
Standardmässig war lange Zeit bei TypeScript Projekten keine strikte Typenprüfung (bekannt als: “Strict Mode”) aktiviert. Durch das Fehlen dieser strikten Prüfung bleiben unschöne Code-Snippets vom TypeScript Compiler erlaubt. Es herrscht ein Hauch von antiautoritärer Erziehung im Software-Business, ohne diesen aktivierten Modus nach dem Motto: “Mach mal – es wird schon nichts passieren”. Nur leider passiert es dann eben doch oft – die Rede ist von unerwartet fehlerhaftem Verhalten aufgrund fehlender Definitionen.
Nachfolgende TypeScript Klasse ist im default mode (auch “schlampiger Modus” genannt) möglich:
Spoiler-Alert: Wird nun auf einem “Beer”-Objekt die Methode “isNonAlcoholic()” aufgerufen, kann es sein, dass zu diesem Zeitpunkt der Alkoholgehalt – also der Member “alcoholByVolume” nicht initialisiert wurde und das Programm verhält sich fehlerhaft.
Wir versuchen’s trotzdem mal:
🤔 Ist das “Bier” alkoholfrei?
Die Antwort nach dem obigen Programm lautet zweimal: “false”.
Aber das “Ginger-Beer” ist doch alkoholfrei? Was läuft hier falsch?
Auf dem Objekt Beer ist “alcoholByVolume” als number definiert. Das Ginger-Beer hatte jedoch den Member “alcoholByVolume” nicht initialisiert. TypeScript (resp. JavaScript) liefert “false” für den Vergleich “undefined < 0.5” zurück.
Fazit zum Default Mode
Ohne “Strict Mode” fehlt dem TypeScript Compiler die Möglichkeit uns Software Entwickler:innen vor unerwarteten Fehler aufgrund fehlender Definitionen zu bewahren.
So bleibt das Ginger-Beer alkoholfrei
Hätten wir den Strict-Mode aktiviert gehabt, hätte uns die IDE vor dem Compile-Error warnen können. Hätte man diese Warnung der IDE ignoriert, hätte spätestens der Compiler uns auf das Problem aufmerksam gemacht mit einer Fehlermeldung beim Build-Process.
Schlussendlich hätten wir mit zwei Änderungen die Klasse angepasst:
(1) Der Member “alcoholByVolume” wird mit dem Typ undefined erweitert. Er wird hiermit zu einem sogenannten “Optional Member”.
(2) In der Methode wird vor dem Zugriff auf “alcoholByVolume” geprüft, ob der Member undefined ist – falls ja, wird direkt true zurückgegeben.
Was ist der “Strict Mode” in TypeScript?
TypeScript selbst definiert das Aktivieren der “Strict Flags” wie folgt:
So aktivierst du den “Strict Mode”
Setze das “strict” Flag auf “true” im File “tsconfig.json” – damit werden sämtliche Strict-Checks aktiviert.
Diese Strict-Checks werden unterstützt
Auf nachfolgender Webseite werden sämtliche Strict-Checks aufgeführt: https://www.typescriptlang.org/tsconfig/#strict 
.
noImplicitAnynoImplicitThisstrictNullChecksstrictPropertyInitializationstrictBindCallApplystrictFunctionTypes
Empfehlung
Neues Projekt
Es ist bestimmt sinnvoll, wenn man den “Strict Mode” bei neuen TypeScript-Projekten von Anfang an aktiviert hat. Somit spart man sich viel Zeit und Ärger. Zudem steigt die Qualität von Softwareprojekten immens und einige Softwareentwickler:innen werden zusätzlich wichtige JavaScript und TypeScript Lektionen lernen. Es ist also ein erster Schritt in die richtige Richtung und es macht eine sehr gutmütige Programmiersprache etwas strenger und damit stabiler.
Bestehendes Projekt
Bei einem Projekt, welches bereits vor einiger Zeit gestartet wurde, steht man als Entwickler:in vor einem Dilemma. Einerseits will man bestmögliche Qualität – etwa durch die Aktivierung des Strict-Modes. Andererseits will man keine grossen Refactorings dafür machen müssen. Und eigentlich sieht alles auch ziemlich harmlos aus: Nur ein Flag in einem JSON-File auf true setzen – Wo ist hier das Problem? Wer es schon mal in einem grösseren Projekt gemacht hat, weiss was das Problem ist: Der Compiler builded das Projekt nicht mehr. Nicht wegen einem Fehler und auch nicht wegen ein paar Fehlern, sondern womöglich eher wegen ein paar hundert oder tausend Fehler. Niemand hat Zeit und Lust alle diese verketteten Probleme zu lösen und tagelang Members zu initialisieren, auf Typen zu prüfen und vieles mehr.
Eine clevere Lösung bietet sich hier je nach Projekt trotzdem an unter der Voraussetzung, dass der aktuelle Projektstand korrekt ist – und zwar wie folgt:
- Aktiviere den Strict Mode
- Füge auf allen *.ts-Files auf der ersten Zeile “// @ts-nocheck” ein (das kann man natürlich gut mit einem Bash Script oder ähnlich automatisiert machen).
- Füge auf deinem GIT Repository einen Server Hook ein, welcher zukünftige Commits mit File-Content “// @ts-nocheck” ablehnt
Was passiert da genau?
Unsere Grundidee dahinter ist, dass man Altes so belässt wie es ist und Neues mit der hilfreichen und stabileren Strict-Mode Prüfung entwickelt. Durch das einfügen von “// @ts-nocheck” (Schritt 2) ignoriert der TypeScript Compiler sämtliche checks der jeweiligen Datei. Da wir dies für sämtliche bestehenden *.ts Dateien machen, haben wir quasi den Strict Mode aktiviert und trotz der tausenden Fehler funktioniert der Build des Projekts weiterhin. Mit dem Server Hook (Schritt 3) wird sichergestellt, dass zukünftig keine Datei auf den Repository Server gepushed werden darf, welche unseren “// @ts-nocheck”-Hack beinhaltet. Ändert man also etwas an einem “alten” File, muss man die einzelnen Strict-Mode Issues beheben, den Hack auf Zeile 1 entfernen und kann dann erst pushen.
Pro’s & Con’s
+ Code-Qualität wird fortlaufend verbessert
+ Aktivierung des Strict-Modes möglich
– grösserer Zeitaufwand bei der Entwicklung während “Misch-Modus” (d.h. solange noch Files den Strict-Mode mittels “// @ts-nocheck” ignorieren)
