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.