TypeScript LSP lento: reiniciar o server não resolve
Inferência profunda em tRPC reinicia o TS server. O audit levou a um cache no checker — e o 5.9 beta traz mais alívio no editor.
Resposta direta
Em monorepos com tRPC e Zod, o TypeScript language server reinicia porque cada mudança força reinferência em cascata nos routers. O audit com especialistas encontrou falha de cache no checker em merges profundos; um PR no TypeScript cortou instanciações pela metade em repos tRPC. TypeScript 5.9 beta soma alívio de editor (hovers expansíveis, init mais limpo). TSGo/native ainda é parallel track — use beta estável antes de nightly.
O sintoma: Command+Shift+P reinicia o server
Em bases grandes com Zod e tRPC, o relato é claro: o editor piora, a tipagem demora e o hábito vira reiniciar o TypeScript server. Não é runtime do Node ou Bun — é o language server e o LSP sufocados por inferência. Quem comprou TypeScript 'de verdade' sente punição justamente por tipar ponta a ponta.
tRPC liga front e back sem codegen: você muda um procedure e o consumidor React já reclama de tipo. Isso é o valor. O custo é que routers compostos (billing, auth, legacy) formam grafos grandes de inferência. Qualquer alteração no retorno de uma mutation pode recomputar o router inteiro.
Por que a inferência explode
Procedures sem anotações explícitas de retorno são o padrão saudável em tRPC: input validado (Zod/Valibot) e retorno inferido. O preço é que o checker instancia tipos em profundidade. Em merges genéricos aninhados, o cache do TypeScript falhava de um jeito perverso: a chave do cache dependia de instantiateType, então o trabalho caro rodava antes mesmo de saber se o resultado já estava cacheado.
Project references pareciam a solução óbvia — isolar sub-routers e reutilizar artefato. Na prática, o time ainda via regressão de performance. O diagnóstico externo (Arctype/David + Andarist) apontou comportamento estranho do checker, não só 'tRPC mal escrito'.
Na prática
Regra prática: meça instanciações e tempo de check em um router real antes de culpar só a lib. Microbenchmarks mentem; repos tRPC reais mostraram corte de ~metade no tempo de verificação após o PR de cache.
O que entrou no TypeScript e o que vem no 5.9
O PR de cache de mappers/instanciações profundas passou pelo review do time (incluindo discussão com Anders sobre nível certo de cache). Em benches estilo at-test e em repos tRPC, o número de instanciações despencou e o tempo de check caiu na mesma ordem. Hovers que antes quebravam em profundidade passaram a aguentar cadeias longas.
TypeScript 5.9 beta traz melhorias de DX além do perf: `tsc --init` mais enxuto, import defer, descrições MDN mais úteis em APIs DOM, e hovers expansíveis no editor — o tipo deixa de ser só um alias opaco. Truncation configurável também ajuda quem vive de erros gigantes de inferência.
Como aplicar no seu monorepo esta semana
Suba para um TypeScript que já inclua o fix de cache (nightly recente ou 5.9 beta quando maduro no seu CI). Atualize tRPC. Meça: tempo de `tsc --noEmit` e tempo até o primeiro hover útil no router mais gorduroso. Se ainda dói, isole routers com project references de verdade e evite reexportar o app router inteiro em cada arquivo de UI.
Pagar audit de performance do TS server fez sentido no caso tRPC porque o dinheiro foi para mudança upstream que beneficia todo mundo. No seu time, o equivalente barato é: reproduzir o router mínimo que dói, abrir issue com números, e não aceitar 'só reinicia o server' como processo.
Na prática
Evite nightly em produção. Beta do TypeScript costuma ser testado o suficiente para times que já sofrem no editor; nightly é para quem reporta bugs.
TSGo e o risco de congelar o checker
O rewrite em Go (preview nativo) preocupava quem temia que o time congelasse mudanças grandes no checker JS durante o porte. O fato de um PR sensível de cache ter sido mergeado em paralelo é sinal bom: o produto TypeScript continua sendo otimizado para usuários reais enquanto o native avança.
Conclusão operacional: trate LSP lento como bug de plataforma mensurável, não como falha moral de quem usa tipagem forte. Se sua stack é tRPC+Zod, priorize versão de TS com cache corrigido, depois DX do 5.9, e só então experimente TSGo em branch separado.