Stellen Sie sich vor, Sie ziehen in eine neue Wohnung. Früher mussten Sie Kühlschrank, Herd und Waschmaschine selbst mitbringen. Heute ist die Küche bereits eingebaut. Sie können natürlich trotzdem Ihre eigene Kaffeemaschine aufstellen, aber für den Alltag brauchen Sie sie oft gar nicht mehr.

Genau so geht es Ihnen inzwischen mit Node.js. Wer eine package.json aus dem Jahr 2020 öffnet, findet fast immer dieselben Namen: axios, nodemon, dotenv, jest, chalk, uuid, rimraf. Für jedes dieser Pakete bringt Node.js mittlerweile eine eigene, eingebaute Lösung mit. In diesem Artikel stelle ich Ihnen zwölf dieser eingebauten Bordmittel vor. Zu jedem erfahren Sie, welches Paket es ersetzt, wie ein einfaches Beispiel aussieht, wie stabil es in der aktuellen LTS-Version ist und an welcher Stelle das alte Paket immer noch mehr kann.

Bevor es losgeht: Welche Node-Version zählt?

Die Angaben in diesem Artikel beziehen sich auf Node 24, die aktuelle Active-LTS-Linie (Stand September 2026). Zur Einordnung ein kurzer Überblick über die Versionen:

• Node 20 hat am 30. April 2026 sein Lebensende erreicht.
• Node 22 befindet sich noch bis April 2027 im Wartungsmodus.
• Node 26 wird am 28. Oktober 2026 zur nächsten LTS-Version.

Wo sich Node 22 und Node 24 unterscheiden, weise ich ausdrücklich darauf hin.

Die Stabilitätsstufen verstehen

Node.js kennzeichnet jede Schnittstelle mit einer Stabilitätsstufe. Sie können sich das wie die Ampel an einer Baustelle vorstellen:

• Stufe 2 (stabil): grünes Licht, Sie können die Funktion bedenkenlos in Produktion einsetzen.
• Stufe 1 (experimentell): gelbes Licht, mit drei Unterstufen: 1.0 bedeutet frühe Entwicklung, 1.1 aktive Entwicklung und 1.2 Release Candidate.

Alles, was experimentell ist, kann sich in einer kleinen Folgeversion ändern oder sogar wieder verschwinden. Wenn Sie also Code für den Produktivbetrieb schreiben, lohnt sich ein Blick auf diese Zahl.

Daten, Tests und Netzwerk

1. node:sqlite statt better-sqlite3

Wer bisher mit SQLite arbeiten wollte, griff meist zu better-sqlite3. Das Paket ist ein sogenanntes natives Addon, das bei jeder Installation kompiliert oder als vorgefertigte Binärdatei heruntergeladen werden musste. Seit Node 22.5 steckt ein SQLite-Treiber direkt im Kern. Wie sein Vorbild arbeitet er synchron. Der Code liest sich also wie ein Kochrezept von oben nach unten, ganz ohne await.

import { DatabaseSync } from 'node:sqlite';

const db = new DatabaseSync('kontakte.db');
db.exec(
  'CREATE TABLE IF NOT EXISTS kontakte (id INTEGER PRIMARY KEY, name TEXT)',
);

db.prepare('INSERT INTO kontakte (name) VALUES (?)').run('Anna Schmidt');
console.log(db.prepare('SELECT * FROM kontakte').all());

Beachten Sie: Das Modul existiert nur mit dem Präfix node:. Ein schlichtes import 'sqlite' schlägt fehl.

Status und Einschränkung

In Node 24 hat das Modul seit Version 24.15.0 die Stufe 1.2 erreicht und gibt keine Warnung mehr aus. In Node 22 steht es dagegen noch auf 1.1. Das Flag --experimental-sqlite ist dort zwar seit 22.13 verschwunden, die Einstufung aber nicht.

Was fehlt, ist eine Komfortfunktion für Transaktionen. better-sqlite3 bietet db.transaction(fn), das eine Funktion automatisch mit BEGIN, COMMIT und ROLLBACK umschließt. Bei node:sqlite schreiben Sie diese drei Anweisungen selbst in einen try/catch-Block.

2. node:test und node:assert statt Jest und Mocha

Jest war lange der Standard für Tests, Mocha zusammen mit Chai die beliebte Alternative. Beide sind nach wie vor brauchbar. Seit Node 20 liefert Node.js aber einen eigenen Testrunner samt Assertion-Bibliothek mit, und der erste Test kommt ohne jede Konfiguration aus.

