scriptc da Vercel: Compilando TypeScript Direto para LLVM e WASI sem Passar pelo V8

A busca por eliminar o overhead de máquinas virtuais na execução de TypeScript avançou para a camada de compilação AOT nativa. Criado pela Vercel Labs, o projeto experimental scriptc propõe uma abordagem arquitetural distinta dos empacotadores tradicionais: em vez de distribuir a máquina virtual V8 completa com o código-fonte empacotado, o compilador traduz construções estáticas de TypeScript diretamente para Representação Intermediária LLVM (LLVM IR) e módulos WASI Preview 1, utilizando um backend C/LLVM.¹²

O modelo de distribuição tradicional vs. Compilação AOT

No ecossistema JavaScript e TypeScript tradicional, a geração de binários executáveis sempre foi sinônimo de encapsulamento de runtime.⁵ Para que um arquivo .ts ou .js seja executado como um binário autocontido, ferramentas consolidadas agrupam o interpretador (V8 no Node.js e Deno ou JavaScriptCore no Bun), as bibliotecas base em C++ e um sistema de arquivos virtual (VFS) com o código serializado.⁷³⁴

Embora esse modelo garanta compatibilidade integral com a semântica dinâmica do ECMAScript, ele impõe restrições estruturais de engenharia:

1. Inicialização da VM: Toda invocação exige o ciclo de bootstrap do motor JavaScript (como o V8), alocação inicial de heaps de isolamento e configuração do coletor de lixo (garbage collector).¹⁸
2. Footprint do Runtime: A inclusão dos interpretadores e dos componentes de runtime eleva o consumo de memória base e o tamanho final do artefato distribuído.¹⁷
3. Compilação JIT em Ambientes Efêmeros: Em ferramentas de linha de comando (CLIs) ou microsserviços de curta duração, o motor muitas vezes encerra a execução antes que as otimizações do compilador JIT (Just-In-Time) entrem em regime estável.⁸

O scriptc investiga a hipótese de que o subconjunto tipado e estático do TypeScript contém informação suficiente para permitir a compilação antecipada direta para linguagens intermediárias de baixo nível.¹⁶

Arquitetura do scriptc: do TypeScript ao LLVM IR

O projeto reutiliza a API oficial do compilador TypeScript para análise sintática e verificação de tipos, construindo sobre essa árvore sintática abstrata (AST) um gerador de código para a infraestrutura do LLVM:¹⁶

┌─────────────────────────┐
│ Código TypeScript (.ts) │
└────────────┬────────────┘
             │ Parser & Type Checker Oficial
             ▼
┌─────────────────────────┐
│   AST Tipada e Estática │
└────────────┬────────────┘
             │ scriptc (Emissão AOT)
             ▼
┌─────────────────────────┐
│   Código C / LLVM IR    │
└────────────┬────────────┘
             │ Clang / Zig CC
      ┌──────┴──────┐
      ▼             ▼
┌───────────┐ ┌───────────┐
│  Binário  │ │   WASI    │
│  Nativo   │ │  Preview 1│
└───────────┘ └───────────┘

O pipeline de compilação opera através dos seguintes componentes documentados no repositório oficial:¹

1. Análise de Cobertura Estática (scriptc coverage): O utilitário analisa o código-fonte e calcula a proporção de tipos e expressões que podem ser compiladas de forma puramente estática para LLVM, emitindo diagnósticos para construções dinâmicas que não possuem mapeamento AOT direto.¹
2. Geração de Código Intermediário: O compilador emite código C estruturado e representações intermediárias que interagem com um runtime C minimalista (runtime.c), eliminando a infraestrutura de objetos dinâmicos pesados do V8.¹
3. Backend de Compilação Nativa: O código gerado é compilado para código de máquina nativo utilizando o clang instalado no sistema operacional para compilações locais, ou uma toolchain externa como o zig cc (configurado via variável de ambiente SCRIPTC_CC=zigcc) para cross-compilação entre arquiteturas e para o target wasm32-wasi.¹

Compilação para WebAssembly e o Modelo WASI

Além da geração de binários nativos para o sistema operacional hospedeiro, o scriptc suporta como target formal a especificação WASI Preview 1 (WebAssembly System Interface).¹²

WASI define uma interface de sistema operacional padronizada e baseada em capacidades (capability-based security) para módulos WebAssembly, permitindo que o binário compile para uma arquitetura independente de plataforma com restrições explícitas de acesso a arquivos, rede e variáveis de ambiente.²

Para compilar para WASI, o procedimento oficial documentado pelo projeto requer a definição explícita do compilador C externo e do target de compilação via variáveis de ambiente:¹

