Abhängigkeiten pflegen, ohne das Projekt zu zerlegen
Nicht die Menge der Aktualisierungen kostet Zeit, sondern ihr Alter. Wer wöchentlich kleine Schritte macht, hat bei der nächsten Sicherheitsmeldung keinen Rückstand aufzuholen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Aufgeschobene Aktualisierungen werden mit der Zeit nicht billiger
Der typische Verlauf: Die Aktualisierung wird zweimal verschoben, weil gerade eine Auslieferung ansteht. Ein halbes Jahr später kommt eine Sicherheitsmeldung zu einem Paket, das inzwischen vier Hauptversionen weiter ist. Aus dem Anheben einer Zahl ist damit eine Umstellung geworden, und sie steht ausgerechnet unter Zeitdruck an, weil eine Meldung offen ist.
Die zweite Baustelle ist die Frage, was überhaupt installiert wird. In der package.json steht ein Bereich, in der Lockdatei die tatsächliche Version. Wer im Betrieb npm install statt npm ci ausführt, kann eine andere Fassung bekommen als die geprüfte, und wenn die Lockdatei nicht eingecheckt ist, hat jeder Rechner seinen eigenen Stand. Genau daraus entstehen die Fehler, die sich nur auf einem Gerät zeigen.
Der dritte Punkt ist die Gewöhnung. Jede Installation gibt eine Zahl gemeldeter Schwachstellen aus, und der größte Teil davon steckt in Werkzeugen, die nur beim Bauen laufen und nie beim Nutzer ankommen. Wer diese Ausgabe über Monate ignoriert, ignoriert sie auch an dem Tag, an dem eine Meldung tatsächlich die eigene Laufzeit betrifft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was, und wo es meistens hakt
Die häufigste Ursache für liegen gebliebene Aktualisierungen ist keine technische, sondern eine ungeklärte Zuständigkeit. Die folgende Aufteilung hat sich bewährt, weil sie Entscheidung und Umsetzung sauber trennt.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Patch- und Minor-Aktualisierungen | Das Team einmalig als Regel, nicht bei jedem Paket neu: Rhythmus, Gruppierung und was ohne Rückfrage zusammengeführt werden darf. | Ein Bot erzeugt die Vorschläge, die Pipeline prüft sie, eine Person aus dem Team sieht sie durch und führt sie zusammen. | Automatisches Zusammenführen bei dünner Testabdeckung. Grün heißt dann nur, dass nichts geprüft wurde, und der Fehler fällt erst beim Nutzer auf. |
| Sprünge auf eine neue Hauptversion | Technische Leitung gemeinsam mit der fachlichen Planung, weil ein solcher Sprung Zeit im Plan braucht und nicht nebenbei läuft. | Eine Person in einem eigenen Zweig, ein Paket je Zweig, mit dem Änderungsprotokoll und der Migrationsanleitung daneben. | Mehrere Hauptversionen in einem Vorgang. Wenn danach etwas nicht mehr läuft, weiß niemand, welche der Änderungen es war. |
| Gemeldete Schwachstellen | Wer für das Produkt geradesteht, entscheidet über Dringlichkeit und darüber, ob ein Fund bewusst offen bleibt. | Das Entwicklungsteam, mit einer kurzen Notiz je Fund: betroffen, nicht betroffen oder vertagt mit Datum und Begründung. | Der Griff zu npm audit fix mit erzwungener Behebung. Der Befehl zieht neue Hauptversionen herein und macht aus einer Meldung einen Ausfall. |
| Neue Abhängigkeit aufnehmen | Das Team im Review, mit einer Begründung, die über bequem hinausgeht, und mit einem Blick auf vorhandene Alternativen im Projekt. | Wer das Paket vorschlägt, prüft vorab Pflegezustand, Zahl der eigenen Abhängigkeiten, Lizenz, Typen und ob es ESM ausliefert. | Pakete, die eine Handvoll Zeilen ersetzen. Der Gewinn ist einmalig, die Abhängigkeit bleibt und wandert in jede spätere Meldung mit ein. |
| Node- und Werkzeugversionen | Das Team gemeinsam mit dem Betrieb, weil davon Laufzeitumgebung und Container-Abbilder abhängen. | Ein Eintrag unter engines in der package.json, eine .nvmrc im Projekt und dieselbe Version in der Pipeline. | Lokal eine andere Node-Version als in der Pipeline. Die Lockdatei sieht dann bei jedem zweiten Rechner anders aus, und niemand weiß, welcher Stand gilt. |
Patch- und Minor-Aktualisierungen
- Wer entscheidet
- Das Team einmalig als Regel, nicht bei jedem Paket neu: Rhythmus, Gruppierung und was ohne Rückfrage zusammengeführt werden darf.
- Wer setzt um
- Ein Bot erzeugt die Vorschläge, die Pipeline prüft sie, eine Person aus dem Team sieht sie durch und führt sie zusammen.
- Stolperfalle
- Automatisches Zusammenführen bei dünner Testabdeckung. Grün heißt dann nur, dass nichts geprüft wurde, und der Fehler fällt erst beim Nutzer auf.
Sprünge auf eine neue Hauptversion
- Wer entscheidet
- Technische Leitung gemeinsam mit der fachlichen Planung, weil ein solcher Sprung Zeit im Plan braucht und nicht nebenbei läuft.
- Wer setzt um
- Eine Person in einem eigenen Zweig, ein Paket je Zweig, mit dem Änderungsprotokoll und der Migrationsanleitung daneben.
- Stolperfalle
- Mehrere Hauptversionen in einem Vorgang. Wenn danach etwas nicht mehr läuft, weiß niemand, welche der Änderungen es war.
Gemeldete Schwachstellen
- Wer entscheidet
- Wer für das Produkt geradesteht, entscheidet über Dringlichkeit und darüber, ob ein Fund bewusst offen bleibt.
- Wer setzt um
- Das Entwicklungsteam, mit einer kurzen Notiz je Fund: betroffen, nicht betroffen oder vertagt mit Datum und Begründung.
- Stolperfalle
- Der Griff zu npm audit fix mit erzwungener Behebung. Der Befehl zieht neue Hauptversionen herein und macht aus einer Meldung einen Ausfall.
Neue Abhängigkeit aufnehmen
- Wer entscheidet
- Das Team im Review, mit einer Begründung, die über bequem hinausgeht, und mit einem Blick auf vorhandene Alternativen im Projekt.
- Wer setzt um
- Wer das Paket vorschlägt, prüft vorab Pflegezustand, Zahl der eigenen Abhängigkeiten, Lizenz, Typen und ob es ESM ausliefert.
- Stolperfalle
- Pakete, die eine Handvoll Zeilen ersetzen. Der Gewinn ist einmalig, die Abhängigkeit bleibt und wandert in jede spätere Meldung mit ein.
Node- und Werkzeugversionen
- Wer entscheidet
- Das Team gemeinsam mit dem Betrieb, weil davon Laufzeitumgebung und Container-Abbilder abhängen.
- Wer setzt um
- Ein Eintrag unter engines in der package.json, eine .nvmrc im Projekt und dieselbe Version in der Pipeline.
- Stolperfalle
- Lokal eine andere Node-Version als in der Pipeline. Die Lockdatei sieht dann bei jedem zweiten Rechner anders aus, und niemand weiß, welcher Stand gilt.
Fünf Fragen vor jeder Aktualisierung
- 01 Ist es Patch, Minor oder Major? Nur das Letzte braucht eigene Zeit.
- 02 Steckt das Paket zur Laufzeit im Produkt oder nur im Bauvorgang?
- 03 Sagt die Pipeline etwas Belastbares, wenn der Lauf grün ist?
- 04 Gibt es ein Änderungsprotokoll mit einer Migrationsanleitung?
- 05 Wie alt ist die Version, die gerade bei euch im Einsatz ist?
Was du danach als Verabredung im Team hast
Die Pflege von Abhängigkeiten ist weniger eine technische als eine organisatorische Aufgabe. Nötig sind vier Verabredungen: wer wann kleine Aktualisierungen zusammenführt, wie ein Hauptversionssprung geplant wird, wie eine Meldung bewertet wird und wer über neue Pakete entscheidet.
Die Lockdatei als verbindliche Antwort behandeln
Der Bereich in der package.json sagt, was erlaubt ist, die Lockdatei sagt, was installiert wird. Sie gehört in die Versionsverwaltung, und in der Pipeline gehört npm ci statt npm install, weil nur das die Lockdatei unverändert übernimmt.
Klein und regelmäßig statt groß und selten
Ein fester wöchentlicher Termin für Patch- und Minor-Aktualisierungen kostet Minuten. Derselbe Umfang nach einem halben Jahr kostet Tage, weil sich Änderungen überlagern und die Zuordnung eines Fehlers schwerfällt.
Vorschläge automatisch erzeugen lassen
Renovate oder Dependabot legen die Änderungen an, die Pipeline prüft sie. Sinnvoll sind Gruppen, etwa alle Pakete eines Werkzeugs in einem Vorgang, und ein Zeitfenster, das nicht mit dem Auslieferungstag zusammenfällt.
Neue Versionen ein paar Tage reifen lassen
Eine kurze Wartezeit vor der Übernahme brandneuer Veröffentlichungen kostet nichts und schützt gegen zurückgezogene oder kompromittierte Pakete. Renovate kennt dafür eine Mindestwartezeit als Einstellung.
Meldungen bewerten statt abarbeiten
Entscheidend ist, ob der betroffene Code in deiner Laufzeit erreichbar ist oder nur beim Bauen läuft. npm audit mit dem Zusatz für ausgelassene Entwicklungsabhängigkeiten trennt beides und macht aus einer langen Liste eine kurze.
Hauptversionen einzeln planen
Ein Sprung pro Zweig, mit dem Änderungsprotokoll daneben und ohne fachliche Änderung im selben Vorgang. Nur dann lässt sich ein danach auftretender Fehler eindeutig zuordnen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was das Dachzeichen wirklich erlaubt
Ein Eintrag wie ^1.4.2 erlaubt jede Version bis ausschließlich 2.0.0, also alle Minor- und Patch-Sprünge. ~1.4.2 erlaubt nur Patch-Sprünge bis ausschließlich 1.5.0. Eine reine Zahl ohne Zeichen bindet exakt. Wichtig ist der Sonderfall bei Nullversionen: Bei ^0.4.2 gilt die mittlere Stelle als Hauptversion, erlaubt sind also nur 0.4.x. Genau deshalb verhalten sich Pakete vor der 1.0 anders, als die meisten erwarten.
Der Bereich sagt allerdings nur, was erlaubt wäre. Was tatsächlich installiert wird, steht in der Lockdatei, und die gehört in die Versionsverwaltung, auch bei Bibliotheken. Für Konsumenten einer Bibliothek hat sie zwar keine Wirkung, für die eigene Pipeline schon, denn sie ist der Unterschied zwischen einem reproduzierbaren und einem zufälligen Lauf.
In der Pipeline gehört deshalb npm ci und nicht npm install. Der Befehl installiert ausschließlich das, was in der Lockdatei steht, löscht node_modules vorher und bricht ab, wenn Lockdatei und package.json nicht zusammenpassen. Genau dieser Abbruch ist erwünscht, denn er macht sichtbar, dass jemand einen Bereich geändert hat, ohne die Lockdatei mitzuliefern.
Ein Rhythmus, den niemand verschiebt
Wöchentlich, an einem festen Tag, gruppiert und in kleiner Menge: Das ist der ganze Trick. Gruppieren heißt, alle Pakete eines Werkzeugs in einem Vorgang zusammenzufassen, weil sie ohnehin zusammen versioniert werden. Der Tag sollte nicht der Auslieferungstag sein, sonst wird der Vorgang jedes Mal verschoben und wächst weiter an.
Ein zweiter Baustein ist die Wartezeit. Neu veröffentlichte Versionen ein paar Tage liegen zu lassen, kostet nichts und fängt zwei Fälle ab: zurückgezogene Veröffentlichungen mit Fehlern und die selteneren Fälle, in denen ein Konto eines Paketautors übernommen wurde. Renovate bietet dafür eine Mindestwartezeit als Einstellung an, sodass die Regel nicht an der Disziplin einzelner hängt.
Der dritte Baustein ist das Lesen von Hinweisen auf veraltete Funktionen. Warnungen beim Bauen sind die Vorankündigung des nächsten Hauptversionssprungs, und wer sie abarbeitet, während die alte Version noch läuft, hat beim Sprung selbst kaum noch Arbeit. Das ist der Unterschied zwischen einer Umstellung in Etappen und einer Umstellung an einem Wochenende.
Meldungen einordnen statt abhaken
npm audit vergleicht deinen Abhängigkeitsbaum mit einer Datenbank bekannter Schwachstellen. Was es nicht prüft, ist die Erreichbarkeit: Ob die betroffene Funktion in deinem Programm überhaupt aufgerufen wird, weiß der Befehl nicht. Deshalb sagt eine hohe Zahl gemeldeter Funde wenig über das tatsächliche Risiko aus, und deshalb ist die erste Frage immer, wo das Paket steckt.
Die brauchbare Trennung verläuft zwischen Laufzeit und Bauzeit. Eine Schwachstelle in einem Werkzeug, das nur auf dem Bau-Rechner läuft, ist etwas anderes als eine in einer Bibliothek, die auf dem Server Anfragen entgegennimmt oder im Browser Nutzereingaben verarbeitet. npm audit --omit=dev liefert genau diese Trennung, und die verbleibende Liste ist meist kurz genug, um sie einzeln zu bewerten.
Steckt die verwundbare Fassung tief im Baum und der direkte Abhängige hat noch nicht nachgezogen, hilft das Feld overrides in der package.json: Es erzwingt für ein transitives Paket eine bestimmte Version. Das ist ein Eingriff und gehört getestet, denn du setzt damit die Angabe des Paketautors außer Kraft. Und wenn ein Fund bewusst offen bleibt, gehört das mit Datum und Begründung notiert, sonst wiederholt ihr die Bewertung in drei Monaten von vorn.
Bevor ein Paket ins Projekt kommt
Eine Abhängigkeit ist Code, den du ausführst, und beim Installieren möglicherweise auch Code, der auf deinem Rechner läuft, denn Pakete dürfen Skripte beim Installieren ausführen. In Pipelines lässt sich das mit dem Zusatz zum Auslassen dieser Skripte abstellen, wo es die Pakete zulassen. Diese Perspektive hilft bei der Abwägung mehr als jede Diskussion über Bequemlichkeit.
Die Prüfliste vor der Aufnahme ist kurz. Wann kam die letzte Veröffentlichung, wie viele offene Fehlerberichte stehen wie lange offen, wie viele eigene Abhängigkeiten bringt das Paket mit, welche Lizenz gilt, gibt es Typdeklarationen, wird ESM ausgeliefert, und braucht es beim Installieren einen Übersetzungsvorgang mit nativem Code. Der letzte Punkt ist der am meisten unterschätzte, denn er bindet dich an bestimmte Node-Versionen und an das Abbild, in dem gebaut wird.
Bei sehr kleinen Paketen lohnt der Vergleich mit der Alternative, die Funktion selbst zu schreiben. Zehn Zeilen im eigenen Projekt sind auf Dauer billiger als eine Abhängigkeit, die in jeder Sicherheitsmeldung, in jedem Aktualisierungsvorgang und in jedem Bündel wieder auftaucht. Umgekehrt gilt genauso: Bei allem, was Sonderfälle kennt, etwa Zeitzonen oder Zeichensätze, ist die gepflegte Bibliothek die günstigere Wahl.
Der Hauptversionssprung als eigenes Vorhaben
Vor dem ersten Befehl steht das Änderungsprotokoll. Gute Pakete beschreiben die brechenden Änderungen einzeln und liefern eine Migrationsanleitung, manche zusätzlich ein Werkzeug, das den Code umschreibt. Diese halbe Stunde Lesen ist der Unterschied zwischen einer gezielten Umstellung und dem Verfahren, in dem man so lange etwas ändert, bis die Tests wieder grün sind.
Danach gilt: ein Paket, ein Zweig, keine fachlichen Änderungen nebenher. Der Typprüfer und die Tests sind dabei die Landkarte, sie zeigen die betroffenen Stellen. Wenn ein Sprung mehr als ein paar Stunden kostet, gehört er in die Planung wie jede andere Aufgabe, mit Zeitrahmen und einer klaren Abbruchbedingung.
Manchmal ist die richtige Entscheidung, nicht zu springen. Auch das ist eine Entscheidung und gehört aufgeschrieben, samt Grund und dem Zeitpunkt, zu dem sie erneut geprüft wird. Was nicht funktioniert, ist die stillschweigende Variante: Niemand hat entschieden zu bleiben, es hat sich nur ergeben, und in zwei Jahren erklärt niemand mehr, warum die Anwendung auf einer Fassung läuft, für die es keine Korrekturen mehr gibt.
Dazu passende Kurse
Wer im Team einen Rhythmus für Paketaktualisierungen finden will, braucht dafür weniger Werkzeuge als Verabredungen, und genau solche Abläufe sind Teil der JavaScript- und Node-Kurse bei cmt.
Wenn regelmäßig Meldungen aus dem Abhängigkeitsbaum auf deinem Tisch landen, hilft ein Überblick darüber, wie Schwachstellen bewertet werden, dafür gibt es Kurse rund um Sicherheit in Betrieb und Anwendung .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Die Schulung ist gerade für Einsteiger oder Entwickler*innen mit eingestaubtem Basiswissen sehr hilfreich.
Ich bin sehr glücklich Franz als Trainer gehabt zu haben. Er hat offensichtlich unglaublich viel Wissen zu den Themen, und schafft es, dieses auch interaktiv und verständlich weiterzugeben.
Häufige Fragen
Gehört die Lockdatei in die Versionsverwaltung?
npm install oder npm ci in der Pipeline?
Wie oft ist oft genug?
Was tun, wenn ein Paket nicht mehr gepflegt wird?
Passt thematisch dazu
Nach welchen Kriterien ein Team über ein fremdes Paket entscheidet und wie die Prüfung danach bei jedem Pull Request automatisch weiterläuft, zeigen die Aufnahmeregeln für fremde Pakete in Rust-Projekten .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Webentwicklung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Abhängigkeiten, die kein Ereignis mehr sind
In den Node-Kursen bei cmt richtest du diesen Ablauf an einem Projekt ein, von den Versionsbereichen über die Lockdatei bis zur Bewertung einer Sicherheitsmeldung.