What types exist only at compile time in Typescript - Step-by-Step Execution

Concept Flow - What types exist only at compile time

Write TypeScript code with types

↓

Compiler checks types

↓

Types removed during compilation

↓

Output JavaScript without types

↓

Run JavaScript code at runtime

TypeScript types exist only during compilation to check code correctness and are removed before running JavaScript.

Execution Sample

Typescript

type User = { name: string; age: number };

function greet(user: User) {
  return `Hello, ${user.name}`;
}

const person = { name: "Alice", age: 30 };
greet(person);

Defines a type for a user object and uses it to check the function argument at compile time.

Execution Table

Step	Action	Type Check	Result
1	Define type User	User type created	No runtime code generated
2	Define function greet with User parameter	Parameter checked against User type	Function code generated (types erased)
3	Create object person with name and age	Object matches User type	Object created at runtime
4	Call greet(person)	Argument matches User type	Function runs, returns greeting string
5	Compile to JavaScript	Types removed	Output JS has no types
6	Run JavaScript code	No type checks	Outputs: Hello, Alice

💡 Compilation ends with types removed; runtime runs plain JavaScript without types

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
User	Type defined	Type exists only at compile time	Removed after compilation	No runtime presence
person	Undefined	{ name: 'Alice', age: 30 }	{ name: 'Alice', age: 30 }	Same object at runtime
greet	Function defined with type	Function exists	Returns 'Hello, Alice'	Function runs at runtime

Key Moments - 3 Insights

Why don't types appear in the final JavaScript code?

Types are only for compile-time checks and are removed during compilation, as shown in execution_table step 5.

Can types affect runtime behavior?

No, types do not exist at runtime and cannot change how the JavaScript runs, confirmed by step 6 in execution_table.

What happens if an object doesn't match the type?

The compiler shows an error before generating JavaScript, preventing runtime errors, as implied in step 2 and 3.

Visual Quiz - 3 Questions

Look at the execution_table at step 5, what happens to the types?

A They are converted to runtime checks

B They are removed from the output JavaScript

C They become variables in JavaScript

D They are ignored but stay in the code

💡 Hint

Check the 'Result' column in step 5 of execution_table

According to variable_tracker, what is the state of 'User' after compilation?

A It is removed and does not exist at runtime

B It becomes a JavaScript function

C It exists as a runtime object

D It is converted to a string

💡 Hint

Look at the 'User' row in variable_tracker under 'Final'

If the object 'person' did not match the 'User' type, what would happen during compilation?

A The types would be ignored and code runs

B The code would run but with warnings

C The compiler would show an error and stop

D The runtime would throw an error

💡 Hint

Refer to key_moments about type mismatch and execution_table steps 2 and 3

Concept Snapshot

TypeScript types exist only at compile time.
They help check code correctness before running.
Types are removed when compiling to JavaScript.
No types or checks remain at runtime.
Errors happen during compilation if types don't match.

Full Transcript

In TypeScript, types like 'User' exist only during compilation to check code correctness. When you write a function with typed parameters, the compiler verifies the arguments match the types. These types do not produce any JavaScript code and are removed during compilation. The final JavaScript runs without any type information or checks. If an object does not match the expected type, the compiler shows an error and stops before generating JavaScript. This ensures safer code without affecting runtime performance.

Practice

1. Which of the following TypeScript types exist only at compile time and do not produce any JavaScript code?

easy

A. Functions and variables

B. Classes and enums

C. Interfaces and type aliases

D. Objects and arrays

Solution

1. Step 1: Understand TypeScript compile-time types

   Interfaces and type aliases are used only to check types during compilation and do not exist in the final JavaScript.

2. Step 2: Identify runtime constructs

   Classes, enums, functions, variables, objects, and arrays exist in the JavaScript output and run at runtime.

3. Final Answer:

   Interfaces and type aliases -> Option C

4. Quick Check:

   Compile-time only types = Interfaces, type aliases [OK]

Hint: Remember: interfaces and types vanish after compiling [OK]

Common Mistakes:

• Thinking classes are compile-time only
• Confusing enums with type aliases
• Assuming variables are compile-time types

2. Which syntax correctly declares a type alias that exists only at compile time in TypeScript?

easy

A. type User = { name: string; age: number };

B. const User = { name: 'Alice', age: 30 };

C. class User { name: string; age: number; }

D. enum User { Name, Age }

Solution

1. Step 1: Identify type alias syntax

   Using type User = { ... } declares a type alias that exists only during compilation.

2. Step 2: Differentiate from runtime declarations

   Const objects, classes, and enums produce JavaScript code and exist at runtime.

3. Final Answer:

   type User = { name: string; age: number }; -> Option A

4. Quick Check:

   Type alias syntax = type ... = ... [OK]

Hint: Type aliases start with 'type' keyword [OK]

Common Mistakes:

• Using const or class instead of type alias
• Confusing enums with types
• Missing semicolon in type alias

3. What will be the output of the following TypeScript code when compiled and run in JavaScript?

interface Person { name: string; age: number; }
const p: Person = { name: 'Bob', age: 25 };
console.log(typeof Person);

medium

A. "undefined"

B. "object"

C. "function"

D. "string"

Solution

1. Step 1: Understand interface removal at compile time

   Interfaces do not exist in JavaScript output, so Person is not defined at runtime.

2. Step 2: Evaluate typeof on undefined identifier

   Using typeof Person when Person is not defined returns "undefined" as a string.

3. Final Answer:

   "undefined" -> Option A

4. Quick Check:

   Interfaces vanish, typeof interface = "undefined" [OK]

Hint: Interfaces disappear; typeof interface is undefined [OK]

Common Mistakes:

• Expecting 'object' because of interface
• Thinking interface is a function
• Confusing interface with class

4. Identify the error in this TypeScript code snippet:

type Animal = { species: string };
console.log(Animal);

medium

A. Missing semicolon after type declaration

B. Animal should be declared as an interface

C. Type alias syntax is incorrect

D. Animal is not defined at runtime, so console.log causes an error

Solution

1. Step 1: Recognize type alias compile-time only nature

   Type aliases do not exist in JavaScript, so Animal is not a runtime value.

2. Step 2: Understand console.log usage

   Trying to log Animal causes a runtime error because it is undefined in JavaScript.

3. Final Answer:

   Animal is not defined at runtime, so console.log causes an error -> Option D

4. Quick Check:

   Logging type alias = runtime error [OK]

Hint: Type aliases can't be used as runtime values [OK]

Common Mistakes:

• Thinking type aliases exist at runtime
• Ignoring runtime vs compile-time difference
• Assuming missing semicolon causes error

5. You want to create a function that accepts only objects matching a specific shape but does not add any runtime overhead. Which TypeScript feature should you use?

hard

A. Use a type alias and create a runtime object

B. Use an interface to define the object shape

C. Use a class to define the object shape

D. Use an enum to define the object shape

Solution

1. Step 1: Understand compile-time type checking

   Interfaces define object shapes only at compile time and do not generate JavaScript code, so no runtime overhead.

2. Step 2: Compare with other options

   Classes and enums generate runtime code; type aliases do not create runtime objects unless explicitly instantiated.

3. Final Answer:

   Use an interface to define the object shape -> Option B

4. Quick Check:

   Interfaces = compile-time only, no runtime overhead [OK]

Hint: Interfaces check shape without runtime cost [OK]

Common Mistakes:

• Using classes which add runtime code
• Confusing enums with object shapes
• Thinking type aliases create runtime objects