attaform 0.16.2 → 0.16.4

package/dist/shared/attaform.ls_7jBYc.d.ts

@@ -1,84 +0,0 @@
-import { z } from 'zod';
-import { n as FieldMetaPayload } from './attaform.0Gxd_OOx.js';
-
-/**
- * Field-metadata write/read API for the Zod v4 adapter.
- *
- * Backed by Zod 4's native `z.registry<T>()` mechanism — the schema
- * carries the metadata directly through `schema.register(fieldMeta,
- * payload)` (returns the schema, chainable) or the `withMeta()`
- * helper (same effect, version-agnostic across the v3 / v4 adapter
- * split).
- *
- * **Registration patterns:** both styles work — register on whatever
- * schema reference you assign into the parent's shape, OR on the
- * inner schema before wrapping. The adapter's resolver tries the
- * walker-returned schema first, then falls back to the peeled
- * inner so either ordering hits:
- *
- *     // both equivalent — registry hits at lookup time
- *     withMeta(z.string(), { label: 'Email' }).optional()
- *     withMeta(z.string().optional(), { label: 'Email' })
- *     z.string().optional().register(fieldMeta, { label: 'Email' })
- *     z.string().register(fieldMeta, { label: 'Email' }).optional()
- *
- * The path walker returns the wrapper at terminal positions
- * (`['email']` against `{ email: z.string().optional() }` resolves
- * to `ZodOptional<ZodString>`) and peels at intermediate descent
- * (`['address', 'street']` peels through `address`'s wrapper to
- * reach the inner object). The two-stage lookup covers both leaf
- * and container registrations symmetrically.
- */
-
-/**
- * The shared registry every Attaform-aware Zod 4 schema can register
- * field metadata against. One module-scoped instance per consumer
- * project — re-exported from `attaform/zod` so user code reads the
- * same registry the runtime does.
- *
- * Consumers extending `FieldMetaPayload` via declaration merging
- * automatically get the richer payload type at every `register` /
- * `add` / `get` call site.
- *
- * **Shared-instance disambiguation.** A single schema instance reused
- * at multiple form paths (e.g. one address schema bound to both
- * `pickup` and `delivery`) can carry distinct metadata per path —
- * even via the canonical `schema.register(fieldMeta, payload)` chain.
- * Internally we maintain a parallel WeakMap of payload LISTS indexed
- * per schema reference, and the path-resolver walks the form's
- * schema tree counting per-schema occurrences to pick the right
- * payload for each path. Object literals evaluate left-to-right, so
- * registration order matches tree-walk order, and shared schemas
- * pair their two registrations to the two paths correctly:
- *
- *     z.object({
- *       pickup: addressSchema.register(fieldMeta, { label: 'Pickup address' }),
- *       delivery: addressSchema.register(fieldMeta, { label: 'Delivery address' }),
- *     })
- *     // form.fields('pickup').label   → 'Pickup address'
- *     // form.fields('delivery').label → 'Delivery address'
- *
- * Schemas reused via `withMeta()` get a fresh clone per call (see
- * `withMeta` below), so they never share a registry slot in the
- * first place.
- */
-declare const fieldMeta: z.core.$ZodRegistry<FieldMetaPayload, z.core.$ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>;
-/**
- * Attach `payload` to `schema` in the shared `fieldMeta` registry
- * and return `schema` (chainable). Cross-version with `attaform/zod-v3`'s
- * `withMeta()`; user code that uses this helper reads the same on
- * either adapter.
- *
- * Equivalent to `schema.register(fieldMeta, payload)` on Zod 4.
- * Prefer the native chain for v4-only code; reach for `withMeta`
- * when authoring schema modules that may need to compile under both
- * adapters.
- *
- * Registers on the schema reference passed in. See the
- * "Registration rule" note in this file's header — register on the
- * inner schema before wrapping with `.optional()` / `.nullable()` /
- * `.default()` / etc.
- */
-declare function withMeta<S extends z.ZodType>(schema: S, payload: FieldMetaPayload): S;
-
-export { fieldMeta as f, withMeta as w };

