
Nestjs Patterns
Scaffold production-grade NestJS modules, validation, guards, and config patterns while you build a TypeScript API as a solo developer.
Overview
NestJS Patterns is an agent skill for the Build phase that applies production-grade NestJS module, DTO, guard, interceptor, and configuration patterns for TypeScript backends.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill nestjs-patternsWhat is this skill?
- Feature-module layout with common/ for filters, guards, interceptors, and pipes
- Global ValidationPipe bootstrap with whitelist and transform
- DTO validation patterns colocated per module
- Guards, interceptors, and exception filters in common/
- Environment-aware configuration and validation modules
- Documented src/ tree spans app bootstrap, common/, config/, feature modules, and prisma/database
- When to Activate lists five trigger areas including modules, DTO validation, guards, config, and testing
Adoption & trust: 3.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your NestJS repo is growing messy modules, ad-hoc validation, and guards scattered outside a repeatable feature-module layout.
Who is it for?
Solo builders shipping a NestJS REST or GraphQL API who want ECC-style structure before adding payments, webhooks, or multi-tenant features.
Skip if: Greenfield teams committed to serverless-only Lambdas, non-TypeScript stacks, or tiny scripts without Nest’s module overhead.
When should I use this skill?
Building NestJS APIs or services; structuring modules, controllers, and providers; adding DTO validation, guards, interceptors, or exception filters; configuring environment-aware settings and database integrations; test
What do I get? / Deliverables
You get a consistent src/ module map, global validation bootstrap, and cross-cutting common/ patterns ready to extend with auth, users, and database integration tests.
- Feature-module folder layout and bootstrap snippet
- DTO, guard, interceptor, and config patterns aligned to modules
Recommended Skills
Journey fit
NestJS structure and cross-cutting concerns belong squarely in the Build phase when the product backend is taking shape. Backend subphase is the canonical home for modular controllers, providers, DTOs, and database wiring—not frontend or ship-time perf tuning alone.
How it compares
Opinionated NestJS architecture playbook—not a generic Node/Express starter or Prisma-only migration skill.
Common Questions / FAQ
Who is nestjs-patterns for?
Indie developers and small teams building TypeScript APIs with NestJS who want module boundaries, validation, and testing patterns without hiring a platform engineer.
When should I use nestjs-patterns?
Use it during Build/backend when creating Nest APIs, splitting feature modules, adding DTO validation, guards, interceptors, config validation, or endpoint tests.
Is nestjs-patterns safe to install?
It is procedural documentation from the ECC repo; review the Security Audits panel on this Prism page and your own dependency choices (Prisma, auth strategies) before applying snippets.
SKILL.md
READMESKILL.md - Nestjs Patterns
# NestJS Development Patterns Production-grade NestJS patterns for modular TypeScript backends. ## When to Activate - Building NestJS APIs or services - Structuring modules, controllers, and providers - Adding DTO validation, guards, interceptors, or exception filters - Configuring environment-aware settings and database integrations - Testing NestJS units or HTTP endpoints ## Project Structure ```text src/ ├── app.module.ts ├── main.ts ├── common/ │ ├── filters/ │ ├── guards/ │ ├── interceptors/ │ └── pipes/ ├── config/ │ ├── configuration.ts │ └── validation.ts ├── modules/ │ ├── auth/ │ │ ├── auth.controller.ts │ │ ├── auth.module.ts │ │ ├── auth.service.ts │ │ ├── dto/ │ │ ├── guards/ │ │ └── strategies/ │ └── users/ │ ├── dto/ │ ├── entities/ │ ├── users.controller.ts │ ├── users.module.ts │ └── users.service.ts └── prisma/ or database/ ``` - Keep domain code inside feature modules. - Put cross-cutting filters, decorators, guards, and interceptors in `common/`. - Keep DTOs close to the module that owns them. ## Bootstrap and Global Validation ```ts async function bootstrap() { const app = await NestFactory.create(AppModule, { bufferLogs: true }); app.useGlobalPipes( new ValidationPipe({ whitelist: true, forbidNonWhitelisted: true, transform: true, transformOptions: { enableImplicitConversion: true }, }), ); app.useGlobalInterceptors(new ClassSerializerInterceptor(app.get(Reflector))); app.useGlobalFilters(new HttpExceptionFilter()); await app.listen(process.env.PORT ?? 3000); } bootstrap(); ``` - Always enable `whitelist` and `forbidNonWhitelisted` on public APIs. - Prefer one global validation pipe instead of repeating validation config per route. ## Modules, Controllers, and Providers ```ts @Module({ controllers: [UsersController], providers: [UsersService], exports: [UsersService], }) export class UsersModule {} @Controller('users') export class UsersController { constructor(private readonly usersService: UsersService) {} @Get(':id') getById(@Param('id', ParseUUIDPipe) id: string) { return this.usersService.getById(id); } @Post() create(@Body() dto: CreateUserDto) { return this.usersService.create(dto); } } @Injectable() export class UsersService { constructor(private readonly usersRepo: UsersRepository) {} async create(dto: CreateUserDto) { return this.usersRepo.create(dto); } } ``` - Controllers should stay thin: parse HTTP input, call a provider, return response DTOs. - Put business logic in injectable services, not controllers. - Export only the providers other modules genuinely need. ## DTOs and Validation ```ts export class CreateUserDto { @IsEmail() email!: string; @IsString() @Length(2, 80) name!: string; @IsOptional() @IsEnum(UserRole) role?: UserRole; } ``` - Validate every request DTO with `class-validator`. - Use dedicated response DTOs or serializers instead of returning ORM entities directly. - Avoid leaking internal fields such as password hashes, tokens, or audit columns. ## Auth, Guards, and Request Context ```ts @UseGuards(JwtAuthGuard, RolesGuard) @Roles('admin') @Get('admin/report') getAdminReport(@Req() req: AuthenticatedRequest) { return this.reportService.getForUser(req.user.id); } ``` - Keep auth strategies and guards module-local unless they are truly shared. - Encode coarse access rules in guards, then do resource-specific authorization in services. - Prefer explicit request types for authenticated request objects. ## Exception Filters and Error Shape ```ts @Catch() export class HttpExceptionFilter implements ExceptionFilter { catch(exception: unknown, host: ArgumentsHost) { const resp