Choosing between `tsx` and `ts-node` for your Express project? Learn why this dev-time choice has major production implications and discover the right, production-safe way to build and deploy your TypeScript application.

tsx vs. ts-node: A Senior Dev’s Take on What Actually Matters for Production

I remember it vividly. It was 2 AM, and the PagerDuty alert was screaming about `api-gateway-03` being down. The deployment pipeline had passed all its checks—linting, tests, the works—but the service itself was crash-looping. I shelled into the box, tailed the logs, and saw the error that still gives me shivers: SyntaxError: Cannot use import statement outside a module. It turned out a well-meaning junior dev had tweaked a startup script, and our production environment was now trying to run a raw TypeScript file directly with a misconfigured runner. This, my friends, is a classic symptom of a much deeper problem: confusing a development tool with a production runtime.

The Core of the Problem: Dev Convenience vs. Prod Reality

Let’s get one thing straight. Tools like ts-node and its newer, faster cousin tsx are fantastic. They are Just-In-Time (JIT) transpilers. When you run tsx server.ts, it compiles your TypeScript into JavaScript in memory and then executes it with Node.js. This is amazing for local development because it’s fast, requires zero configuration, and gives you a tight feedback loop.

But that convenience is a trap. In production, you don’t want magic. You want predictable, boring, and fast. Running a JIT transpiler in production adds unnecessary overhead, increases cold start times, and introduces another potential point of failure. Production servers should run plain, optimized JavaScript, period.

The Solutions: From Quickest to “Correct-est”

So, you’re building your Express app and you need to figure out the right way to run it. Here are the three plays I recommend, depending on your situation.

Solution 1: The Quick Fix (For Local Dev ONLY) – Use `tsx`

If you’re just looking for the best local development experience, my vote goes to tsx. It’s built on esbuild, making it ridiculously fast. It also handles both CommonJS (require) and ESM (import) modules with less fuss than ts-node. It’s the perfect “hot reload” tool.

Your package.json would look something like this:

{
  "name": "my-express-app",
  "version": "1.0.0",
  "scripts": {
    "dev": "tsx watch src/server.ts"
  },
  "dependencies": {
    "express": "^4.18.2"
  },
  "devDependencies": {
    "@types/express": "^4.17.17",
    "tsx": "^4.7.0",
    "typescript": "^5.3.3"
  }
}

Warning: I’m serious about this. This is for your local machine. Do not put "start": "tsx src/server.ts" in your scripts and ship it. You’re just setting up a 2 AM wake-up call for someone on your team (probably me).

Solution 2: The Permanent Fix (The Production Standard) – The `tsc` Build Step

This is the bread-and-butter of professional TypeScript development. The strategy is simple: transpile your entire TypeScript codebase into a directory of plain JavaScript files, and then run the entry point with standard node. This is what your CI/CD pipeline should be doing.

Step 1: Configure your `tsconfig.json`

You need to tell the TypeScript Compiler (tsc) where to put the output files.

{
  "compilerOptions": {
    "target": "es2021",
    "module": "commonjs",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

Step 2: Update your `package.json` scripts

Now, we create a `build` script and a `start` script that points to the compiled JavaScript.

{
  "name": "my-express-app",
  "version": "1.0.0",
  "main": "dist/server.js",
  "scripts": {
    "dev": "tsx watch src/server.ts",
    "build": "tsc",
    "start": "node dist/server.js"
  },
  "dependencies": {
    "express": "^4.18.2"
  },
  "devDependencies": {
    "@types/express": "^4.17.17",
    "tsx": "^4.7.0",
    "typescript": "^5.3.3"
  }
}

This is the pattern. Your deployment process runs npm run build, and the server’s start command runs npm start. Simple, predictable, and robust.

Solution 3: The “Bulletproof” Fix (The Multi-Stage Docker Build)

When you want to guarantee that the environment is identical from the build server to `prod-db-01`, you containerize it. A multi-stage Docker build takes the previous solution and makes it portable and foolproof.

The magic here is that we use one container (the `builder`) with all the development tools to create our compiled JavaScript, and then copy only the necessary artifacts into a second, clean, lightweight container (the final image).

Here’s a simplified Dockerfile:

# ---- Stage 1: The Builder ----
# Use a full Node image that has all the build tools
FROM node:20 AS builder

WORKDIR /usr/src/app

# Copy package files and install ALL dependencies (including dev)
COPY package*.json ./
RUN npm install

# Copy the rest of the source code
COPY . .

# Build the TypeScript project
RUN npm run build

# Prune dev dependencies for a smaller node_modules
RUN npm prune --production

# ---- Stage 2: The Runner ----
# Use a slim image for a smaller footprint and attack surface
FROM node:20-slim

WORKDIR /usr/src/app

# Copy the pruned node_modules from the builder stage
COPY --from=builder /usr/src/app/node_modules ./node_modules

# Copy the compiled JS code from the builder stage
COPY --from=builder /usr/src/app/dist ./dist

# Copy package.json (needed by some hosting platforms)
COPY package.json .

# Expose the port your app runs on
EXPOSE 3000

# The command to run the application
CMD ["node", "dist/server.js"]

This is the gold standard. The final Docker image contains no TypeScript, no devDependencies, and no build tools. It’s a lean, mean, production-ready machine.

Comparison at a Glance

My Final Take

Stop thinking about it as “tsx vs. ts-node“. Start thinking about it as “development workflow” vs. “production artifact”. Use the incredible speed of tsx to iterate quickly on your local machine. But when it’s time to ship, embrace the build step. Compile your code down to vanilla JavaScript. Your team, your servers, and the on-call engineer at 2 AM will thank you for it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions