Um bundler JavaScript desenvolvido em fluxo de consciência (Transpilador e compilador TypeScript nativo em Zig)
(github.com/ohah)Como estudar na era da AI?
Eu não conseguia ter clareza sobre que tipo de especialização é exigida e que tipo de habilidade tem mais valor neste momento.
Acho que é a mesma coisa tanto para as empresas que contratam desenvolvedores quanto para os próprios desenvolvedores: ninguém conhece critérios claros.
De qualquer forma, tive a sensação de que, se eu ficasse parado, estaria perdendo sem dúvida nenhuma.
Então pensei: pelo menos vou fazer alguma coisa.
No começo, comecei criando simplesmente um Chrome Remote DevTools para estudo.
Enquanto fazia isso, pensei em também fazer o React Native ter suporte a depurador remoto.
-> Não conheço o Metro, então tudo é muito confuso.
-> Vamos estudar reproduzindo o Metro.
-> Não daria para criar um bundler melhor que o Metro para React Native?
-> Fuçando aqui e ali com Rolldown, swc e Bun, tentei criar um bundler melhor que o Metro Bundler.
Bun e Rolldown até pareciam ter potencial, mas senti limites em ficar personalizando demais a parte principal ou manter um fork.
Além disso, não existe um bundler web totalmente compatível com o Metro Bundler: flow, a sintaxe JavaScript permitida pelo engine Hermes, a ordem de chamadas importante de um jeito diferente do web comum etc.
Ah... já que de qualquer forma é estudo, então vou fazer também o bundler e substituir o Metro do React Native.
O que senti enquanto fazia o bundler.
Então não basta simplesmente dar suporte à web também?
Vamos incluir também o ES5 que o Rolldown abandonou.
Como precisa executar RN, vamos dar suporte também ao parser de Flow.
Vamos dar suporte também a wasm.
Vamos tentar superar também a velocidade do Bun e do Rolldown.
Vamos colocar HMR próprio também.
Vamos tentar fazer um tree-shaking mais agressivo.
Vamos tentar ficar à frente de outros bundlers também em minify.
Desenvolvi com a ideia de vencer, em benchmark e nas funcionalidades que eu conhecia, todos os bundlers existentes.
Claro que imagino que esteja perdendo em muitos aspectos.
Comparado a outros bundlers, ainda há naturalmente muitas partes incompletas, como estabilidade, funcionalidades, ecossistema e comunidade suportados; e, quanto ao tree-shaking e ao minify mencionados acima, em alguns módulos ele fica à frente, mas em outros fica atrás.
Mesmo assim, em testes de execução até agora, há partes em que ele vence; e embora ainda haja muito a fazer (SSL, MCP, CLI, estabilização, documentação de API etc.), o objetivo original — buildar e executar apps React Native — já foi verificado em 3 apps comerciais, com build de release, build de desenvolvimento e servidor de desenvolvimento, e funcionou sem problemas. Então pensei que talvez já fosse um bom momento para abrir o projeto e continuar desenvolvendo, e por isso escrevi este post.
Ainda assim, o desenvolvimento e as funções de bundling (zntc também é buildado e distribuído com zntc) estão funcionando razoavelmente bem;
funcionalidades essenciais como decorators e, no React Native, funcionalidades quase essenciais como worklet, TypeScript, Flow etc. funcionaram sem problemas nas bibliotecas que testei;
além disso, ele oferece plugins para vite e rspack, fornece também ambiente de desenvolvimento como vite e rspack (RN, Web), tem documentação, React HMR, suporta Module Federation etc.
Então considerei que, no mínimo, ele já possui as funções básicas de um bundler/transpilador, e pretendo continuar desenvolvendo depois de publicá-lo, também para receber feedback.
A quantidade de código escrito à mão foi zero; tudo foi desenvolvido em discussões intensas com AI.
Acho que forcei mais a AI do que em qualquer outro desenvolvimento de produto.
Usei só o Claude no começo e depois também usei o Codex.
O período de desenvolvimento do próprio bundler foi de cerca de 3 meses (aproximadamente 3000 PRs); incluindo todo aquele fluxo de consciência mencionado acima, foram uns 6 meses trabalhando dia e noite sem parar.
Trabalhei sem descanso em dias úteis e feriados, e por um certo complexo de inferioridade? ou consciência por estar comparando com outros bundlers à toa,
desenvolvi também escrevendo testes em quantidade quase exagerada, a ponto de parecer obsessão, para passar por vários casos de teste como test262 100%.
Agradeço muito qualquer feedback (__)
5 comentários
Como alternativa ao Metro, também existe o Re.Pack, que usa RSPack ou WebPack.
Acabei esquecendo disso enquanto escrevia sem muita ordem.
Como você mencionou, também me baseei bastante no Re.pack.
Pelo que sei, tanto o Re.pack quanto o Rspack são baseados em
swc, então não oferecem suporte nativo aflow,e, no caso do Re.pack, pelo que sei, desde a versão 5 ele é baseado no Rspack; da mesma forma, o Re.pack também usa
swc+babel, então plugins muito populares comoflow,reanimatedenativewind(ozntcpretende oferecer suporte) ainda acabam sendo transpilados com Babel.Pessoalmente, eu queria me afastar do Babel, então no caso do
zntceu o criei com opções suportadas nativamente por padrão.O
zntctambém oferece compatibilidade com Babel, mas eu queria deixar a dependência de Babel o mais próximo possível de zero.São códigos muito estáveis e já bem validados, mas por causa das limitações do JavaScript, sempre existe gargalo de desempenho.
Na prática, durante o desenvolvimento, fui comparando benchmarks com outros bundlers o tempo todo e, como eu mesmo fui sentindo isso na prática, é natural que ele ainda fique atrás de outros bundlers em recursos, estabilidade e extensibilidade, então pretendo continuar melhorando essa parte.
Ainda assim, como a compatibilidade de parser com as principais bibliotecas do React Native já vem totalmente embutida, acredito que ele esteja à frente justamente nos pontos de gargalo estrutural que inevitavelmente acontecem no Re.pack!
Parece que vai ser um projeto difícil, torço por vocês.
Obrigado!!
Hum... test262 100%... só pelo selo achei que era nível V8 haha