Die fünf npm-Pakete, die KI-Coding-Assistenten ständig empfehlen - und warum keines davon in die Produktion gehört

Jede vibe-gecodete Codebasis, die wir bei Wolf-Tech auditieren, sieht an der Oberfläche anders aus. Unterschiedliche Domänen, unterschiedliche Gründer, unterschiedliche Produktideen. Aber darunter erzählt die Dependency-Liste eine vertraute Geschichte. Dieselben fünf oder sechs npm-Pakete tauchen immer wieder auf - installiert nicht, weil der Entwickler sie ausgewählt hat, sondern weil Cursor, Copilot oder ChatGPT sie vorgeschlagen haben und der Entwickler ohne Nachfrage akzeptiert hat.

Das ist keine Kritik an KI-Coding-Assistenten. Sie sind wirklich nützlich, und die Pakete, die sie empfehlen, waren zu irgendeinem Zeitpunkt oft die richtige Wahl. Das Problem ist, dass KI-Modelle auf historischem Code trainiert sind. Sie können nicht sehen, dass ein Maintainer sein Paket 2020 als deprecated markiert hat, dass ein Supply-Chain-Vorfall 2022 ein Release vergiftet hat oder dass das JavaScript-Ökosystem weitergezogen ist und eine einst beliebte Bibliothek zurückgelassen hat.

Bis eine vibe-gecodete SaaS bei uns landet - meist nach einem gescheiterten Security-Audit, einer Performance-Wand oder einer Due-Diligence-Anfrage eines Investors - sind diese Pakete zu stillen Verbindlichkeiten geworden. Hier sind die fünf, die wir am häufigsten finden, warum jedes davon 2026 ein Problem ist und welche moderne Alternative wir stattdessen installieren.

1. request - der HTTP-Client, der seit fünf Jahren tot ist

Das request-Paket ist seit Februar 2020 deprecated. Sein Maintainer hat eine formelle Deprecation-Notiz veröffentlicht, auf Alternativen verlinkt und keine Sicherheitspatches mehr angenommen. Die npm-Registry zeigt es weiterhin an. KI-Tools empfehlen es weiterhin. Es erhält immer noch rund 15 Millionen wöchentliche Downloads, weil ein großer Teil des Internets seinen Code nicht aktualisiert hat.

In einer vibe-gecodeten Codebasis taucht es typischerweise auf, sobald die App eine externe API aufrufen muss: Stripe-Webhooks, Datenfeeds von Drittanbietern, Zahlungsdienstleister, SMS-Gateways. Cursor oder ChatGPT generiert einen Handler, greift zu request, und der Entwickler installiert es, ohne die npm-Seite zu prüfen.

Das konkrete Risiko: Wenn eine Schwachstelle in der Dependency-Kette von request entdeckt wird - und sie werden entdeckt, weil das Paket weiterhin transitive Abhängigkeiten hat, die sehr wohl aktualisiert werden - gibt es keinen Maintainer, der sie patcht. Dein npm audit wird sie melden, deine CI wird fehlschlagen, und deine einzige Lösung ist die Migration weg vom Paket.

Der Ersatz, den wir installieren: Node.js 18+ liefert natives fetch mit. Für komplexe Anwendungsfälle, die Interceptors, Retry-Logik oder eine Streaming-API benötigen, greifen wir zu got oder undici. Null zusätzliche Abhängigkeiten für einfache API-Aufrufe; spezialisierte Bibliotheken für die Fälle, die sie tatsächlich brauchen.

2. moment - die Datumsbibliothek, die 200 KB liefert, die du nicht brauchst

Die moment.js-Maintainer haben 2020 eine öffentliche Erklärung geschrieben: "We now generally consider Moment to be a legacy project in maintenance mode." Sie empfahlen die Migration zu modernen Alternativen. Das Paket funktioniert weiterhin. Aber es bringt 67 KB gezipptes JavaScript mit - und es ist nicht tree-shakeable, du zahlst also für das komplette Bundle, selbst wenn du nur moment().format() aufrufst.

2026 optimiert jeder große Bundler auf Tree-Shaking. Eine moderne SaaS sollte auf einer 4G-Verbindung in unter drei Sekunden laden. Moment macht das ohne Gegenwert schwerer. Schlimmer noch: Moment-Objekte sind mutable. moment().add(1, 'day') verändert das Originalobjekt in-place. Das erzeugt Bugs, die wirklich schwer zu reproduzieren sind, weil sie von der Aufrufreihenfolge über Komponenten hinweg abhängen.

