So halten Sie npm-Abhängigkeiten in Ihrem Projekt aktuell

Es kommt sehr häufig vor, dass Projekte in der Produktion einwandfrei funktionieren, aber nicht mehr aktiv gepflegt werden – sie laufen, funktionieren, und der Kunde betrachtet das Projekt als abgeschlossen.

Leider stimmt das nicht ganz. Wir vergessen leicht, dass ein abgeschlossenes Projekt, das in der Produktion läuft, trotzdem gewartet werden muss. Die meisten Projekte müssen weiterhin überprüft und auftretende Vorfälle behoben werden. Vergleichen wir es mit dem Kauf eines Fahrzeugs: Wir gehen zum Händler, wählen das passende Modell aus, bezahlen und nutzen es so lange, wie es uns nützt – ganz ohne regelmäßige Wartung, oder? Natürlich nicht. Für Software gilt dasselbe.

Bei der Entwicklung von REST-API-Projekten oder CLI-Anwendungen mit Node.js ist es sehr üblich, den Open-Source-Paketmanager npm für Abhängigkeiten zu verwenden, um Frameworks und Tools in diese Projekte einzubinden.

Das ist bis zu einem gewissen Grad vorteilhaft, da es uns helfen kann, die Entwicklungszeit zu verkürzen. Mit stabilen Paketen, die gründlich getestet und von der Community gepflegt werden, lassen sich bestimmte Anforderungen unseres Projekts erfüllen. Das kann sich jedoch auch gegen uns wenden und zum Problem werden.

Im Folgenden betrachten wir ein häufiges Szenario mit einem Node.js-Projekt. Einige dieser Probleme treten auf, wenn wir ein Projekt unbeaufsichtigt lassen und weder evolutionäre noch vorbeugende Wartung durchführen.

Ein konkreter Fall

Stellen Sie sich ein REST-API-Projekt mit Node.js vor, das seit zwei Jahren oder länger in der Produktion läuft. In diesen zwei Jahren hat niemand Schritte unternommen, um die Abhängigkeiten zu aktualisieren oder an neue Versionen anzupassen. Bei der Entwicklung diente das Paket express als Basis-Framework für die CRUD-Funktionalität. Außerdem wurde die Bibliothek jsonwebtoken zum Erzeugen von Sicherheitstokens und das Paket moment zur Internationalisierung von Datumsangaben verwendet.

Mögliche Probleme

Die Verwendung relativ neuer Abhängigkeitsbibliotheken kann als erstes Problem betrachtet werden, da wir einen Teil unserer Lösung auf Software stützen, die von der Community nicht getestet wurde und sich möglicherweise nicht kontinuierlich weiterentwickelt.

Zweitens stützen wir einen Teil unserer Lösung auf Bibliotheken mit nur einem Beitragenden – so nenne ich sie. Diese Abhängigkeiten werden von einer einzigen Person entwickelt, die Verbesserungen veröffentlicht, die Bibliothek pflegt und Vorfälle behebt und schließlich allein über die Entwicklungsrichtung der Software entscheidet. Solche Abhängigkeiten schränken uns erheblich ein.

Als drittes Problem gibt es Abhängigkeiten, die selbst weitere Abhängigkeiten enthalten. Das ist auf den ersten Blick jedoch nicht zu erkennen – ein Phänomen, das wir oft als „Node-Module-Loch“ bezeichnen.

Quelle: https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif

Weitere Tipps dazu finden Sie hier.

Einige Lösungsansätze

1. Brauche ich diese Abhängigkeit wirklich?

In einem Node.js-Projekt sollten wir zuerst in der eigenen Dokumentation nach Informationen suchen. Die Node.js-API-Dokumentation enthält zahlreiche praktische Beispiele dafür, was wir selbst mit der Node.js-API erreichen können – ganz ohne externe Abhängigkeiten, indem wir „nativ“ arbeiten.

2. Micro-Dependencies verwenden

Wenn wir sicher sind, dass wir ein Modul benötigen, um die Anforderungen unseres Projekts zu erfüllen, müssen wir das passende finden. Zunächst denken wir oft, dass die erste Option in den Ergebnissen unserer Google-Suche (oder der npm-Suche) am besten geeignet ist. In vielen Fällen ist das jedoch nicht so. Wir sollten innehalten, überlegen und prüfen, wie viel von dem, was diese Bibliothek bietet, wir tatsächlich brauchen. Vielleicht kann sie viel mehr, als nötig ist, und zieht so eine Bibliothek in unser Projekt, die wir größtenteils gar nicht nutzen.

3. Marktanalyse

Wir sollten uns umsehen und nach Alternativen suchen – das npm-Ökosystem ist sehr groß, und es gibt verschiedene Bibliotheken, die praktisch dasselbe leisten. Doch welche sollten wir auswählen? Hier können wir Webtools wie Bundlephobia nutzen, die die Größe der einzelnen Pakete vergleichen, oder npmtrends, das Vergleiche unter anderem anhand von Downloadzahlen und Beiträgen aus der Community ermöglicht.

Diese Tools können dabei helfen, die passende Abhängigkeit auszuwählen. Angaben zur Größe der Abhängigkeit, zum Umfang der pflegenden Community, zur Zahl der Veröffentlichungen in den vergangenen Monaten oder zu den Downloads können wichtige Anhaltspunkte sein.

4. Präventive Tools einsetzen

Snyk hat die Open-Source-Erweiterung Vuln Cost für Visual Studio Code veröffentlicht. Damit lässt sich schnell und einfach ermitteln, wie viele Schwachstellen unsere Software enthält – anhand der Datei package.json und sogar anhand einzelner Dateien, die einen Bibliotheksimport enthalten.

In einem Node.js-Projekt können wir Abhängigkeiten derzeit über require und import einbinden – entweder vollständig oder teilweise, sofern dies unterstützt wird. Das folgende Bild zeigt anschaulich, wie das beim zuvor beschriebenen Projekt (express + jsonwebtoken + moment) aussieht:

Quelle: https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif

Wenn Sie weitere Informationen zur Verwendung von Vuln Cost suchen, sehen Sie sich die drei folgenden Videos an:

• So installieren Sie die Vuln-Cost-Erweiterung in Visual Studio Code

• JavaScript-Bibliotheken mit „require“ einbinden und auf Schwachstellen prüfen

• JavaScript-Bibliotheken importieren und auf Schwachstellen prüfen

Fazit

Eine der Herausforderungen, mit denen die Softwarebranche schon immer konfrontiert war, besteht darin, Endnutzerinnen und Endnutzern zu erklären und verständlich zu machen, dass Software regelmäßig gewartet und weiterentwickelt werden muss – zum Beispiel, um sie an Betriebssystem-Updates anzupassen, ihre Leistung zu verbessern oder mögliche Schwachstellen zu beseitigen.

Eine weitere Herausforderung ist, Entwicklungsteams Zeit zum Nachdenken, Aktualisieren und Weiterbilden zu verschaffen, damit sie bei der Softwareentwicklung die am besten geeigneten Alternativen finden. Die erstbeste Option ist nicht immer die richtige.

Die vier vorgestellten Lösungsansätze können Ihnen dabei helfen, eine wartbare, hochwertige, skalierbare und sicherere Codebasis zu entwickeln.