Im Stream of Consciousness entwickelter JavaScript-Bundler (Zig Native TypeScript Transpiler & Compiler)

Wie sollte man im Zeitalter der AI lernen?
Ich hatte kein klares Gefühl dafür, welche Fachlichkeit gefragt ist und welche Fähigkeiten in der heutigen Zeit wirklich wertvoll sind.
Ich denke, dass es den Unternehmen, die Entwickler einstellen, genauso geht wie den Entwicklern selbst – auch sie kennen keine klaren Maßstäbe.

Trotzdem hatte ich das Gefühl, dass man auf jeden Fall verliert, wenn man einfach stillsteht.
Also dachte ich mir: Lass uns erst einmal irgendetwas bauen.
Zum Lernen habe ich anfangs einfach damit begonnen, einfache Chrome Remote DevTools zu bauen.

Während ich daran arbeitete, dachte ich: Lass uns auch React Native so unterstützen, dass es als Remote-Debugger funktioniert.

-> Ich kenne Metro nicht, also ist das alles ziemlich verwirrend.
-> Lass uns Metro nachbauen und dabei lernen.
-> Kann man für React Native nicht einen besseren Bundler als Metro bauen?
-> Mit Rolldown, swc und bun habe ich vieles ausprobiert und versucht, einen besseren Bundler als Metro zu bauen.

Am ehesten schienen bun und Rolldown Potenzial zu haben, aber ich stieß an Grenzen, wenn es darum ging, den Main-Teil umfassend anzupassen oder einen Fork zu pflegen.

Und zugleich gibt es keinen Web-Bundler, der vollständig mit Metro kompatibel ist: die von Flow und der Hermes-Engine erlaubte JavaScript-Syntax, außerdem wichtige Aufrufreihenfolgen, die sich anders verhalten als im normalen Web, und so weiter.

Ah … es ist ohnehin zum Lernen, also lass uns einfach auch den Bundler selbst bauen und React Native Metro ersetzen.

Was ich beim Bauen des Bundlers dachte:

Dann kann er doch einfach auch Web unterstützen, oder nicht?

Packen wir auch ES5 hinein, das ich bei Rolldown aufgegeben habe.
Da React Native laufen muss, unterstützen wir auch einen Flow-Parser.
WASM soll ebenfalls unterstützt werden.
Und bei der Geschwindigkeit wollen wir bun und Rolldown schlagen.

Eine eigene HMR bauen wir auch ein.

Beim Tree-Shaking gehen wir etwas aggressiver vor.
Auch beim Minify wollen wir anderen Bundlern voraus sein.

Ich habe mit dem Gedanken entwickelt, in Benchmarks und bei allen zunächst erkannten Funktionen die existierenden Bundler zu übertreffen.

Natürlich glaube ich, dass ich an vielen Stellen trotzdem verliere.

Im Vergleich zu anderen Bundlern gibt es selbstverständlich noch viele unfertige Bereiche – etwa Stabilität, Funktionsumfang oder die unterstützte Ökosystem-Community. Auch das oben erwähnte Tree-Shaking und Minify ist je nach Modul teils besser, teils schlechter.

Trotzdem haben die bisherigen Ausführungstests gezeigt, dass es in einigen Bereichen bereits besser ist. Es bleibt noch viel zu tun (SSL, MCP, CLI, Stabilisierung, API-Dokumentation usw.), aber das ursprüngliche Ziel – React-Native-Apps zu bauen und auszuführen – funktioniert bereits: Ich habe bei drei produktiven Apps Release-Builds, Development-Builds und den Dev-Server geprüft, und alles lief ohne Probleme. Deshalb dachte ich, dass ich es an diesem Punkt veröffentlichen und parallel weiterentwickeln kann, und habe diesen Beitrag geschrieben.

