scriptc: TypeScript in native ausführbare Dateien ohne JavaScript-Engine kompilieren

Projektkern und README-Grenzen · vercel labs scriptc

scriptc kompiliert TypeScript in native ausführbare Dateien ohne Node.js, V8 oder eine JavaScript-Engine in der Binärdatei. Die README zeigt eine Fibonacci-Funktion, die über `scriptc run fib.ts` läuft und eine eigenständige Binärdatei von etwa 178 KB mit etwa 2 ms Startzeit erzeugt. Die Installation erfolgt mit `npm install -g scriptc`; clang (vorinstalliert mit Xcode Command Line Tools) ist erforderlich. macOS arm64 ist die primäre Plattform, während Linux- und Windows-Binärdateien durch Cross-Kompilierung erstellt und durch separate Differenztest-Lanes verifiziert werden.

Im Abschnitt Projektkern und README-Grenzen lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Konkreter Einstieg im Repository · vercel labs scriptc

scriptc analysiert ein Programm Konstrukt für Konstrukt, um zu entscheiden, was zu nativem Code kompiliert werden kann. Der Befehl `coverage` meldet analysierte Anweisungen, wie viele statisch kompiliert werden, und Blocker mit Fehlercodes wie SC1090 und SC2020. Die README beschreibt drei explizite Ebenen: statisch kompilierten Code (nativ, ohne Engine), dynamisch ausgeführten Code über das `--dynamic`-Flag mit einer eingebetteten quickjs-ng-Engine (ca. 620 KB) und abgelehnten Code mit einem spezifischen Fehler und meist einem Umschreibhinweis. Nichts wird stillschweigend falsch kompiliert.

Im Abschnitt Konkreter Einstieg im Repository lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Architektur und Datenfluss · vercel labs scriptc

Die statische Ebene umfasst Sprach- und Standardbibliotheksfunktionen, die reale Programme nutzen: Klassen mit einfacher Vererbung und dynamischer Dispatch, Closures, Generika (monomorphisiert), diskriminierte Unions, async/await auf Stackful-Fasern, Ausnahmen, Destrukturierung, Spread, Getter/Setter, Iteratoren, Template-Literale und reguläre Ausdrücke. Die Standardbibliothek enthält UTF-16-exakte Zeichenketten, Arrays/Maps/Sets mit JS-exakter Reihenfolge, JSON mit Laufzeit-validierten Casts, Math, typisierte Arrays und Buffer sowie Error-Hierarchien. Die Node-API-Abdeckung umfasst fs, path, process, child_process, os, crypto, url, zlib, Timer und den Server-Stack (net, http, https, tls, dgram, dns, fs.watch, readline). `fetch` und die WHATWG-Web-Teilmenge funktionieren über denselben nativen net/TLS-Stack. Mit `--dynamic` werden npm-Abhängigkeiten mit Node-Algorithmus aufgelöst, gegen mitgelieferte .d.ts typgeprüft und ihr JS wird zur Build-Zeit in die Binärdatei eingebettet.

Im Abschnitt Architektur und Datenfluss lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Konfiguration, Laufzeit und Abhängigkeiten · vercel labs scriptc

Bei jeder Änderung laufen zwei Durchsetzungsmechanismen. Differenztests führen jedes Korpusprogramm (800+ Tests) unter Node und als native Binärdatei aus und verlangen, dass stdout, stderr und Exit-Codes byteweise übereinstimmen. Die Zahlenformatierung ist JS-exakt und wurde gegen Node auf einer Million Doubles fuzz-verifiziert. Server werden mit Live-Client-Treibern gegen beide Implementierungen getestet. Eine Speichersicherheits-Lane führt das Korpus unter AddressSanitizer mit einer Referenzzählungsprüfung erneut aus; Leaks und Use-after-free gelten als Build-Fehler. Die wenigen Dutzend bewussten Abweichungen von Node, hauptsächlich bei Timing-Interna und Fehlerobjekteigenschaften, sind dokumentiert und nummeriert.

Im Abschnitt Konfiguration, Laufzeit und Abhängigkeiten lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Betrieb, Sicherheit und Wartung · vercel labs scriptc

