Your First Compilation

Beginner · 16 min read · ▶ live playground · ✦ checkpoint

Time to catch the compiler in the act. In this lesson you write a real .ts file, run tsc, and read the JavaScript that comes out the other side — the moment "types erase" stops being a slogan and becomes something you've seen. You'll also hit your first deliberate type error and learn to read a diagnostic without flinching.

hello.ts, meet tsc

In the project folder from last lesson, create hello.ts:

function greet(name: string): string {
  return `Hello, ${name}!`;
}
 
const audience: string = "TypeScript";
console.log(greet(audience));

Compile it, then run the output:

npx tsc hello.ts
node hello.js
# Hello, TypeScript!

tsc read your file, checked every type, and — finding no complaints — wrote hello.js next to it. That .js file is the actual program; the .ts file never runs anywhere.

Reading the emitted JavaScript

Open hello.js. This is its exact content:

function greet(name) {
    return `Hello, ${name}!`;
}
const audience = "TypeScript";
console.log(greet(audience));

Play spot-the-difference: : string is gone from the parameter, the return type is gone, the annotation on audience is gone. Nothing else changed. No library was imported, no checks were inserted, your logic wasn't rewritten. The compiler's whole runtime contribution is deletion.

It goes further — entire lines can vanish. An interface (a named object shape, properly introduced in Section 5) exists only for the checker:

interface Rocket {
  name: string;
  stages: number;
}
 
const falcon: Rocket = { name: "Falcon 9", stages: 2 };
console.log(falcon.name, "has", falcon.stages, "stages");
const falcon = { name: "Falcon 9", stages: 2 };
console.log(falcon.name, "has", falcon.stages, "stages");

Your first type error — read it like a pro

Break the file on purpose. Change the audience line:

function greet(name: string): string {
  return `Hello, ${name}!`;
}
 
const audience: string = 42;
console.log(greet(audience));

→ hello.ts:5:7 - error TS2322: Type 'number' is not assignable to type 'string'.

Every TypeScript diagnostic has the same anatomy, and once you see it you can't unsee it:

  • hello.ts:5:7 — file, line, column. It points at audience, the thing that's wrong.
  • error TS2322 — a stable error code. Searchable, and the same code every time this kind of mistake happens (2322 is "assignability" — you'll meet it weekly for the rest of your career).
  • The sentence — always shaped "Type X is not assignable to type Y": what you provided, then what was required. Read it as: "you promised string, you delivered number."

And critically: no hello.js was updated. With errors present, this compile produced nothing new to run. Wrong programs don't ship — the playgrounds on this site behave the same way, which you saw in 1.1.

Try it — the same loop, one button

This playground is that whole terminal loop compressed: Run = check, then (only if clean) execute the erased JavaScript. Run it as-is, then follow the break-it comment and study the diagnostic — same anatomy you just learned.

typescript — playgroundtype-checked
⌘/Ctrl + Enter to run

tsc --noEmit — the checker as a test

One more flag completes your toolkit. Most real projects don't use tsc to produce JavaScript at all — faster tools (or Node itself, per 1.4) do the running. They use the compiler purely as a verifier:

npx tsc --noEmit
# no output files — exit code 0 if the types check, 1 if not

That's type checking as a test suite you never had to write: point it at the project, get a pass/fail. It's the command CI pipelines run on every push (Section 19 wires that up), and the habit from 1.4's loop — run it before you commit.

You now have the full mental model: a type layer you write, a checker that verifies it, and an eraser that deletes it. Next section we zoom into the layer itself — starting with the annotation syntax and the inference engine that means you'll write far fewer annotations than you think.

Checkpoint

Answer all three to mark this lesson complete

+50 XP on completion