KI-Assistenten greifen standardmäßig zu Moment, weil es das JavaScript-Ökosystem fast ein Jahrzehnt lang dominiert hat. Ihre Trainingsdaten sind damit gesättigt. Wir finden es in Dashboards, Billing-Seiten, Admin-Panels - überall, wo Datumsangaben auftauchen.

Der Ersatz, den wir installieren: dayjs für einfache Formatierungsbedürfnisse (2 KB gezippt, nahezu identische API zu Moment, standardmäßig immutable). date-fns für komplexe Datumsarithmetik (vollständig tree-shakeable, pure Functions, keine Prototype Pollution). Die Migration von Moment zu dayjs dauert für eine mittelgroße Codebasis typischerweise einen Nachmittag.

3. colors - ein Supply-Chain-Vorfall, der sich zu wiederholen droht

Das colors-Paket hatte im Januar 2022 einen dramatischen Vorfall. Sein Maintainer führte absichtlich einen Breaking Change in Version 1.4.44-liberty ein, der das Paket in eine Endlosschleife versetzte und die Ausgabe jeder Anwendung korrumpierte, die davon abhing. Tausende Projekte - darunter das AWS CDK - waren über Nacht kaputt.

Die Motivation des Maintainers war sein eigener Unmut über die Ökonomie von Open Source. Der Schaden für Downstream-Projekte war unmittelbar und real. Die Episode wurde zur Fallstudie dafür, wie ein einzelner npm-Maintainer mit Publish-Rechten Tausende Produktionsanwendungen lahmlegen kann.

Das Paket erholte sich (eine frühere Version wurde gepinnt), aber der Vorfall legte die fundamentale Fragilität offen, von einem Single-Maintainer-Paket ohne Governance-Prozess abzuhängen. KI-Assistenten empfehlen colors weiterhin, um Terminal-Ausgaben einzufärben, weil der Vorfall nach ihren Trainings-Cutoffs passierte.

Der Ersatz, den wir installieren: chalk (gut verwaltet, TypeScript-first, ESM-kompatibel) oder picocolors für minimale Anwendungsfälle. Beide haben mehrere Maintainer, klare Release-Prozesse und aktives Security-Monitoring. Die API-Migration von colors zu chalk ist eine Suchen-und-Ersetzen-Operation.

4. uuid v1 - Zeitstempel, die die MAC-Adresse deines Servers leaken

Das uuid-Paket selbst ist in Ordnung und wird aktiv gepflegt. Das Problem ist, welche Version KI-Assistenten generieren. Wenn du Cursor oder ChatGPT bittest, einen UUID-Generator zu einem Node.js-Service hinzuzufügen, produzieren sie häufig uuidv1() - eine zeitbasierte UUID, die sowohl den aktuellen Zeitstempel als auch die MAC-Adresse des Netzwerk-Interfaces in die generierte ID kodiert.

In einer SaaS-Anwendung geben UUID v1s, die in API-Responses, URLs oder Logdateien auftauchen, zwei Dinge preis, die du nicht preisgeben willst: den exakten Zeitpunkt, zu dem dein Server den Datensatz erzeugt hat, und einen Fingerabdruck des physischen oder virtuellen Netzwerk-Interfaces, auf dem dein Server läuft. Letzteres ist ein relevantes Privacy-Leak in containerisierten Umgebungen, wo die MAC-Adresse mit Cloud-Provider-Zuweisungen korreliert werden kann.

Über die Privacy-Bedenken hinaus ist UUID v1 sequenziell - kurz nacheinander generierte IDs liegen numerisch nah beieinander. In Datenbanken mit B-Tree-Indizes (also den meisten) sind sequenzielle Inserts in Ordnung. Aber wenn IDs jemals in nutzerseitigen URLs oder externen API-Responses auftauchen, machen sequenzielle IDs Enumeration trivial.

Der Ersatz, den wir verwenden: uuidv4() für zufällige, opake Identifier. Wenn du sortierbare IDs mit eingebetteten Zeitstempeln für Log-Korrelation brauchst, verwende stattdessen ulid - sortierbar, URL-safe und ohne Leak von Hardware-Informationen.

5. Vollständige lodash-Imports - 24 KB für eine Funktion, die du in einer Zeile schreiben könntest

lodash ist keine schlechte Bibliothek. Sie ist gut getestet, gut gepflegt und wirklich nützlich. Das Problem ist, wie KI-Assistenten sie verwenden. Ein häufiges KI-generiertes Muster sieht so aus:

import _ from 'lodash';
const grouped = _.groupBy(items, 'category');

