[RFC] Validation Plugin System

[Evanion]

[RFC] Validation Plugin System

Overview

Validation is a common requirement in modern applications, but the ecosystem is split between class-based (e.g., class-validator) and schema-based (e.g., Zod, Yup) libraries. Many frameworks hardwire a specific validation library, but this can be limiting and increase bundle size or dependencies.

For NexusDI, the goal is to provide a validation plugin system that is:

• Agnostic: Works with any validation library via adapters (resolvers)
• Extensible: New resolvers can be added as the ecosystem evolves
• Minimal: No validation logic in the DI core—everything is opt-in via plugins
• Declarative: Validation logic is close to business logic, easy to read and maintain

Proposed Features

• Register a ValidationPlugin via the use() method, specifying a resolver (adapter) for your preferred validation library
• Use a @Validate() decorator on method parameters or methods to trigger validation
  • On parameters: validates the argument before method execution
  • On methods: validates the return value after execution
• For schema-based libraries (Zod, Yup, etc.), the schema is provided to the decorator
• For class-based libraries (class-validator), the schema is inferred from the class metadata
• Resolvers are provided in a subpath (e.g., @nexusdi/validation/resolvers)
• Community or custom resolvers can be added for other libraries

Example Usage

// Registering a Zod adapter
import { ValidationPlugin } from '@nexusdi/validation';
import { zodResolver } from '@nexusdi/validation/resolvers';
container.use(ValidationPlugin, { resolver: zodResolver });

class UserService {
  createUser(@Validate(createUserSchema) data: CreateUserDto) { /* ... */ }

  @Validate(profileSchema)
  getProfileFromBackend(id: string): Promise<Profile> {}
}

// Registering a class-validator adapter
import { ValidationPlugin } from '@nexusdi/validation';
import { classValidatorResolver } from '@nexusdi/validation/resolvers';
container.use(ValidationPlugin, { resolver: classValidatorResolver });

class UserDto {
  @IsString()
  name: string;
}

class UserService {
  createUser(@Validate() data: UserDto) { /* ... */ }

  @Validate()
  getProfileFromBackend(id: string): Promise<Profile> {}
}

API Design

• @Validate(schema?) can be used on parameters (for input validation) or on methods (for return value validation)
• The registered resolver handles the actual validation logic
• For schema-based libraries, the schema must be provided
• For class-based libraries, the schema is inferred from the parameter or return type

Extensibility

• New resolvers can be added for other libraries (Yup, Joi, Superstruct, custom, etc.)
• Community can contribute resolvers for their favorite libraries
• The core remains minimal and agnostic

Open Questions

• Should we support both parameter and method decorators, or just one?
• Should we allow multiple validation plugins/resolvers, or just one at a time?
• What should the error handling/exception contract look like?
• Should we provide built-in resolvers for Zod, Yup, class-validator, and others out of the box?
• Any other features or decorator options you’d want?

Call for Feedback

• Would you use this validation plugin system?
• Which validation libraries would you want adapters for?
• Do you prefer schema-based, class-based, or both?
• Any other features or decorator options you’d want?
• Any concerns about error handling, DX, or extensibility?