NestJS Code Review
Overview
This skill provides structured, comprehensive code review for NestJS applications. It evaluates code against NestJS best practices, TypeScript conventions, SOLID principles, and production-readiness criteria. The review produces actionable findings categorized by severity (Critical, Warning, Suggestion) with concrete code examples for improvements.
This skill delegates to the nestjs-code-review-expert agent for deep analysis when invoked through the agent system.
When to Use
- Reviewing NestJS controllers, services, modules, or providers before merging
- Validating proper use of decorators (
@Controller, @Injectable, @Module, etc.)
- Checking dependency injection patterns and provider scoping
- Reviewing REST API endpoints for standards compliance
- Evaluating error handling with exception filters
- Assessing guard and interceptor implementations
- Reviewing database integration (TypeORM, Prisma, Drizzle ORM)
- Validating DTO definitions and validation pipes
- After implementing new NestJS features or refactoring modules
- Checking microservices patterns (message/event patterns, transport layers)
Instructions
Identify Scope: Determine which NestJS files and modules are under review. Use glob and grep to discover controllers, services, modules, guards, interceptors, and pipes in the target area.
Analyze Module Structure: Verify proper module organization — each feature should have its own module with clearly defined imports, controllers, providers, and exports. Check for circular dependencies and proper module boundaries.
Review Dependency Injection: Validate that all injectable services use constructor injection. Check provider scoping (singleton, request, transient) matches the intended lifecycle. Ensure no direct instantiation bypasses the DI container.
Evaluate Controllers: Review HTTP method usage, route naming, status codes, request/response DTOs, validation pipes, and OpenAPI decorators. Confirm controllers are thin — business logic belongs in services.
Assess Services & Business Logic: Check that services encapsulate business logic properly. Verify error handling, transaction management, and proper separation from infrastructure concerns. Look for service methods that are too large or have too many responsibilities.
Check Security: Review guard implementations, authentication/authorization patterns, input validation with class-validator, and protection against common vulnerabilities (injection, XSS, CSRF).
Review Testing: Assess test coverage for controllers, services, guards, and pipes. Verify proper mocking strategies and that tests validate behavior, not implementation details.
Produce Review Report: Generate a structured report with severity-classified findings (Critical, Warning, Suggestion), positive observations, and prioritized recommendations with code examples.
Examples
Example 1: Reviewing a Controller
// ❌ Bad: Fat controller with business logic and missing validation
@Controller('users')
export class UserController {
constructor(private readonly userRepo: Repository<User>) {}
@Post()
async create(@Body() body: any) {
const user = this.userRepo.create(body);
return this.userRepo.save(user);
}
}
// ✅ Good: Thin controller with proper DTOs, validation, and service delegation
@Controller('users')
@ApiTags('Users')
export class UserController {
constructor(private readonly userService: UserService) {}
@Post()
@HttpCode(HttpStatus.CREATED)
@ApiOperation({ summary: 'Create a new user' })
@ApiResponse({ status: 201, type: UserResponseDto })
async create(
@Body(ValidationPipe) createUserDto: CreateUserDto,
): Promise<UserResponseDto> {
return this.userService.create(createUserDto);
}
}
Example 2: Reviewing Dependency Injection
// ❌ Bad: Direct instantiation bypasses DI
@Injectable()
export class OrderService {
private readonly logger = new Logger();
private readonly emailService = new EmailService();
async createOrder(dto: CreateOrderDto) {
this.emailService.send(dto.email, 'Order created');
}
}
// ✅ Good: Proper constructor injection
@Injectable()
export class OrderService {
private readonly logger = new Logger(OrderService.name);
constructor(
private readonly orderRepository: OrderRepository,
private readonly emailService: EmailService,
) {}
async createOrder(dto: CreateOrderDto): Promise<Order> {
const order = await this.orderRepository.create(dto);
await this.emailService.send(dto.email, 'Order created');
return order;
}
}
Example 3: Reviewing Error Handling
// ❌ Bad: Generic error handling with information leakage
@Get(':id')
async findOne(@Param('id') id: string) {
try {
return await this.service.findOne(id);
} catch (error) {
throw new HttpException(error.message, 500);
}
}
// ✅ Good: Domain-specific exceptions with proper HTTP mapping
@Get(':id')
async findOne(@Param('id', ParseUUIDPipe) id: string): Promise<UserResponseDto> {
const user = await this.userService.findOne(id);
if (!user) {
throw new NotFoundException(`User with ID ${id} not found`);
}
return user;
}
Example 4: Reviewing Guard Implementation
// ❌ Bad: Authorization logic in controller
@Get('admin/dashboard')
async getDashboard(@Req() req: Request) {
if (req.user.role !== 'admin') {
throw new ForbiddenException();
}
return this.dashboardService.getData();
}
// ✅ Good: Guard-based authorization with decorator
@Get('admin/dashboard')
@UseGuards(JwtAuthGuard, RolesGuard)
@Roles(Role.ADMIN)
async getDashboard(): Promise<DashboardDto> {
return this.dashboardService.getData();
}
Example 5: Reviewing Module Organization
// ❌ Bad: Monolithic module with everything
@Module({
imports: [TypeOrmModule.forFeature([User, Order, Product, Review])],
controllers: [UserController, OrderController, ProductController],
providers: [UserService, OrderService, ProductService, ReviewService],
})
export class AppModule {}
// ✅ Good: Feature-based module organization
@Module({
imports: [UserModule, OrderModule, ProductModule],
})
export class AppModule {}
@Module({
imports: [TypeOrmModule.forFeature([User])],
controllers: [UserController],
providers: [UserService, UserRepository],
exports: [UserService],
})
export class UserModule {}
Review Output Format
Structure all code review findings as follows:
1. Summary
Brief overview with an overall quality score (1-10) and key observations.
2. Critical Issues (Must Fix)
Issues that could cause security vulnerabilities, data corruption, or production failures.
3. Warnings (Should Fix)
Issues that violate best practices, reduce maintainability, or could lead to bugs.
4. Suggestions (Consider Improving)
Improvements for code readability, performance, or developer experience.
5. Positive Observations
Well-implemented patterns and good practices to acknowledge and encourage.
6. Recommendations
Prioritized next steps with code examples for the most impactful improvements.
Best Practices
- Controllers should be thin — delegate all business logic to services
- Use DTOs with class-validator for all request/response payloads
- Apply
ParseUUIDPipe, ParseIntPipe, etc. for parameter validation
- Use domain-specific exception classes extending
HttpException
- Organize code into feature modules with clear boundaries and exports
- Prefer constructor injection — never use
new for injectable services
- Apply guards for authentication and authorization, not inline checks
- Use interceptors for cross-cutting concerns (logging, caching, transformation)
- Add OpenAPI decorators (
@ApiTags, @ApiOperation, @ApiResponse) to all endpoints
- Write unit tests for services and integration tests for controllers
Constraints and Warnings
- Do not enforce a single ORM — the codebase may use TypeORM, Prisma, Drizzle, or MikroORM
- Respect existing project conventions even if they differ from NestJS defaults
- Focus on high-confidence issues — avoid false positives on style preferences
- When reviewing microservices patterns, consider transport-layer specific constraints
- Do not suggest architectural rewrites unless critical issues warrant them
References
See the references/ directory for detailed review checklists and pattern documentation:
references/patterns.md — NestJS best practice patterns with examples
references/anti-patterns.md — Common NestJS anti-patterns to flag during review
references/checklist.md — Comprehensive review checklist organized by area
1---2name: nestjs-code-review3description: Provides comprehensive code review capability for NestJS applications, analyzing controllers, services, modules, guards, interceptors, pipes, dependency injection, and database integration patterns. Use when reviewing NestJS code changes, before merging pull requests, after implementing new features, or for architecture validation. Triggers on "review NestJS code", "NestJS code review", "check my NestJS controller/service".4---56# NestJS Code Review78## Overview910This skill provides structured, comprehensive code review for NestJS applications. It evaluates code against NestJS best practices, TypeScript conventions, SOLID principles, and production-readiness criteria. The review produces actionable findings categorized by severity (Critical, Warning, Suggestion) with concrete code examples for improvements.1112This skill delegates to the `nestjs-code-review-expert` agent for deep analysis when invoked through the agent system.1314## When to Use1516- Reviewing NestJS controllers, services, modules, or providers before merging17- Validating proper use of decorators (`@Controller`, `@Injectable`, `@Module`, etc.)18- Checking dependency injection patterns and provider scoping19- Reviewing REST API endpoints for standards compliance20- Evaluating error handling with exception filters21- Assessing guard and interceptor implementations22- Reviewing database integration (TypeORM, Prisma, Drizzle ORM)23- Validating DTO definitions and validation pipes24- After implementing new NestJS features or refactoring modules25- Checking microservices patterns (message/event patterns, transport layers)2627## Instructions28291. **Identify Scope**: Determine which NestJS files and modules are under review. Use `glob` and `grep` to discover controllers, services, modules, guards, interceptors, and pipes in the target area.30312. **Analyze Module Structure**: Verify proper module organization — each feature should have its own module with clearly defined imports, controllers, providers, and exports. Check for circular dependencies and proper module boundaries.32333. **Review Dependency Injection**: Validate that all injectable services use constructor injection. Check provider scoping (singleton, request, transient) matches the intended lifecycle. Ensure no direct instantiation bypasses the DI container.34354. **Evaluate Controllers**: Review HTTP method usage, route naming, status codes, request/response DTOs, validation pipes, and OpenAPI decorators. Confirm controllers are thin — business logic belongs in services.36375. **Assess Services & Business Logic**: Check that services encapsulate business logic properly. Verify error handling, transaction management, and proper separation from infrastructure concerns. Look for service methods that are too large or have too many responsibilities.38396. **Check Security**: Review guard implementations, authentication/authorization patterns, input validation with class-validator, and protection against common vulnerabilities (injection, XSS, CSRF).40417. **Review Testing**: Assess test coverage for controllers, services, guards, and pipes. Verify proper mocking strategies and that tests validate behavior, not implementation details.42438. **Produce Review Report**: Generate a structured report with severity-classified findings (Critical, Warning, Suggestion), positive observations, and prioritized recommendations with code examples.4445## Examples4647### Example 1: Reviewing a Controller4849```typescript50// ❌ Bad: Fat controller with business logic and missing validation51@Controller('users')52export class UserController {53 constructor(private readonly userRepo: Repository<User>) {}5455 @Post()56 async create(@Body() body: any) {57 const user = this.userRepo.create(body);58 return this.userRepo.save(user);59 }60}6162// ✅ Good: Thin controller with proper DTOs, validation, and service delegation63@Controller('users')64@ApiTags('Users')65export class UserController {66 constructor(private readonly userService: UserService) {}6768 @Post()69 @HttpCode(HttpStatus.CREATED)70 @ApiOperation({ summary: 'Create a new user' })71 @ApiResponse({ status: 201, type: UserResponseDto })72 async create(73 @Body(ValidationPipe) createUserDto: CreateUserDto,74 ): Promise<UserResponseDto> {75 return this.userService.create(createUserDto);76 }77}78```7980### Example 2: Reviewing Dependency Injection8182```typescript83// ❌ Bad: Direct instantiation bypasses DI84@Injectable()85export class OrderService {86 private readonly logger = new Logger();87 private readonly emailService = new EmailService();8889 async createOrder(dto: CreateOrderDto) {90 this.emailService.send(dto.email, 'Order created');91 }92}9394// ✅ Good: Proper constructor injection95@Injectable()96export class OrderService {97 private readonly logger = new Logger(OrderService.name);9899 constructor(100 private readonly orderRepository: OrderRepository,101 private readonly emailService: EmailService,102 ) {}103104 async createOrder(dto: CreateOrderDto): Promise<Order> {105 const order = await this.orderRepository.create(dto);106 await this.emailService.send(dto.email, 'Order created');107 return order;108 }109}110```111112### Example 3: Reviewing Error Handling113114```typescript115// ❌ Bad: Generic error handling with information leakage116@Get(':id')117async findOne(@Param('id') id: string) {118 try {119 return await this.service.findOne(id);120 } catch (error) {121 throw new HttpException(error.message, 500);122 }123}124125// ✅ Good: Domain-specific exceptions with proper HTTP mapping126@Get(':id')127async findOne(@Param('id', ParseUUIDPipe) id: string): Promise<UserResponseDto> {128 const user = await this.userService.findOne(id);129 if (!user) {130 throw new NotFoundException(`User with ID ${id} not found`);131 }132 return user;133}134```135136### Example 4: Reviewing Guard Implementation137138```typescript139// ❌ Bad: Authorization logic in controller140@Get('admin/dashboard')141async getDashboard(@Req() req: Request) {142 if (req.user.role !== 'admin') {143 throw new ForbiddenException();144 }145 return this.dashboardService.getData();146}147148// ✅ Good: Guard-based authorization with decorator149@Get('admin/dashboard')150@UseGuards(JwtAuthGuard, RolesGuard)151@Roles(Role.ADMIN)152async getDashboard(): Promise<DashboardDto> {153 return this.dashboardService.getData();154}155```156157### Example 5: Reviewing Module Organization158159```typescript160// ❌ Bad: Monolithic module with everything161@Module({162 imports: [TypeOrmModule.forFeature([User, Order, Product, Review])],163 controllers: [UserController, OrderController, ProductController],164 providers: [UserService, OrderService, ProductService, ReviewService],165})166export class AppModule {}167168// ✅ Good: Feature-based module organization169@Module({170 imports: [UserModule, OrderModule, ProductModule],171})172export class AppModule {}173174@Module({175 imports: [TypeOrmModule.forFeature([User])],176 controllers: [UserController],177 providers: [UserService, UserRepository],178 exports: [UserService],179})180export class UserModule {}181```182183## Review Output Format184185Structure all code review findings as follows:186187### 1. Summary188Brief overview with an overall quality score (1-10) and key observations.189190### 2. Critical Issues (Must Fix)191Issues that could cause security vulnerabilities, data corruption, or production failures.192193### 3. Warnings (Should Fix)194Issues that violate best practices, reduce maintainability, or could lead to bugs.195196### 4. Suggestions (Consider Improving)197Improvements for code readability, performance, or developer experience.198199### 5. Positive Observations200Well-implemented patterns and good practices to acknowledge and encourage.201202### 6. Recommendations203Prioritized next steps with code examples for the most impactful improvements.204205## Best Practices206207- Controllers should be thin — delegate all business logic to services208- Use DTOs with class-validator for all request/response payloads209- Apply `ParseUUIDPipe`, `ParseIntPipe`, etc. for parameter validation210- Use domain-specific exception classes extending `HttpException`211- Organize code into feature modules with clear boundaries and exports212- Prefer constructor injection — never use `new` for injectable services213- Apply guards for authentication and authorization, not inline checks214- Use interceptors for cross-cutting concerns (logging, caching, transformation)215- Add OpenAPI decorators (`@ApiTags`, `@ApiOperation`, `@ApiResponse`) to all endpoints216- Write unit tests for services and integration tests for controllers217218## Constraints and Warnings219220- Do not enforce a single ORM — the codebase may use TypeORM, Prisma, Drizzle, or MikroORM221- Respect existing project conventions even if they differ from NestJS defaults222- Focus on high-confidence issues — avoid false positives on style preferences223- When reviewing microservices patterns, consider transport-layer specific constraints224- Do not suggest architectural rewrites unless critical issues warrant them225226## References227228See the `references/` directory for detailed review checklists and pattern documentation:229- `references/patterns.md` — NestJS best practice patterns with examples230- `references/anti-patterns.md` — Common NestJS anti-patterns to flag during review231- `references/checklist.md` — Comprehensive review checklist organized by area