# ts-node vs SWC: executando TypeScript mais rápido no CI

> ts-node vs SWC register no CI: execução baseada em tsc vs transpile na velocidade do Rust, type checking e ESM. Qual runner de TypeScript mantém os scripts de CI rápidos.

Source: https://latchkey.dev/pt/learn/tool-comparisons/ts-node-vs-swc-node  
Updated: 2026-06-26

O ts-node roda TypeScript através do tsc; combiná-lo com o SWC register (ou @swc-node) troca o transpile pela velocidade do Rust, para uma execução muito mais rápida.

O ts-node executa TypeScript via o compilador do TypeScript. A abordagem SWC (a flag --swc do ts-node ou @swc-node/register) transpila com SWC em Rust para um startup muito mais rápido, ao custo de não rodar o type-checking completo durante a execução.

## Comparison

|  | ts-node | SWC (register) |
| --- | --- | --- |
| Motor de transpile | tsc | SWC (Rust) |
| Velocidade de startup | Mais lenta | Muito mais rápida |
| Type checking | Opcional (mais lento) | Não (só remove) |
| Suporte a ESM | Funciona (config) | Funciona |
| Melhor para | Execução ciente de tipos | Execução rápida de scripts/testes |

## No CI

O ts-node puro pode fazer type-check conforme executa, mas é a opção mais lenta; usar o SWC register (ou ts-node --swc) mantém o mesmo workflow enquanto transpila muito mais rápido, o que reduz o startup de scripts e testes. Como outros transpiladores rápidos, o SWC não faz type-check, então rode tsc --noEmit separadamente. Para pura velocidade de execução no CI, o caminho SWC vence.

## Type-check separado

Adicione uma etapa tsc --noEmit (em paralelo) para segurança de tipos, já que o SWC apenas remove os tipos. Ambos rodam em managed runners; runners gerenciados mais rápidos encurtam longas passagens de type-check em bases de código grandes.

## The switching cost is mostly in the parts nobody lists

- Assertions and mocks usually port mechanically when the target implements a compatible API; custom transformers and framework plugins do not.
- Snapshot formats differ between runners, so plan to regenerate and review rather than port.
- Run both suites in parallel in CI for a period and diff the results. A migration that changes which tests fail is not a migration, it is a regression you have not found yet.
- Coverage numbers move on a runner change even when the tests do not, because instrumentation differs. Re-baseline any coverage gate deliberately.

## O veredito

Quer a execução de TypeScript mais rápida: ts-node com o SWC register (ou @swc-node), mais uma verificação separada tsc --noEmit. Precisa de execução ciente de tipos em uma só ferramenta: ts-node puro. A maioria dos pipelines separa velocidade de type-checking.

## FAQ

### ts-node vs SWC: Running TypeScript Faster in CI?

ts-node executes TypeScript via the TypeScript compiler. The SWC approach (ts-node's --swc flag or @swc-node/register) transpiles with SWC in Rust for far faster startup, at the cost of not running full type-checking during execution.

### In CI?

Plain ts-node can type-check as it runs but is the slowest option; using the SWC register (or ts-node --swc) keeps the same workflow while transpiling far faster, which trims script and test startup. As with other fast transpilers, SWC does not type-check, so run tsc --noEmit separately. For sheer execution speed in CI, the SWC path wins.

### Type-check separately?

Add a tsc --noEmit step (in parallel) for type safety since SWC only strips types. Both run on CI runners; faster managed runners shorten long type-check passes on large codebases.

### Which should I choose?

Want the fastest TypeScript execution: ts-node with the SWC register (or @swc-node), plus a separate tsc --noEmit check. Need type-aware execution in one tool: plain ts-node. Most pipelines split speed from type-checking.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt