Node.js unterstützt die Ausführung von TypeScript-Dateien ohne zusätzliche Konfiguration

• Node.js wurde so verbessert, dass TypeScript-Dateien direkt ausgeführt werden können
• Ab sofort lassen sich .ts-Dateien auch ohne zusätzliche Konfiguration oder Transpilierung direkt ausführen
• Entwickler können ihre Arbeitseffizienz steigern, ohne tsconfig.json oder einen separaten Bundler installieren zu müssen
• Die Funktion ist ab Node.js v22.18.0 (LTS) offiziell enthalten
• Es wird erwartet, dass sich dadurch die Grenze zwischen JavaScript- und TypeScript-Entwicklung weiter auflöst

---

Direkte Ausführung von TypeScript in Node.js

• Node.js hat mit der aktuellen Version v22.18.0 (LTS) eine Funktion zur direkten Ausführung von TypeScript-Dateien (.ts) ohne zusätzliche Konfiguration oder Werkzeuge eingeführt
• Bisher waren für die Ausführung von TypeScript-Code externe Transpiler oder Bundler wie ts-node, esbuild oder Babel nötig; nun erkennt und startet Node.js TypeScript-Code direkt selbst, ohne diese Tools
• Mit dieser Funktion können Entwickler .ts-Dateien in Node.js unmittelbar ausführen, ohne eine tsconfig.json-Konfigurationsdatei oder zusätzliche Bibliotheken
• Bei Prototyping, experimenteller Entwicklung und der Ausführung von Skripten steigen Produktivität und Entwicklungsfreundlichkeit deutlich
• Es werden Effekte wie eine stärkere Verknüpfung zwischen JavaScript- und TypeScript-Projekten sowie niedrigere Einstiegshürden für neue Entwickler erwartet

Weitere bemerkenswerte Änderungen

• esm: Implementierung von import.meta.main
• fs: Verbesserte Verarbeitung von fs-Ereignissen auf Basis von AsyncIterator
• permission: Unterstützung für die Weitergabe von Berechtigungsmodell-Flags bei der Ausführung von Unterprozessen
• sqlite: Option readBigInts hinzugefügt
• src/permission: Unterstützung für permission.has(addon)
• url: API fileURLToPathBuffer hinzugefügt
• watch: Flag --watch-kill-signal hinzugefügt
• worker: Das Worker-Objekt wurde zu einem async disposable verbessert

Updates zu Commits und Dokumentation

• Enthält die Entfernung unnötigen Codes, Bereinigungen der Build-Umgebung und Toolchain sowie ein Upgrade auf npm 10.9.3
• In Dokumenten wie globals.md, child_process.md und http2 wurden detaillierte Stabilitätsindikatoren und RFC-Nummern korrigiert
• Zahlreiche Tests wurden ergänzt und Bugfixes übernommen

Distributionsdateien

• Installationsdateien und Binärdateien werden für Windows, macOS (Intel/Apple Silicon) und Linux (x64, ARM, PPC, s390x, AIX) bereitgestellt
• Quellcode und vollständige Release-Dateien können auf der offiziellen Distributionsseite von Node.js heruntergeladen werden
• Die API-Dokumentation wurde auf Basis von v22.18.0 aktualisiert

[aliveornot]

Endlich fühlt man sich wirklich erleichtert … Hoffentlich setzt sich das schnell durch.

[tested]

Für die Ausführung einfacher Skripte scheint es ganz brauchbar zu sein, aber für Live-Projekte gibt es viele Einschränkungen, sodass es wohl kaum zum Einsatz kommen wird.

Wegen der Fehler ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT muss man auch Erweiterungen und Pfade passend angeben,
und Funktionen wie in NestJS, die TypeScript-Build-Unterstützung mit der Einstellung emitDecoratorMetadata benötigen, kann man dann nicht nutzen, also ...

[kimjeongwonn]

Ist --experimental-strip-types dann standardmäßig aktiviert?

[click]

Da ich enum ohnehin nicht verwende, läuft es für mich schon allein mit dem reinen Entfernen der Typen völlig ausreichend gut.

[crawler]

Das wird ja unglaublich praktisch!

[honglu]

Ich kann mir ein Like einfach nicht verkneifen.

Ich fand schon das Flag --no-experimental-strip-types völlig ausreichend gut.

Umso besser scheint es jetzt zu sein.

[GN⁺]

Hacker-News-Kommentare