# Compilação de TypeScript para módulo WebAssembly WASI via Zig CC
SCRIPTC_CC=zigcc SCRIPTC_TARGET=wasm32-wasi scriptc build src/agent-tool.ts --no-keep-c -o dist/agent-tool.wasm

# Execução isolada em host WASI compatível (exemplo: Wasmtime)
wasmtime run dist/agent-tool.wasm

Diferente do WebAssembly puramente web — que interage com APIs do navegador através do DOM e de bindings JavaScript —, módulos WASI operam sobre uma interface de sistema operacional padronizada e dependem de um host runtime compatível (como Wasmtime ou Wasmer) para fornecer as chamadas de sistema e capacidades autorizadas.²

O modo híbrido: Fallback dinâmico com QuickJS-ng

Uma das barreiras clássicas na compilação AOT de código JavaScript e TypeScript reside no uso de recursos dinâmicos da linguagem, como manipulação em tempo de execução de protótipos, eval, reflexão arbitrária e dependências externas do ecossistema npm que dependem de comportamentos não estáticos.

Para viabilizar a execução de projetos heterogêneos sem limitar o desenvolvedor exclusivamente a um subconjunto restrito, o scriptc implementa a flag experimental --dynamic:¹

• Ramo Estático AOT: Blocos tipados e funções puramente estáticas continuam sendo compilados diretamente para LLVM IR e otimizados pelo compilador de backend.¹
• Avaliação Dinâmica com QuickJS-ng: Trechos de código dinâmicos ou dependências que exigem interpretação flexível são delegados ao motor QuickJS-ng, um interpretador JavaScript ANSI C compacto embutido no binário final.¹⁹

Esse modelo em dois níveis assegura que trechos estáticos obtenham os benefícios de compilação nativa sem que construções dinâmicas impeçam a geração do binário.

Comparativo Estrutural de Execução no Ecossistema TypeScript

A comparação técnica entre as abordagens consolidadas reflete trade-offs entre portabilidade dinâmica e compilação antecipada:

Implicações Arquiteturais para Ferramentas de Agentes no MaxVision Code

Na engenharia de sistemas autônomos e ferramentas operadas por agentes (como os MCPs e utilitários auxiliares do MaxVision Code), o isolamento de código gerado e o tempo de bootstrap de processos efêmeros constituem áreas ativas de exploração arquitetural.

Hipótese de Sandbox Capability-Based para Agentes

Na visão de arquitetura do MaxVision Code, a compilação de ferramentas utilitárias para o target wasm32-wasi representa uma hipótese promissora para execução segura de rotinas automatizadas:

1. Restrição Estrita de Capacidades: Em vez de conceder acesso total ao sistema de arquivos do hospedeiro, o host de execução (como o Wasmtime) concede permissões explícitas apenas aos diretórios necessários para a tarefa do agente.²
2. Eliminação do Aquecimento de VM: Tarefas efêmeras de verificação sintática ou formatação compiladas como binários AOT não necessitam inicializar a máquina virtual completa do Node.js a cada execução.

# Experimento de execução com sandbox capability-based restrito
# 1. Compilação do script de validação para WASI Preview 1
SCRIPTC_CC=zigcc SCRIPTC_TARGET=wasm32-wasi scriptc build src/agent-tool.ts --no-keep-c -o dist/agent-tool.wasm

# 2. Invocação no host Wasmtime com mapeamento restrito de diretório isolado
wasmtime run --dir=/tmp/agent-scratch::/workspace dist/agent-tool.wasm

Limitações Técnicas e Requisitos de Ambiente

O scriptc encontra-se em estágio experimental pela Vercel Labs e possui requisitos e fronteiras técnicas bem delimitados:¹

• Pré-requisitos de Toolchain: Exige Node.js 24 ou superior no ambiente de compilação para execução do CLI, clang para compilações locais do host e zig cc para compilação cruzada ou emissão de artefatos WASI.¹
• Fronteiras de Compatibilidade e Targets: O modo --dynamic embute o interpretador QuickJS-ng para empacotar pacotes npm e trechos dinâmicos com any, sem suporte a leitura de node_modules em tempo de execução.¹⁹ Já no target WebAssembly (wasm32-wasi), chamadas de rede/fetch, processos-filhos, captura de sinais e monitoramento de sistema de arquivos falham antes da linkedição devido às fronteiras do modelo WASI Preview 1.¹²

À medida que projetos de compilação AOT como o scriptc e iniciativas do ecossistema TypeScript evoluem, o desenvolvimento em TypeScript expande seu alcance de runtimes de interpretação dinâmica para a geração de código nativo e WebAssembly de alta densidade.

Fontes primárias e referências técnicas