tsx vs ts-node: Executando TypeScript no CI
tsx executa TypeScript de forma rápida via esbuild com ESM sem dor de cabeça; ts-node é o executor consagrado com verificação de tipos opcional.
ts-node executa TypeScript diretamente no Node, opcionalmente verificando tipos enquanto roda, mas a configuração de ESM pode ser trabalhosa. tsx é um executor movido a esbuild que remove tipos rapidamente e lida com ESM/CJS de forma suave, sem verificação de tipos por conta própria.
| ts-node | tsx | |
|---|---|---|
| Motor | Baseado em tsc (opção type-aware) | esbuild (apenas transpilação) |
| Verificação de tipos durante a execução | Opcional | Não (rode tsc à parte) |
| Ergonomia de ESM | Pode ser trabalhosa | Suave |
| Velocidade de inicialização | Mais lenta | Rápida |
| Uso típico | Rodar TS com segurança de tipos | Scripts TS rápidos / dev |
No CI
tsx é ótimo para rodar scripts e ferramentas em TypeScript de forma rápida no CI, especialmente com ESM, porque transpila com esbuild e pula a verificação de tipos por velocidade. Combine-o com uma etapa separada de tsc --noEmit para segurança de tipos. ts-node pode verificar tipos enquanto roda, o que alguns preferem para scripts, mas é mais lento e sua configuração de ESM é uma fonte frequente de falhas no CI (os clássicos problemas de ERR_UNKNOWN_FILE_EXTENSION / loader).
Boa prática
Na maioria dos pipelines, rode a verificação de tipos uma vez com tsc --noEmit e execute os scripts com o executor rápido de apenas transpilação (tsx). Isso separa correção (tipos) de execução (velocidade) de forma limpa e evita trabalho duplicado.
O veredito
Quer execução rápida e ESM sem dor, com uma etapa separada de type-check com tsc: tsx. Quer verificação de tipos durante a execução e você já tem um setup de ts-node funcionando: ts-node. O padrão comum é tsx para executar mais tsc para tipos.