v1.5.0

What's Changed

This release adds flexible validation error handling for class-validator / NestJS ValidationPipe, shipped via a new optional subpath export nest-problem-details-filter/class-validator-mappers. It supports three progressively more structured approaches — from zero-config string arrays to full RFC 9457 JSON Pointer compliance — without breaking existing consumers.

Features

• Validation error mapping helpers (#34) — new nest-problem-details-filter/class-validator-mappers subpath export with three utilities:

  Field-map approach — per-field Record<string, string[]> with dotted-path nesting:

  import { mapClassValidatorErrors } from 'nest-problem-details-filter/class-validator-mappers';
  
  new ValidationPipe({
    exceptionFactory: (e) =>
      new BadRequestException({
        message: 'Validation failed',
        errors: mapClassValidatorErrors(e),
      }),
  });

  JSON Pointer approach — strict RFC 9457 compliance with pointer arrays:

  import { mapToPointerErrors } from 'nest-problem-details-filter/class-validator-mappers';
  
  new ProblemDetailsException({
    status: 400,
    title: 'Validation Failed',
    type: 'validation-error',
    errors: mapToPointerErrors(e),
  });

  One-liner shorthand — toValidationProblemDetails() wraps the field-map or pointer logic and returns a ready-to-throw ProblemDetailsException:

  import { toValidationProblemDetails } from 'nest-problem-details-filter/class-validator-mappers';
  
  // Field-map (default)
  new ValidationPipe({
    exceptionFactory: (e) => toValidationProblemDetails(e),
  });
  
  // RFC 9457 JSON Pointer array
  new ValidationPipe({
    exceptionFactory: (e) => toValidationProblemDetails(e, { usePointers: true }),
  });

  All helpers use the real class-validator ValidationError type (no duck-typing), flatten nested objects (e.g. address.street), and surface custom validator messages alongside built-in constraints.

• errors extension member support — HttpExceptionFilter now detects string[] messages from Nest's default ValidationPipe and places them in the errors field (per RFC 9457 §3.1.4), instead of concatenating into detail. It also passes through explicit errors objects from custom exceptionFactory implementations.

• IExceptionResponse relaxed message type — message now accepts string | string[], matching NestJS HttpException runtime behavior and the default ValidationPipe output shape.

• class-validator as optional peer dependency — declared in peerDependenciesMeta so the core filter remains zero-runtime-dependency. Users who opt into validation helpers install class-validator alongside the filter.

• Comprehensive test coverage — 253 tests, 100% coverage across all metrics, including nested DTO flattening and custom registerDecorator validators in both Express and Fastify integration suites.

• Dev mock server + OpenAPI playground (#33) — pnpm run dev:mock spins up a local NestJS app with all problem detail endpoints exposed; Swagger UI auto-documents @ApiProblemResponse and the new validation examples.

Fixes

• Import path consistency — corrected stale nest-problem-details-filter/class-validator paths in README and docs/usage.md to the final nest-problem-details-filter/class-validator-mappers subpath.

Changes

• src/validation → src/class-validator-mappers — directory renamed for clarity; the old name implied built-in validation logic rather than optional mapping helpers.
• src/index.ts cleanup — validation helpers removed from the main barrel export to avoid forcing the class-validator type dependency on consumers who don't need it.
• Documentation — README and docs/usage.md updated with a dedicated "Validation errors" section covering all three approaches (default array, field-map via BadRequestException, and ProblemDetailsException with or without JSON Pointers).

Full Changelog: v1.4.0...v1.5.0