import { test } from 'node:test';
import assert from 'node:assert/strict';

test('addiert zwei Zahlen', () => {
  assert.equal(3 + 4, 7);
});

Gestartet wird mit node --test. Node sucht dann selbstständig nach Dateien, deren Name etwa auf .test.js endet.

Status und Einschränkung

Der Testrunner ist seit Node 20.0.0 stabil, node:assert sogar schon deutlich länger. Anders sieht es an den Rändern aus: Die Codeabdeckung benötigt --experimental-test-coverage und ist experimentell. Das Mocken ganzer Module über mock.module() steckt hinter einem eigenen Flag auf Stufe 1.0, und auch der Watch-Modus für Tests ist noch experimentell. Einzelne Funktionen können Sie dagegen stabil über t.mock.fn() mocken. Für normale Unit-Tests reicht das völlig aus. Wenn Ihre Testsuite jedoch stark auf das Mocken kompletter Module setzt, bleiben Sie vorerst bei Jest.

3. Globales fetch() statt axios und node-fetch

Axios war jahrelang das Erste, was man in einem Node-Projekt installierte, um mit einer API zu sprechen. Heute steht Ihnen die aus dem Browser bekannte Fetch-API einfach zur Verfügung:

const antwort = await fetch('https://api.github.com/repos/nodejs/node');
const daten = await antwort.json();

console.log(daten.full_name, antwort.status);

Unter der Haube arbeitet undici, ein für Node geschriebener HTTP/1.1-Client. Zusätzlich stehen Request, Response, Headers und FormData global bereit. Code, der im Browser oder in einem Cloudflare Worker läuft, funktioniert also in Node auf dieselbe Weise.

Status und Einschränkung

fetch() ist seit Node 21.0.0 stabil und seit Node 18 ohne Flag verfügbar. Die wichtigste Stolperfalle: fetch() wirft bei einem 404- oder 500-Fehler keinen Fehler. Axios dagegen tut genau das bei jedem Statuscode außerhalb des 200er-Bereichs, und viel bestehender Code verlässt sich stillschweigend darauf. Mit fetch() prüfen Sie also jedes Mal selbst res.ok. Das ist ein wenig so, als würde der Briefträger Ihnen auch einen Brief mit dem Vermerk „Empfänger unbekannt“ kommentarlos in den Kasten werfen: Sie müssen selbst nachsehen, was drinsteht.

Außerdem fehlen Interceptors und automatische Wiederholungsversuche. Proxy-Einstellungen aus HTTP_PROXY und HTTPS_PROXY werden nur beachtet, wenn Sie Node mit --use-env-proxy starten; dieses Flag kam in 24.5.0 hinzu und ist noch experimentell. Zeitlimits setzen Sie über AbortSignal.timeout():

const antwort = await fetch('https://example.com/feed.xml', {
  signal: AbortSignal.timeout(3000),
});

4. Der WebSocket-Client statt ws

Das Paket ws ist die bekannte WebSocket-Bibliothek für Node, sowohl für Server als auch für Clients. Den Client-Teil übernimmt heute die aus dem Browser bekannte Klasse WebSocket, die Node global bereitstellt:

const ws = new WebSocket('wss://echo.websocket.org');

ws.addEventListener('open', () => ws.send('Hallo aus Node'));
ws.addEventListener('message', (event) => {
  console.log(event.data);
  ws.close();
});

Status und Einschränkung

Seit 22.0.0 standardmäßig aktiv und seit 22.4.0 stabil. Allerdings handelt es sich um einen reinen Client. Einen WebSocketServer gibt es im Node-Kern nicht. Ein Bot oder ein Kommandozeilenwerkzeug, das sich mit fremden Sockets verbindet, kommt ohne ws aus. Jeder Server, der selbst Verbindungen annimmt, braucht das Paket weiterhin.

Werkzeuge für den Entwickleralltag

5. node --watch statt nodemon

nodemon startet Ihr Programm neu, sobald sich eine Datei ändert. Node kann das seit Version 18.11 selbst, und zwar mit einem einzigen Flag:

node --watch server.js

Ändern Sie server.js oder eine importierte Datei, startet Node automatisch neu. Mit --watch-preserve-output bleibt die bisherige Ausgabe im Terminal erhalten.

