Scriptc: Vercel compila TypeScript direto para binário nativo

O scriptc, do Vercel Labs, é um compilador que transforma TypeScript e JavaScript em executáveis nativos e módulos WebAssembly. O README o chama de experimental, e a licença é Apache 2.0.

Como funciona

Segundo o README, ele usa as informações de tipo do TypeScript para compilar o código suportado direto para instruções nativas. Num build estático, o executável não precisa de nenhum motor JavaScript para rodar.

Para código sem anotações de tipo ou que usa dependências do npm, existe o modo --dynamic. Ele embute o motor quickjs-ng, e o JavaScript das dependências entra no binário em tempo de build.

Comandos

• scriptc run [arquivo]: compila e executa na hora;
• scriptc build [arquivo] -o [saída]: gera um executável independente;
• scriptc coverage [arquivo]: mostra quanto do código ficou estático, dinâmico ou sem suporte.

Para instalar é preciso Node.js 24 ou mais novo. Para gerar executáveis, também precisa de um linker e de SDK ou sysroot da plataforma.

O que ele não faz

O projeto suporta um subconjunto de JavaScript, TypeScript e das APIs do Node.js, e o README manda consultar a lista de limitações e a tabela de compatibilidade antes de adotar. Entre o que compila para código nativo estão coisas como criar servidor HTTP e operações com arquivos.

O README não traz benchmarks, uso de memória, tempo de compilação nem prazo para ficar estável. A versão anterior deste post descrevia um pipeline de tsc para C e clang e chegava a citar estrelas no GitHub. Isso não está no README, então saiu. Como o próprio texto diz que é experimental, a conclusão prática é testar com um projeto pequeno e rodar o scriptc coverage antes de qualquer coisa séria.

Onde eu usaria (e onde não usaria)

A ideia de distribuir uma ferramenta escrita em TypeScript como um único executável, sem pedir para o usuário instalar Node.js, resolve um problema real. Eu já perdi tempo explicando para colegas por que um script interno não rodava na máquina deles por causa da versão do runtime.

Mesmo assim, eu não colocaria um projeto experimental no caminho crítico de nada. O lugar onde eu testaria o scriptc primeiro seria uma ferramenta de linha de comando interna, pequena, sem muitas dependências: um script que valida arquivos de configuração, por exemplo. Se quebrar, o prejuízo é baixo e eu aprendo onde estão os limites do compilador.

O comando de cobertura me parece a parte mais útil para decidir. Se a maior parte do código cai no modo dinâmico, o ganho de um binário nativo diminui bastante, e talvez outra abordagem, como empacotar o runtime junto, seja mais estável. Eu também compararia o tamanho do executável e o tempo de inicialização com o que já uso hoje, porque são esses números que o usuário da ferramenta vai sentir.

Leia também: Se o seu interesse é binário nativo e performance, dois textos do lado do Rust: a armadilha Tokio/Rayon e o Rust Glancer, LSP que mira menos de 100 MB de RAM.