tsx — Run TypeScript in Node.js Without the Build Step

Run TypeScript directly in Node.js — zero config
8.3 /10

tsx is ideal for development and scripts. TypeScript without overhead, but not production-ready. If you want esbuild speed and zero config: tsx is your answer.

Free
Price
cli
Platforms
Yes
Open Source
No
Self-Host

What is tsx?

tsx is a TypeScript executor for Node.js. The tool solves a concrete problem: running TypeScript directly in your development workflow without prior compilation or complex configuration. It transpiles TypeScript on the fly to JavaScript and executes the result.

The tool was developed by PrivateNumber and is open source under the MIT license. tsx uses esbuild as its transpiler backend — which explains the performance. The current version is 4.21.0 (as of November 2025). The maintainer pushes updates regularly; the project is active and well-maintained.

Node.js ≥18 is required (all currently maintained LTS versions are supported). tsx works both as a CLI tool and as a Node.js loader, making it flexible for various scenarios.

Installation & Setup

Prerequisites

  • Node.js: ≥18 (all currently maintained versions, tested under LTS 18, 20, 22)
  • npm: Required for installing the package
  • Operating system: Linux, macOS, Windows (with a known watch mode limitation on Windows)

Optional dependencies: None. tsx is a fully self-contained binary without external peer dependencies.

Installation

npm install --save-dev tsx

After that, tsx is available at ./node_modules/.bin/tsx or via npx:

npx tsx script.ts

Global installation is possible, but not recommended for projects:

npm install -g tsx

Alternatives: brew install tsx (macOS) or via nix (for NixOS/nix environments). Binary downloads are available on the GitHub releases page.

Initial Configuration

tsx requires no configuration file. It works immediately after installation. The minimal setup is a TypeScript file:

const greeting: string = "TypeScript with tsx";
console.log(greeting);

And execution:

npx tsx script.ts

That’s it. If you have a tsconfig.json in your project, tsx automatically respects path aliasing and other settings. If not, tsx uses TypeScript defaults.

Optional watch mode activation for development:

npx tsx --watch script.ts

This is equivalent to nodemon + ts-node, but zero config.

Core Features

Zero-Config TypeScript Execution

tsx runs TypeScript files directly without configuration, installing peer dependencies, or setting up a compiler. That’s the core value: npm install + run = done. No .tsconfig required, no boilerplate.

interface User {
  name: string;
  id: number;
}

const user: User = { name: "Alice", id: 42 };
console.log(`User: ${user.name}`);

Execution:

tsx main.ts

The limitation: tsx only transpiles, it does not type-check. If types are wrong, they pass through at runtime. You still need tsc --noEmit or IDE integration for type safety.

Watch Mode with Auto-Restart

--watch monitors file changes and restarts the script. This is cleaner than maintaining a separate nodemon config.

tsx --watch server.ts

On Windows there is a limitation: tsx watch can hang when your code imports certain modules (chalk, prom-client, googleapis). This is a known bug documented by the maintainer but not yet fixed.

CommonJS ↔ ESM Interop

tsx solves the problem that CommonJS and ESM are difficult to mix in Node.js. It lets you load ESM modules seamlessly from CommonJS:

// ESM modules can be used directly
const { default: chalk } = await import('chalk');
console.log(chalk.blue('Interop works'));

Using --import, you can use tsx as a loader:

node --import tsx/esm ./entry.mjs

The caveat: not all edge cases are tested. Highly complex dependency graphs can cause issues.

Path Aliasing from tsconfig.json

If your tsconfig.json defines path aliasing, tsx picks it up automatically:

{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"],
      "@utils/*": ["./utils/*"]
    }
  }
}

Absolute imports then work out of the box:

import { helper } from '@utils/helpers';
console.log(helper());

This saves you from deeply nested relative paths like ../../utils/helpers. The limitation: only tsconfig paths, no .env-based configuration.

Fast esbuild-Based Transpilation

tsx uses esbuild as its backend. This makes TypeScript-to-JavaScript conversion very fast. On startup, the entire code is transpiled — typically in the millisecond range for normal projects.

From the research benchmark: tsx clearly beats ts-node (esbuild vs. tsc, startup is 2–5x faster). This matters for development loops.

The limitation: startup latency adds up with frequent spawning (e.g., in serverless or with many rapid script invocations). tsx is not recommended for production; precompiled binaries are the right choice there.

Strengths

  • Zero config and fast: npm install + run. No peer deps, no config hell.
  • esbuild-based: Startup is 2–5x faster than ts-node (tsc is slow). Ideal for dev loops.
  • Built-in watch mode: Replaces the nodemon + ts-node combination with a single tool.
  • Path aliasing out of the box: tsconfig.json paths work directly without extra setup.
  • ESM/CJS interop: Mixed modules are handled more cleanly than with plain Node.js.
  • Active development: 11.8k GitHub stars, 26.7M npm downloads/week, regular updates.

Weaknesses

  • No type checking: tsx only transpiles, it does not type-check. Type errors are not caught at runtime. You need tsc --noEmit separately.
  • Not suitable for production: Runtime transpilation puts heavy load on the CPU. Resource-constrained environments suffer. Pre-compiled executables are the right tool.
  • Startup latency on frequent spawning: Every invocation re-transpiles the entire code. Serverless and microservices are problem cases.
  • Watch mode bug on Windows: Hangs with certain imports (chalk, prom-client, googleapis). Documented, not fixed.
  • Bundling overhead: tsx does not externalize node_modules automatically. Large projects with many dependencies pay a performance price.

Pricing

tsx is free and open source. License: MIT. No tiers, no paid features. You self-host on your own machine or server.

The real cost factor: CPU and RAM during transpilation. In the cloud or on lean VMs this can become problematic — hence the recommendation against production use.

Conclusion & Assessment

tsx is a fit if you want to run TypeScript quickly during development — build scripts, migrations, CLI tools, task runners like Gulp with TypeScript. The workflow is as frictionless as it gets: write code, run tsx file.ts, done.

tsx is not suitable for production workloads or serverless scenarios with frequent restarts. There, pre-compiled binaries or esbuild with explicit output are the right choice.

Direct alternatives: ts-node (older, slower, tsc-integrated), esbuild (transpiler only, requires CLI know-how), Bun (Rust runtime, 3–4x faster, but a different ecosystem), Deno (security-first, but weak npm compatibility).

tsx occupies the “development tools” niche and does its job well — fast, pragmatic, no surprises.

## Pricing

Best Value
Free
$0
  • Full feature set
  • MIT license
  • No restrictions

Last verified: Sat Mar 07 2026 00:00:00 GMT+0000 (Coordinated Universal Time).

## The Good and the Not-So-Good

+ Strengths

  • Fastest TypeScript execution via esbuild — no build-step overhead
  • Zero config: works immediately after installation
  • Integrates CommonJS + ESM seamlessly
  • Built-in watch mode — replaces nodemon + ts-node
  • Active project with regular updates (11.8k GitHub stars, 26.7M npm downloads/week)

− Weaknesses

  • No type checking — transpilation only, type errors are not caught
  • Not suitable for production — runtime transpilation is resource-intensive
  • Startup latency from re-transpilation on every run
  • Windows watch mode bug with certain imports (chalk, prom-client, googleapis)
  • Bundles dependencies — performance impact on large projects

## Who It's For

Best for: Developers who want to iterate quickly on TypeScript scripts. Build scripts, migrations, CLI tools. Watch-based development workflows with auto-restart.

Not ideal for: Production services (use pre-built). Microservices with strict performance requirements. Teams without IDE-based type checking. Serverless functions (startup latency).