Dieser Import zieht ganz lodash - 24 KB gezippt - für eine einzige Funktion in dein Bundle. In einem serverseitigen Node.js-Kontext ist die Bundle-Größe weniger wichtig. In einem React- oder Next.js-Frontend fügt sie messbare Ladezeit hinzu und ist völlig unnötig.

Die JavaScript-Standardbibliothek hat aufgeholt. Array.prototype.groupBy ist in der Pipeline. Bis dahin lassen sich groupBy, debounce, throttle und die meisten lodash-Funktionen, die Entwickler tatsächlich nutzen, in fünf bis zehn Zeilen Vanilla-JavaScript implementieren, die lesbarer sind, keine Abhängigkeiten haben und leichter zu testen sind.

Wenn wir vibe-gecodete Frontends auditieren, finden wir oft fünf oder sechs lodash-Funktionen, die über eine gesamte Anwendung verteilt genutzt werden - jede durch einen anderen KI-Prompt hinzugefügt, jede zieht die volle Bibliothek. Tree-Shaking fängt das manchmal ab (import groupBy from 'lodash/groupBy' liefert die einzelne Funktion), aber KI-Tools generieren die pfadbasierte Import-Form selten.

Was wir stattdessen installieren: Entweder benannte Imports (import groupBy from 'lodash/groupBy') oder, häufiger, Inline-Implementierungen. Wir greifen auch zu lodash-es, wenn Tree-Shaking korrekt konfiguriert ist. Wenn eine Anwendung mehr als zehn lodash-Funktionen intensiv nutzt, verdient sich die volle Bibliothek ihren Platz - aber diese Schwelle wird in den SaaS-Anwendungen, die wir auditieren, selten erreicht.

Das Muster hinter dem Muster

Jedes dieser Pakete hat dieselbe zugrunde liegende Geschichte: Sie waren exzellent, als die Trainingsdaten gesammelt wurden, und die Welt hat sich weiterentwickelt, ohne dass die KI davon wusste. Supply-Chain-Vorfälle passierten. Maintainer schrieben Deprecation-Notizen. Das JavaScript-Ökosystem baute bessere Alternativen.

Eine vibe-gecodete Anwendung wird schnell gebaut, und genau das ist der Punkt. Aber der Vorschlag der KI ist immer ein Ausgangspunkt, keine finale Entscheidung. Der Fehler, den wir durchgängig sehen, ist, KI-Output als reviewten Output zu behandeln - eine Abhängigkeit zu akzeptieren, ohne ihre npm-Seite, ihr letztes Publish-Datum, ihren Download-Trend und ihre offenen Issues zu prüfen.

Der Renovate-Konfigurationsausschnitt, den wir bei jeder Rettung hinzufügen:

{
  "packageRules": [
    {
      "matchPackageNames": ["request", "moment", "colors", "node-uuid"],
      "matchCurrentVersion": ">=0.0.1",
      "enabled": false,
      "description": "Flagged as deprecated or supply-chain risk - migrate to modern alternative"
    }
  ]
}

Das weist Renovate an, diese Pakete bei jedem PR zu markieren, und verhindert, dass sie nach einem Aufräum-Sprint stillschweigend zurückkehren.

Was tun, wenn diese Pakete bereits in deiner Codebasis sind

Führe zuerst npm audit und npx depcheck aus, um das Gesamtbild zu verstehen. Priorisiere dann nach Risikofläche: Pakete, die Authentifizierung, externe HTTP-Aufrufe oder nutzergelieferte Daten verarbeiten, müssen zuerst migriert werden. Datumsformatierungs-Bibliotheken und Utility-Pakete können im nächsten Sprint folgen.

Wenn du eine vibe-gecodete Codebasis geerbt hast und einen vollständigen Dependency-Review möchtest - nicht nur die fünf Pakete oben, sondern ein komplettes Bild davon, was deprecated ist, was offene Schwachstellen hat und was ersetzt werden sollte - deckt unser Service für Code-Qualitätsberatung das als Teil eines umfassenderen Codebasis-Audits ab.

Wir haben das für SaaS-Teams gemacht, die sich auf eine Series-A-Due-Diligence vorbereiten, für Gründer, die gerade ihren ersten Senior-Entwickler eingestellt haben und die Codebasis in verteidigungsfähigem Zustand brauchen, und für Unternehmen, deren KI-generiertes MVP zu einem verlässlichen Produkt werden muss. Das Dependency-Audit ist selten das größte Problem, das wir finden - aber es ist immer ein Problem, das wir finden.

Wenn dir davon etwas bekannt vorkommt, melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io, um ein Gespräch zu starten. Ein Dependency-Audit dauert einen Tag. Die Gewissheit hält deutlich länger.