Gemessen auf Apple M-Series gegen Node, Go, Rust und Zig (byteidentische Ausgabe) zeigt scriptc eine Startzeit von etwa 2,4 ms (Node etwa 47 ms), eine Binärgröße von 170-200 KB statisch (oder etwa 3 MB mit --dynamic und eingebetteten Abhängigkeiten) und einen typischen RSS-Speicher von 1-4 MB (Node 67-116 MB). Die Laufzeitleistung wird als wettbewerbsfähig mit Systemsprachen bei den meisten Arbeitslasten beschrieben, mit Integer-Inferenz und Ownership-Analyse auf der Roadmap. Builds verwenden einen inhaltsadressierten Cache, der unveränderte ausführbare Dateien oder Bibliotheken nach leichten Toolchain-Proben wiederherstellt. Die Cache-Identitäten umfassen aufgelöste Systemheader-Bytes, Linker/Assembler-Identitäten und exakte implizite Linker-Eingaben. Zwischengespeicherte Artefakte werden per Prüfsumme verifiziert. `SCRIPTC_NO_CACHE=1` deaktiviert den Cache, `SCRIPTC_CACHE_DIR` wählt das Cache-Root.

Im Abschnitt Betrieb, Sicherheit und Wartung lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Lizenz und belegte Nutzung · vercel labs scriptc

scriptc bietet vier Ausweichmöglichkeiten. `comptime(() => ...)` führt TypeScript zur Build-Zeit in einer isolierten VM aus und bäckt das Ergebnis als Literal in die Binärdatei. Native FFI (`--ffi`) bindet Signatur-Only-TypeScript-Deklarationen an direkte C-ABI-Aufrufe und verlinkt manifest-deklarierte Archive, Objekte und Systembibliotheken. Das `--dynamic`-Flag bettet die Engine für npm-Abhängigkeiten und `any`-Code ein; `coverage --dynamic` meldet genau, welche Anweisungen wo ausgeführt werden. Geprüfte Casts lassen `JSON.parse(...) as Config` eine Laufzeitvalidierung einfügen, die einen abfangbaren Fehler mit Angabe des problematischen Pfads wirft.

Im Abschnitt Lizenz und belegte Nutzung lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Prüfung für den konkreten Anwendungsfall · vercel labs scriptc

Die Pipeline ist TypeScript → tsc-Parse/Typprüfung → Senkung in typisiertes IR → C-Code → clang → native ausführbare Datei. Das Compiler-Paket behandelt Frontend, IR und Backends; das Laufzeitpaket ist eine C-Laufzeit mit referenzgezählten Werten, Stackful-Fasern und Ereignisschleife; die CLI bietet `build`, `run` und `coverage`. Entwicklung nutzt pnpm: `pnpm install && pnpm build`, dann `pnpm test` für Differenzkorpus und Diagnose-Snapshots oder `SCRIPTC_SAN=1 pnpm test` für ASan + RC-Audit. Sandbox-Tests laufen auf Vercel Sandboxes, mit einem schnellen Pro+-Gate und einem Hobby-Gate mit geringerer Parallelität. Jede Funktion wird mit Differenztests ausgeliefert; beide Lanes grün ist die Merge-Bar. Das Projekt ist unter Apache-2.0 lizenziert; die Lizenz gewährt unbefristete, weltweite, nicht exklusive, kostenlose, lizenzgebührenfreie Urheberrechts- und Patentlizenzen, aber die README spezifiziert keine Gewährleistung oder Support-Bedingungen.

Im Abschnitt Prüfung für den konkreten Anwendungsfall lässt sich scriptc an konkreten Repository-Spuren prüfen: vercel-labs/scriptc, README.md, die dort genannten Befehle und die beschriebenen Konfigurationsdateien. Die Dokumentation ist die Grenze der Aussage. Nicht genannte Betriebssysteme, Leistungswerte und Garantien werden hier nicht ergänzt.

Ein sinnvoller Probelauf für scriptc beginnt mit dem im README genannten Einstieg und einer kleinen Eingabe. Dabei sollten Rückgabecode, erzeugte Dateien, Protokollausgaben und die verwendete Version gemeinsam notiert werden. Weicht das Ergebnis von der Beschreibung ab, gehört die genaue Kommandozeile samt Fehlermeldung in den Befund.

Redaktionelles Fazit

Geeignet ist scriptc für Leser, deren Anwendungsfall zu den im README beschriebenen Eingängen und Laufzeitbedingungen passt. Ungeeignet ist es, die Dokumentation als Zusage für nicht genannte Skalierung oder Kompatibilität zu lesen. Vor einer Entscheidung sollte der konkrete README-Einstieg mit einer kleinen Eingabe ausgeführt und das Ergebnis anhand der genannten Dateien und Ausgaben geprüft werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes