Gestern habe ich bei meiner eigenen Seite eine tägliche Prüfung der Abhängigkeiten eingerichtet. Einmal am Tag läuft ein Agent über die Pakete, schreibt auf, was veraltet oder unsicher ist, und schickt mir das in Slack. Und ja, kurz danach hatte ich das erste Update schon auf dem Tisch. Nodemailer, das Paket, das bei mir die Mails verschickt, stand noch auf Version 6. Aktuell ist 10, und für die alte Version gab es gleich drei Sicherheitshinweise, unter anderem einen, bei dem SMTP-Zugangsdaten rausrutschen können. Hochziehen ging schnell, am Code musste ich gar nichts ändern. Aber eine Sache ist mir dabei aufgefallen. Version 10 braucht Node.js 20 oder neuer.
Bei mir kein Problem, die Seite läuft auf Node 24. Aber so funktioniert das halt, die Pakete ziehen irgendwann die Laufzeit mit. Wer bei Node lange nichts gemacht hat, kann irgendwann auch die Pakete nicht mehr aktualisieren, und dann sitzt man auf Sicherheitslücken, die eigentlich längst behoben sind.
Was sich bei Node gerade ändert
Ende Oktober wird Node.js 26 zur LTS-Version, also zu der Version, die man im Betrieb benutzen soll. Gleichzeitig stellt das Projekt den Rhythmus um, das hatten sie im März angekündigt. Bisher gab es zwei Hauptversionen im Jahr, die geraden wurden LTS, die ungeraden hat ehrlich gesagt kaum jemand im Betrieb benutzt. Ab Node 27 gibt es nur noch eine Hauptversion pro Jahr, immer im April, jede wird LTS und bekommt insgesamt 36 Monate Unterstützung. Die Versionsnummer passt dann auch zum Jahr, 27 kommt 2027, 28 kommt 2028. Vorher gibt es ab Oktober eine Alpha-Phase zum Testen.
Die Begründung finde ich ziemlich ehrlich. Also, die ungeraden Versionen hat kaum jemand benutzt, und die Leute, die Node pflegen, und das sind zu großen Teilen Freiwillige, mussten vier bis fünf Versionen gleichzeitig mit Korrekturen versorgen. War auf Dauer einfach nicht zu stemmen.
Für alle, die gerade nicht wissen, wo sie stehen, laut endoflife.date sieht es so aus: Node 20 bekommt seit dem 30. April 2026 keine Sicherheitsupdates mehr. Node 22 noch bis April 2027. Node 24 geht Ende Oktober in die Wartung und bekommt bis April 2028 Sicherheitskorrekturen. Node 26 läuft bis April 2029.
Warum mich das freut
Ich habe lange gedacht, Updates macht man, wenn was ist. Eine Sicherheitsmeldung kommt rein, man guckt, ob man betroffen ist, man zieht das Paket hoch, fertig. Klappt auch. Solange es um ein einzelnes Paket geht. Bei der Laufzeit klappt das aber nicht, weil ein Sprung von Node 18 auf 24 kein Nachmittag ist, wenn dazwischen drei Jahre liegen und jedes zweite Paket was anderes erwartet. Und das merkt man dann meistens genau in der Woche, in der eigentlich was anderes dran wäre.
Genau deshalb machen wir Entwicklung bei Kunden auch im Abo und nicht als Projekt mit Abgabetermin. Software ist nach dem Livegang ja nicht fertig, die läuft auf einem Server, auf einer Laufzeit, mit ein paar Hundert Paketen von anderen Leuten, und die bewegen sich alle weiter, ob man will oder nicht. Wenn das keiner im Blick hat, fällt es irgendwann auf. Und dann wird es teuer.
Mit dem festen Rhythmus bei Node wird das jetzt irgendwie richtig planbar. Einmal im Jahr, im Herbst, wenn die neue Version LTS wird, ist der Termin. Man muss nicht mehr überlegen, ob gerade 25 oder 26 die richtige ist, es gibt einfach die eine.
So würde ich das angehen
Wer Node-Anwendungen betreibt, selbst oder über eine Agentur, kann das in einer Stunde einmal sortieren:
- Aufschreiben, welche Anwendung auf welcher Node-Version läuft. Auf dem Server reicht
node -v, im Projekt steht es oft unterenginesin derpackage.jsonoder im Dockerfile. Oft weiß das nur einer. Ulf. - Alles, was noch auf Node 20 oder älter läuft, ganz nach oben auf die Liste. Das bekommt seit April keine Korrekturen mehr.
- Einen festen Termin im Jahr in den Kalender schreiben, der für die Laufzeit reserviert ist. Für 2026 bietet sich November an, wenn Node 26 LTS ist und die ersten Kinderkrankheiten raus sind.
- Die Pakete laufend prüfen lassen, täglich oder wöchentlich, und die Meldung an jemanden schicken, der sie auch liest. Ein Bericht, den keiner aufmacht, hilft genau gar nicht.
Der vierte Punkt ist der, der den dritten klein hält. Wenn die Pakete das Jahr über aktuell bleiben, ist der Sprung auf die neue Node-Version meistens ziemlich unspektakulär.
Wie ist das bei euch, gibt es so einen Termin im Jahr schon, oder wird die Laufzeit erst angefasst, wenn ein Paket nicht mehr will? Wer das einmal sortiert haben möchte, kann sich gern melden, das geht meistens schneller, als man denkt.