intermediate30 minby DevFox

Runtime Versus Compile Time

Types are erased before your code runs. What that means for validation, reflection and generics, and the checks people expect the type system to perform at runtime.

TypeScript
Types

Four things this course has told you do not work, and one explanation covering all of them.

You cannot check value instanceof MyType for a type alias. You cannot ask what T is inside a generic function. A validated Photo from response.json() is not validated. And a branded AccountId is an ordinary string once the program starts.

By the end of this lesson you will know exactly what survives compilation and what does not, so that these stop being four separate surprises and become one fact you can reason from.

The line

typescript

type Photo = { id: string; size: number };

interface Uploader {
  upload(photo: Photo): Promise<void>;
}

enum Status {
  Done = "done",
}

class PhotoStore {
  constructor(private readonly limit: number) {}
}

const photo: Photo = { id: "a", size: 1 };

Compiled:

javascript

var Status;
(function (Status) {
  Status["Done"] = "done";
})(Status || (Status = {}));

class PhotoStore {
  constructor(limit) {
    this.limit = limit;
  }
}

const photo = { id: "a", size: 1 };

The type and the interface are gone entirely. The private and readonly modifiers are gone. Photo as an annotation is gone.

Erased

Instructions to the checker.

Type aliases, interfaces, type annotations, generic parameters, access modifiers, satisfies, as and !.

Every one of them is deleted the moment the checker has finished reading it.

Survives

Actual JavaScript.

Classes and enums, plus everything you would have written in plain JavaScript anyway — const, let, function, and the values themselves.

Enums and classes are the only TypeScript-specific constructs that produce output

That is the single fact. Every consequence below follows from it.

Checking a type at runtime

Bad — a check against something that no longer exists.

typescript

type Photo = { id: string; size: number };

function process(value: unknown) {
  if (value instanceof Photo) {         // Photo is not a value
    ...
  }
}

Good — checking the shape.

typescript

function isPhoto(value: unknown): value is Photo {
  return (
    typeof value === "object" &&
    value !== null &&
    typeof (value as Record<string, unknown>).id === "string" &&
    typeof (value as Record<string, unknown>).size === "number"
  );
}

The first does not compile — Photo is a type, not a value, so there is nothing to put on the right of instanceof. That error is the language telling you the truth: you asked to check something that will not be there.

The second inspects what actually exists at runtime — an object with properties — and the value is Photo predicate is how you report the result back to the checker.

instanceof works for classes, because a class survives:

That is why the errors lesson recommended classes for errors specifically. It is the one place the runtime and the type system agree about identity.

Generics have no value at runtime

There is no way to ask what T is. The function body is identical for every call, and the as T is an assertion with nothing behind it — the generic makes an unchecked cast look like a feature, as the generics lesson argued.

When behaviour must depend on the type, pass a value:

The schema exists at runtime and does the checking. T is inferred from it, so the caller writes no type argument and gets a checked result rather than an asserted one.

That is the general shape: if you need a type at runtime, you need a value that represents it.

The four ways to say nothing

Every construct that overrides the checker is a compile-time statement with no runtime effect.

as and ! are you overruling the checker. satisfies verifies without widening — checked at compile time, emitting nothing.

So this compiles cleanly and crashes:

Which is the boundary lesson's point, now with the mechanism underneath it: the assertion was a note to a program that had already stopped running.

Erasure changes what you can build

Several patterns from other languages are unavailable, and knowing why saves you looking.

Overloading by type
Overload signatures describe one implementation, and that implementation has to tell the cases apart itself.
Reflection over types
No listing a type's properties, no constructing one from its name. Tools that appear to do this read your source at build time or use a runtime value instead.
Decorator metadata
Needs an explicit library, because the type information is not there to read.
Telling identical shapes apart
Meters and Feet as bare number aliases are the same type everywhere — which is exactly what branding was for.

All four are the same absence: at runtime there is no type to consult

The first one, since the syntax exists and misleads people:

Three signatures, one function body, and the body doing the distinguishing by hand.

Getting values from types

Since types cannot be read at runtime, derive the value and the type from one source. Two patterns cover nearly everything.

A constant array, with the union derived:

One declaration gives a runtime list, a compile-time union, and a checked predicate.

A schema, with the type inferred:

The schema is a value that exists at runtime and can check things. The type comes from it, so they cannot disagree.

Both invert the usual direction — the value is the source, and the type is derived — which is the reliable way to have something in both worlds.

A cheat sheet to keep

Where to go next

Four separate surprises are now one fact: types are instructions to a checker that finishes before your program starts. The practical rule that follows is short — when you need something at runtime, make it a value first and derive the type from it.

Next is TypeScript in CI, the closing lesson of this course. It ties together the checks these lessons have introduced — type checking, linting, tests, builds — into a gate that runs on every change and stays fast enough that nobody works around it.

Before you move on, take any as SomeType in your code and ask what would happen if the value were the wrong shape. In every case the answer is the same — nothing, until something much later fails — and that is the whole of this lesson in one question.