Module für JavaScript und Node.js auswählen
Die Auswahl von npm-Modulen ist im Wesentlichen Erfahrungssache, als Indizien für tragfähige und zukunftsträchtige Module können aber deren Verbreitung und die Aktivität der Autoren dienen.
- Golo Roden
Unter JavaScript und Node.js gibt es für fast jeden Anwendungsfall das passende Modul. Daher ist es üblicherweise kein Problem, ein Modul für eine bestimmte Aufgabe zu finden – sondern sich für eins der zahlreichen potenziell passenden Module zu entscheiden. Welche Kriterien erleichtern die Auswahl?
Es gibt fast nichts, was es nicht gibt: Egal ob man ein Webframework, einen Algorithmus zur Ähnlichkeitsanalyse oder eine Möglichkeit sucht, .png-Dateien auf der Kommandozeile auszugeben – npm hält ein passendes Modul bereit. Tatsächlich ist es nur in sehr seltenen Fällen schwierig, überhaupt ein npm-Modul für eine bestimmte Aufgabe zu finden.
Problematisch ist vielmehr, dass man allzu oft von der Auswahl erschlagen wird. In der Regel findet man nämlich nicht nur ein einziges Modul, sondern gleich hunderte – und dann stellt sich rasch die Frage, welches davon man verwenden sollte.
Götz & Golo
"Götz & Golo" ist eine gemeinsame Serie von Götz Martinek und Golo Roden. Der eine ist Geschäftsführer der sodge IT GmbH, der andere CTO der the native web GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Götz findet sich im Blog von sodge IT. Die Fragestellung zu diesem Beitrag lautete: "Welche Bibliotheken nutzt Ihr? Und warum?"
Anders als in anderen Programmiersprachen stößt man bei JavaScript sehr rasch auf dieses Problem, da die zugrunde liegende Plattform keine umfangreiche Standardbibliothek enthält. Selbst triviale Funktionen wie das Auffüllen einer Zeichenkette mit Leerzeichen sind nicht Bestandteil der Plattform (beziehungsweise in dem Fall in Form der beiden Funktionen padStart und padEnd erst seit ECMAScript 2017).
Der einfache Fall: lodash & Co.
Deshalb sind an erster Stelle einige Module zu nennen, die praktisch in keinem größeren Projekt fehlen. Dazu zählt in erster Linie lodash, das zahlreiche Hilfsfunktionen für die verschiedenen Basisdatentypen enthält. Auch common-tags mit verschiedenen Template-Funktionen und moment zum Umgang mit Datum und Zeit gehören sicherlich dazu.
Doch wie sieht es mit Modulen darüber hinaus aus? Was, wenn man etwas Spezielleres braucht oder man zum Beispiel einfach noch nicht so viel Erfahrung bei der Auswahl von Modulen hat? An welchen Kriterien lässt sich festmachen, welches Modul empfehlenswert ist und welches nicht?
Die Suche von npm ist in der Regel leider alles, nur nicht hilfreich: Man erhält viel zu viele Ergebnisse, sortiert nach wenig intuitiven Kriterien, was letztlich bedeutet, dass man bestenfalls einen Zufallstreffer landen kann. Deutlich besser funktioniert hier bereits die Google-Suche, wobei es hilft, an den gewünschten Suchbegriff noch npm oder js anzuhängen.
Als Ergebnis erhält man dann eine Liste von npm-Modulen, entweder direkt auf npm oder auf den zugehörigen GitHub-Seiten. Wie bewertet man diese Ergebnisse?
Kriterien auf npm
In beiden Fällen, npm und GitHub, hilft primär ein Blick in die Statistiken. Das sind am Ende zwar nicht die allein ausschlaggebenden Kriterien, aber sie helfen, eine gute Vorauswahl zu treffen. Bei npm ist zunächst ein Blick auf die aktuelle Versionsnummer, die vergangenen Versionsnummern und das Veröffentlichungsdatum der letzten Version empfehlenswert: Module, die weiterentwickelt und regelmäßig gepflegt werden, weisen naturgemäß mehr Versionen auf als Module, für die das nicht gilt – dabei ist aber natürlich das Alter des Moduls zu berücksichtigen.
Auch die Anzahl der wöchentlichen Downloads ist aussagekräftig: Je häufiger ein Modul heruntergeladen wird, desto beliebter scheint es zu sein, was wiederum bedeutet, dass man vermutlich nicht so viel falsch machen kann. Bei Modulen, die eher spezielle Probleme lösen, können diese Zahlen natürlich trotzdem niedrig sein. Aussagekräftig ist also unter Umständen weniger die absolute Zahl als vielmehr das Verhältnis der Zahlen zu anderen, konkurrierenden Modulen.
Die Anzahl der offenen Issues und Pull Requests sind wiederum überhaupt nicht relevant: Viel aussagekräftiger ist, wie häufig Issues und Pull Requests erstellt und geschlossen werden. Auch hier ist primär also die Aktivität ein guter Indikator. Leider lässt sich das auf npm nicht auslesen, da hier nur die offenen Issues und Pull Requests gelistet werden.
Unterm Strich gilt es also zu ermitteln, ob ein Modul gepflegt wird: Je mehr Aktivität zu erkennen ist, desto aktiver sind die Autoren und die Community, was dem Modul im Falle des Falles zugute kommt. Darüber hinaus gibt es aber noch ein paar Aspekte, die zu beachten sind:
- Module sollten über eine aussagekräftige README.md-Datei verfügen, die einen leichten Einstieg in das Thema des Moduls bietet und rasch zum Punkt kommt – weiter hinten dann aber auch die Details des Moduls erklärt. Finden sich Schreibfehler, ist das direkt ein schlechtes Zeichen: Wird bei der Dokumentation, die den Erstkontakt darstellt, kein Wert auf Korrektheit legt, lässt das befürchten, dass auch beim Code nicht allzu viel Wert auf Details gelegt wurde.
- Auch eine Webseite und ein Repository sollten verlinkt sein. Fehlen diese Links oder verweisen sie auf nicht (mehr) existente Seiten, ist das ebenfalls ein schlechtes Zeichen. Tatsächlich verwenden beinahe alle Autoren hier GitHub. Ist bei der Webseite eine eigens gestaltete Landing-Page angegeben, zeugt das von Liebe für Details und ist daher eher positiv zu bewerten.
- Ebenfalls wichtig ist die angegebene Lizenz: Häufig begegnet man der Annahme, alles auf npm stehe ohnehin unter der MIT-Lizenz, das ist jedoch falsch. Da in der Regel nicht alle Lizenzen gleichermaßen kompatibel zum eigenen Projekt sind, sollte man hier darauf achten, keine Lizenzverletzung zu begehen.
- Zu guter Letzt lohnt auch noch ein Blick auf die von npm angegebenen Autoren des Moduls. Einige Autoren trifft man immer wieder an, weshalb ein bekannter Name hier unter Umständen durchaus ein positives Kriterium sein kann.
Kriterien auf GitHub
Auf GitHub verhält es sich anschließend ähnlich. Auch hier geht es primär wieder darum herauszulesen, ob ein Modul regelmäßig gepflegt wird. Daher sind hier die Anzahl der Commits und die Regelmäßigkeit von Commits das erste Kriterium. Da der master-Branch in der Regel einen releasefähigen Stand enthält, finden größere Arbeiten unter Umständen in einem anderen Branch im Hintergrund statt. Hier darf man also nicht nur auf den master-Branch achten, sondern muss gegebenenfalls ein bisschen herumschauen.
Ein interessanter Aspekt auf GitHub sind anschließend die Anzahl der Forks und die Anzahl der Contributoren. Je höher diese Zahlen sind, desto wahrscheinlicher ist es, dass ein Modul auch dann noch weiterentwickelt und gepflegt wird, wenn der hauptsächliche Autor – aus welchen Gründen auch immer – keine Zeit mehr investieren können sollte. Auch eine hohe Zahl an Stargazern ist in dem Zusammenhang ein gutes Zeichen.
Ein Blick in die Issues und Pull Requests ist auf GitHub deutlich sinnvoller als auf die damit zusammenhängenden reinen Zahlen auf npm: Auf GitHub lässt sich gut nachvollziehen, wie mit Problemen umgegangen wird. Wie rasch werden Issues behoben? Werden Pull Requests aus der Community gemergt? Oder bleiben externe Beiträge über lange Zeit liegen?
Fazit
Bei all diesen Kriterien darf man nicht vergessen, dass sie nur Anhaltspunkte für eine erste Orientierung sind. Es gibt durchaus Module, die im Hinblick auf sämtliche Aspekte wie eine schlechte Wahl wirken, sich aber im Nachhinein doch als wahre Perlen entpuppen – und umgekehrt. Ganz am Ende kommt man um Ausprobieren nicht herum, wodurch man im Lauf der Zeit Erfahrung sammelt und den eigenen Horizont nach und nach vergrößert und mehr und mehr Module gut kennenlernt.
Trotzdem helfen die genannten Punkte für eine erste Einschätzung, die oft zumindest eine Tendenz aufzeigen kann und im Zweifelsfall zumindest dazu dienen kann, die Reihenfolge festzulegen, in der man sich verschiedene in Frage kommende Module anschaut und diese ausprobiert.
tl;dr: Die Auswahl von npm-Modulen ist im Wesentlichen Erfahrungssache, als Indizien für tragfähige und zukunftsträchtige Module können aber deren Verbreitung und die Aktivität der Autoren dienen. ()
