# Validator type · @imqueue/validation

Source: https://imqueue.org/api/validation/latest/validation.validator/
Published: 2026-08-01
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/validation 1.1.0 — generated reference, not hand-written

What [validate()](https://imqueue.org/api/validation/latest/validation.validate/) and [validated()](https://imqueue.org/api/validation/latest/validation.validated/) accept for a single value: a Zod schema, a [validatable()](https://imqueue.org/api/validation/latest/validation.validatable/) class whose own field schemas should be used, or `null`/`undefined` to skip validation at that position.

**Signature:**

```typescript
export type Validator = ZodType | Ctor | null | undefined;
```
**References:** [Ctor](https://imqueue.org/api/validation/latest/validation.ctor/)

## Remarks

A class is resolved through [schemaOf()](https://imqueue.org/api/validation/latest/validation.schemaof/) at the moment it is first needed rather than when the decorator runs. That defers the cost, not the reference: the class still has to be declared above the decorator that names it, which both the compiler and the temporal dead zone enforce, so two input classes cannot be made to reference each other.

A class that was never sealed with [validatable()](https://imqueue.org/api/validation/latest/validation.validatable/) resolves to `null`, and the value it was meant to guard is then left unvalidated with no error raised — see [validate()](https://imqueue.org/api/validation/latest/validation.validate/) for why that mistake usually shows up somewhere else entirely.