@stone-js/validation 0.8.9 → 0.8.11

package/dist/adapters/standardSchema.d.ts

@@ -1,13 +1,13 @@
-import { ValidationSchema, StandardSchemaV1 } from '../declarations.js';
+import { NativeSchema, StandardSchemaV1 } from '../declarations.js';
 /**
  * Adapts a [Standard Schema](https://standardschema.dev) (Zod 3.24+, Valibot, ArkType, …) to the
- * Stone.js {@link ValidationSchema} contract. Only the synchronous path is supported here; an
+ * Stone.js {@link NativeSchema} contract. Only the synchronous path is supported here; an
  * async schema throws a clear {@link ValidationError} so the misuse is obvious.
  *
  * @param schema - The Standard Schema.
  * @returns A Stone.js validation schema.
  */
-export declare function fromStandard<T>(schema: StandardSchemaV1<T>): ValidationSchema<T>;
+export declare function fromStandard<T>(schema: StandardSchemaV1<T>): NativeSchema<T>;
 /**
  * Whether a value implements the Standard Schema v1 contract.
  *

package/dist/adapters/zod.d.ts

@@ -1,13 +1,13 @@
-import { ValidationSchema, ZodLikeSchema } from '../declarations.js';
+import { NativeSchema, ZodLikeSchema } from '../declarations.js';
 /**
  * Adapts a Zod-style schema (anything exposing a synchronous `safeParse`) to the Stone.js
- * {@link ValidationSchema} contract. Structural — never imports Zod, so it works with any
+ * {@link NativeSchema} contract. Structural — never imports Zod, so it works with any
  * compatible engine and keeps the module dependency-free.
  *
  * @param schema - The Zod-like schema.
  * @returns A Stone.js validation schema.
  */
-export declare function fromZod<T>(schema: ZodLikeSchema<T>): ValidationSchema<T>;
+export declare function fromZod<T>(schema: ZodLikeSchema<T>): NativeSchema<T>;
 /**
  * Whether a value looks like a Zod-style schema.
  *

package/dist/declarations.d.ts

@@ -29,7 +29,7 @@ export type ValidationResult<T> = {
  * implement the Standard Schema spec, or expose `safeParse`), so you write the schema once and
  * use it identically on the backend and the frontend.
  */
-export interface ValidationSchema<T = unknown> {
+export interface NativeSchema<T = unknown> {
     /** Validate a value, returning a normalised result. */
     validate: (data: unknown) => ValidationResult<T>;
 }
@@ -76,10 +76,10 @@ export type ZodSafeParseResult<T> = {
     };
 };
 /**
- * Anything that can be resolved into a {@link ValidationSchema}: a native Stone.js schema, a
+ * Anything that can be resolved into a {@link NativeSchema}: a native Stone.js schema, a
  * Standard Schema, or a Zod-like schema.
  */
-export type SchemaInput<T = unknown> = ValidationSchema<T> | StandardSchemaV1<T> | ZodLikeSchema<T>;
+export type SchemaInput<T = unknown> = NativeSchema<T> | StandardSchemaV1<T> | ZodLikeSchema<T>;
 /**
  * The telemetry-free validation service contract.
  */

package/dist/decorators/Validation.d.ts