Status und Einschränkung

Stabil seit 22.0.0 (und 20.13.0). Beobachtet werden allerdings nur die Einstiegsdatei und die von ihr importierten Module. Eine JSON-Datei, die Sie per fs.readFile() einlesen, eine Vorlage oder eine .env-Datei lösen keinen Neustart aus. Zwar können Sie mit --watch-path weitere Ordner hinzufügen, doch diese Option funktioniert nur unter macOS und Windows. Zudem lässt sich --watch nicht mit --run kombinieren. nodemon ist hier flexibler: Es beobachtet beliebige Pfade auf jeder Plattform und erlaubt Dateiendungen, Ausschlusslisten und Verzögerungen.

6. --env-file und process.loadEnvFile() statt dotenv

Das Einlesen einer .env-Datei war die Aufgabe von dotenv. Heute erledigt Node das selbst, entweder beim Start:

node --env-file=.env app.js

oder direkt im Code, ganz ähnlich wie früher dotenv.config():

process.loadEnvFile();

Beide Varianten verstehen Werte in Anführungszeichen, mehrzeilige Werte und Kommentare mit #. Das Flag kann sogar NODE_OPTIONS aus der Datei auslesen und anwenden, was dotenv nie konnte. Bei process.loadEnvFile() kommt das zu spät: Der Wert landet zwar in process.env, bewirkt aber nichts mehr.

Status und Einschränkung

Stabil seit 24.10.0 beziehungsweise 22.21.0. Ältere 22er-Versionen zeigen unter Umständen noch eine Warnung. Was fehlt, ist die Variablenersetzung: Schreiben Sie URL=http://${HOST}:3000, erhalten Sie wörtlich diese Zeichenkette mit Dollarzeichen. Dafür gibt es weiterhin dotenv-expand. Außerdem gilt:

• --env-file bricht ab, wenn die Datei fehlt. Für optionale Dateien nutzen Sie --env-file-if-exists.
• Bereits in der Shell gesetzte Variablen haben Vorrang vor der Datei.

7. util.parseArgs() statt yargs, commander und minimist

Das Auswerten von Kommandozeilenargumenten gehört zu den am häufigsten nachinstallierten Aufgaben überhaupt. Seit Node 18.3 steckt ein eigener Parser in node:util:

import { parseArgs } from 'node:util';

const { values, positionals } = parseArgs({
  options: {
    port: { type: 'string', short: 'p', default: '3000' },
    verbose: { type: 'boolean', short: 'v' },
  },
  allowPositionals: true,
});

console.log(values, positionals);

Ein Aufruf wie node deploy.js --port 8080 -v production liefert die Optionen als Objekt und production als Positionsargument.

Status und Einschränkung

Stabil seit Node 20.0.0. Als Typen sind nur 'string' und 'boolean' erlaubt, Zahlen wandeln Sie selbst um. Eine automatische --help-Ausgabe gibt es nicht, ebenso wenig Unterbefehle. Unbekannte Optionen führen standardmäßig zu einem Fehler, es sei denn, Sie setzen strict: false. Die Faustregel lautet: Für ein kleines Skript mit drei Schaltern genügt parseArgs. Für ein Kommandozeilenwerkzeug, das Sie an andere weitergeben, bleibt commander mit Validierung und Hilfetexten die bessere Wahl.

8. util.styleText() statt chalk

Farbige Ausgaben im Terminal waren das Revier von chalk, denn rohe Escape-Codes sind kaum lesbar. Seit Node 20.12 gibt es styleText():

import { styleText } from 'node:util';

console.log(styleText('green', 'Erfolgreich veröffentlicht'));
console.log(styleText(['bold', 'red'], 'Fehlgeschlagen'));

Mehrere Stile kombinieren Sie, indem Sie ein Array übergeben.

Status und Einschränkung

Stabil seit 22.13.0 (und 23.5.0). Die Funktion prüft vor dem Einfärben den Ausgabekanal. Leiten Sie die Ausgabe in eine Datei oder an ein anderes Programm weiter, liefert styleText() schlichten Text ohne Farbcodes. Das ist sinnvoll und berücksichtigt auch NO_COLOR und FORCE_COLOR, überrascht aber gerne beim Testen von Kommandozeilenausgaben. Mit der Option validateStream: false erzwingen Sie die Farben. Eine verkettete Schreibweise wie chalk.bold.red() gibt es nicht.

