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.

Ähnlich verhält es sich 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. Die folgenden zwölf Bordmittel zeigen jeweils, welches Paket sie ersetzen, wie ein einfaches Beispiel aussieht, wie stabil sie in den aktuellen LTS-Versionen sind und an welcher Stelle das alte Paket immer noch mehr kann.

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

LTS steht für Long Term Support: Diese Versionen erhalten über Jahre Sicherheitsupdates und sind für den Produktivbetrieb gedacht. Stand November 2026 sieht der Release-Plan des Node.js-Projekts so aus:

• Node 26 ist seit dem 28. Oktober 2026 die Active-LTS-Linie, also die Version, die neue Projekte wählen sollten. Sie wird bis April 2029 gepflegt.
• Node 24 ist seit dem 20. Oktober 2026 im Wartungsmodus (Maintenance LTS) und erhält bis zum 30. April 2028 Sicherheitsupdates.
• Node 22 befindet sich noch bis zum 30. April 2027 im Wartungsmodus.
• Node 20 hat am 30. April 2026 sein Lebensende erreicht.

Die Stabilitätsangaben unten gelten für Node 24 und Node 26. Eine Funktion, die in Node 24 stabil ist, ist es in Node 26 ebenfalls. Wo Node 22 zurückliegt, steht das ausdrücklich dabei. Node 27 läuft seit Ende Oktober 2026 als Vorabversion. Mit ihr ändert das Projekt seinen Rhythmus: Künftig erscheint eine Hauptversion pro Jahr, und jede wird zur LTS-Version. Bis Node 26 galt die Regel, dass nur gerade Versionsnummern LTS werden.

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.
• Stufe 0 (abgekündigt) und Stufe 3 (Legacy) markieren Schnittstellen, die verschwinden sollen oder nicht mehr weiterentwickelt werden.

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. Die Stufe steht in der offiziellen Dokumentation unter nodejs.org/api direkt am Anfang jedes Moduls und oft auch an einzelnen Funktionen.

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. Seit Node 26.11.0 heißt die Klasse Database; DatabaseSync bleibt als abgekündigter Alias erhalten und ist der Name, der auch unter Node 24 funktioniert.

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 26 gilt dieselbe Stufe. Stabil ist node:sqlite damit in keiner LTS-Version, aber kurz davor. In Node 22 steht es noch auf 1.1. Das Flag --experimental-sqlite ist dort zwar seit 22.13 verschwunden, die Einstufung aber nicht.

