Type erasure and its consequences in Typescript - Deep Dive

Overview - Type erasure and its consequences

What is it?

Type erasure is a process where TypeScript removes all type information when converting code to JavaScript. This means types exist only during development and are not present at runtime. It helps catch errors early but does not affect the running program. The JavaScript code runs without any type checks or type data.

Why it matters

Type erasure exists because JavaScript, the language TypeScript compiles to, does not support types natively. Without type erasure, the extra type information would slow down or break the program. Without this concept, developers would lose the benefits of type safety during coding or face slower, more complex runtime code. It balances safety during development with performance and compatibility at runtime.

Where it fits

Before learning type erasure, you should understand TypeScript basics like types, interfaces, and how TypeScript compiles to JavaScript. After this, you can explore advanced topics like generics, decorators, and runtime type checking libraries that work around type erasure.

Mental Model

Core Idea

Type erasure means all type information disappears when TypeScript code turns into JavaScript, leaving only plain code to run.

Think of it like...

It's like writing a recipe with notes on ingredients and cooking times (types) but when you share the recipe, you only send the cooking steps without the notes. The notes help you cook better but aren't needed to follow the recipe.

TypeScript code with types
  ↓ (compilation)
JavaScript code without types

┌───────────────┐       ┌───────────────┐
│ let x: number │  →    │ let x = 5;    │
│ let y: string │       │ let y = 'hi'; │
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is TypeScript Compilation

Concept: TypeScript code is transformed into JavaScript code by a compiler.

TypeScript adds types to JavaScript to help catch errors early. When you write TypeScript, you use types like number, string, or custom interfaces. The TypeScript compiler then converts this code into plain JavaScript that browsers or Node.js can run.

Result

You get JavaScript code that runs everywhere but without any type information.

Understanding that TypeScript code is not directly run but converted helps grasp why types don't exist at runtime.

2

Foundation

Types Exist Only During Development

Concept: Types are used only while writing and checking code, not when the program runs.

When you write TypeScript, the compiler checks types to find mistakes. But after compiling, the output JavaScript has no types. This means types help you avoid bugs before running the program but do not affect the program's behavior.

Result

The running program behaves like normal JavaScript, ignoring types.

Knowing that types vanish after compilation explains why runtime errors related to types can still happen.

3

Intermediate

How Type Erasure Works in Practice

🤔Before reading on: do you think TypeScript keeps some type info in JavaScript or removes all? Commit to your answer.

Concept: Type erasure removes all type annotations, interfaces, and generics from the output code.

For example, a function with typed parameters and return type loses all type info after compilation. Only the function logic remains. This means you cannot check types at runtime unless you add extra code.

Result

Compiled JavaScript has no trace of TypeScript types, making it lightweight and compatible.

Understanding that type erasure removes all type info clarifies why runtime type checks need manual coding or libraries.

4

Intermediate

Consequences for Runtime Behavior

🤔Before reading on: do you think TypeScript types can prevent all runtime errors? Commit to your answer.

Concept: Because types are erased, runtime errors related to types can still occur if the code receives unexpected values.

For example, if a function expects a number but gets a string at runtime, JavaScript will not stop it. TypeScript helped during development but cannot enforce types when running.

Result

Runtime errors can happen despite TypeScript's compile-time checks.

Knowing this prevents overconfidence in TypeScript's safety and encourages runtime validation when needed.

5

Intermediate

Generics and Type Erasure

🤔Before reading on: do you think generic types exist in the compiled JavaScript? Commit to your answer.

Concept: Generic types are also erased, meaning the compiled code does not know about the specific types used.

Generics let you write flexible code that works with many types. But after compilation, the JavaScript code treats all generic types as normal variables without type info. This means you cannot check or reflect on generic types at runtime.

Result

Generics provide compile-time flexibility but no runtime type data.

Understanding this helps explain why some patterns require extra code to preserve type info at runtime.

6

Advanced

Workarounds for Type Erasure

🤔Before reading on: do you think it's possible to keep type info at runtime in TypeScript? Commit to your answer.

Concept: Developers use techniques like decorators, manual type tagging, or libraries to keep some type info at runtime despite erasure.

For example, decorators can add metadata to classes or properties that survive compilation. Libraries like 'io-ts' let you define runtime type checks that mirror TypeScript types. These approaches add code to check types during execution.

Result

You can regain some runtime type safety but with extra effort and code.

Knowing these workarounds reveals the tradeoff between TypeScript's simplicity and runtime type safety.

7

Expert

Impact on Performance and Tooling

🤔Before reading on: do you think keeping types at runtime would slow down JavaScript? Commit to your answer.

Concept: Type erasure keeps JavaScript fast and small by removing type checks, but it limits runtime introspection and debugging.

If TypeScript kept types at runtime, the JavaScript code would be larger and slower because it would need to check types constantly. This would hurt performance and compatibility with existing JavaScript tools. Instead, TypeScript focuses on compile-time safety and leaves runtime checks optional.

Result

Type erasure balances developer safety with runtime efficiency.

Understanding this tradeoff explains why TypeScript chose erasure and why runtime type systems are separate.

