NestJS

nestjsBackend33 lines

TypeScript server framework with dependency injection, modules and decorators.

Current — as published in v1.3.2. Written by hand for NestJS, not generated.
This rule adapts to the rest of your stack. The text below is shown for a project that selected the companion module; a different selection changes a sentence or two.

The rule

Validation

  • ValidationPipe is registered globally with whitelist: true and forbidNonWhitelisted: true. Without whitelist, unknown properties in the body reach your service — that is how a profile update smuggles in role.
  • DTOs are classes with `class-validator` decorators. An interface does not exist at runtime and validates nothing.

Auth

  • Guards, applied globally, with public routes opted out explicitly. Per-route guards mean the one you forget is the one that leaks.
  • Never take a user id from the request body; derive it from the verified token.

Structure

  • Controllers are thin: parse, delegate to a service, return.
  • Business logic lives in providers so it can be tested without HTTP.
  • One module per feature; export only what other modules genuinely need.

Responses

  • Map entities to response DTOs. Returning an ORM entity serialises whatever is on it, including fields no client should see.
  • Never return a raw error or stack trace to a client.

Never

  • Never put an interface where a DTO class belongs.
  • Never disable whitelist to make a request work — fix the DTO.
  • Never log secrets, tokens or personal data.

As each tool receives it

The same guidance, in the shape each editor reads. Cursor and Claude Code are written separately by hand; the rest are derived from the Cursor rule.

.cursor/rules/nestjs.mdchand-written for this tool
.cursor/rules/nestjs.mdc
---
description: NestJS conventions
globs: ["src/**/*.controller.ts", "src/**/*.service.ts", "src/**/*.module.ts", "src/**/dto/**"]
alwaysApply: false
---

# NestJS

## Validation

- `ValidationPipe` is registered globally with `whitelist: true` and
  `forbidNonWhitelisted: true`. Without `whitelist`, unknown properties in the
  body reach your service — that is how a profile update smuggles in `role`.
- **DTOs are classes with `class-validator` decorators.** An interface does not
  exist at runtime and validates nothing.

## Auth

- Guards, applied globally, with public routes opted out explicitly. Per-route
  guards mean the one you forget is the one that leaks.
- Never take a user id from the request body; derive it from the verified token.

## Structure

- Controllers are thin: parse, delegate to a service, return.
- Business logic lives in providers so it can be tested without HTTP.
- One module per feature; export only what other modules genuinely need.

## Responses

- Map entities to response DTOs. Returning an ORM entity serialises whatever is
  on it, including fields no client should see.
- Never return a raw error or stack trace to a client.

## Never

- Never put an interface where a DTO class belongs.
- Never disable `whitelist` to make a request work — fix the DTO.
- Never log secrets, tokens or personal data.

What else this module writes

Selecting NestJS contributes more than a rule file — all of it merged with every other module you pick, with conflicts resolved rather than duplicated.

Environment
PORToptionalPort the server listens on.
DATABASE_URLrequiredConnection string. Full access — never in a client.
JWT_SECRETrequiredSigns and verifies access tokens. Rotating it invalidates every session.
ALLOWED_ORIGINSrequiredComma-separated CORS origins. Never `*` with credentials.
Dependencies
@nestjs/core^11.1.0@nestjs/common^11.1.0@nestjs/platform-express^11.1.0@nestjs/config^4.0.0class-validator^0.15.0class-transformer^0.5.0reflect-metadata^0.2.0rxjs^7.8.0helmet^8.3.0@nestjs/cli^11.0.0dev@nestjs/testing^11.1.0dev
Folders
src/modules/src/common/guards/src/common/filters/src/config/test/

Related

Put this in your repo

Adds NestJS to a project this tool generated, without starting over. Files you have hand-edited are left alone.