• Mit node:test in Node.js denke ich inzwischen, dass Node.js in den meisten Fällen eine überzeugende Default-Wahl ist. Die Ausführung mit tsx war bereits ein großer Gewinn für die Lebensqualität, aber noch nicht vollständig. Mit Tools wie zod, ts-rest und trpc werden Runtime-Type-Assertions an den Rändern inzwischen weitgehend gelöst, und Full-Stack-Typescript-Entwicklung ist heute wirklich einfach geworden
  • Absolut. Im Jahr 2025 ist das Node-Ökosystem endlich mit den Standardeinstellungen brauchbar. ESM-Module funktionieren sowohl in Node als auch in Typescript einfach so, Node kann .ts-Dateien direkt ausführen und bringt einen ordentlich brauchbaren eingebauten Test-Runner mit (--watch wird unterstützt). Auch die eingebauten Pakete werden besser. Bei node:fs/promises zum Beispiel sind asynchrone Loop-Aufgaben dank Top-Level-Await deutlich einfacher geworden. Es hat lange gedauert, bis alle zu einem realistischen Ansatz bewegt werden konnten, aber jetzt ist die Situation wirklich angenehm
  • Ich bin sehr dafür, dass Node Typescript direkt unterstützt. Vitest macht heute vieles bequem, aber ich habe trotzdem enorm viel Zeit mit der Einrichtung einer Testumgebung für .ts-Dateien verbracht. Trpc und ts-rest sind meiner Meinung nach ein ganz anderes Thema. Man kann beides nutzen, aber in Produktion vermeide ich trpc, weil ich dort die API-URL nicht wirklich selbst kontrollieren und alte URLs nicht sauber verwalten und auslaufen lassen kann. Auch bei ts-rest bevorzuge ich meist, API-Request/Response-Paare direkt selbst zu verwalten, indem ich einfach zod und Typen teile. Und jedes Mal stört es mich, wenn ein klar erkennbares RPC-Tool -rest im Namen trägt
  • Ich werde mal beobachten, ob Sveltr in Zukunft seine Codebasis wieder auf Typescript umstellt
  • Ich frage mich, ob damit tsx ausgeführt wird. Selbst wenn die Typen entfernt werden, muss JSX ja noch in JavaScript umgewandelt werden, und genau dieser Teil interessiert mich
  • Ich bin vor kurzem auf Python umgestiegen. Dort ist alles eingebaut, und ich bin viel zufriedener, weil ich nicht die seltsamen Probleme eines unfertigen Systems debuggen muss
• Ich bin sehr beeindruckt von den Fortschritten, die Node in den letzten Jahren gemacht hat. Es war gut, dass deno und bun Node unter Druck gesetzt und zu fokussierten, sinnvollen Verbesserungen bewegt haben. Eine Zeit lang herrschte Stillstand
  • Mich würde interessieren, welche Verbesserungen es bei Node zuletzt gab. Die letzte Änderung, die ich als wirklich bedeutend empfand, war die offizielle Unterstützung von Import/Export. Ich weiß nicht einmal, ob man den .mjs-Hack noch braucht. Ich war eine Weile aus dem Ökosystem raus und würde gern wissen, was sich seitdem getan hat
  • Ich bezweifle, dass das wirklich so war. In den Projekten, an denen ich beteiligt war, hätten wir deno oder bun überhaupt nicht gebraucht. Praktisch relevant sind nur die Node-LTS-Releases, und selbst neue Projekte nutzen weiterhin Node 20
• Ich finde es schade, dass Typescript in node_modules nicht akzeptiert wird (siehe: offizielle node.js-Dokumentation). Dann frage ich mich, was mit Projektabhängigkeiten ist. Ich habe eine Bibliothek für Datenmodelle in Typescript geschrieben und möchte sie in meiner App gern im Typescript-Zustand importieren. Ich frage mich, ob diese Regel nur für npm-Pakete gilt oder für alle Abhängigkeiten. Hier steckt eine Chance drin. Ich habe eine auf Golang basierende Runtime für die Ausführung von typescript (genauer: von JS allgemein) gebaut, und auch sobek, das vom Grafana-Team verwendet wird, bräuchte wohl nur Type-Stripping-Unterstützung. Wenn nur eine Runtime käme, die vollständig auf Typescript als Standard setzt, würde das Node.js meiner Meinung nach wirklich revolutionieren. Kein Transpiler, kein typescript-go, kein rust nötig (obwohl rust trotzdem ein bisschen 😉), sondern einfach ein gutes Parsersystem, das Source Maps und Typen im Debug-Modus nachverfolgt. Wie auch immer: Anerkennung und Dank an das Node-Team und alle Mitwirkenden. Weil Node der Standard ist, fühlt es sich an, als würden wir alle ihm folgen. Auch die Embedding-API ist schlicht und sauber nutzbar, was praktisch ist, wenn man Standalone-Binaries baut
  • Ich habe denselben Kommentar schon einmal hinterlassen (Referenz). Dort heißt es: „damit nicht dazu ermutigt wird, in Typescript geschriebene Pakete auf npm zu veröffentlichen“, und ich habe es auch mit privaten Paketen versucht, aber es funktionierte nicht, und Node interessiert sich überhaupt nicht für das Feld private
  • Ich denke, Pakete sollten vor der Veröffentlichung auf npm unbedingt nach JavaScript kompiliert und so verteilt werden. Ich sehe keinen Grund, rohes TypeScript auf npm hochzuladen