Under the Hood

During compilation, the TypeScript compiler parses the code and removes all type annotations, interfaces, and type-only constructs. It transforms the code into plain JavaScript syntax that browsers and Node.js understand. This process is called type erasure because it erases all type information. The compiler does not generate any runtime code for types, so no type data exists when the program runs.

Why designed this way?

TypeScript was designed to add type safety without changing JavaScript's runtime behavior or performance. JavaScript engines do not support types, so embedding types would require a new runtime or slow down execution. Type erasure allows TypeScript to provide developer tools and safety while producing fast, compatible JavaScript. Alternatives like runtime type systems exist but add complexity and overhead, so TypeScript keeps them optional.

┌───────────────┐   parse & erase types   ┌───────────────┐
│ TypeScript    │ ───────────────────────▶ │ JavaScript    │
│ code with     │                         │ code without  │
│ types         │                         │ types         │
└───────────────┘                         └───────────────┘

Inside compiler:
[Parse] → [Remove types] → [Emit JS code]

Myth Busters - 4 Common Misconceptions

Quick: Does TypeScript add type checks to JavaScript at runtime? Commit yes or no.

Common Belief: TypeScript adds type checks that run when the program runs, preventing all type errors.

Reality: TypeScript only checks types during compilation; no type checks exist in the running JavaScript code.

Why it matters: Believing this causes developers to ignore runtime validation, leading to unexpected errors in production.

Quick: Do generic types exist in the compiled JavaScript? Commit yes or no.

Common Belief: Generic types remain in the JavaScript code and can be inspected or used at runtime.

Reality: Generics are erased like other types; the compiled code has no information about them.

Why it matters: This misconception leads to confusion when trying to use generics for runtime logic or debugging.

Quick: Does type erasure mean TypeScript types are useless? Commit yes or no.

Common Belief: Since types disappear at runtime, they don't provide real benefits.

Reality: Types help catch errors early during development, improving code quality and reducing bugs.

Why it matters: Underestimating types reduces motivation to use TypeScript properly, losing its main advantage.

Quick: Can you rely on TypeScript types to guarantee no runtime errors? Commit yes or no.

Common Belief: TypeScript types guarantee the program will never have type-related runtime errors.

Reality: TypeScript types reduce errors but cannot guarantee no runtime errors because types are erased.

Why it matters: Overconfidence in types can cause missing runtime checks and harder-to-debug failures.

Expert Zone

1

Type erasure means that advanced type features like conditional types or mapped types exist only at compile time and have no runtime representation.

2

Some patterns use type assertions or 'as' casting which bypass compile-time checks but do not affect runtime, potentially hiding bugs.

3

Decorators and metadata reflection APIs can partially restore type info at runtime but require explicit setup and increase code size.

When NOT to use

TypeScript's type erasure is not suitable when you need full runtime type safety or reflection, such as in serialization, validation, or dynamic type-based logic. In those cases, use runtime type libraries like 'io-ts', 'zod', or manual runtime checks.

Production Patterns

In production, developers often combine TypeScript for compile-time safety with runtime validation libraries to ensure data correctness. They also use decorators or metadata to enable frameworks like Angular to perform dependency injection and validation despite type erasure.

Connections

Static vs Dynamic Typing

Type erasure is a key difference between static typing (TypeScript) and dynamic typing (JavaScript).

Understanding type erasure clarifies how static types help during development but do not change dynamic runtime behavior.

Compile-Time vs Runtime

Type erasure separates compile-time checks from runtime execution.

Knowing this distinction helps developers design systems that balance early error detection with runtime flexibility.

Data Validation in Security

Type erasure means runtime validation is needed to secure programs against invalid or malicious input.

Recognizing this connection highlights why security practices must include runtime checks beyond compile-time types.

Common Pitfalls

#1 Assuming TypeScript types prevent all runtime errors.

Wrong approach:

function greet(name: string) { console.log('Hello ' + name.toUpperCase()); }
greet(123); // TypeScript error ignored or bypassed

Correct approach:

function greet(name: string) { if (typeof name !== 'string') throw new Error('Invalid input'); console.log('Hello ' + name.toUpperCase()); }
greet(123); // Throws error at runtime

Root cause:

Misunderstanding that TypeScript types vanish at runtime and do not enforce type safety during execution.

#2 Trying to use generic type info at runtime directly.

Wrong approach:

function identity(arg: T): T { console.log(typeof T); return arg; }

Correct approach:

function identity(arg: T): T { console.log(typeof arg); return arg; }

Root cause:

Believing generic types exist at runtime, when in fact they are erased and only values remain.

#3 Ignoring runtime validation because TypeScript types exist.

Wrong approach:

function parseUser(data: any): User { return data; } // no runtime checks

Correct approach:

function parseUser(data: any): User { if (!data.name || typeof data.name !== 'string') throw new Error('Invalid user'); return data; }

Root cause:

Assuming compile-time types guarantee data correctness at runtime.

Key Takeaways

Type erasure means TypeScript removes all type information when compiling to JavaScript, so types exist only during development.

