Running TypeScript: tsc, ts-node and the Playground

You wrote a ten-line script to print overdue tasks. Do you really need a build step to see its output? Not always. There are three common ways to run TypeScript, and each fits a different moment.

The rule

Experiment in the Playground, iterate with a runner, ship compiled JavaScript.

1. The TS Playground. An official web page where you type TypeScript on one side and see the compiled JavaScript and any errors on the other. Nothing to install. Hover over a variable to see its type, and change compiler settings from a menu. It is ideal for questions like "what type does this expression have?"

2. A runner such as ts-node. ts-node compiles your file in memory and runs it with Node.js in one step:

No .js file is written to disk. That makes it handy for scripts and quick checks while developing. Other runners, such as tsx, work in a similar way, and recent versions of Node.js can run many .ts files directly by stripping out the type annotations. Note that stripping types is not the same as checking them: a runner that only strips will happily run code that has type errors.

3. Compile, then run. The production route:

The compiler checks everything, writes JavaScript once, and Node runs that output. The running program never needs TypeScript installed, and it starts without any compile step.

The shortcut

Ask "Who is this for, and how long will it live?"

• Just me, for thirty seconds → Playground.
• Just me, while I work → a runner.
• Users, for months → compile with tsc, run the JavaScript.

The trap: relying on a type-stripping runner and never running tsc. Your code runs, but nobody is checking the types anymore. Keep npx tsc --noEmit (check only, write nothing) in your workflow.

Drills

Answer fast — trust the rule.

Remember

• Experiment in the Playground, iterate with a runner, ship compiled JavaScript.
• Ask who it is for and how long it lives to choose the method.
• Trap: running is not checking — keep tsc --noEmit in your workflow.