Vendix Validation
Backend Default
Global validation is configured in apps/backend/src/main.ts with Nest ValidationPipe:
transform: true
whitelist: true
forbidNonWhitelisted: true
enableImplicitConversion: true
Design APIs assuming DTO validation runs before controller methods.
DTO Rules
- Use
class-validator decorators for shape, required fields, enums, lengths, arrays, and numeric bounds.
- Use
class-transformer for type conversion: @Type(() => Number), nested DTOs, arrays, and targeted @Transform().
- Prefer DTO validation for request structure and simple constraints.
- Keep business invariants in services after resource lookup and permission/context checks.
- Avoid hypothetical shared helpers unless they exist in the codebase.
Example patterns used in Vendix:
@IsOptional()
@Type(() => Number)
@IsInt()
store_id?: number;
@ValidateNested({ each: true })
@Type(() => LineItemDto)
items: LineItemDto[];
Service Validation Order
Use early returns/throws, but do not duplicate DTO validation unnecessarily:
- Auth/tenant context and permissions.
- Resource existence and ownership.
- Business state transitions.
- Cross-record or monetary consistency.
- Execute mutation.
Use VendixHttpException and domain error codes where available.
Frontend Forms
- Use Angular reactive forms.
- Use typed controls/getters when templates need strict
FormControl bindings.
- Use built-in
Validators for simple fields and custom validators for cross-field rules.
- Product pricing has real cross-field validators in the product module; prefer existing validators over new ad-hoc checks.
- On submit, mark controls touched and return early when invalid.
Related Skills
vendix-error-handling
vendix-angular-forms
vendix-backend-api