TypeScript-first philosophy in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does NestJS use TypeScript types at runtime?

Consider a NestJS controller using TypeScript interfaces for request validation. What happens to these types when the app runs?

NestJS

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

@Controller('users')
export class UsersController {
  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return `User ${createUserDto.name} created`;
  }
}

A TypeScript types remain in the compiled code and throw errors if data doesn't match.

B TypeScript interfaces are compiled into JavaScript classes and checked automatically at runtime.

C TypeScript types are removed at runtime; NestJS uses decorators and validation pipes to enforce data shape.

D NestJS converts TypeScript types into JSON schemas and validates requests without extra code.

💡 Hint

Think about what happens to TypeScript types after compilation.

TypeScript types and interfaces are erased during compilation. NestJS relies on decorators and validation pipes (like class-validator) to check data at runtime.

📝 Syntax

intermediate

Which NestJS syntax correctly uses TypeScript decorators for dependency injection?

Identify the correct way to inject a service into a NestJS controller using TypeScript decorators.

A constructor(userService: UserService) { this.userService = userService; }

B constructor(@Inject(UserService) userService) { this.userService = userService; }

C constructor(@Injectable() userService: UserService) {}

D constructor(private readonly userService: UserService) {}

💡 Hint

Remember how NestJS uses TypeScript's parameter properties for injection.

Option D uses TypeScript's shorthand to declare and inject the service. Option D misses readonly and type declaration. Option D lacks decorators. Option D misuses @Injectable.

🔧 Debug

advanced

Why does this NestJS service fail to inject the repository?

Given this service code, why does NestJS throw a runtime error about missing provider?

NestJS

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  constructor(@InjectRepository(User) private userRepository: Repository<User>) {}

  findAll() {
    return this.userRepository.find();
  }
}

A The User entity is not included in the TypeOrmModule.forFeature() imports in the module.

B The @InjectRepository decorator is used incorrectly; it should be @InjectableRepository.

C The UsersService class is missing the @Controller decorator.

D The Repository type is not imported from '@nestjs/typeorm'.

💡 Hint

Check the module setup for repository injection.

To inject a repository, the entity must be registered in TypeOrmModule.forFeature() in the module. Without it, NestJS cannot provide the repository.

❓ state_output

advanced

What is the output of this NestJS controller method with TypeScript enums?

Given this enum and controller method, what will be returned when calling GET /status?

NestJS

enum Status {
  Active = 'active',
  Inactive = 'inactive',
  Pending = 'pending'
}

@Controller('status')
export class StatusController {
  @Get()
  getStatus(): string {
    const currentStatus: Status = Status.Active;
    return `Status is ${currentStatus}`;
  }
}

A "Status is Active"

B "Status is active"

C "Status is 0"

D "Status is Status.Active"

💡 Hint

Remember how string enums work in TypeScript.

String enums assign string values. Accessing Status.Active returns 'active', so the returned string is 'Status is active'.

🧠 Conceptual

expert

Why does NestJS recommend a TypeScript-first approach for DTOs and validation?

Choose the best explanation for why NestJS encourages defining DTOs with TypeScript classes and decorators instead of plain JavaScript objects.

A TypeScript classes with decorators enable automatic runtime validation and clear API contracts, improving maintainability and developer experience.

B Plain JavaScript objects are faster at runtime but harder to write, so NestJS avoids them.

C Using TypeScript classes forces the app to compile slower but produces smaller bundles.

D NestJS requires TypeScript classes because JavaScript objects cannot be serialized to JSON.

💡 Hint

Think about how decorators and TypeScript types help beyond just typing.

TypeScript classes combined with decorators allow NestJS to perform runtime validation (e.g., with class-validator), generate API docs, and provide clear, maintainable code. Plain objects lack these benefits.

Practice

1. What is the main benefit of the TypeScript-first philosophy in NestJS?

easy

A. It makes the app run faster at runtime.

B. It removes the need for any testing.

C. It helps catch errors early by using types.

D. It allows writing code without any types.

Solution

1. Step 1: Understand TypeScript's role

   TypeScript adds types to JavaScript, which helps find mistakes before running the code.

