@stone-js/validation 0.8.10 → 0.8.12

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,17 @@
-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,4 +1,4 @@
-import { IntegrationError, methodDecoratorLegacyWrapper, addMetadata, hasMetadata, getMetadata, classDecoratorLegacyWrapper, addBlueprint, 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';
 
 /**
@@ -595,42 +595,6 @@ const MetaValidateRouteMiddleware = {
     priority: 5
 };
 
-/**
- * Build-phase middleware: collect every class registered with `@ValidationSchema` into the registry.
- *
- * The same scan the router does for its route definitions, applied to this module's own key. After
- * it runs, `stone.validation.schemas` maps each alias to its class, so a route or a handler can name
- * a schema instead of importing it, and `@stone-js/openapi` can walk the registry to publish request
- * schemas without loading anything itself.
- *
- * @param context - The blueprint context.
- * @param next - The next blueprint middleware.
- * @returns The blueprint.
- */
-async function ValidationSchemaMiddleware(context, next) {
-    const registered = context
-        .modules
-        .filter((module) => hasMetadata(module, VALIDATION_SCHEMA_KEY))
-        .reduce((registry, module) => {
-        const { alias } = getMetadata(module, VALIDATION_SCHEMA_KEY, {});
-        return { ...registry, [alias ?? module.name]: module };
-    }, {});
-    if (Object.keys(registered).length > 0) {
-        context.blueprint.set('stone.validation.schemas', {
-            ...context.blueprint.get('stone.validation.schemas', {}),
-            ...registered
-        });
-    }
-    return await next(context);
-}
-/**
- * Meta blueprint middleware for schema discovery.
- */
-const MetaValidationSchemaMiddleware = {
-    module: ValidationSchemaMiddleware,
-    priority: 5
-};
-
 /**
  * Opt-in blueprint: import and register it to enable validation.
  *
@@ -644,11 +608,6 @@ const MetaValidationSchemaMiddleware = {
 const validationBlueprint = {
     stone: {
         validation: {},
-        blueprint: {
-            middleware: [
-                MetaValidationSchemaMiddleware
-            ]
-        },
         providers: [
             ValidationServiceProvider
         ],
@@ -693,24 +652,44 @@ const Validation = (options = {}) => {
 };
 
 /**
- * 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' } } } }
+ * }
+ * ```
  */
 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 }
+                }
+            }
+        });
+    });
 };
 
 /**
@@ -734,4 +713,4 @@ function validate(rules) {
     };
 }
 
-export { MetaValidateRouteMiddleware, MetaValidationSchemaMiddleware, VALIDATE_KEY, VALIDATION_SCHEMA_KEY, Validate, ValidateRouteMiddleware, Validation, ValidationError, ValidationSchema, ValidationSchemaMiddleware, ValidationServiceProvider, Validator, defineValidationSchema, fromStandard, fromZod, isNativeSchema, isSchemaLike, isStandardSchema, isValidationSchema, isValidationSchemaClass, isZodLike, metadataKeyFor, readSource, resolveSchema, rulesOf, toValidationRules, validate, validateEvent, validationBlueprint };
+export { MetaValidateRouteMiddleware, VALIDATE_KEY, VALIDATION_SCHEMA_KEY, Validate, ValidateRouteMiddleware, Validation, ValidationError, ValidationSchema, ValidationServiceProvider, Validator, defineValidationSchema, fromStandard, fromZod, isNativeSchema, isSchemaLike, isStandardSchema, isValidationSchema, isValidationSchemaClass, isZodLike, metadataKeyFor, readSource, resolveSchema, rulesOf, toValidationRules, validate, validateEvent, validationBlueprint };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stone-js/validation",
-  "version": "0.8.10",
+  "version": "0.8.12",
   "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.10"
+    "@stone-js/core": "0.8.12"
   },
   "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.10"
+    "@stone-js/core": "0.8.12"
   },
   "ts-standard": {
     "globals": [
@@ -75,7 +75,7 @@
     ]
   },
   "dependencies": {
-    "@stone-js/config": "0.8.10"
+    "@stone-js/config": "0.8.12"
   },
   "scripts": {
     "lint": "ts-standard src",

package/dist/middleware/BlueprintMiddleware.d.ts

@@ -1,18 +0,0 @@
-import { BlueprintContext, ClassType, IBlueprint, NextMiddleware, type MetaMiddleware } from '@stone-js/core';
-/**
- * Build-phase middleware: collect every class registered with `@ValidationSchema` into the registry.
- *
- * The same scan the router does for its route definitions, applied to this module's own key. After
- * it runs, `stone.validation.schemas` maps each alias to its class, so a route or a handler can name
- * a schema instead of importing it, and `@stone-js/openapi` can walk the registry to publish request
- * schemas without loading anything itself.
- *
- * @param context - The blueprint context.
- * @param next - The next blueprint middleware.
- * @returns The blueprint.
- */
-export declare function ValidationSchemaMiddleware(context: BlueprintContext<IBlueprint, ClassType>, next: NextMiddleware<BlueprintContext<IBlueprint, ClassType>, IBlueprint>): Promise<IBlueprint>;
-/**
- * Meta blueprint middleware for schema discovery.
- */
-export declare const MetaValidationSchemaMiddleware: MetaMiddleware<any, any>;