Un bundler de JavaScript desarrollado en flujo de conciencia (Transpilador y compilador nativo de TypeScript en Zig)
(github.com/ohah)¿Cómo habría que estudiar en la era de la IA?
No lograba tener claro qué tipo de especialización se requiere ni qué habilidades son las más valiosas en esta época.
Supongo que tanto las empresas que contratan desarrolladores como los propios desarrolladores están en la misma situación, sin criterios del todo claros,
pero de todos modos sentí que si me quedaba quieto iba a salir perdiendo sí o sí.
Así que pensé: al menos hagamos algo.
Al principio empecé haciendo una herramienta simple de Chrome Remote DevTools como proyecto de aprendizaje.
Y mientras lo hacía, pensé en hacer que React Native también fuera compatible mediante un depurador remoto.
-> No conozco Metro y me confunde muchísimo.
-> Vamos a estudiarlo haciendo un clon de Metro.
-> ¿No se podrá hacer un bundler mejor que Metro para React Native?
-> Probé varias cosas con Rolldown, SWC y Bun, intentando crear un bundler mejor que Metro.
De todos ellos, Bun y Rolldown eran los que más potencial tenían, pero sentí límites al tener que hacer demasiadas personalizaciones del lado principal o mantener forks.
Además, no existe un bundler web que sea perfectamente compatible con Metro: está Flow, la sintaxis de JavaScript que permite el motor Hermes, y también detalles como el orden de invocación, que es importante de una forma distinta a la web común...
Ah... total, como de todos modos era para aprender, pensé: mejor hago también el bundler e intento reemplazar Metro de React Native.
Lo que sentí al hacer el bundler:
Entonces, ¿no bastaría con que también soporte web?
Metamos también ES5, que Rolldown dejó de lado.
Como hay que ejecutar RN, soportemos también el parser de Flow.
Soportemos también wasm.
Intentemos incluso superar en velocidad a Bun y Rolldown.
Metámosle también HMR propio.
Probemos un tree-shaking más agresivo.
Hagamos que el minify también quede por delante de otros bundlers.
Lo desarrollé con la idea de ganarle, al menos en benchmarks y en las funciones que tenía identificadas, a todos los bundlers existentes.
Claro que también pienso que debe haber muchos puntos donde sigo perdiendo.
Comparado con otros bundlers, naturalmente todavía hay muchas partes incompletas: estabilidad, funciones, ecosistema y comunidad; además, tanto en tree-shaking como en minify hay módulos donde va mejor y otros donde se queda atrás.
Aun así, según varias pruebas de ejecución, hay aspectos donde sí gana. Y aunque todavía queda mucho por hacer (SSL, MCP, CLI, estabilización, documentación de API, etc.), el objetivo original —compilar y ejecutar apps de React Native— ya lo confirmé en 3 apps comerciales: probé builds de release, builds de desarrollo y el servidor de desarrollo, y todo funcionó sin problemas. Por eso pensé que ya era buen momento para publicarlo y seguir desarrollándolo de forma abierta, y por eso escribo esta publicación.
Aun así, tanto el desarrollo como las funciones de bundling (zntc también se compila y distribuye con zntc) están funcionando bastante bien,
y las librerías que probé con funciones esenciales como decorators, y también worklet —casi indispensable en React Native—, TypeScript, Flow, etc., funcionaron todas sin problemas.
También ofrece plugins para vite y rspack, proporciona un entorno de desarrollo al estilo de vite y rspack (RN, Web), tiene documentación, HMR para React y soporte para module federation, entre otras cosas.
Así que considero que, al menos, ya cuenta con las funciones básicas de un bundler/transpilador, y quiero publicarlo para recibir feedback y seguir desarrollándolo.
La cantidad de código escrito a mano es 0; todo fue desarrollado con IA a base de discusiones intensas.
Creo que nunca había exprimido tanto a la IA en el desarrollo de un producto.
Usaba solo Claude al principio, y después también empecé a usar Codex.
El desarrollo del bundler en sí tomó unos 3 meses (alrededor de 3000 PR); si incluyo todo el flujo de ideas que mencioné arriba, fueron unos 6 meses trabajando día y noche.
Trabajé sin parar entre semana y fines de semana, y también, por una especie de complejo al compararlo innecesariamente con otros bundlers,
terminé escribiendo una cantidad exagerada de casos de prueba, al punto de la obsesión, para pasar test262 al 100% y muchas otras pruebas.
Agradeceré mucho cualquier feedback (__)
5 comentarios
Como alternativa a Metro, también está Re.Pack, que usa RSPack o WebPack.
Se me pasó mencionarlo porque escribí el texto de forma algo desordenada.
Como comentaste, también tomé bastante como referencia a Re.pack.
Tengo entendido que tanto Re.pack como Rspack están basados en
swc, así que no soportanflowde forma nativa,y en el caso de Re.pack, entiendo que desde la versión 5 está basado en Rspack. Del mismo modo, Re.pack también usa
swc+babel, así que tengo entendido que plugins muy populares comoflow,reanimatedynativewind(zntc tiene previsto soportarlo) todavía se transpilan con Babel.En lo personal, quería alejarme de Babel, así que en el caso de zntc lo hice como una opción con soporte nativo por defecto.
zntc también ofrece compatibilidad con Babel, pero quería dejar la dependencia de Babel en cero en la medida de lo posible.
Su estabilidad es excelente y son códigos ya probados, pero por la limitación de estar en JS, la velocidad siempre termina teniendo cuellos de botella.
La verdad es que durante el desarrollo fui comparándolo continuamente con benchmarks de otros bundlers, y tal como lo fui notando en la práctica, naturalmente todavía queda por detrás de otros bundlers en funcionalidad, estabilidad y extensibilidad, así que pienso seguir mejorando esa parte.
Aun así, como la compatibilidad de parser para las principales librerías de React Native ya viene totalmente integrada, creo que va por delante en las secciones de cuello de botella estructural que en Re.pack inevitablemente terminan ocurriendo.
No debe ser un proyecto fácil; te apoyo.
¡¡Gracias!!
Mmm... 100% en test262... por la pura insignia pensé que era de nivel V8 jaja