@@ -21,7 +21,7 @@ export interface ValidationDecoratorOptions extends ValidationConfig {
  * ```typescript
  * import { Validation } from '@stone-js/validation'
  *
- * @Validation({ abortEarly: false })
+ * @Validation({ schemas: { listQuery: ListQuerySchema } })
  * @StoneApp({ name: 'my-app' })
  * export class Application {}
  * ```

package/dist/decorators/ValidationSchema.d.ts

@@ -1,18 +1,28 @@
+import { ClassType } from '@stone-js/core';
 /**
- * Class decorator: register a schema class under a name.
+ * Declare a class as a rule set.
  *
- * ```ts
- * @ValidationSchema('createUser')
- * export class CreateUserSchema implements IValidationSchema { rules () { … } }
- * ```
+ * Three statements in one, which is why nothing has to be wired by hand:
  *
- * Routes and handlers then refer to it by name (`@Validate('createUser')`), so schemas live in their
- * own files, organised however the application likes, and nothing has to be imported at the route.
- * The class is resolved by the container, so its constructor receives services and `rules()` can use
- * them.
+ * 1. **It is a service.** The container builds it, as a singleton, so its constructor is auto-wired
+ *    like any other class: a repository, a client, a translator, whatever it destructures is resolved
+ *    for it. That is what lets a rule set depend on the application instead of on constants.
+ * 2. **It is reachable by name.** The alias is bound as `schema:<name>`, prefixed on purpose: an
+ *    application is free to bind its own service under a plain word, and a declaration named after a
+ *    domain concept must not compete for that name.
+ * 3. **It activates the module.** The blueprint comes with the decorator, so declaring this is the
+ *    whole setup, and a route naming it resolves to this class.
  *
- * @param alias - The name the schema is registered under. Defaults to the class name, which the
- * discovery middleware fills in, since it is the one holding the class.
+ * @param alias - The name a route refers to it by. Defaults to the class name.
  * @returns A class decorator.
+ *
+ * @example
+ * ```ts
+ * @ValidationSchema('createUser')
+ * export class CreateUser {
+ *   constructor (private readonly users: UserRepository) {}
+ *   rules (): RouteValidationRules { return { body: { email: { rules: 'email' } } } }
+ * }
+ * ```
  */
-export declare const ValidationSchema: (alias?: string) => ClassDecorator;
+export declare const ValidationSchema: <T extends ClassType = ClassType>(alias?: string) => ClassDecorator;

package/dist/index.d.ts

@@ -1,18 +1,18 @@
-export * from './ValidationServiceProvider.js';
-export * from './Validator.js';
 export * from './adapters/standardSchema.js';
 export * from './adapters/zod.js';
 export * from './declarations.js';
+export * from './decorators/constants.js';
 export * from './decorators/Validate.js';
 export * from './decorators/Validation.js';
 export * from './decorators/ValidationSchema.js';
-export * from './decorators/constants.js';
 export * from './errors/ValidationError.js';
 export * from './middleware/BlueprintMiddleware.js';
-export * from './middleware/ValidateRouteMiddleware.js';
 export * from './middleware/validate.js';
+export * from './middleware/ValidateRouteMiddleware.js';
 export * from './options/ValidationBlueprint.js';
 export * from './schema.js';
 export * from './schemaClass.js';
 export * from './sources.js';
 export * from './validateEvent.js';
+export * from './ValidationServiceProvider.js';
+export * from './Validator.js';

package/dist/index.js

@@ -1,9 +1,9 @@
-import { IntegrationError, hasMetadata, getMetadata, classDecoratorLegacyWrapper, addBlueprint, methodDecoratorLegacyWrapper, addMetadata, setClassMetadata } from '@stone-js/core';
+import { IntegrationError, methodDecoratorLegacyWrapper, addMetadata, hasMetadata, getMetadata, classDecoratorLegacyWrapper, addBlueprint, setMetadata, SERVICE_KEY } from '@stone-js/core';
 import { cloneValue } from '@stone-js/config';
 
 /**
  * Adapts a Zod-style schema (anything exposing a synchronous `safeParse`) to the Stone.js
- * {@link ValidationSchema} contract. Structural — never imports Zod, so it works with any
+ * {@link NativeSchema} contract. Structural — never imports Zod, so it works with any
  * compatible engine and keeps the module dependency-free.
  *
  * @param schema - The Zod-like schema.
@@ -71,7 +71,7 @@ class ValidationError extends IntegrationError {
 
 /**
  * Adapts a [Standard Schema](https://standardschema.dev) (Zod 3.24+, Valibot, ArkType, …) to the
- * Stone.js {@link ValidationSchema} contract. Only the synchronous path is supported here; an
+ * Stone.js {@link NativeSchema} contract. Only the synchronous path is supported here; an
  * async schema throws a clear {@link ValidationError} so the misuse is obvious.
  *
  * @param schema - The Standard Schema.
@@ -110,7 +110,7 @@ function isStandardSchema(value) {
 }
 
 /**
- * Normalises any supported schema input into a Stone.js {@link ValidationSchema}.
+ * Normalises any supported schema input into a Stone.js {@link NativeSchema}.
  *
  * Resolution order: a Standard Schema (`~standard`) is preferred (canonical, covers Zod 3.24+,
  * Valibot, ArkType), then a Zod-like `safeParse`, then a native Stone.js schema (`validate`).
@@ -132,7 +132,7 @@ function resolveSchema(input) {
     throw new ValidationError('Unrecognised validation schema: expected a Standard Schema, a Zod-like schema, or a Stone.js schema.', { issues: [] });
 }
 /**
- * Whether a value is already a native Stone.js {@link ValidationSchema}.
+ * Whether a value is already a native Stone.js {@link NativeSchema}.
  *
  * @param value - The value to test.
  * @returns True when it exposes a `validate` function.
@@ -407,6 +407,30 @@ const VALIDATE_KEY = '@stone-js/validation/validate';
  */
 const VALIDATION_SCHEMA_KEY = '@stone-js/validation/schema';
 
+/**
+ * Method decorator: declare what a handler accepts.
+ *
+ * ```ts
+ * @Validate(CreateUserSchema)                       // the body
+ * @Validate({ body: CreateUserSchema, query: Page }) // several sources
+ * @Validate('createUser')                            // a registered schema class
+ * ```
+ *
+ * This knows nothing about the router, and that is the point: the declaration is recorded on the
+ * handler itself, under this module's own key, so validation runs the same in a routed application,
+ * a single-handler service, a CLI command or the browser. When a router *is* in play you may instead
+ * put it on the route (`@Post('/users', { validation: … })`), which keeps the method uncluttered and
+ * puts everything a route does in one place; both forms end up in the same middleware.
+ *
+ * @param validation - What the handler accepts.
+ * @returns A method decorator.
+ */
+const Validate = (validation) => {
+    return methodDecoratorLegacyWrapper((_target, context) => {
+        addMetadata(context, VALIDATE_KEY, { action: context.name, validation });
+    });
+};
+
 /**
  * Route middleware: validates what a route declared, before its handler runs.
  *
@@ -652,7 +676,7 @@ const validationBlueprint = {
  * ```typescript
  * import { Validation } from '@stone-js/validation'
  *
- * @Validation({ abortEarly: false })
+ * @Validation({ schemas: { listQuery: ListQuerySchema } })
  * @StoneApp({ name: 'my-app' })
  * export class Application {}
  * ```
@@ -669,48 +693,44 @@ const Validation = (options = {}) => {
 };
 
 /**
- * Method decorator: declare what a handler accepts.
+ * Declare a class as a rule set.
  *
- * ```ts
- * @Validate(CreateUserSchema)                       // the body
- * @Validate({ body: CreateUserSchema, query: Page }) // several sources
- * @Validate('createUser')                            // a registered schema class
- * ```
+ * Three statements in one, which is why nothing has to be wired by hand:
  *
- * This knows nothing about the router, and that is the point: the declaration is recorded on the
- * handler itself, under this module's own key, so validation runs the same in a routed application,
- * a single-handler service, a CLI command or the browser. When a router *is* in play you may instead
- * put it on the route (`@Post('/users', { validation: … })`), which keeps the method uncluttered and
- * puts everything a route does in one place; both forms end up in the same middleware.
+ * 1. **It is a service.** The container builds it, as a singleton, so its constructor is auto-wired
+ *    like any other class: a repository, a client, a translator, whatever it destructures is resolved
+ *    for it. That is what lets a rule set depend on the application instead of on constants.
+ * 2. **It is reachable by name.** The alias is bound as `schema:<name>`, prefixed on purpose: an
+ *    application is free to bind its own service under a plain word, and a declaration named after a
+ *    domain concept must not compete for that name.
+ * 3. **It activates the module.** The blueprint comes with the decorator, so declaring this is the
+ *    whole setup, and a route naming it resolves to this class.
  *
- * @param validation - What the handler accepts.
- * @returns A method decorator.
- */
-const Validate = (validation) => {
-    return methodDecoratorLegacyWrapper((_target, context) => {
-        addMetadata(context, VALIDATE_KEY, { action: context.name, validation });
-    });
-};
-
-/**
- * Class decorator: register a schema class under a name.
+ * @param alias - The name a route refers to it by. Defaults to the class name.
+ * @returns A class decorator.
  *
+ * @example
  * ```ts
  * @ValidationSchema('createUser')
- * export class CreateUserSchema implements IValidationSchema { rules () { … } }
+ * export class CreateUser {
+ *   constructor (private readonly users: UserRepository) {}
+ *   rules (): RouteValidationRules { return { body: { email: { rules: 'email' } } } }
+ * }
  * ```
- *
- * Routes and handlers then refer to it by name (`@Validate('createUser')`), so schemas live in their
- * own files, organised however the application likes, and nothing has to be imported at the route.
- * The class is resolved by the container, so its constructor receives services and `rules()` can use
- * them.
- *
- * @param alias - The name the schema is registered under. Defaults to the class name, which the
- * discovery middleware fills in, since it is the one holding the class.
- * @returns A class decorator.
  */
 const ValidationSchema = (alias) => {
-    return setClassMetadata(VALIDATION_SCHEMA_KEY, { alias });
+    return classDecoratorLegacyWrapper((target, context) => {
+        const name = alias ?? target.name;
+        setMetadata(context, VALIDATION_SCHEMA_KEY, { alias: name });
+        setMetadata(context, SERVICE_KEY, { singleton: true, isClass: true, alias: `schema:${name}` });
+        addBlueprint(target, context, validationBlueprint, {
+            stone: {
+                validation: {
+                    schemas: { [name]: target }
+                }
+            }
+        });
+    });
 };
 
 /**

package/dist/schema.d.ts

@@ -1,6 +1,6 @@
-import { SchemaInput, ValidationSchema } from './declarations.js';
+import { NativeSchema, SchemaInput } from './declarations.js';
 /**
- * Normalises any supported schema input into a Stone.js {@link ValidationSchema}.
+ * Normalises any supported schema input into a Stone.js {@link NativeSchema}.
  *
  * Resolution order: a Standard Schema (`~standard`) is preferred (canonical, covers Zod 3.24+,
  * Valibot, ArkType), then a Zod-like `safeParse`, then a native Stone.js schema (`validate`).
@@ -9,11 +9,11 @@ import { SchemaInput, ValidationSchema } from './declarations.js';
  * @returns A Stone.js validation schema.
  * @throws {ValidationError} When the input is not a recognisable schema.
  */
-export declare function resolveSchema<T>(input: SchemaInput<T>): ValidationSchema<T>;
+export declare function resolveSchema<T>(input: SchemaInput<T>): NativeSchema<T>;
 /**
- * Whether a value is already a native Stone.js {@link ValidationSchema}.
+ * Whether a value is already a native Stone.js {@link NativeSchema}.
  *
  * @param value - The value to test.
  * @returns True when it exposes a `validate` function.
  */
-export declare function isNativeSchema<T>(value: unknown): value is ValidationSchema<T>;
+export declare function isNativeSchema<T>(value: unknown): value is NativeSchema<T>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stone-js/validation",
-  "version": "0.8.9",
+  "version": "0.8.11",
   "description": "Framework-agnostic input validation for Stone.js. Define a schema once (Zod, Valibot, ArkType — anything Standard Schema) and validate it identically on the backend and the frontend.",
   "author": "Mr. Stone <evensstone@gmail.com>",
   "license": "MIT",
@@ -40,7 +40,7 @@
     "node": ">=18.17.0"
   },
   "peerDependencies": {
-    "@stone-js/core": "0.8.9"
+    "@stone-js/core": "0.8.11"
   },
   "devDependencies": {
     "@commitlint/cli": "^19.8.1",
@@ -62,7 +62,7 @@
     "typescript": "^5.6.3",
     "vitest": "^3.2.4",
     "zod": "^3.24.1",
-    "@stone-js/core": "0.8.9"
+    "@stone-js/core": "0.8.11"
   },
   "ts-standard": {
     "globals": [
@@ -75,7 +75,7 @@
     ]
   },
   "dependencies": {
-    "@stone-js/config": "0.8.9"
+    "@stone-js/config": "0.8.11"
   },
   "scripts": {
     "lint": "ts-standard src",