2. Step 2: Connect to NestJS philosophy

   NestJS uses TypeScript-first to improve code safety and clarity by leveraging types.

3. Final Answer:

   It helps catch errors early by using types. -> Option C

4. Quick Check:

   TypeScript-first = catch errors early [OK]

Hint: TypeScript-first means using types to find errors early [OK]

Common Mistakes:

• Thinking it makes runtime faster
• Believing it removes need for tests
• Assuming it means no types needed

2. Which of the following is the correct way to define a typed controller method in NestJS using TypeScript-first philosophy?

easy

A. async getUser(): Promise<User> { return this.userService.find(); }

B. async getUser() { return this.userService.find(); }

C. async getUser(): any { return this.userService.find(); }

D. async getUser(): string { return this.userService.find(); }

Solution

1. Step 1: Check method return type

   TypeScript-first means explicitly typing the return value, here Promise<User>.

2. Step 2: Compare options

   async getUser(): Promise<User> { return this.userService.find(); } uses correct typing; others omit or use wrong types like any or string.

3. Final Answer:

   async getUser(): Promise<User> { return this.userService.find(); } -> Option A

4. Quick Check:

   Explicit return type = async getUser(): Promise<User> { return this.userService.find(); } [OK]

Hint: Always specify method return types explicitly [OK]

Common Mistakes:

• Omitting return type annotation
• Using 'any' instead of specific types
• Using wrong return types like string

3. Given this NestJS service method using TypeScript-first philosophy:

async findUser(id: number): Promise {
  const user = await this.userRepository.findOneBy({ id });
  return user ?? null;
}

What is the type of the value returned when no user is found?

medium

A. undefined

B. an empty object {}

C. throws an error

D. null

Solution

1. Step 1: Analyze return statement

   The method returns user ?? null, which means if user is nullish, return null.

2. Step 2: Understand nullish coalescing

   If findOneBy returns undefined, the expression returns null explicitly.

3. Final Answer:

   null -> Option D

4. Quick Check:

   Nullish coalescing returns null if no user [OK]

Hint: ?? operator returns right side if left is null or undefined [OK]

Common Mistakes:

• Assuming undefined is returned
• Thinking an error is thrown
• Expecting empty object instead of null

4. Identify the error in this NestJS controller method using TypeScript-first philosophy:

@Get(':id')
async getUser(@Param('id') id: string): Promise<User> {
  return this.userService.findUser(id);
}

medium

A. The method should not be async if it returns a Promise.

B. The return type should be Promise if user might not exist.

C. The parameter id should be typed as number not string.

D. The decorator @Get is missing a path.

Solution

1. Step 1: Check return type correctness

   If findUser can return null when user not found, the controller must reflect that in its return type.

2. Step 2: Compare options

   The return type should be Promise if user might not exist. correctly points out the return type should allow null. The parameter id should be typed as number not string. is not always true because id can be string if parsed later.

3. Final Answer:

   The return type should be Promise if user might not exist. -> Option B

4. Quick Check:

   Return type must match possible null values [OK]

Hint: Return types must include null if possible [OK]

Common Mistakes:

• Ignoring possible null return
• Thinking async keyword is wrong here
• Assuming @Get needs path always

5. You want to create a NestJS DTO (Data Transfer Object) that enforces a required name string and an optional age number using TypeScript-first philosophy. Which of these is the best TypeScript definition?

hard

A. export class CreateUserDto { name: string; age?: number; }

B. export interface CreateUserDto { name?: string; age: number; }

C. export type CreateUserDto = { name?: string; age?: number; };

D. export class CreateUserDto { name?: string; age: number; }

Solution

1. Step 1: Identify required and optional properties

   The name must be required (no question mark), age optional (with question mark).

2. Step 2: Match with options

   export class CreateUserDto { name: string; age?: number; } correctly defines name as required and age as optional in a class, which is standard for NestJS DTOs.

3. Final Answer:

   export class CreateUserDto { name: string; age?: number; } -> Option A

4. Quick Check:

   Required name, optional age = export class CreateUserDto { name: string; age?: number; } [OK]

Hint: Use '?' for optional properties, omit for required [OK]

Common Mistakes:

• Marking required fields as optional
• Using interface instead of class for DTO
• Making optional fields required