• Zugehöriges Issue Ich finde es schade, dass es kein Type-Stripping in node_modules gibt
  • Genau deshalb hatte ich die Funktion zur Hälfte überhaupt erwartet. Ich wollte Bibliotheken in TypeScript schreiben, die Typprüfung nur in CI/CD ausführen und sie dann direkt in Node.js importieren können
  • Ich halte das für die richtige Entscheidung. Typescript hat ziemlich häufig Breaking Changes. Solange es nicht standardisiert ist, halte ich den aktuellen Ansatz für besser
• Ich nutze JS/TS nicht besonders viel, aber ich frage mich, ob es nicht besser wäre, einfach Bun zu verwenden. Nicht jedes Projekt fängt neu an, aber insgesamt fühlte sich Bun für mich wie die bessere Runtime an. TS-Ausführung funktioniert von Anfang an, die Abhängigkeitsauflösung ist deutlich schneller und die Nutzbarkeit ist hervorragend. Ich persönlich habe viele ältere Node-Projekte auf Bun umgestellt und nutze Node seit der Veröffentlichung von Bun fast gar nicht mehr. Falls ich etwas falsch verstehe, sagt es mir bitte
  • Ich habe fast acht Jahre lang nur Node benutzt und bin kürzlich auf Deno umgestiegen. Dieser Wechsel war auch nicht leicht, und nicht weil es tatsächlich nicht funktionierte, sondern weil ich Angst hatte, nie zu wissen, wann etwas plötzlich nicht mehr läuft. Node hat definitiv viele Schwächen, ist aber trotzdem der De-facto-Industriestandard. Das JS-Ökosystem selbst ist chaotisch, und viele Entwickler sind müde von immer neuen Build-Tools, Bundlern und Runtimes. Ich glaube nicht, dass Bun schon genug Stabilität oder Support angesammelt hat, um wirklich überzeugend zu sein. Ich hatte auch schon Fälle, in denen mich schon ein einziges Minor-Update von TS tagelang Probleme lösen ließ
  • Ich jage den neuesten Trends nicht besonders gern hinterher. NodeJS ist die am besten unterstützte Runtime im JS-Ökosystem. Ich halte es für deutlich besser, der Standardwahl zu folgen. Ich entscheide mich eher für sogenannte „langweilige“ Technologien
  • Seit der Veröffentlichung von Bun habe ich mehrfach versucht, komplett umzusteigen, bin aber jedes Mal bei etwa 90 % auf unvermeidbare Probleme gestoßen. Beim letzten Versuch funktionierten einige Bibliotheken nicht, weil bestimmte napi-Funktionen nicht implementiert waren, und es gab Probleme wie ignorierte recursive-Optionen bei opendir. Das sind nur die Issues, an die ich mich spontan erinnere. Ich warte darauf, dass Bun aufholt, aber für große Projekte scheint es für den produktiven Einsatz noch nicht bereit zu sein. Auch Bun-spezifische Features sehen auf den ersten Blick gut aus, wirken in der Praxis aber unausgereift. Die Dokumentation ist ebenfalls nicht so hochwertig wie die von Node.js
  • Das sind Kompatibilitätsprobleme, die ich beim Versuch erlebt habe, Node durch Bun zu ersetzen.
• localAddress wird bei TCP-Verbindungen ignoriert
• Inkompatibilität mit der Node-Modul-API (Beispiel: Projekt spamscanner funktioniert nicht)
• Race-Probleme rund um EventEmitter (teilweise gelöst mit eventemitter2)
• Der Dev-Server von Svelte vites blieb gelegentlich hängen, sodass ich node_modules löschen und neu installieren musste

  • Ich habe die TS- und Test-Runner-Funktionen von Node selbst ausprobiert, aber sie sind noch nicht so gut wie bei Bun. Für solche Features nutze ich vorerst weiter Bun. Im Node-Ökosystem habe ich gelernt, dass es besser ist, nicht alles auf ein einziges Tool zu setzen, sondern passende spezialisierte Werkzeuge zu kombinieren.

    • Bun.js: für die Node-Runtime sowie für TS-Ausführung und Tests. Ich habe Verschiedenes ausprobiert, darunter TSX, TS-Node und Node selbst

    • NPM: zum Ausführen von Tooling-Skripten

    • PNPM: für die Installation von Abhängigkeiten. (Meiner Meinung nach das Beste im Vergleich zu npm, yarn und bun)

    • Biome.js: fürs Linting. Besser als jedes andere Linting-Tool, das ich bisher verwendet habe

• Es ist wirklich gut, dass diese Verbesserung nur aus „Type Stripping“ besteht, weil dadurch keine Source Maps nötig sind und es in Produktion vollständig ohne Zusatzkosten bleibt. Das Node-Team hat das wirklich gut gemacht
• Auch die Type-Strip-Funktion (import { stripTypeScriptTypes } from 'node:module') ist freigelegt. Wenn man eine einfache Web-App ohne Frontend-Abhängigkeiten entwickelt, kann man alles in Typescript schreiben und beim Ausliefern der Frontend-Skripte einfach nur die Typen entfernen (Beispielprojekt)
• Durch diese Änderung konnte unser Unternehmen endlich auf Typescript umsteigen. Wir haben mehrere Services gleichzeitig auf TS umgestellt, und einige sind noch in Arbeit. Ein großer Gewinn
• So wie ich es verstehe, funktioniert das, indem Typinformationen entfernt werden. Das heißt, es spart einen Transpile-Schritt ein, verbessert aber die Sicherheit nicht
  • Eines der wichtigsten Designziele von Typescript ist, dass das Ergebnis eine gültige JavaScript-Datei ist, wenn man nur die typspezifische Syntax entfernt. Der TS-Compiler erzeugt keinen Code (anders als etwa PureScript). Die statische Prüfung erfolgt über Typechecker wie tsc, und die Typinformationen werden entfernt. Auch Python ignoriert Typannotationen zur Laufzeit, und selbst bei Java werden manche Typinformationen wie Generics im Bytecode gelöscht
  • Die Aussage „es spart höchstens einen Transpile-Schritt, verbessert aber die Sicherheit nicht“ ist etwas missverständlich. Dass Node TS direkt ausführen kann, erhöht die Sicherheit der Typprüfung selbst nicht, aber Typechecking kann ohnehin separat im Editor oder mit anderen Tools erfolgen. Dass Node die direkte Ausführung von TS unterstützt, senkt die Einstiegshürde für TS massiv und hilft damit indirekt der Type Safety
  • Typescript hat nie versprochen, Sicherheitsverbesserungen zu garantieren. Das ist ein verbreitetes Missverständnis. TS hatte gewissermaßen keinen Runtime-Modus oder keine Runtime-Informationen, und wenn man keinen Typechecker laufen lässt, kann es trotz gravierender Typfehler einfach ausgeführt werden. Genau genommen ist Typescript eher näher an einem Linter
  • Ich finde es extrem praktisch, Skripte direkt ohne Build/Transpile ausführen zu können. Wenn ich Typechecking brauche, lasse ich einfach tsc laufen; das funktioniert für mich gut
  • Ich nutze in Projekten ein Setup mit tsx, das genauso ohne Build/Transpile läuft. In der Entwicklung ist das sehr nützlich. Dank tsx --watch kann ich den Server direkt aus TS-Quellen starten, und bei Änderungen wird er automatisch neu gestartet. Künftig sollte sich mit nodemon und den eingebauten Funktionen von Node eine ähnliche Umgebung bauen lassen. Wenn man Typechecking auch noch zur Laufzeit haben wollte, müsste das auf V8-Ebene unterstützt werden, und das wäre fast ein kompletter Neuaufbau
• Tatsächlich wird nicht ganz Typescript ausgeführt, sondern nur eine Teilmenge. Der Titel könnte also übertrieben wirken. Es besteht die Gefahr, dass solche Änderungen dazu führen, TS nur noch wie einen Linter zu benutzen, und dass verschiedene mächtige TS-Funktionen, die sich nicht allein durch Type-Stripping umsetzen lassen, an Bedeutung verlieren
  • Mich würde interessieren, welche Funktionen in TS sich denn nicht strippen lassen. Außer enum: Welche tatsächlich genutzten Fälle gibt es da?