nestjs

NestJS

Build server-side Node apps the way NestJS intends: feature modules, providers wired through the DI container, controllers, and a cross-cutting layer bound at a deliberate scope. This skill is about Nest-specific mechanics — how DI scopes resolve, what order the request lifecycle runs in, where to bind guards/pipes/interceptors/filters, and how to test it with Test.createTestingModule.

Not this — route instead

• Bare Express/Fastify/http service, no @Module/@Injectable → ../nodejs/SKILL.md. Nest starts the moment the DI container appears.
• REST resource modeling, versioning, status codes, idempotency (framework-agnostic) → ../api-design/SKILL.md. Nest is where you implement those decisions.
• Designing the schema / writing queries / migrations → ../prisma-orm/SKILL.md. Injecting a repo or DataSource provider stays here; designing the table does not.
• Generic JS/TS test infra (Jest config, coverage thresholds, monorepo) → ../testing-web/SKILL.md. The Nest harness (TestingModule, overrideProvider, Supertest bootstrap) stays here.

Mental model

Everything is a provider in a directed DI graph. Modules draw the boundaries of that graph — a provider is only reachable where it is provided or imported. Cross-cutting concerns (guards, interceptors, pipes, filters) are decorators bound at a scope you choose: global, controller, or route. Get those three right and the rest is plumbing.

The request lifecycle runs in a fixed order. Memorize it — most "my guard can't see the validated body" bugs are an ordering misunderstanding:

req → middleware → guards → interceptors(pre) → pipes → handler → interceptors(post) → exception filters → res

So pipes run after guards (a guard cannot read a transformed DTO), and filters catch everything thrown downstream. Source: NestJS request-lifecycle docs.

Module design

One feature module per bounded context. Rules, each with its why:

• exports is the module's public API. A provider not exported is private to that module — that is the encapsulation, lean on it.
• imports brings in another module's exports; it does not re-declare providers. Re-declaring a provider in two modules gives you two singletons and silent state bugs.
• Keep AppModule thin. It wires feature modules and global config, nothing else. A god AppModule that declares every controller becomes an untestable circular-dependency magnet.
• Use a dynamic module (forRoot / forRootAsync) for configurable infrastructure (DB, cache, mailer) so consumers pass options instead of editing the module.