What survives compilation to JavaScript in Typescript - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output after TypeScript compiles this code?

Consider this TypeScript code snippet. What will be the output when the compiled JavaScript runs?

Typescript

const num: number = 5;
function greet(name: string): string {
  return `Hello, ${name}!`;
}
console.log(greet('Alice') + ' Number is ' + num);

A Hello, Alice! Number is undefined

B Compilation error due to type annotations

C Hello, Alice! Number is 5

D Hello, Alice! Number is num

💡 Hint

Type annotations are removed during compilation but variable values remain.

TypeScript removes type annotations during compilation. The variable 'num' and function 'greet' remain as normal JavaScript code, so the output is the concatenated string.

❓ Predict Output

intermediate

Which part of this TypeScript code is NOT present in the compiled JavaScript?

Look at this TypeScript code. After compilation, which part will NOT appear in the JavaScript output?

Typescript

interface Person {
  name: string;
  age: number;
}

const user: Person = { name: 'Bob', age: 30 };
console.log(user.name);

A The interface Person

B The object user

C The console.log statement

D The property user.name

💡 Hint

Interfaces are only for type checking and do not exist at runtime.

Interfaces are removed during compilation because they are only used for type checking. The object and console.log remain in the JavaScript output.

❓ Predict Output

advanced

What will this compiled JavaScript output?

Given this TypeScript code, what will the compiled JavaScript output when run?

Typescript

enum Color {
  Red,
  Green,
  Blue
}

console.log(Color.Green);

A "Green"

B 1

C undefined

D Compilation error

💡 Hint

Enums are compiled into objects with numeric values starting at 0.

TypeScript compiles enums into JavaScript objects with numeric values starting at 0. Color.Green is 1.

❓ Predict Output

advanced

What error does this compiled JavaScript produce?

This TypeScript code uses a type assertion. What happens when the compiled JavaScript runs?

Typescript

const someValue: unknown = "hello";
const strLength: number = (someValue as string).length;
console.log(strLength);

A undefined

B TypeError at runtime

C Compilation error

D 5

💡 Hint

Type assertions do not exist in JavaScript and do not affect runtime behavior.

Type assertions are removed during compilation. The JavaScript code accesses the length property of a string, so it prints 5.

❓ Predict Output

expert

What is the output of this TypeScript code after compilation and execution?

This TypeScript code uses a generic function and a type parameter. What will the compiled JavaScript output when run?

Typescript

function identity<T>(arg: T): T {
  return arg;
}

console.log(identity<number>(42));

A 42

B undefined

C Compilation error

D NaN

💡 Hint

Generics are removed during compilation and do not affect runtime.

Generics are erased during compilation. The function returns the argument as is, so the output is 42.

Practice

1. Which of the following TypeScript elements does NOT survive compilation to JavaScript?

easy

A. Interfaces

B. Functions

C. Classes

D. Variables

Solution

1. Step 1: Understand TypeScript compilation

   TypeScript removes type-only constructs like interfaces during compilation.

2. Step 2: Identify which elements remain

   Functions, classes, and variables are actual code and remain in JavaScript output.

3. Final Answer:

   Interfaces -> Option A

4. Quick Check:

   Interfaces are erased in JS output [OK]

Hint: Remember: types/interfaces vanish, code stays [OK]

Common Mistakes:

• Thinking interfaces generate JavaScript code
• Confusing types with variables
• Assuming classes disappear

2. Which of these TypeScript code snippets will produce JavaScript code after compilation?

easy

A. type User = { name: string };

B. function greet() { console.log('Hi'); }

C. type ID = number | string;

D. interface User { name: string }

Solution

1. Step 1: Identify code vs type declarations

   Types and interfaces are erased; only executable code remains.

2. Step 2: Check each option

   Only the function greet produces JavaScript code.

3. Final Answer:

   function greet() { console.log('Hi'); } -> Option B

4. Quick Check:

   Functions compile to JS code [OK]

Hint: Only executable code survives compilation [OK]

Common Mistakes:

• Assuming type aliases produce JS code
• Confusing interfaces with functions
• Thinking all declarations compile to JS

3. What will be the output JavaScript code after compiling this TypeScript snippet?

interface Person { name: string; age: number; }
const user: Person = { name: 'Alice', age: 30 };
console.log(user.name);

medium

A. const user = { name: 'Alice', age: 30 };
console.log(user.name);

B. interface Person { name: string; age: number; }
const user = { name: 'Alice', age: 30 };
console.log(user.name);

C. const user: Person = { name: 'Alice', age: 30 };
console.log(user.name);

D. SyntaxError: interface not allowed in JS

Solution

1. Step 1: Remove type-only declarations

   The interface Person is removed during compilation.

2. Step 2: Remove type annotations

   The variable user loses its : Person annotation.

3. Final Answer:

   const user = { name: 'Alice', age: 30 }; console.log(user.name); -> Option A

4. Quick Check:

   Types/interfaces removed, code remains [OK]

Hint: Types vanish, only code stays in JS output [OK]

Common Mistakes:

• Leaving interface in output
• Keeping type annotations in JS
• Expecting syntax errors for interfaces

4. Identify the error in this TypeScript code that prevents correct JavaScript output:

interface Data { id: number; }
function printId(data: Data) {
  console.log(data.id);
}
printId({ id: 5 });

medium

A. The interface Data causes a runtime error in JavaScript.

B. The type annotation data: Data is removed, so data.id is undefined.

C. The function printId is removed during compilation.

D. There is no error; the code compiles to valid JavaScript.

Solution

1. Step 1: Understand interface removal

   Interfaces are erased and do not cause runtime errors.

2. Step 2: Check function and parameter

   Type annotations are removed but the function and its logic remain intact.

3. Final Answer:

   There is no error; the code compiles to valid JavaScript. -> Option D

4. Quick Check:

   Interfaces vanish, functions remain [OK]

Hint: Interfaces don't cause runtime errors [OK]

Common Mistakes:

• Thinking interfaces cause runtime errors
• Believing type annotations remain in JS
• Assuming functions get removed

5. Given this TypeScript code, what will the compiled JavaScript output be?

type Status = 'success' | 'error';
class Response {
  constructor(public status: Status) {}
  print() {
    console.log(`Status: ${this.status}`);
  }
}
const res = new Response('success');
res.print();

hard

A. SyntaxError: Type aliases not allowed in JavaScript

B. type Status = 'success' | 'error';
class Response {
constructor(public status: Status) {}
print() {
console.log(`Status: ${this.status}`);
}
}
const res = new Response('success');
res.print();

C. class Response {
constructor(status) {
this.status = status;
}
print() {
console.log(`Status: ${this.status}`);
}
}
const res = new Response('success');
res.print();

D. class Response {
constructor() {}
print() {
console.log('Status unknown');
}
}
const res = new Response();
res.print();

Solution

1. Step 1: Remove type alias

   The type Status is erased during compilation.

2. Step 2: Remove parameter type annotation

   The constructor's public status: Status becomes status without type.

3. Step 3: Keep class and method code

   The class and method remain unchanged except for type removal.

4. Final Answer:

   class Response { constructor(status) { this.status = status; } print() { console.log(`Status: ${this.status}`); } } const res = new Response('success'); res.print(); -> Option C

5. Quick Check:

   Types removed, class code remains [OK]

Hint: Types vanish, classes and methods stay intact [OK]

Common Mistakes:

• Expecting type aliases in JS output
• Thinking constructor parameters keep types
• Assuming class code is removed