Because types vanish at runtime, TypeScript cannot prevent all runtime errors related to types.

Generics and interfaces are erased too, so no type info is available during program execution.

Developers must add runtime checks or use libraries to regain type safety after compilation.

Type erasure balances developer productivity with runtime performance and compatibility.

Practice

1. What does type erasure mean in TypeScript?

easy

A. TypeScript removes all type information when compiling to JavaScript.

B. TypeScript keeps all type information in the final JavaScript code.

C. TypeScript converts types into runtime checks automatically.

D. TypeScript adds extra type annotations in the JavaScript output.

Solution

1. Step 1: Understand TypeScript compilation

   TypeScript compiles to JavaScript by removing all type annotations and interfaces.

2. Step 2: Define type erasure meaning

   This removal of type info is called type erasure, meaning types exist only during development, not at runtime.

3. Final Answer:

   TypeScript removes all type information when compiling to JavaScript. -> Option A

4. Quick Check:

   Type erasure = types removed at compile time [OK]

Hint: Remember: TypeScript types vanish in JavaScript output [OK]

Common Mistakes:

• Thinking types exist at runtime
• Believing TypeScript adds runtime type checks
• Confusing type erasure with type inference

2. Which of the following is the correct way to check a variable's type at runtime in TypeScript?

easy

A. Using typeof operator in JavaScript code.

B. Using TypeScript type annotations like string in if statements.

C. Using TypeScript interfaces to check types at runtime.

D. Using instanceof with TypeScript types.

Solution

1. Step 1: Recall type erasure effect

   TypeScript types do not exist at runtime, so you cannot use them in runtime checks.

2. Step 2: Identify runtime type check method

   JavaScript's typeof operator works at runtime to check primitive types like string or number.

3. Final Answer:

   Using typeof operator in JavaScript code. -> Option A

4. Quick Check:

   Runtime type check = typeof operator [OK]

Hint: Use JavaScript's typeof for runtime type checks [OK]

Common Mistakes:

• Trying to use TypeScript types at runtime
• Using interfaces for runtime checks
• Confusing instanceof with TypeScript types

3. What will be the output of this TypeScript code after compilation and running in JavaScript?

function isString(value: any): boolean {
  return typeof value === 'string';
}

console.log(isString(123));
console.log(isString('hello'));

medium

A. true\ntrue

B. false\nfalse

C. false\ntrue

D. TypeError at runtime

Solution

1. Step 1: Understand the function logic

   The function returns true if the input's JavaScript type is 'string', false otherwise.

2. Step 2: Evaluate the calls

   For 123, typeof is 'number', so returns false. For 'hello', typeof is 'string', so returns true.

3. Final Answer:

   false\ntrue -> Option C

4. Quick Check:

   typeof 123 = number (false), typeof 'hello' = string (true) [OK]

Hint: Check typeof results for each input value [OK]

Common Mistakes:

• Assuming TypeScript types affect runtime
• Expecting true for number input
• Confusing output order

4. Identify the error in this TypeScript code that tries to check if value is a number at runtime:

function checkNumber(value: any): boolean {
  if (value instanceof number) {
    return true;
  }
  return false;
}

medium

A. The function should use typeof value === 'number' instead.

B. The function should use value.constructor === Number.

C. The function is correct and will return true for numbers.

D. Using instanceof with a primitive type causes a runtime error.

Solution

1. Step 1: Understand instanceof usage

   instanceof works with objects, not primitive types like number.

2. Step 2: Identify error cause

   Using value instanceof number causes a runtime error because number is not a constructor function.

3. Final Answer:

   Using instanceof with a primitive type causes a runtime error. -> Option D

4. Quick Check:

   instanceof with primitives = error [OK]

Hint: Use typeof for primitives, not instanceof [OK]

Common Mistakes:

• Using instanceof with primitive types
• Thinking instanceof works like typeof
• Ignoring runtime errors from wrong instanceof usage

5. Given that TypeScript types are erased at runtime, how can you safely handle different input types in a function that accepts string | number and returns their length or value doubled?

function process(input: string | number) {
  // What is the best way to handle types here?
}

hard

A. Rely on TypeScript types only and assume input is always correct at runtime.

B. Use JavaScript runtime checks like typeof to distinguish types and process accordingly.

C. Use instanceof to check if input is a string or number.

D. Convert input to string and always return its length.

Solution

1. Step 1: Recall type erasure impact

   TypeScript types do not exist at runtime, so runtime checks must use JavaScript operators.

2. Step 2: Choose correct runtime check

   Using typeof lets you detect if input is 'string' or 'number' and handle each case safely.

3. Step 3: Avoid incorrect methods

   Relying only on TypeScript types or using instanceof with primitives is unsafe or incorrect.

4. Final Answer:

   Use JavaScript runtime checks like typeof to distinguish types and process accordingly. -> Option B

5. Quick Check:

   Runtime type safety = typeof checks [OK]

Hint: Always check types at runtime with typeof for unions [OK]

Common Mistakes:

• Assuming TypeScript types exist at runtime
• Using instanceof with primitives
• Ignoring runtime type checks