Nestjs Best Practices
Design NestJS modules, DI scopes, exception filters, validated DTOs, and Drizzle ORM wiring without common encapsulation and coupling mistakes.
Overview
nestjs-best-practices is an agent skill for the Build phase that applies official NestJS patterns for modular architecture, dependency injection, exception filters, DTO validation, and Drizzle ORM integration.
Install
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill nestjs-best-practicesWhat is this skill?
- Modular domain boundaries: export only needed providers; avoid casual `forwardRef()` circular dependency escapes
- Dependency injection scoping patterns aligned with official NestJS documentation
- Exception filter design for consistent HTTP error surfaces
- DTO validation with `class-validator` at API boundaries
- Drizzle ORM integration patterns inside NestJS services and repositories
- Five practice areas in overview: modules, DI scoping, exception filters, DTO validation, Drizzle integration
Adoption & trust: 968 installs on skills.sh; 271 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your NestJS app is growing into circular modules, leaky exports, and inconsistent validation or error handling across endpoints.
Who is it for?
Indie API builders starting a NestJS service or refactoring a monolith-style `AppModule` into feature modules with Drizzle.
Skip if: Non-Node backends, front-end-only stacks, or teams that only need generic TypeScript style guides without NestJS DI and module semantics.
When should I use this skill?
Designing or refactoring NestJS modules, providers, exception filters, DTO validation, or Drizzle ORM integration within NestJS applications.
What do I get? / Deliverables
You get module layouts, provider scoping, filters, and Drizzle boundaries that match NestJS documentation and keep domains testable and isolated.
- Refactored `@Module()` layouts with clear exports
- Exception filters and validated DTO classes aligned to NestJS docs
Recommended Skills
Journey fit
The skill applies while implementing or refactoring server-side NestJS structure before production hardening passes. Content targets modules, providers, controllers, persistence integration—core backend application architecture.
How it compares
Framework-scoped backend patterns skill—not a generic REST tutorial or an infrastructure deploy playbook.
Common Questions / FAQ
Who is nestjs-best-practices for?
Solo builders and small teams shipping NestJS APIs who want consistent module boundaries, validation, and ORM integration without rereading the entire docs site each sprint.
When should I use nestjs-best-practices?
During Build/backend while designing modules, implementing providers, creating exception filters, validating DTOs, integrating Drizzle, or reviewing NestJS code for structural anti-patterns.
Is nestjs-best-practices safe to install?
It is read/write coding guidance; allowed tools include Read, Write, Edit, Glob, Grep, and Bash—confirm agent permissions and review the Security Audits panel on this Prism page before install.
SKILL.md
READMESKILL.md - Nestjs Best Practices
# NestJS Best Practices ## Overview Grounded in the [Official NestJS Documentation](https://docs.nestjs.com/), this skill enforces modular architecture, dependency injection scoping, exception filters, DTO validation with `class-validator`, and Drizzle ORM integration patterns. ## When to Use - Designing/refactoring NestJS modules or dependency injection - Creating exception filters, validating DTOs, or integrating Drizzle ORM - Reviewing code for anti-patterns or onboarding to a NestJS codebase ## Instructions ### 1. Modular Architecture Follow strict module encapsulation. Each domain feature should be its own `@Module()`: - Export only what other modules need — keep internal providers private - Use `forwardRef()` only as a last resort for circular dependencies; prefer restructuring - Group related controllers, services, and repositories within the same module - Use a `SharedModule` for cross-cutting concerns (logging, configuration, caching) See `references/arch-module-boundaries.md` for enforcement rules. ### 2. Dependency Injection Choose the correct provider scope based on use case: | Scope | Lifecycle | Use Case | |-------------|------------------------------|---------------------------------------------| | `DEFAULT` | Singleton (shared) | Stateless services, repositories | | `REQUEST` | Per-request instance | Request-scoped data (tenant, user context) | | `TRANSIENT` | New instance per injection | Stateful utilities, per-consumer caches | - Default to `DEFAULT` scope — only use `REQUEST` or `TRANSIENT` when justified - Use constructor injection exclusively — avoid property injection - Register custom providers with `useClass`, `useValue`, `useFactory`, or `useExisting` See `references/di-provider-scoping.md` for enforcement rules. ### 3. Request Lifecycle Understand and respect the NestJS request processing pipeline: ``` Middleware → Guards → Interceptors (before) → Pipes → Route Handler → Interceptors (after) → Exception Filters ``` - **Middleware**: Cross-cutting concerns (logging, CORS, body parsing) - **Guards**: Authorization and authentication checks (return `true`/`false`) - **Interceptors**: Transform response data, add caching, measure timing - **Pipes**: Validate and transform input parameters - **Exception Filters**: Catch and format error responses ### 4. Error Handling Standardize error responses across the application: - Extend `HttpException` for HTTP-specific errors - Create domain-specific exception classes (e.g., `OrderNotFoundException`) - Implement a global `ExceptionFilter` for consistent error formatting - Use the Result pattern for expected business logic failures - Never silently swallow exceptions See `references/error-exception-filters.md` for enforcement rules. ### 5. Validation Enforce input validation at the API boundary: - Enable `ValidationPipe` globally with `transform: true` and `whitelist: true` - Decorate all DTO properties with `class-validator` decorators - Use `class-transformer` for type coercion (`@Type()`, `@Transform()`) - Create separate DTOs for Create, Update, and Response operations - Never trust raw user input — validate everything See `references/api-validation-dto.md` for enforcement rules. ### 6. Database Patterns (Drizzle ORM) Integrate Drizzle ORM following NestJS provider conventions: - Wrap the Drizzle client in an injectable provider - Use the Repository pattern for data access encapsulation - Def