Immerhin laufen Entwicklung und Bundling bereits recht gut (zntc wird auch mit zntc selbst gebaut und ausgeliefert),
und auch essenzielle Funktionen wie Decorators sowie in React Native quasi unverzichtbare Features wie worklet, TypeScript und Flow funktionieren in den getesteten Bibliotheken ohne Probleme.
Außerdem gibt es Plugins für vite und rspack, Entwicklungsumgebungen wie bei vite und rspack werden ebenfalls bereitgestellt (RN, Web), es gibt Dokumentation, React HMR, Unterstützung für Module Federation und so weiter.
Darum denke ich, dass die grundlegenden Funktionen eines Bundlers und Transpilers inzwischen vorhanden sind, und möchte es veröffentlichen, Feedback einsammeln und dann weiterentwickeln.

Von Hand geschriebener Code ist 0 – alles wurde in intensiven Diskussionen mit AI entwickelt.
Ich glaube, ich habe AI mehr beansprucht als bei jeder anderen Produktentwicklung.
Zuerst habe ich nur Claude verwendet, später dann auch Codex.

Die reine Entwicklungszeit für den Bundler selbst betrug etwa 3 Monate (rund 3000 PRs); rechnet man den oben beschriebenen Gedankenstrom mit ein, waren es insgesamt etwa 6 Monate ununterbrochener Arbeit bei Tag und Nacht.

Ich habe ohne Pause an Werktagen wie an freien Tagen gearbeitet, und wegen einer Art Minderwertigkeitsgefühl? oder Bewusstseins gegenüber dem Vergleich mit anderen Bundlern
habe ich auch extrem viele Testfälle geschrieben – fast schon übertrieben –, um verschiedenste Tests wie test262 zu 100 % zu bestehen.

https://ohah.github.io/zntc/

Ich freue mich über viel Feedback (__)

[caniel]

Als Metro-Alternative gibt es auch Re.Pack, das RSPack oder WebPack verwendet.

[ohah173]

Ich habe beim etwas ungeordneten Schreiben vergessen, das zu erwähnen.
Wie Sie gesagt haben, habe ich mich auch stark an Re.pack orientiert.

Soweit ich weiß, basieren sowohl Re.pack als auch Rspack auf swc und unterstützen Flow daher nicht nativ. Bei Re.pack ist meines Wissens seit Version 5 außerdem Rspack die Basis. Entsprechend nutzt auch Re.pack swc + babel, sodass beliebte Plugins wie Flow, Reanimated und NativeWind (zntc-Support ist geplant) meines Wissens weiterhin mit Babel transpiliert werden.

Ich persönlich wollte mich von Babel lösen, deshalb habe ich zntc so gebaut, dass das standardmäßig unterstützt wird.

zntc unterstützt zwar auch Babel-Kompatibilität, aber ich wollte die babel-Abhängigkeit möglichst auf null reduzieren.

Die Stabilität ist zwar hervorragend und es handelt sich um bewährten Code, aber wegen der Grenzen von JavaScript bleibt die Geschwindigkeit immer ein Flaschenhals.

Tatsächlich habe ich während der Entwicklung ständig Benchmarks mit anderen Bundlern verglichen, und so deutlich ich den Unterschied selbst gespürt habe, ist es natürlich auch so, dass es im Vergleich zu anderen Bundlern bei Funktionen, Stabilität und Erweiterbarkeit noch Defizite gibt. Diesen Teil möchte ich weiter kontinuierlich verbessern.
Ich denke allerdings, dass wir bei strukturellen Flaschenhals-Bereichen, die in Re.pack unvermeidlich auftreten, vorne liegen, weil Dinge wie Parser-Kompatibilität für wichtige React-Native-Bibliotheken bereits direkt integriert sind!

[caniel]

Kein einfaches Projekt, aber ich drücke die Daumen.

[ohah173]

Vielen Dank!!

[dydwls140]

Hm ... test262 100 % ... Nur wegen des Badges dachte ich, das sei auf V8-Niveau, haha.