Statische Code Analyse in Node.js

JavaScript ist eine extrem mächtige Sprache. Dies hat viele Vorteile, bei falscher Benutzung kann sich dieser Umstand jedoch negativ auf die Lesbarkeit des Quellcodes auswirken.

Statische Code Analyse kann zur automatischen Erkennung gängiger Fehler und der Durchsetzung eines einheitlichen Programmierstils eingesetzt werden. In diesem Artikel möchte ich einige dieser Tools empfehlen, welche ich erfolgreich in Projekten eingesetzt habe.

TypeScript

Bei TypeScript handelt es sich um eine Sprache, welche JavaScript um ein statisches Typsystem erweitert. Dadurch können viele Fehler bereits vor der Ausführung des Programms gefunden werden. Durch die deutlich verbesserte Autovervollständigung der gängigen Editoren wird vor allem in großen Projekten zusätzlich die Entwicklungsgeschwindigkeit erhöht. Eines des besten Features ist, dass die Typen in vielen Fällen von TypeScript automatisch erkannt (“inferiert”) werden und somit nicht extra definiert werden müssen. Es ist sogar möglich die Typen eines normalen JavaScript Projektes zu überprüfen.

Prettier

Bei Prettier handelt es sich um ein Code Formatierungstool. Die Konfigurationsmöglichkeiten werden dabei bewusst klein gehalten. Somit vermeidet man lange Diskussionen über subjektive Aspekte der Formatierungsregeln. Mit Prettier gibt es meistens nur ein korrektes Format des Quellcodes. Dies ist beispielweise sehr nützlich in Code Reviews, da die Diffs nicht mehr mit versehentlichen Formatierungsänderungen “zugemüllt” werden.

ESLint

ESLint ist quasi der Standardlinter für JavaScript Projekte. Der bereits große Standardregelsatz kann mit Plugins einfach erweitert werden. Ich würde empfehlen zunächst mit den empfohlenen Regeln durch das Setzen von "extends": "eslint:recommended" zu starten. Individuelle Regeln können dann im Anschluss, je nach Bedarf, aktiviert und deaktiviert werden.

Falls du ESLint in Kombination mit TypeScript verwendest, solltest du den TypeScript ESLint Parser nutzen.

Folgende Plugins kann ich empfehlen:

• eslint-config-prettier deaktiviert alle Regeln, welche potentiell in Konflikt mit der Prettier Formatierung geraten.
• eslint-plugin-import fügt Regeln zur Verwaltung der Imports hinzu. Ich würde vor allem die Regel order empfehlen, welche automatisch die Imports sortiert. Dies vermeidet wieder versehentliche Änderungen in Pull Requests.
• eslint-plugin-unused-imports. Ungenutzte Imports können sich negativ auf die Größe und Lesbarkeit der Applikation auswirken. Dieses Plugin fügt Regeln hinzu, mit denen diese automatisch entfernt werden können.
• eslint-plugin-unicorn erweitert ESLint um viele neue Regeln. Es kann zum Beispiel mit prevent-abbreviations die Nutzung von bestimmter Abkürzungen, welche die Lesbarkeit des Quellcodes einschränken, verboten werden. Ich empfehle die Nutzung der empfohlenden Einstellungen des Plugins.
• eslint-plugin-promise. Bei Promises und async/await handelt es sich um großartige JavaScript Features um asynchronen Code zu organisieren. Dieses Plugin hilft häufige Fehler bei der Nutzung von Promises zu vermeiden.
• eslint-plugin-node erweitert ESLint um einige Node.js spezifische Regeln. Beispielsweise kann es die Nutzung des neuen Promise basierenden fs Module mittels der node/prefer-promises/fs Regel erzwingen.
• eslint-plugin-json fügt einige Regeln für JSON Dateien hinzu. Diese können beispielsweise genutzt werden um falsch formatierte JSON Konfigurationen zu vermeiden.
• eslint-plugin-eslint-comments verhindert den Missbrauch von Kommentaren, welche bestimme Regeln deaktivieren, beispielsweise /* eslint-disable */. So wirst du gewarnt, wenn eine Ausnahme zu generisch ist, oder nicht mehr benötigt wird.

Ich empfehle mit den empfohlenen Einstellungen jedes Plugins zu starten und individuelle Regeln basierend auf Projektanforderungen zu ändern. Eine Ausnahme ist jedoch das eslint-plugin-import. Da die einzelnen Regeln einen recht hohen negativen Einfluss auf die Geschwindigkeit des Linting haben, sollten nur Regeln ausgewählt werden, die dies wert sind. Der Einfluss der einzelnen Regeln auf die Performance kann gemessen werden, indem die Umgebungsvariable TIMING=1 gesetzt wird (Quelle). Zur weiteren Optimierung empfehle ich die Nutzung der --cache ESLint Option.

Das war’s! Ich hoffe, ich konnte dir helfen, die statische Analyse deines JavaScript-Projekts zu verbessern. Glaubst du, ich habe etwas übersehen? Dann lasse es mich bitte in den Kommentaren wissen.

---

Über den Autor