Ein Nebeneffekt betrifft die Installation: Bis Version 12 lud better-sqlite3 seine Binärdatei über ein Installationsskript. Solche Skripte blockiert npm ab Version 12 standardmäßig, sodass das Paket erst freigegeben werden muss. Seit Version 13.0.2 liegen die vorkompilierten Binärdateien für gängige Plattformen direkt im Paket, ein Installationsskript entfällt. Das eingebaute Modul braucht nichts dergleichen.

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 auch in Node 26 noch 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 oder die Umgebungsvariable NODE_USE_ENV_PROXY=1 setzen; das Flag kam in 24.5.0 hinzu und ist in Node 24 und 26 noch experimentell. Für Firmennetze mit Pflicht-Proxy ist das ein wichtiges Detail. 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, seit 24.0.0 und 22.17.0 ist sie stabil:

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 (und 22.17.0) und damit auch in Node 26. 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 mitbringt; seine Kommandozeile steckt seit Version 13 im separaten Paket glob-bin. 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“. randomUUID() erzeugt zufällige UUIDs der Version 4. UUIDs der Version 7, deren IDs zeitlich sortiert sind und sich daher gut als Primärschlüssel in Datenbanken eignen, liefert seit 24.16.0 und 26.1.0 randomUUIDv7() aus node:crypto; das globale crypto-Objekt kennt diese Funktion nicht. Das Paket uuid bietet zusätzlich 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. Die Option recursive des alten fs.rmdir() war lange veraltet und wurde in Node 25 entfernt, in Node 26 gibt es sie nicht mehr. 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 (und 25.2.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.0.0 hat dieses Flag entfernt. Wer auf Node 26 wechselt, muss solche Stellen also umschreiben oder weiter übersetzen. 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 Bordmittel 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.
• Ein Kommandozeilenwerkzeug mit Unterbefehlen und Hilfetexten bleibt bei commander.

Angenommen, ein kleines Team pflegt ein internes Werkzeug, das nachts Daten aus einer API abruft, in eine SQLite-Datei schreibt und eine farbige Zusammenfassung ins Terminal gibt. Früher standen dafür axios, better-sqlite3, dotenv, chalk und nodemon in der package.json. Unter Node 26 kommt dieses Werkzeug mit fetch(), node:sqlite, --env-file, styleText() und --watch aus, also ganz ohne Laufzeitabhängigkeiten. Bei einer größeren Webanwendung mit Authentifizierung, Datenbankschicht und Framework schrumpft die Liste dagegen nur um ein paar Einträge.

Prüfen Sie Ihr Deployment-Ziel

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

{
  "engines": {
    "node": ">=24"
  }
}

npm warnt bei einer abweichenden Version standardmäßig nur. Soll die Installation abbrechen, setzen Sie in der .npmrc des Projekts engine-strict=true.

Ein Blick nach vorn: Temporal in Node 26

Node 26 bringt die neue Datums-API Temporal mit, die als Teil des JavaScript-Standards das fehleranfällige Date-Objekt ablösen soll. Sie kennt Zeitzonen, Kalenderdaten ohne Uhrzeit und Zeitspannen. Für viele Aufgaben, für die Projekte bisher Moment.js, Luxon oder date-fns installiert haben, ist damit ein dreizehnter Kandidat in Sicht. Solange Ihre Anwendung auch unter Node 24 laufen muss, bleibt die Bibliothek aber vorerst im Projekt.

Weniger Pakete, weniger Angriffsfläche

Jede Abhängigkeit ist Code von Dritten, der mit den Rechten Ihrer Anwendung läuft, und sie bringt meist weitere Abhängigkeiten mit. Fällt eine weg, verschwindet auch ein Teil der Lieferkette, über die Angreifer Schadcode einschleusen können. Wie solche Angriffe ablaufen, erklärt der Beitrag npm install unter der Lupe. Für die Pakete, die bleiben, lohnt sich eine kurze Prüfung vor dem Einsatz, wie sie npm-Pakete sicher prüfen beschreibt. Ein eingebautes Modul ist dagegen Teil der Node.js-Version, die Sie ohnehin aktuell halten müssen.

Wann sich das Aufräumen lohnt

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: Wird die zusätzliche Funktion, die nur das Paket bietet, wirklich gebraucht? 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.

Unsere Empfehlung: Räumen Sie nicht in einer großen Aktion auf, sondern bei Gelegenheit. Der Wechsel auf Node 26 ist ein guter Anlass, denn dann steht ohnehin ein Testlauf an. Am meisten bringt das bei kleinen Werkzeugen, Skripten und Microservices. Überschätzt wird der Effekt bei großen Anwendungen, deren Abhängigkeiten überwiegend aus Frameworks bestehen. Wer ein Node.js-Backend mit TypeScript neu aufsetzen oder bestehende Projekte modernisieren will, findet Beratung und Seminare auf unserer Themenseite TypeScript und Node.js.

Häufige Fragen zu Node.js-Bordmitteln

Lassen sich alle zwölf Pakete sofort aus einem 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 die 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.

Sollte ein Projekt auf Node 24 bleiben oder auf Node 26 wechseln?

Node 24 erhält noch bis April 2028 Sicherheitsupdates, ein Wechsel ist also nicht eilig. Neue Projekte starten aber sinnvollerweise auf Node 26, weil sie dann länger ohne Versionssprung auskommen. Bestehende Projekte sollten vor dem Wechsel prüfen, ob sie --experimental-transform-types oder andere entfernte Flags nutzen.