© saicle/Shutterstock.com
Kolumne: The Good Parts

JavaScript-Werkzeuge im Teenageralter


Große JavaScript-Projekte sind heute keine Ausnahme mehr, sondern die Regel. Komplexe Systeme bestehen immer aus diversen unterschiedlichen Komponenten, deren Zusammenspiel ein großes Ganzes ergibt. Um einen reibungslosen Ablauf während der Entwicklung zu gewährleisten, ist es wichtig, die einzelnen Applikationsteile sowie das eingesetzte Tooling zu verknüpfen und unter Kontrolle zu halten.

In meinem Job habe ich tagtäglich mit diversen unterschiedlichen Build- und Infrastruktur-Set-ups zu tun. Diese sind nicht nur auf JavaScript beschränkt, sondern beziehen häufig weitere Sprachen und Technologien wie Datenbanken, Messaging-Systeme und Suchindizes mit ein. Wenn ich kein existierendes Set-up verwende oder für Kunden erweitere, ist es meist meine Aufgabe, problemlösungsspezifische Set-ups zu entwerfen. Auch außerhalb meiner täglichen Arbeit benötige ich oft entsprechende Umgebungen für Prototypen und Open-Source-Projekte, an denen ich in meiner Freizeit arbeite. Um nicht in jedem dieser Fälle wieder bei Null beginnen zu müssen, habe ich mir eine Art Baukasten [1] geschaffen, den ich – mit entsprechenden Anpassungen versteht sich – in nahezu jedem der zuvor beschriebenen Fälle einsetze. Eine derartige Grundlage spart mir viel Zeit bei der Entwicklung eines komplexeren Systems, ohne dabei auf meine gewohnte Toolchain verzichten zu müssen. Dieser Artikel beschreibt dieses Set-up und die dafür über Jahre hinweg ausgewählten Technologien im Detail. Außerdem beleuchte ich einige der Hintergründe, die zu diesen Entscheidungen geführt haben. Das Ergebnis ist ein fast perfektes Build-System für die meisten JavaScript-Projekte – oder zumindest ein sehr solider Grundstock.

Problemstellung

In nahezu jedem Projekt werde ich mit den gleichen Problemstellungen konfrontiert:

  • Statische Codeanalyse (Linter, Coding-Style, Metriken …)

  • Testausführung (Unit Tests in einer Crossbrowser-Umgebung)

  • Externe Abhängigkeitsverwaltung (Libraries und Tools)

  • Interne Abhängigkeitsverwaltung (korrekte Reihenfolge projektinterner Pakete)

  • Paketierung für den Produktivbetrieb

  • Management aller dieser Aufgaben in einem übergreifenden Build-System

Natürlich existieren neben den genannten noch diverse weitere spezielle Aufgaben. Jedoch handelt es sich bei der aufgeführten Liste um Anforderungen, die sich für die Mehrheit aller Projekte wiederholen. Nachdem ich über die letzten Jahre verschiedenste Tools für jede der Problemstellungen im Einsatz hatte, haben sich nach dem aktuellen Stand ganz klar Favoriten herauskristallisiert.

Statische Codeanalyse

Der erste Schritt zur Entwicklung von qualitativ hochwertiger JavaScript-Software ist die Einhaltung bestimmter Grundregeln. JavaScript ist eine sehr flexible Sprache, die extrem viele unterschiedliche Konzepte und Variationen bei der Lösung eines Problems erlaubt. Leider ist es eben diese Flexibilität, die häufig auch zu Fehlern und Ungenauigkeiten führt. Die einfachste Möglichkeit, diesem Dilemma entgegenzuwirken, ist der Einsatz statischer Codeanalysetools, im Speziellen sog. Linter. Sie sind in der Lage, mögliche Fehler im Code noch vor der eigentlichen Ausführung zu identifizieren und so deren Konsequenzen zu verhindern. Zum jetzigen Zeitpunkt existieren drei große Vertreter dieser Kategorie von Analysetools: JSLint, JSHint und ESLint. Alle drei verfolgen das gleiche Ziel, benutzen hierbei jedoch unterschiedliche Herangehensweisen.

JSLint

JSLint [2], 2002 von Douglas Crockford geschrieben und veröffentlicht, war das erste Analysetool seiner Art. Crockford schrieb JSLint nahezu parallel zur Veröffentlichung seines Buchs „JavaScript: The Good Parts“. Darin beschreibt Crockford detailliert, welche Teile der Sprache gefahrlos eingesetzt werden können und auf welche besser verzichtet werden sollte, um etwaigen Problemen und Uneindeutigkeiten vorzubeugen. JSLint prüft den ihm übergebenen JavaScript-Code auf den Einsatz nahezu aller in Crockfords Buch beschriebenen Problemfälle und meldet sie. Hierbei lässt sich in begrenztem Umfang konfigurieren, welche der Überprüfungen durchgeführt werden sollen und welche nicht. Viele der angewendeten Kriterien sind jedoch fest in dem System verankert und lassen sich weder abschalten noch konfigurieren. Eben diese Hartnäckigkeit, mit der Douglas Crockford an vielen der Regeln festhält, hat 2010 zu einem Fork des Projekts geführt. Aus JSLint entstand JSHint.

JSHint

JSHint [3] ging 2010 aus dem JSLint-Projekt hervor. Die Gründe waren hauptsächlich Uneinigkeit über die Konfigurierbarkeit einiger der Checks des Tools. Eine Gruppe um Anton Kovalyov wünschte sich mehr Einstellungsmöglichkeiten des Linters, die es ermöglichen sollten, auf Wunsch gegen einige der von Crockford formulierten Best Practices zu verstoßen. Da Crockford dies strikt ablehnte, entstand JSHint, ein direkter Fork der damaligen JSLint-Codebasis. Um JSHint hat sich mittlerweile eine nicht zu unterschätzende Community gebildet, welche neue Checks einbaut und die existierenden pflegt und dokumentiert. Aus diesem Grund ist JSHint momentan das Mittel meiner Wahl, wenn es um das Linten von JavaScript-Dateien geht. Ein Wort der Warnung ist jedoch angebracht: JSHint ist in seiner Ausgangskonfiguration sehr viel weniger strikt in der Überprüfung von möglichen Problemstellen im Sourcecode. Aus diesem Grund sollte dringend für jedes Projekt eine detaillierte Konfiguration vorgenommen werden, in der viele der standardmäßig deaktivierten Checks wieder eingeschaltet werden. Ein guter Ausgangspunkt kann die jshint.json in meinem zuvor referenzierten Basisprojekt sein.

ESLint

ESLint [4] ist der jüngste Spross der Familie der Linter. Von Nicholas C. Zakas im Juni 2013 ins Leben gerufen, handelt es sich hierbei um ein neues Projekt, welches mit dem Ziel erschaffen wurde, nicht nur neueste Technologien und Bibliotheken zur Lösung des Problems einzusetzen, sondern ebenfalls einfach erweiterbar zu sein. Dass die Erweiterbarkeit eines der Hauptziele des Projekts ist, ist sehr schnell ersichtlich, wenn man einen Blick auf die Codebasis wirft. Jede einzelne Überprüfung ist in einem eigenständ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang