swc-node: TypeScript ohne Typprüfung, aber mit Tempo
Schnellerer TS-Knoten ohne Typprüfung. Detail: @swc-node/core Benchmark transformiert RxJS AjaxObservable.ts in ES2015 & CommonJS JavaScript.
Auf einen Blick
- Was ist das?
- swc-node ersetzt ts-node und ts-jest durch einen schlanken, auf SWC basierenden Transformer. Das Projekt verzichtet bewusst auf Typprüfung und gewinnt dadurch Geschwindigkeit, was für viele Workflows die richtige Abwägung ist.
- Für wen ist es gedacht?
- Wer TypeScript nur ausführen oder in Jest testen will und die Typprüfung bereits in einem separaten Schritt erledigt, sollte swc-node ernsthaft in Betracht ziehen. Wer Typprüfung als Teil des Ausführungs- oder Testprozesses benötigt, ist mit ts-node oder ts-jest besser bedient.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 3 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: ts-node ist langsam, Typprüfung kostet Zeit
Wer TypeScript mit Node ausführt, kennt den Standardweg: ts-node kompiliert und prüft Typen bei jedem Start. Das ist korrekt, aber langsam. In Projekten mit vielen Dateien wartet man bei jedem Testlauf oder Skriptstart. swc-node adressiert genau diese Wartezeit. Es verzichtet vollständig auf Typprüfung und setzt stattdessen auf SWC, einen in Rust geschriebenen Compiler. Das Projekt richtet sich an Entwickler, die TypeScript nur transpilieren wollen, nicht prüfen. Die Zielgruppe sind Teams, die Typprüfung bereits in CI oder im Editor erledigen und lokal nur schnelle Ausführung brauchen. Der README nennt explizit das Ziel: ein schnellerer ts-node/register/transpile-only-Ersatz zu sein.
Wie es arbeitet: SWC statt TypeScript-Compiler
Der Kern ist @swc-node/core, ein Transformationsmodul, das TypeScript in JavaScript umwandelt. Es nutzt die SWC-Bibliothek, die in Rust geschrieben ist und daher keine node-gyp-Installation oder Postinstall-Skripte benötigt. Das ist ein praktischer Vorteil gegenüber Projekten, die native Module kompilieren müssen. Die Transformation erfolgt synchron oder parallel. Der README zeigt Benchmarks, in denen die parallele Variante mit UV_THREADPOOL_SIZE=11 1.253 Operationen pro Sekunde erreicht, während esbuild auf 914 kommt. Die synchrone Variante liegt bei 438 Operationen, esbuild bei 510. Diese Zahlen stammen aus dem Projekt-README und sind auf einem MacBook Pro mit Intel Core i7 gemessen. Sie zeigen: swc-node ist bei paralleler Auslastung schnell, aber nicht immer die absolute Spitze.
Installation und erste Schritte: drei Befehle
Die Installation läuft über npm. Man installiert @swc-node/register als Dev-Dependency: npm i -D @swc-node/register. Danach startet man TypeScript-Dateien direkt mit node -r @swc-node/register script.ts. Für ESM-Projekte gibt es je nach Node-Version unterschiedliche Wege. Ab Node 22.15 nutzt man node --import @swc-node/register/esm-register-next --enable-source-maps script.ts. Für Node 20.6 bis 22.14 gilt esm-register, für ältere Versionen bis 20.5 der veraltete --loader-Aufruf. Wer eine .swcrc-Datei laden möchte, setzt die Umgebungsvariable SWCRC=true. Wer das tsconfig.json ignorieren will, verwendet TS_NODE_PROJECT=null. Diese Konfigurationsmöglichkeiten sind konkret und im README dokumentiert.
Die Benchmark-Realität: schnell, aber nicht immer am schnellsten
Der README enthält Benchmarks, die man ernst nehmen sollte, aber nicht überbewerten darf. Bei der synchronen Transformation ist esbuild mit 510 Operationen pro Sekunde schneller als @swc-node/core mit 438. TypeScript selbst schafft nur 28,83, Babel 24,21. Das zeigt: Beide Tools sind deutlich schneller als die klassischen Compiler. Bei paralleler Ausführung dreht sich das Bild. Mit UV_THREADPOOL_SIZE=11 erreicht @swc-node/core 1.253 Operationen, esbuild 914. Auch ohne die Threadpool-Anpassung bleibt swc-node mit 1.123 vor esbuild mit 847. Die Hardware ist ein MacBook Pro von 2018, also nicht mehr aktuell. Wer andere Hardware nutzt, wird andere Zahlen sehen. Die Kernaussage bleibt: swc-node ist bei parallelen Workloads stark, bei synchronen leicht unterlegen.
Ein klarer Trade-off: keine Typprüfung, keine Sicherheit
Der größte Nachteil ist offensichtlich: swc-node prüft keine Typen. Fehler, die der TypeScript-Compiler finden würde, bleiben unentdeckt. Das ist in Ordnung, wenn man Typprüfung separat ausführt, etwa mit tsc --noEmit in CI. Wer sich darauf verlässt, dass die Ausführungsumgebung Typfehler meldet, wird enttäuscht. Ein weiteres Problem ist die Abhängigkeit von SWC. TypeScript entwickelt sich weiter, und SWC muss jede neue Syntax unterstützen. Bei sehr neuen oder exotischen TypeScript-Features kann es zu Inkompatibilitäten kommen. Das Projekt ist nicht archiviert, aber die letzten Releases zeigen eine Lücke: @swc-node/register wurde zuletzt im Juli 2024 veröffentlicht, @swc-node/core im Juli 2026. Das deutet auf eine ungleiche Pflege der Pakete hin.
Alternativen: esbuild und ts-node im Vergleich
Die naheliegendste Alternative ist esbuild. Es ist ebenfalls ein schneller Transformer ohne Typprüfung und wird im README als Benchmark-Gegner geführt. Der Unterschied liegt in der API und im Fokus. esbuild ist ein General-Purpose-Bundler und -Transformer, swc-node ist speziell für Node-Ausführung und Jest konzipiert. Wer nur Skripte ausführen will, kann beides nutzen. ts-node bleibt die Alternative mit Typprüfung. Es ist langsamer, aber bietet die Sicherheit, die manche Projekte brauchen. ts-jest ist die Jest-Integration mit Typprüfung, während @swc-node/jest im README eine Testsuite in 14,34 Sekunden abschließt, ts-jest in 62,71 Sekunden. Diese Zahlen stammen aus dem README und zeigen den Geschwindigkeitsvorteil, aber auch den Verzicht auf Typprüfung in den Tests.
Wartung, Lizenz und was man vorher prüfen sollte
Die Lizenz ist MIT, was für kommerzielle Projekte unproblematisch ist. Die Wartung ist aktiv, aber ungleichmäßig. Der letzte Push war im Juli 2026, das Kernpaket @swc-node/core hat eine frische Version. Das Register-Paket ist älter, was bei ESM-Support zu Verzögerungen führen kann. Vor der Adoption sollte man die eigene Codebasis testen: Lässt sich ein Skript mit SWC transformieren, ohne dass Fehler auftreten? Man sollte auch die Node-Version prüfen, denn die ESM-Register unterscheiden sich je nach Version. Wer auf Node 20.5 oder älter arbeitet, nutzt einen veralteten Loader. Das ist ein Wartungsrisiko. Die Dokumentation ist knapp, aber die README-Beispiele sind ausreichend für den Einstieg. Für tiefere Konfiguration muss man in die Paket-Dokumentation schauen, die im README verlinkt ist.
Redaktionelles Fazit
Wer TypeScript nur ausführen oder in Jest testen will und die Typprüfung bereits in einem separaten Schritt erledigt, sollte swc-node ernsthaft in Betracht ziehen. Wer Typprüfung als Teil des Ausführungs- oder Testprozesses benötigt, ist mit ts-node oder ts-jest besser bedient. Vor der Übernahme sollte man prüfen, ob die eigene Codebasis mit SWC kompatibel ist, insbesondere bei exotischen TypeScript-Features oder Decorator-Konfigurationen. Ein Blick in die Dokumentation zu .swcrc und die ESM-Register ist Pflicht, denn die Unterschiede zwischen den Node-Versionen sind real.
Community-Notizen