Hilfreich um Libraries von einem zentralen Ort laden zu können, ja. Aber zuverlässig genug, um die Pakete auch wiederherzustellen? Niemals nicht.
Also nutze ich NuGet in .NET seitdem genau für diesen einen Zweck: Pakete zu laden, mehr nicht. Die von mir wirklich benötigten Assemblies ziehe ich mir dann raus und packe sie in einen /dependencies-Ordner in meiner Solution. Wo sie dann auch eingecheckt und versioniert werden.
Nun dreht sich in Node.js seit einigen Jahren aber ziemlich genau alles um Pakete, die über NPM verwaltet und bezogen werden.
Nachdem einer der häufig zitierten Grundsätze der ist, dass man NPM die Paketverwaltung überlassen soll und /npm_modules deshalb in die .gitignore gehört, habe ich das zunächst auch so übernommen. Man will sich ja den neuen Konventionen anpassen.
Der Vorteil erscheint offensichtlich: Da man in Node.js ja nicht von fertig kompilierten Assemblies spricht, sondern alles und jedes im Quellcode vorliegt und noch dazu häufig seine eigenen Abhängigkeiten eine Ebene tiefer mit “installiert”, kommen schnell mehrere tausend Dateien zusammen, die das eigene Repository aufblähen.
Doch je länger ich darüber nachgedacht habe, desto mehr Zweifel sind mir gekommen. Letztendlich habe ich mich dann gestern Abend dafür entschieden, alle von extern geladenen Teile meiner Anwendung doch einzuchecken. Hier kommt, warum:
1. Zukunftssicherheit
Wenn ich heute ein altes ASP-Projekt aus 2001 öffne, dann läuft das out of the box. Auch ein .NET—1.1-Projekt aus 2003 bekomme ich mit einem aktuellen Visual Studio ziemlich sicher zum Laufen.
Was aber ist mit einem Node.js-Projekt von 2014, das ich in 2024 noch einmal bauen muss, weil mir zwischenzeitlich der Server mit der 10 Jahre laufenden Installation abgeraucht ist? Dann muss ich beten, dass NPM und Bower noch existieren, dass alle referenzierten Pakete noch da sind, und dass sich in ihnen keine Breaking Changes ergeben haben (Alternative für NPM).
Ein bisschen viel gute Hoffnung für meinen Geschmack. Zu viel.
2. Referenzierte Module sind Teil der Anwendung
Das erste Argument wird Kritikern häufig sogar im Enterprise-Kontext zugestanden. Doch ich denke nicht, dass das nur ein Enterprise-Thema ist.
Denn ein ebenfalls gravierender Punkt ist, dass der Code, der beispielsweise in einer Node-Webanwendung mit Express mitkommt, ein elementarer Bestandteil der eigenen Applikation ist.
Deshalb wäre es doch wünschenswert, dass man Änderungen an diesem Bestandteil mitbekommt. Wie soll das aber funktionieren, wenn man ein gutes Dutzend oder mehr Module referenziert? Soll man von jedem dieser Module regelmäßig das Changelog, so es denn existiert, lesen?
Das geht einfacher: In dem Moment, wo jedes Modul versioniert ist, lassen sich alle Änderungen daran Zeile für Zeile nachvollziehen. Und ggf. rückgängig machen. Langfristig dürfte das viel Zeit bei der Suche nach lästigen und plötzlich auftretenden Fehlern sparen.
3. Kein Internet, kein Build
Ich nehme hier immer das Bild vom Entwickeln im Zug - was in Deutschland weiter schwierig ist, wenn man auf eine stabile Internetverbindung angewiesen ist.
Doch in Überschneidung mit dem ersten Punkt kann man hier auch anführen, dass einmal NPM oder Bower abrauchen könnten. Und wenn es nur für wenige Stunden ist – in dieser Zeit ist dann kein Build möglich. Das ist dann nicht erst in 10 Jahren blöd, sondern schon in zwei Wochen, wenn gerade ein wichtiges Update raus müsste, der Build-Prozess aber hängenbleibt.
Fazit
So gut es sich anfühlt, die Abhängigkeiten wie von Geisterhand über NPM und Bower zu laden, für ernsthafte Projekte abseits von fixen Prototypen, ist es in meinen Augen schlicht fahrlässig, sich davon abhängig zu machen.
