Eine kleine Library stürzt das JavaScript-Ökosystem ins Chaos

Erinnert ihr euch an Leftpad im Jahr 2016? Als ein Entwickler einfach entschied, das Package zu unpublishen und Millionen anderer Projekte ins Chaos stürzte? Etwas Ähnliches ist übers Wochenende passiert.

Anzeige Ein Update an einer winzigen JS-Bibliothek hat am Samstag einen großen Teil des JavaScript-Ökosystems ins Chaos gestürzt, mehrere Millionen Projekte waren davon betroffen. Das Absurde an der Geschichte: Das Chaos wurde von einer zweizeiligen JavaScript-Library verursacht. Die ganze Situation erinnert stark an den berühmt-berüchtigten Leftpad-Case im Jahr 2016, als das Unpublishen des Packages weitreichende Probleme verursachte. Der diesmalige Übeltäter ist ein Zweizeiler namens is-promise, ein Package, mit dem in Production gecheckt werden kann, ob ein JS-Objekt eine sogenannte promise ist. Zurück bekommen Entwickler je nach Fall ein true oder false. Obwohl is-promise nur aus zwei Zeilen Code besteht und nur einen Boolean zurückgibt, ist die Library eines der meistgenutzten npm-Pakete überhaupt. is-promise findet sich in 3,4 Millionen Projekten und wird in 766 anderen JS-Libraries als Dependency verwendet. Anzeige Fehlerhaftes Update

Am Wochenende erhielt die is-Promise Library ein Update – sie sollte in der Folge dem ES-Module-Standard entsprechend funktionieren. Dabei ist offenbar etwas schiefgelaufen: Nach Veröffentlichung des Updates crashten Projekte, die is-Promise in ihrer Build-Chain verwenden. Der ES-Modul-Support war bei dem Update der Library offenbar fehlerhaft umgesetzt worden. Mit sofortigen Auswirkungen: Sowohl kleinere, private Projekte als auch einige der größten Projekte innerhalb des JS-Ökosystems waren betroffen, darunter Angular, Nuxt.js, create-react-app, AVA oder Googles Firebase-Tools.

Nix mehr verpassen: Die t3n Newsletter zu deinen Lieblingsthemen! Jetzt anmelden Kompilieren neuer Versionen unmöglich

Glücklicherweise crashte der Bug keine bereits existenten Projekte, es gab also keine faktische Downtime. Aber er behinderte das Kompilieren neuer Versionen. Bereits Stunden später rollte das Team um die Library ein Update aus, in dem sie es aber nicht schafften, die Probleme zu fixen. Schließlich entschieden sie sich dazu, den ES-Module-Support vorerst wieder zurückzuziehen.

Angestachelte Debatte

Ähnlich wie im Jahr 2016, als mit Leftpad erstmals eine winzige Library ein ganz ähnliches Chaos im JavaScript-Ökosystem verursachte, stachelte auch dieser Vorfall die Diskussion um die Modularisierung von Code innerhalb des JS-Ökosystems an. Die eine Seite ist der Meinung, dass die Modularisierung im Fall von so winzigen Libraries, die für derart triviale Aufgaben eingesetzt werden, einfach zu weit getrieben wird. Code, den man selber geschrieben habe, sei wenigstens unter der eigenen Kontrolle:

I’ve found little difference in long-term maintenance time between rolling my own and using third-party services/libraries in practice.

Services change and go away.

Libraries change and add complexity to the build and project.

At least when it’s your code, you’re in control. https://t.co/Ydl3Qf3EjN

— Marco Arment (@marcoarment) April 26, 2020 Anzeige

Die Gegenseite argumentiert, dass gerade diese Modularisierung total wertvoll sei, weil sie erlaubt, eine Aufgabe mithilfe eines Moduls auf effiziente Art und Weise zu lösen, anstatt jeden Entwickler und jede Entwicklerin zu einer eigenen Lösung für ihre jeweiligen Projekte zu zwingen.

 

https://samplecic.ch/eine-kleine-library-sturzt-das-javascript-okosystem-ins-chaos.html