tsx vs tsc vs ts-node

Escolha a ferramenta certa de TypeScript por ambiente - tsx para desenvolvimento e testes rápidos, tsc para dist/ de produção e evite novas adoções de ts-node a menos que restrições de brownfield exijam.

Receita

{
  "scripts": {
    "dev": "node --watch --import tsx src/main.ts",
    "build": "tsc -p tsconfig.json",
    "start": "node dist/main.js",
    "test": "node --import tsx --test src/**/*.test.ts"
  },
  "devDependencies": {
    "typescript": "^5.6.0",
    "tsx": "^4.0.0",
    "@types/node": "^24.0.0"
  }
}

Quando usar isso:

• Inicializando um novo serviço Express 5 ou Fastify 5
• Escolhendo comandos de CI que espelham a produção
• Substituindo pilhas ts-node-dev ou nodemon + ts-node
• Depurando incompatibilidades "funciona com tsx, falha com node dist"

Exemplo de Trabalho

// src/main.ts
import { createServer } from 'node:http';
 
const port = Number(process.env.PORT ?? 3000);
 
createServer((_req, res) => {
  res.end('ok');
}).listen(port, () => console.log(`Ouvindo na porta ${port}`));

# Desenvolvimento - sem etapa de compilação separada
npm run dev
 
# Pipeline de produção
npm run build
npm run start

// tsconfig.json - emitir para produção
{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "declaration": true,
    "sourceMap": true,
    "strict": true
  }
}

O que isso demonstra:

• tsx usa o hook do loader do Node - transforma TS em tempo real via esbuild
• tsc escreve dist/main.js preservando especificadores de importação ESM com extensões .js
• A produção executa node puro - sem loader de devDependency no contêiner
• --watch + tsx substitui nodemon para muitos serviços

Análise Profunda

Como Funciona

• tsx - Transformação esbuild, inicialização rápida, suporta ESM e import.meta, ideal para dev/teste.
• tsc - Verificação completa de tipos + emissão; mais lento, mas autoritativo para declarações e dist/.
• ts-node - Integração mais antiga de compilador em tempo real; o suporte a ESM é mais complicado do que o tsx.
• tsc --noEmit - Trabalho de CI apenas para verificação de tipos sem emissão - emparelha com o trabalho build.

Comparação de Pipeline

Notas de TypeScript

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "dev": "node --watch --import tsx src/main.ts"
  }
}

Execute typecheck em CI mesmo quando o dev usar tsx - o tsx sozinho ignora erros de tipo.

Armadilhas

• Enviar tsx para produção - adiciona superfície de devDependency e sobrecarga de transformação. Correção: node dist/main.js no CMD do Docker.
• tsx passa erros de tipo - apenas transpile. Correção: tsc --noEmit no gate de CI.
• Aliases de caminho sem suporte de emissão - tsc não reescreve paths. Correção: importações relativas NodeNext ou etapa pós tsc-alias.
• Saída de módulo diferente (CJS vs ESM) - tsx executa a origem; tsc emite por module. Correção: alinhar "type" do package.json com a emissão.
• Manter ts-node para ESM em 2026 - configuração mais difícil do que tsx. Correção: migrar scripts de dev para node --import tsx.

Alternativas

FAQs

Relacionados

• Noções Básicas de TypeScript no Node - padrões tsconfig
• Brownfield de Tipagem Gradual - migrando bases de código JS
• Typecheck em CI - portões de mesclagem
• Executando Scripts e Shebang - scripts npm

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (LTS Ativo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.