node_modules – ein Horrorfilm in mehreren Akten
Ich hab mal nachgezählt wieviele Packages ein frisches npx create-react-app mitbringt. Die Zahl ist unangenehm groß. Sie ist größer als die Anzahl der Packages in jedem PHP-Projekt das ich je betreut habe. Und viele davon sind Packages von denen man nie gehört hat, die von Packages abhängen von denen man auch nie gehört hat.
Warum das so ist
Das npm-Ökosystem hat eine Kultur der kleinen, spezialisierten Packages. Das ist nicht grundsätzlich falsch – Modularität ist gut. Aber es führt dazu dass selbst einfache Aufgaben über viele Ebenen von Abhängigkeiten gelöst werden. Das berühmteste Beispiel: das left-pad-Paket von 2016 – 11 Zeilen Code, von tausenden anderen Paketen abhängig. Als es entfernt wurde, haben halbe Internets aufgehört zu bauen.
npm audit und seine Freunde
Das Schöne an npm audit ist dass es einem sofort sagt wenn irgendetwas in der 47-Ebenen-Abhängigkeitskette eine Sicherheitslücke hat. Das Unschöne ist dass npm audit fix manchmal mehr kaputt macht als es repariert, weil es aggressiv Versionen hochchiebt ohne zu prüfen ob das kompatibel ist.
Ich hab einmal npm audit fix --force auf einem Produktionsprojekt laufen lassen. Das war ein Freitagnachmittag. Ich hab den Nachmittag nicht mehr so verbracht wie geplant.
Was man dagegen tun kann
Abhängigkeiten bewusst wählen statt reflexartig installieren. Für jeden neuen Package fragen: brauche ich das wirklich oder kann ich das in zwanzig Zeilen selbst schreiben? package-lock.json committen. npm ci statt npm install im CI. Und: Vanilla JS wo möglich, Framework wo nötig.
← zurück zu JavaScript 📂 Archiv