TypeScript behauptet, eine stark typisierte Programmiersprache zu sein, die auf JavaScript aufbaut und bessere Tools in jeder Größenordnung bietet. Allerdings enthält   den Typ   , der sich oft implizit in eine Codebasis einschleichen kann und zum Verlust vieler Vorteile von TypeScript führt. TypeScript any  In diesem Artikel werden Möglichkeiten untersucht, die Kontrolle über   Typen in TypeScript-Projekten zu übernehmen. Machen Sie sich bereit, die Leistungsfähigkeit von TypeScript zu nutzen, um ultimative Typsicherheit zu erreichen und die Codequalität zu verbessern. any  Nachteile der Verwendung von Any in TypeScript  TypeScript bietet eine Reihe zusätzlicher Tools zur Verbesserung der Entwicklererfahrung und Produktivität:  Es hilft, Fehler frühzeitig in der Entwicklungsphase zu erkennen.  Es bietet eine hervorragende automatische Vervollständigung für Code-Editoren und IDEs.  Es ermöglicht ein einfaches Refactoring großer Codebasen durch fantastische Code-Navigationstools und automatisches Refactoring.  Es vereinfacht das Verständnis einer Codebasis, indem es zusätzliche Semantik und explizite Datenstrukturen durch Typen bereitstellt.  Sobald Sie jedoch beginnen, den Typ   in Ihrer Codebasis zu verwenden, verlieren Sie alle oben aufgeführten Vorteile. Der Typ   ist eine gefährliche Lücke im Typsystem und seine Verwendung deaktiviert alle Typprüfungsfunktionen sowie alle Tools, die von der Typprüfung abhängen. Dadurch gehen alle Vorteile von TypeScript verloren: Fehler werden übersehen, Code-Editoren werden weniger nützlich und vieles mehr. any any  Betrachten Sie zum Beispiel das folgende Beispiel:   function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any  Im Code oben:  Sie werden die automatische Vervollständigung innerhalb der   Funktion vermissen. Wenn Sie   In Ihrem Editor erhalten Sie keine korrekten Vorschläge für die verfügbaren Methoden für   . parse data. data  Im ersten Fall liegt ein   da wir eine Zahl anstelle einer Zeichenfolge übergeben haben. TypeScript kann den Fehler nicht hervorheben, da   die Typprüfung deaktiviert wird. TypeError: data.split is not a function any  Im zweiten Fall hat die Variable   ebenfalls den Typ   . Dies bedeutet, dass eine einzelne Verwendung eines   Codes einen kaskadierenden Effekt auf einen großen Teil einer Codebasis haben kann. res2 any any  Die Verwendung von   ist nur in extremen Fällen oder für Prototyping-Anforderungen in Ordnung. Im Allgemeinen ist es besser, die Verwendung   zu vermeiden, um das Beste aus TypeScript herauszuholen. any any  Woher der Typ „Any“ kommt  Es ist wichtig, die Quellen des Typs „   in einer Codebasis zu kennen, da das explizite Schreiben von „   nicht die einzige Option ist. Obwohl wir uns nach besten Kräften bemühen, die Verwendung des Typs   zu vermeiden, kann er sich manchmal implizit in eine Codebasis einschleichen. any any any  Es gibt vier Hauptquellen   Art in einer Codebasis: any  Compiler-Optionen in tsconfig.  Die Standardbibliothek von TypeScript.  Projektabhängigkeiten.  Explizite Verwendung von   in einer Codebasis. any  Zu den ersten beiden Punkten habe ich bereits Artikel zu   und   geschrieben. Bitte schauen Sie sich diese an, wenn Sie die Typensicherheit in Ihren Projekten verbessern möchten. den wichtigsten Überlegungen in tsconfig zur Verbesserung der Standardbibliothekstypen  Dieses Mal konzentrieren wir uns auf automatische Tools zur Steuerung des Erscheinungsbilds eines   Typs in einer Codebasis. any  Stufe 1: Verwendung von ESLint    ist ein beliebtes statisches Analysetool, das von Webentwicklern verwendet wird, um Best Practices und Codeformatierung sicherzustellen. Es kann verwendet werden, um Codierungsstile durchzusetzen und Code zu finden, der bestimmten Richtlinien nicht entspricht. ESLint  Dank des Plugins   kann ESLint auch mit TypeScript-Projekten verwendet werden. Höchstwahrscheinlich wurde dieses Plugin bereits in Ihrem Projekt installiert. Wenn nicht, können Sie dem offiziellen   folgen. typesctipt-eslint Leitfaden für die ersten Schritte  Die häufigste Konfiguration für   ist wie folgt: typescript-eslint   module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, };  Diese Konfiguration ermöglicht   , TypeScript auf Syntaxebene zu verstehen, sodass Sie einfache eslint-Regeln schreiben können, die für manuell geschriebene Typen in einem Code gelten. Sie können beispielsweise die explizite Verwendung von   verbieten. eslint any  Die   Voreinstellung enthält einen sorgfältig ausgewählten Satz von ESLint-Regeln zur Verbesserung der Codekorrektheit. Obwohl empfohlen wird, die gesamte Voreinstellung zu verwenden, konzentrieren wir uns in diesem Artikel nur auf die   Regel. recommended no-explicit-any  nein-explizit-irgendein  Der strikte Modus von TypeScript verhindert die Verwendung von impliziten „   , verhindert jedoch nicht die explizite Verwendung von „   . Die   Regel hilft dabei, das manuelle Schreiben   irgendwo in einer Codebasis zu verhindern. any any no-explicit-any any   // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response<any>): Array<Pokemon> {} // ✅ Correct function parsePokemons(data: Response<unknown>): Array<Pokemon> {} // ❌ Incorrect function reverse<T extends Array<any>>(array: T): T {} // ✅ Correct function reverse<T extends Array<unknown>>(array: T): T {}  Der Hauptzweck dieser Regel besteht darin, den Einsatz von   im gesamten Team zu verhindern. Dies ist ein Mittel, um die Zustimmung des Teams zu stärken, dass von der Verwendung   im Projekt abgeraten wird. any any  Dies ist ein entscheidendes Ziel, da bereits die einmalige Verwendung von   aufgrund   kaskadierende Auswirkungen auf einen erheblichen Teil der Codebasis haben kann. Von der endgültigen Typensicherheit ist dies jedoch noch weit entfernt. any der Typinferenz  Warum „no-explicit-any“ nicht genug ist  Obwohl wir uns mit der expliziten Verwendung   befasst haben, gibt es immer noch viele implizite „   innerhalb der Abhängigkeiten eines Projekts, einschließlich npm-Paketen und der Standardbibliothek von TypeScript. any any  Betrachten Sie den folgenden Code, der wahrscheinlich in jedem Projekt vorkommt:   const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any  Sowohl den Variablen   als auch   wurde implizit der Typ „   zugewiesen. Weder   noch der strikte Modus von TypeScript werden uns in diesem Fall warnen. Noch nicht. pokemons settings any no-explicit-any  Dies liegt daran, dass die Typen für   und   aus der Standardbibliothek von TypeScript stammen, in der diese Methoden eine explizite „   -Annotation haben. Wir können immer noch manuell einen besseren Typ für unsere Variablen angeben, aber in der Standardbibliothek gibt es fast 1.200   davon. Es ist fast unmöglich, sich an alle Fälle zu erinnern, in denen sich   aus der Standardbibliothek in unsere Codebasis einschleichen konnte. response.json() JSON.parse() any any any  Das Gleiche gilt für externe Abhängigkeiten. Es gibt viele schlecht typisierte Bibliotheken in npm, wobei die meisten noch in JavaScript geschrieben sind. Daher kann die Verwendung solcher Bibliotheken leicht zu vielen impliziten   in einer Codebasis führen. any  Im Allgemeinen gibt es immer noch viele Möglichkeiten,   in unseren Code einzuschleichen. any  Stufe 2: Verbesserung der Fähigkeiten zur Typprüfung  Idealerweise hätten wir gerne eine Einstellung in TypeScript, die den Compiler dazu bringt, sich über jede Variable zu beschweren, die aus irgendeinem Grund den Typ „   “ erhalten hat. Leider existiert eine solche Einstellung derzeit nicht und wird voraussichtlich auch nicht hinzugefügt. any  Wir können dieses Verhalten erreichen, indem wir den typgeprüften Modus des   -Plugins verwenden. Dieser Modus arbeitet mit TypeScript zusammen, um den ESLint-Regeln vollständige Typinformationen vom TypeScript-Compiler bereitzustellen. Mit diesen Informationen ist es möglich, komplexere ESLint-Regeln zu schreiben, die die Typprüfungsfunktionen von TypeScript wesentlich erweitern. Beispielsweise kann eine Regel alle Variablen mit dem Typ „   finden, unabhängig davon, wie „   ermittelt wurde. typescript-eslint any any  Um typbewusste Regeln zu verwenden, müssen Sie die ESLint-Konfiguration leicht anpassen:   module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, };  Um die Typinferenz für   zu aktivieren, fügen Sie   zur ESLint-Konfiguration hinzu. Ersetzen Sie dann die   Voreinstellung durch   . Die letztere Voreinstellung fügt etwa 17 neue leistungsstarke Regeln hinzu. In diesem Artikel konzentrieren wir uns nur auf fünf davon. typescript-eslint parserOptions recommended recommended-type-checked  Kein-unsicheres-Argument  Die   Regel sucht nach Funktionsaufrufen, bei denen eine Variable vom Typ „   als Parameter übergeben wird. In diesem Fall geht die Typprüfung verloren und alle Vorteile der starken Typisierung gehen ebenfalls verloren. no-unsafe-argument any  Betrachten wir beispielsweise eine   Funktion, die ein Objekt als Parameter erfordert. Angenommen, wir empfangen JSON, analysieren es und erhalten einen   Typ. saveForm any   // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`.  Wenn wir die Funktion   mit diesem Parameter aufrufen, kennzeichnet die Regel   sie als unsicher und erfordert, dass wir den entsprechenden Typ für die   angeben. saveForm no-unsafe-argument value  Diese Regel ist leistungsstark genug, um verschachtelte Datenstrukturen innerhalb von Funktionsargumenten gründlich zu untersuchen. Daher können Sie sicher sein, dass die Übergabe von Objekten als Funktionsargumente niemals untypisierte Daten enthalten wird.   // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. });  Der beste Weg, den Fehler zu beheben, besteht darin,   von TypeScript oder eine Validierungsbibliothek wie   oder   zu verwenden. Schreiben wir beispielsweise die Funktion   , die den genauen Typ der analysierten Daten einschränkt. die Typeingrenzung Zod Superstruct parseFormValues   // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues);  Beachten Sie, dass es zulässig ist, den Typ   als Argument an eine Funktion zu übergeben, die „   akzeptiert, da damit keine Sicherheitsbedenken verbunden sind. any unknown  Das Schreiben von Datenvalidierungsfunktionen kann eine mühsame Aufgabe sein, insbesondere wenn es um große Datenmengen geht. Daher lohnt es sich, über den Einsatz einer Datenvalidierungsbibliothek nachzudenken. Mit Zod würde der Code beispielsweise so aussehen:   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues);  Keine-unsichere-Zuweisung  Die   Regel sucht nach Variablenzuweisungen, in denen ein Wert den Typ   hat. Solche Zuweisungen können den Compiler zu der Annahme verleiten, dass eine Variable einen bestimmten Typ hat, während die Daten tatsächlich einen anderen Typ haben könnten. no-unsafe-assignment any  Betrachten Sie das vorherige Beispiel der JSON-Analyse:   // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value  Dank der   Regel können wir   Typ abfangen, noch bevor wir   an anderer Stelle übergeben. Die Fixierungsstrategie bleibt dieselbe: Wir können die Typeingrenzung verwenden, um dem Wert der Variablen einen bestimmten Typ zuzuweisen. no-unsafe-assignment any formValues   // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues  No-unsafe-member-access und No-unsafe-call  Diese beiden Regeln werden viel seltener ausgelöst. Meiner Erfahrung nach sind sie jedoch sehr hilfreich, wenn Sie versuchen, schlecht typisierte Abhängigkeiten von Drittanbietern zu verwenden.  Die Regel   verhindert, dass wir auf Objekteigenschaften zugreifen, wenn eine Variable den Typ „   hat, da sie   oder   sein kann. no-unsafe-member-access any null undefined  Die   Regel verhindert, dass wir eine Variable mit dem Typ „   als Funktion aufrufen, da es sich möglicherweise nicht um eine Funktion handelt. no-unsafe-call any  Stellen wir uns vor, wir hätten eine schlecht typisierte Drittanbieter-Bibliothek namens   : untyped-auth   // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value.  Der Linter hebt zwei Probleme hervor:  Der Aufruf der   Funktion kann unsicher sein, da wir möglicherweise vergessen, wichtige Argumente an die Funktion zu übergeben. authenticate  Das Lesen der   aus dem   Objekt ist unsicher, da sie   ist, wenn die Authentifizierung fehlschlägt. name userInfo null  Der beste Weg, diese Fehler zu beheben, besteht darin, die Verwendung einer Bibliothek mit einer stark typisierten API in Betracht zu ziehen. Wenn dies jedoch keine Option ist, können Sie  . Ein Beispiel mit den festen Bibliothekstypen würde so aussehen: die Bibliothekstypen selbst erweitern   // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise<UserInfo | null> const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); }  keine unsichere Rückkehr  Die   Regel hilft dabei, nicht versehentlich den Typ „   von einer Funktion zurückzugeben, die etwas Spezifischeres zurückgeben sollte. Solche Fälle können den Compiler zu der Annahme verleiten, dass ein zurückgegebener Wert einen bestimmten Typ hat, während die Daten tatsächlich einen anderen Typ haben könnten. no-unsafe-return any  Angenommen, wir haben eine Funktion, die JSON analysiert und ein Objekt mit zwei Eigenschaften zurückgibt.   // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null  Die   Funktion kann in jedem Teil des Programms, in dem sie verwendet wird, zu Laufzeitfehlern führen, da der geparste Wert nicht überprüft wird. Die   Regel verhindert solche Laufzeitprobleme. parseForm no-unsafe-return  Dies lässt sich leicht beheben, indem Sie eine Validierung hinzufügen, um sicherzustellen, dass der analysierte JSON-Code mit dem erwarteten Typ übereinstimmt. Lassen Sie uns dieses Mal die Zod-Bibliothek verwenden:   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); }  Ein Hinweis zur Leistung  Die Verwendung typgeprüfter Regeln bringt für ESLint einen Leistungseinbußen mit sich, da der Compiler von TypeScript aufgerufen werden muss, um alle Typen abzuleiten. Diese Verlangsamung macht sich hauptsächlich beim Ausführen des Linters in Pre-Commit-Hooks und in CI bemerkbar, beim Arbeiten in einer IDE ist sie jedoch nicht spürbar. Die Typprüfung wird einmal beim IDE-Start durchgeführt und aktualisiert dann die Typen, wenn Sie den Code ändern.  Es ist erwähnenswert, dass allein das Ableiten der Typen schneller funktioniert als der übliche Aufruf des   Compilers. Bei unserem neuesten Projekt mit etwa 1,5 Millionen Zeilen TypeScript-Code dauert die Typprüfung durch   beispielsweise etwa 11 Minuten, während die zusätzliche Zeit, die für das Bootstrapping der typbewussten Regeln von ESLint erforderlich ist, nur etwa 2 Minuten beträgt. tsc tsc  Für unser Team ist die zusätzliche Sicherheit, die die Verwendung typbewusster statischer Analyseregeln bietet, den Kompromiss wert. Bei kleineren Projekten ist diese Entscheidung noch einfacher zu treffen.  Abschluss  Die Kontrolle der Verwendung von   in TypeScript-Projekten ist entscheidend für die Erzielung optimaler Typsicherheit und Codequalität. Durch die Verwendung des   Plugins können Entwickler alle Vorkommen   Art in ihrer Codebasis identifizieren und beseitigen, was zu einer robusteren und wartbareren Codebasis führt. any typescript-eslint any  Durch die Verwendung typbewusster Eslint-Regeln ist jedes Auftreten des Schlüsselworts „   in unserer Codebasis eine bewusste Entscheidung und kein Fehler oder Versehen. Dieser Ansatz schützt uns vor der Verwendung in unserem   Code sowie in der Standardbibliothek und in Abhängigkeiten von Drittanbietern. any any  Insgesamt ermöglicht uns ein typbewusster Linter, ein Maß an Typsicherheit zu erreichen, das dem von statisch typisierten Programmiersprachen wie Java, Go, Rust und anderen ähnelt. Dies vereinfacht die Entwicklung und Wartung großer Projekte erheblich.  Ich hoffe, Sie haben aus diesem Artikel etwas Neues gelernt. Vielen Dank fürs Lesen!  Nützliche Links   Bibliothek: typescript-eslint   Artikel: Wichtige Überlegungen in tsconfig   Artikel: Verbesserung der Standardbibliothekstypen   Dokumente: Typeingrenzung in TypeScript   Dokumente: Typinferenz in TypeScript   Bibliothek: Zod   Bibliothek: Superstruct

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

TypeScript wirklich „stark typisiert“ machen

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Management Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our Management Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Wir feiern unsere Remote-Work-Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps