ts-node vs tsc, and the TypeScript commands you actually need

When you are new to TypeScript, the tooling can feel like it has too many moving parts. You see tsc in one tutorial, ts-node in another, sometimes tsx, and it is not always clear which one to reach for. This post will clear that up.

The core idea

Browsers and Node.js do not understand TypeScript. They only understand JavaScript. So somewhere along the way, your .ts file has to turn into a .js file. The question is just when and how.

You have two main options:

1. Compile ahead of time, save .js files to disk, and run those.
2. Compile on the fly in memory and run the result right away.

tsc does the first one. ts-node does the second. Same goal, different timing.

tsc, the official compiler

tsc stands for TypeScript Compiler. It comes with the typescript package. You point it at your code, and it writes out plain JavaScript files.

A typical run looks like this:

npx tsc

That reads your tsconfig.json and produces .js files based on the settings inside. If your tsconfig.json has an outDir like "outDir": "./dist", the compiled files land in dist/. If not, they land right next to your .ts files, which is usually not what you want.

What you get from tsc:

• Real .js files on disk that you can run with node.
• Type checking, so it yells at you if your types are wrong.
• An optional .d.ts declaration file if you turn that on, which is useful when you publish a library.

When you want to ship code to production, this is the tool. You compile once, you get a dist/ folder, and you run that with plain node dist/index.js.

ts-node, the run it now tool

ts-node is a separate package. Instead of producing files, it compiles your TypeScript in memory and hands the result straight to Node. Nothing is saved to disk.

npx ts-node index.ts

That command compiles index.ts and runs it immediately. If you check the folder afterwards, there is no new .js file. The compiled output lived for a moment in memory and then vanished.

This is great for development because you save a step. You do not have to run tsc first and then node after. You just edit and run.

A common dev setup pairs ts-node with nodemon so the script restarts whenever you save a file:

{
  "scripts": {
    "dev": "nodemon --exec ts-node index.ts"
  }
}

Now npm run dev gives you a live reload loop while you work.

So which one do I use?

A simple rule:

• While developing, use ts-node so you can iterate fast.
• For production, use tsc to build real files and run those with node.

You will use both in the same project. They are not competitors, they just cover different stages.

A note on tsx

You may also see a tool called tsx. It is a newer alternative to ts-node, and it is faster and handles ESM with less fuss. If ts-node ever feels finicky, give tsx a try. The mental model is the same: it runs TypeScript without writing files to disk.

The commands you actually need

Here is the short list of commands that cover most of what a beginner does day to day.

Set up TypeScript in a project

npm install --save-dev typescript
npx tsc --init

The first line installs the compiler. The second line creates a tsconfig.json with sensible defaults. You only do this once per project.

Type check without building

npx tsc --noEmit

This is one of the most useful commands you will run. It checks your code for type errors but does not produce any output files. Perfect for a quick sanity check or for running in CI.

Build for production

npx tsc

Reads your tsconfig.json and writes .js files to your outDir. This is what you run before shipping.

Watch mode

npx tsc --watch

Same as above, but it stays running and recompiles whenever you save. Handy when you want a real dist/ folder that updates as you edit, though most beginners get more value out of ts-node plus nodemon for development.

Run a TypeScript file directly

npx ts-node index.ts

Or with tsx:

npx tsx index.ts

Either one runs the file without saving any compiled output.

Add Node types

npm install --save-dev @types/node

If you use things like process.env, fs, or path, TypeScript will complain that it does not know what those are. This package teaches it. Most projects need this.

Mental model in one paragraph

tsc is the compiler. It turns .ts into .js. ts-node is a wrapper that runs tsc for you in memory and pipes the result into Node, so you never see the .js file. During development you want the fast loop, so you reach for ts-node. For production you want real output files, so you reach for tsc. Add @types/node if you are touching anything Node specific, and run tsc --noEmit whenever you want a quick "does my code type check" answer.

That is the whole picture. Once these few commands click, the rest of the TypeScript tooling becomes a lot easier to navigate.