package/dist/shared/attaform.xIcmqscx.d.cts

@@ -1,84 +0,0 @@
-import { z } from 'zod';
-import { n as FieldMetaPayload } from './attaform.0Gxd_OOx.cjs';
-
-/**
- * Field-metadata write/read API for the Zod v4 adapter.
- *
- * Backed by Zod 4's native `z.registry<T>()` mechanism — the schema
- * carries the metadata directly through `schema.register(fieldMeta,
- * payload)` (returns the schema, chainable) or the `withMeta()`
- * helper (same effect, version-agnostic across the v3 / v4 adapter
- * split).
- *
- * **Registration patterns:** both styles work — register on whatever
- * schema reference you assign into the parent's shape, OR on the
- * inner schema before wrapping. The adapter's resolver tries the
- * walker-returned schema first, then falls back to the peeled
- * inner so either ordering hits:
- *
- *     // both equivalent — registry hits at lookup time
- *     withMeta(z.string(), { label: 'Email' }).optional()
- *     withMeta(z.string().optional(), { label: 'Email' })
- *     z.string().optional().register(fieldMeta, { label: 'Email' })
- *     z.string().register(fieldMeta, { label: 'Email' }).optional()
- *
- * The path walker returns the wrapper at terminal positions
- * (`['email']` against `{ email: z.string().optional() }` resolves
- * to `ZodOptional<ZodString>`) and peels at intermediate descent
- * (`['address', 'street']` peels through `address`'s wrapper to
- * reach the inner object). The two-stage lookup covers both leaf
- * and container registrations symmetrically.
- */
-
-/**
- * The shared registry every Attaform-aware Zod 4 schema can register
- * field metadata against. One module-scoped instance per consumer
- * project — re-exported from `attaform/zod` so user code reads the
- * same registry the runtime does.
- *
- * Consumers extending `FieldMetaPayload` via declaration merging
- * automatically get the richer payload type at every `register` /
- * `add` / `get` call site.
- *
- * **Shared-instance disambiguation.** A single schema instance reused
- * at multiple form paths (e.g. one address schema bound to both
- * `pickup` and `delivery`) can carry distinct metadata per path —
- * even via the canonical `schema.register(fieldMeta, payload)` chain.
- * Internally we maintain a parallel WeakMap of payload LISTS indexed
- * per schema reference, and the path-resolver walks the form's
- * schema tree counting per-schema occurrences to pick the right
- * payload for each path. Object literals evaluate left-to-right, so
- * registration order matches tree-walk order, and shared schemas
- * pair their two registrations to the two paths correctly:
- *
- *     z.object({
- *       pickup: addressSchema.register(fieldMeta, { label: 'Pickup address' }),
- *       delivery: addressSchema.register(fieldMeta, { label: 'Delivery address' }),
- *     })
- *     // form.fields('pickup').label   → 'Pickup address'
- *     // form.fields('delivery').label → 'Delivery address'
- *
- * Schemas reused via `withMeta()` get a fresh clone per call (see
- * `withMeta` below), so they never share a registry slot in the
- * first place.
- */
-declare const fieldMeta: z.core.$ZodRegistry<FieldMetaPayload, z.core.$ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>;
-/**
- * Attach `payload` to `schema` in the shared `fieldMeta` registry
- * and return `schema` (chainable). Cross-version with `attaform/zod-v3`'s
- * `withMeta()`; user code that uses this helper reads the same on
- * either adapter.
- *
- * Equivalent to `schema.register(fieldMeta, payload)` on Zod 4.
- * Prefer the native chain for v4-only code; reach for `withMeta`
- * when authoring schema modules that may need to compile under both
- * adapters.
- *
- * Registers on the schema reference passed in. See the
- * "Registration rule" note in this file's header — register on the
- * inner schema before wrapping with `.optional()` / `.nullable()` /
- * `.default()` / etc.
- */
-declare function withMeta<S extends z.ZodType>(schema: S, payload: FieldMetaPayload): S;
-
-export { fieldMeta as f, withMeta as w };