Dateien, IDs und TypeScript

9. fs.glob() statt glob

Dateien nach einem Muster zu finden, war die Aufgabe des Pakets glob oder seines flinken Verwandten fast-glob. Node 22 hat diese Fähigkeit in node:fs aufgenommen, Node 24 hat sie stabil gemacht:

import { glob } from 'node:fs/promises';

for await (const datei of glob('src/**/*.md', {
  exclude: ['src/entwuerfe/**'],
})) {
  console.log(datei);
}

Zusätzlich gibt es globSync(), das direkt ein Array zurückgibt. Auch geschweifte Klammern wie **/*.{md,mdx} funktionieren.

Status und Einschränkung

Stabil seit 24.0.0, in Node 22 noch experimentell. Die Promise-Variante liefert einen asynchronen Iterator statt eines Arrays; wer eine Liste braucht, verpackt das Ergebnis in Array.fromAsync(). Die Option zum Ausschließen heißt exclude, nicht ignore. Der Funktionsumfang ist überschaubar, während das glob-Paket ein Dutzend weiterer Optionen und sogar eine eigene Kommandozeile mitbringt. Für typische Build-Skripte reicht die Node-Variante aber aus.

10. crypto.randomUUID() statt uuid

Unzählige Projekte haben das Paket uuid nur für einen einzigen Aufruf installiert. Node beherrscht das seit Version 14.17:

console.log(crypto.randomUUID());

Ein Import ist nicht nötig, denn crypto ist global verfügbar.

Status und Einschränkung

randomUUID() ist stabil. Das globale crypto-Objekt gilt seit Node 23 als stabil; in Node 22 funktioniert es zwar, trägt in der Dokumentation aber noch das Etikett „experimentell“. Erzeugt werden ausschließlich zufällige UUIDs der Version 4. Das Paket uuid bietet zusätzlich Version 7, deren IDs zeitlich sortiert sind und sich daher gut als Primärschlüssel in Datenbanken eignen, außerdem Hilfsfunktionen wie validate() und parse(). Für eine zufällige ID in einem Logeintrag oder Dateinamen genügt die eingebaute Variante völlig.

11. fs.rm() und fs.mkdir() statt rimraf und mkdirp

rimraf war das rm -rf für Node, vor allem damit Aufräumskripte auch unter Windows funktionierten. mkdirp legte verschachtelte Ordner in einem Rutsch an. Beides erledigen heute Optionen der Kernfunktionen:

import { mkdir, rm } from 'node:fs/promises';

await mkdir('build/assets/bilder', { recursive: true });
await rm('build', { recursive: true, force: true });

recursive legt alle fehlenden übergeordneten Ordner an beziehungsweise löscht einen Ordner samt Inhalt. force sorgt dafür, dass ein nicht vorhandener Pfad keinen Fehler auslöst. Beide Funktionen gibt es auch synchron, sodass ein Aufräumskript in der package.json mit einem kurzen node -e-Aufruf auskommt.

Status und Einschränkung

Beides ist stabil, mkdir mit recursive seit Node 10.12, fs.rm() seit 14.14. Das alte fs.rmdir() mit recursive gilt als veraltet. rm() akzeptiert nur einen einzelnen Pfad und kein Muster; wer etwa alle .map-Dateien entfernen will, kombiniert fs.glob() mit einer Schleife. Ohne recursive: true scheitert rm() an Ordnern mit dem Fehler ERR_FS_EISDIR, eine Sicherheitsmaßnahme, die rimraf-Gewohnte gelegentlich überrascht.

12. TypeScript-Type-Stripping statt ts-node und tsx

Wer eine .ts-Datei direkt ausführen wollte, installierte ts-node oder das auf esbuild basierende tsx. Heute genügt:

node begruessung.ts

Node ersetzt die Typangaben einfach durch Leerzeichen und übergibt den Rest an die JavaScript-Engine V8. Das ist ungefähr so, als würden Sie die Notizzettel von einem Bauplan abziehen: Der Plan selbst bleibt unverändert, und weil sich keine Zeilen verschieben, sind auch keine Source Maps nötig. Eine Typprüfung findet dabei allerdings nicht statt, dafür bleibt tsc zuständig.

Status und Einschränkung

Stabil seit 24.12.0, standardmäßig aktiv seit 22.18 und 23.6, ohne Warnung seit 24.3. Zum Abschalten dient inzwischen --no-strip-types. Unterstützt wird nur Syntax, die sich rückstandslos entfernen lässt. Ein enum, ein Namespace mit Laufzeitcode, Parameter-Properties im Konstruktor oder import x = require() führen zum Fehler ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX. In Node 24 hilft noch --experimental-transform-types, doch Node 26 hat dieses Flag entfernt. Weitere Grenzen:

• Importpfade brauchen die Dateiendung, also ./lib.ts statt ./lib.
• Die paths aus der tsconfig.json werden ignoriert.
• Decorators und .tsx-Dateien werden nicht unterstützt.

Ein praktischer Tipp: Setzen Sie in Ihrer tsconfig.json die Option erasableSyntaxOnly: true. Dann meldet tsc die problematische Syntax, bevor Node es tut.

Was bedeutet das für Ihre package.json?

Jedes der vorgestellten eingebauten Funktiomem deckt den häufigsten Anwendungsfall ab und hört dort auf. Das alte Paket bleibt nützlich für alles, was darüber hinausgeht. Einige Beispiele:

• Wer bei jeder Anfrage zentral einen Authentifizierungs-Header anhängen möchte, behält axios oder schreibt sich einen kleinen Wrapper um fetch().
• Jeder WebSocket-Server braucht weiterhin ws.
• Eine Testsuite, die ganze Module mockt, bleibt bei Jest, bis mock.module() die Stufe 1.0 verlässt.

Prüfen Sie Ihr Deployment-Ziel

Denken Sie daran: Die hier genannten Stabilitätsangaben gelten für Node 24. Unter Node 22 sind node:sqlite und fs.glob() noch experimentell, --env-file war es bis 22.21, und das globale crypto trägt noch das Etikett. Schauen Sie deshalb nach, welche Version auf Ihrem Server läuft, bevor Sie ein Paket entfernen. Hinterlegen Sie die Version zusätzlich im Feld engines Ihrer package.json, damit niemand raten muss.

Fazit: Aufräumen lohnt sich

Node.js hat sich still und leise von einem schlanken Grundgerüst zu einer gut ausgestatteten Werkstatt entwickelt. Vieles, wofür Sie früher ein halbes Dutzend Pakete installieren mussten, liegt heute bereits im Werkzeugkasten. Das bedeutet nicht, dass axios, Jest oder commander über Nacht nutzlos geworden sind. Wohl aber lohnt es sich, bei jedem dieser Pakete kurz innezuhalten und zu fragen: Brauche ich wirklich die zusätzliche Funktion, die nur das Paket bietet? In den meisten Projekten lautet die Antwort Nein. Dann verschwindet mit der Abhängigkeit auch ihr ganzer Rattenschwanz aus Updates, indirekten Abhängigkeiten und Installationszeit. Ihr Projekt wird dadurch leichter, übersichtlicher und etwas weniger anfällig für Überraschungen.

Häufig gestellte Fragen (FAQ)

Kann ich alle zwölf Pakete sofort aus meinem Projekt entfernen?

Nicht blind. Prüfen Sie zuerst, welche Node-Version in Ihrer Produktionsumgebung läuft, denn einige der eingebauten neuen Bordmittel sind erst ab Node 24 stabil. Anschließend sollten Sie für jedes Paket klären, ob Sie auf eine seiner Zusatzfunktionen angewiesen sind, etwa auf Interceptors bei axios, Modul-Mocks bei Jest oder Variablenersetzung bei dotenv.

Prüft Node.js beim Ausführen von TypeScript-Dateien auch meine Typen?

Nein. Node entfernt die Typangaben lediglich und führt den verbleibenden JavaScript-Code aus. Fehler in den Typen fallen dabei nicht auf. Für die eigentliche Typprüfung benötigen Sie weiterhin den TypeScript-Compiler tsc, idealerweise als eigenen Schritt in Ihrer Build- oder CI-Pipeline.

Warum wirft fetch() bei einem 404-Fehler keinen Fehler?

Aus Sicht der Fetch-API ist eine Antwort mit Statuscode 404 oder 500 eine erfolgreich empfangene Antwort, denn der Server hat ja geantwortet. Ein Fehler tritt nur bei Netzwerkproblemen oder einem Abbruch auf. Deshalb sollten Sie nach jedem Aufruf die Eigenschaft res.ok prüfen und im Fehlerfall selbst reagieren.