tsrs: trocar o compilador de TypeScript exige medir compatibilidade antes da velocidade

Cloudflare e VoidZero anunciaram colaboração com Max Schwenk, da Owner.com, no tsrs, um port experimental do compilador TypeScript para Rust incubado no ecossistema Oxc.[7] A proposta não é criar um dialeto: sintaxe e semântica devem acompanhar as decisões da equipe oficial do TypeScript.[7] Essa obrigação de compatibilidade é o centro da avaliação, não uma nota de rodapé.

O que muda para quem desenvolve

Nos benchmarks iniciais divulgados pela equipe, o tsrs chega a ser até oito vezes mais rápido e a consumir aproximadamente 70% menos memória que TypeScript 7.0, com o mesmo número de workers de checagem.[7] São resultados de cenários específicos e não uma promessa para qualquer projeto.[7]

O próprio anúncio reconhece avanços no TypeScript 7.1 Beta e informa que algumas otimizações do tsrs já chegaram ao upstream.[7] Além disso, a configuração adaptativa padrão pode consumir mais memória para ganhar velocidade.[7] Comparar apenas comandos padrão, sem verificar as condições, pode responder a uma pergunta diferente daquela que você pretendia fazer.

A aposta também envolve execução em WebAssembly e ambientes como Workers, navegadores e sandboxes de agentes.[7] O argumento apresentado é que a ausência de um coletor de lixo próprio como o que acompanha programas Go facilita uso de memória e interação entre guest e host.[7] Isso justifica investigar portabilidade, não presumir equivalência operacional já demonstrada.

Como aplicar

Monte uma avaliação paralela sem retirar o compilador oficial do caminho de referência. Fixe dependências, configuração do projeto e condições de execução. Compare compilador atual, TypeScript 7.1 e tsrs com o mesmo número de workers sempre que possível.

Meça tempo, pico de memória e conjunto de diagnósticos. Diferencie simples mudança de ordem de um erro omitido, de um erro adicional e de uma divergência de semântica. Guarde reproduções pequenas para qualquer diferença relevante.

Para uma plataforma que compila código gerado por agentes, proponha ainda um teste do caminho completo: inicialização do ambiente, carga das dependências, checagem e liberação dos recursos. O melhor tempo do compilador isolado não deve decidir sozinho a escolha da arquitetura.

Cuidados e limites

Há uma versão experimental no npm, executável por npx tsrs, e diferenças conhecidas, como a ordem de diagnósticos.[7] O anúncio descreve trabalho de unificação com tsc-rs e objetivos que incluem LSP e content mappers; integrações futuras não devem ser tratadas como funcionalidades prontas.[7]

O modelo proposto de manutenção usa agentes para acompanhar mudanças do upstream, testes de compatibilidade e propostas de correção.[7] Minha conclusão é que esse processo também precisa ser avaliado ao longo do tempo. Um port rápido hoje não elimina o custo de acompanhar a próxima decisão da linguagem. Adote por evidência no seu caso, não por entusiasmo com a linguagem de implementação.

Fonte

[7] Fonte: Cloudflare Blog