@splenddev/kreativ-core 0.1.2 → 0.1.3

package/dist/index.d.cts

@@ -1,363 +0,0 @@
-import { TokenValue, SemanticToken, SizeToken, SizeScale, Typography, RecipeDefinition, DesignTokens, TokenDefinition, TokenReferenceString as TokenReferenceString$1, SemanticTokens, Theme, ColorMode, ResolvedTokens } from './types/index.cjs';
-export { AnimationTokens, BaseBreakpoint, BaseColor, BaseProps, BaseVariant, BreakpointTokens, CSSPropertiesWithVars, ClearableProps, ColorModeValue, ColorProps, ColorScale, ColorTokens, ControlledProps, CustomRecipes, DeepPartial, DefaultRecipeCollection, DisabledProps, Easing, EmbeddedProps, FontSizeTokens, FontTokens, FontWeightTokens, FormFieldStatus, FullWidthProps, IntensityMap, LetterSpacingTokens, LineHeightTokens, LoadingProps, Orientation, OrientationProps, RadiusTokens, RecipeCollection, RecipeCompoundVariant, RecipeStyle, RecipeVariant, RecipeVariantValue, ReportedValidity, RequiredStateControlProps, ResponsiveStyles, ResponsiveValue, SemanticColorTokens, ShadowTokens, Size, SizeProps, SizeValue, SpacingTokens, StateControlProps, StateProps, StatusProps, StyleObject, StyleValue, Styleable, ThemeAnimation, ThemeOverride, ThemeTogglerTransition, ThemeTransition, TokenGroup, TrimProps, TypographyProps, TypographyStyle, UndoRedoProps, ValidateOn, ValidateProps, ValidationResult, ValueProps, Variant, VariantProps } from './types/index.cjs';
-import * as React from 'react';
-export { CreateComponentConfig, CreateFromPropsInput, KuiComponent, KuiMeta, KuiRole, KuiSkeletonHint, KuiSupports, ResolvedResponsiveValue, composeRefs, createComponent, createFromProps, deepMerge, hasKuiMeta, isResponsiveValue, mergeResponsiveValue, resolveResponsiveValue, resolveSemanticTokenReferences, resolveTokenReference, resolveTokens, resolveTypography, toKebabCase, toResponsiveClasses, tokensToCssVars } from './utils/index.cjs';
-
-declare function defineToken<T extends TokenValue>(value: T): {
-    value: T;
-};
-declare function defineTokens<T extends Record<string, TokenValue>>(tokens: T): { [K in keyof T]: ReturnType<typeof defineToken<T[K]>>; };
-
-/**
- * Defines a semantic token that shares a single value across both
- * light and dark modes (the explicit sameForBothModes shorthand).
- */
-declare function defineSemanticToken<T extends TokenValue>(value: T): SemanticToken<T>;
-/**
- * Defines a semantic token with distinct light and dark values.
- */
-declare function defineSemanticToken<T extends TokenValue>(light: T, dark: T): SemanticToken<T>;
-type SemanticTokenInput<T extends TokenValue> = T | {
-    light: T;
-    dark: T;
-};
-declare function defineSemanticTokens<T extends Record<string, SemanticTokenInput<TokenValue>>>(tokens: T): {
-    [K in keyof T]: SemanticToken<T[K] extends {
-        light: infer V;
-        dark: infer _;
-    } ? V extends TokenValue ? V : never : T[K] extends TokenValue ? T[K] : never>;
-};
-
-declare function defineSize<const T extends SizeToken>(size: T): T;
-declare function defineSizes<const T extends SizeScale>(sizes: T): T;
-
-declare function defineTypography<const T extends Typography>(typography: T): T;
-
-declare function defineRecipe<const T extends RecipeDefinition>(recipe: T): T;
-
-/**
- * Branded type-level error, surfaced at the defineTheme() call site
- * when a section validator fails. Section validators wrap this in a
- * section-named key (e.g. { semanticTokens: Invalid<...> }) rather
- * than composing into an unreadable anonymous intersection.
- *
- * Path-tracking (__kuiPath) is a locked stretch goal, not yet built —
- * ship section-named base errors first, confirm they render legibly
- * in editor tooltips, then treat path-tracking as a follow-on.
- */
-type Invalid<Message extends string> = {
-    readonly __kuiError: Message;
-};
-
-/**
- * A token reference string, e.g. "{colors.brand.500}" — legal for
- * semantic tokens, but NOT legal for primitive tokens. defineToken's
- * "no token references" rule is what makes defineTheme's cycle
- * detection tractable (cycle detection only needs to walk
- * semantic→semantic edges).
- */
-type TokenReferenceString = `{${string}}`;
-type IsTokenReference$1<T> = T extends TokenReferenceString ? true : false;
-/**
- * Recursively checks that every leaf in a token tree is a real
- * terminal TokenValue, never a "{...}" reference string.
- */
-type ValidateTokenLeaf<T> = T extends TokenDefinition<infer V> ? IsTokenReference$1<V> extends true ? Invalid<"Primitive tokens cannot contain token references — use defineSemanticToken instead"> : unknown : T extends Record<string, unknown> ? ValidateTokenTree<T> : unknown;
-type ValidateTokenTree<T> = {
-    [K in keyof T]: ValidateTokenLeaf<T[K]>;
-}[keyof T] extends infer Result ? Result extends Invalid<any> ? Result : unknown : never;
-type ValidateTokens<T extends {
-    tokens?: unknown;
-}> = T["tokens"] extends DesignTokens ? ValidateTokenTree<T["tokens"]> : unknown;
-type ValidateTokenSection<T extends {
-    tokens?: unknown;
-}> = ValidateTokens<T> extends infer Result ? Result extends Invalid<any> ? {
-    tokens: Result;
-} : unknown : never;
-
-type IsTokenReference<T> = T extends TokenReferenceString$1 ? true : false;
-/**
- * Strips the surrounding "{" "}" from a reference string, giving the
- * raw dotted path, e.g. "{colors.brand.500}" -> "colors.brand.500".
- */
-type ExtractPath<T extends string> = T extends `{${infer Path}}` ? Path : never;
-/**
- * Splits a dotted path string into a tuple of segments.
- * "colors.brand.500" -> ["colors", "brand", "500"]
- */
-type SplitPath<S extends string> = S extends `${infer Head}.${infer Rest}` ? [Head, ...SplitPath<Rest>] : [S];
-/**
- * Looks up a single path segment against T's keys, tolerating the
- * common case where the segment is a numeric-looking string
- * ("500") but the actual object key is a numeric literal (500) —
- * e.g. color scale steps. TS's keyof does not match these directly.
- */
-type LookupKey<T, Head extends string> = Head extends keyof T ? Head : Head extends `${infer N extends number}` ? N extends keyof T ? N : never : never;
-/**
- * Walks an object tree along a tuple of path segments. Resolves to
- * the value at that path, or `never` if any segment doesn't exist.
- */
-type ResolvePath<T, Path extends readonly string[]> = Path extends [infer Head extends string, ...infer Rest] ? LookupKey<T, Head> extends infer K ? K extends keyof T ? Rest extends readonly string[] ? Rest["length"] extends 0 ? T[K] : ResolvePath<T[K], Rest> : never : never : never : never;
-/**
- * True if a dotted-path reference resolves to something inside T.
- */
-type PathExists<T, Ref extends string> = ResolvePath<T, SplitPath<ExtractPath<Ref>>> extends never ? false : true;
-/**
- * Validates that a single reference string, if it is one, actually
- * resolves against the given tokens/semanticTokens tree. Non-reference
- * values pass through as `unknown` (valid).
- */
-type ValidateReferenceExists<Value, Tokens, _Path extends string = "unknown path"> = Value extends TokenReferenceString$1 ? PathExists<Tokens, Value> extends true ? unknown : Invalid<`References an unknown token: "${Value}"`> : unknown;
-
-/**
- * Extracts the underlying value(s) out of a semantic token's
- * ColorModeValue, to run existence checks against each.
- */
-type ExtractCheckableValues<V> = V extends {
-    sameForBothModes: true;
-    value: infer X;
-} ? [X] : V extends {
-    light: infer L;
-    dark: infer D;
-} ? [L, D] : [];
-/**
- * Validates a single semantic token leaf: every reference it
- * contains (light and/or dark) must resolve against the combined
- * tokens+semanticTokens tree.
- *
- * NOTE: semantic->semantic cycle detection is NOT done here — it
- * was attempted at the type level and hit TypeScript inference
- * edge cases in recursive conditional types that made it unreliable
- * (false positives on valid semantic->primitive references). Cycle
- * detection is handled at runtime instead — see validateNoCycles in
- * runtime/validateCycles.ts, called from defineTheme/extendTheme.
- */
-type ValidateSemanticLeaf<Leaf, AllTokens> = Leaf extends {
-    value: infer V;
-} ? ExtractCheckableValues<V> extends infer Values extends readonly unknown[] ? {
-    [I in keyof Values]: Values[I] extends TokenReferenceString$1 ? ValidateReferenceExists<Values[I], AllTokens> : unknown;
-}[number] extends infer Result ? Result extends Invalid<any> ? Result : unknown : never : unknown : unknown;
-/**
- * Recursively walks the semanticTokens tree, validating every leaf.
- */
-type ValidateSemanticTree<Tree, AllTokens> = {
-    [K in keyof Tree]: Tree[K] extends {
-        value: unknown;
-    } ? ValidateSemanticLeaf<Tree[K], AllTokens> : ValidateSemanticTree<Tree[K], AllTokens>;
-}[keyof Tree] extends infer Result ? Result extends Invalid<any> ? Result : unknown : never;
-type ValidateSemanticTokens<T extends {
-    tokens?: unknown;
-    semanticTokens?: unknown;
-}> = T["semanticTokens"] extends SemanticTokens ? ValidateSemanticTree<T["semanticTokens"], (T["tokens"] extends DesignTokens ? T["tokens"] : {}) & T["semanticTokens"]> : unknown;
-type ValidateSemanticTokenSection<T extends {
-    tokens?: unknown;
-    semanticTokens?: unknown;
-}> = ValidateSemanticTokens<T> extends infer Result ? Result extends Invalid<any> ? {
-    semanticTokens: Result;
-} : unknown : never;
-
-/**
- * Validates a single SizeToken's fontSize: if present, it MUST be a
- * "{typography.someVariant}"-style reference into the theme's
- * Typography collection — a raw CSS value (e.g. "1rem") is invalid.
- *
- * This is a cross-section rule (spans sizes + typography), which is
- * why it lives in defineTheme's territory rather than defineSize or
- * defineTypography individually — neither of those functions can see
- * the other section in isolation.
- */
-type ValidateSizeFontSize<FontSize, TypographyTree> = FontSize extends undefined ? unknown : FontSize extends TokenReferenceString$1 ? ValidateReferenceExists<FontSize, {
-    typography: TypographyTree;
-}> : Invalid<`SizeToken.fontSize must reference a typography preset (e.g. "{typography.body}"), not a raw value: "${FontSize & string}"`>;
-/**
- * Walks every size in the SizeScale, validating each one's fontSize.
- */
-type ValidateSizeScaleFontSizes<Sizes, TypographyTree> = {
-    [K in keyof Sizes]: Sizes[K] extends {
-        fontSize?: infer F;
-    } ? ValidateSizeFontSize<F, TypographyTree> : unknown;
-}[keyof Sizes] extends infer Result ? Result extends Invalid<any> ? Result : unknown : never;
-type ValidateTypography<T extends {
-    typography?: unknown;
-    sizes?: unknown;
-}> = T["sizes"] extends SizeScale ? ValidateSizeScaleFontSizes<T["sizes"], T["typography"] extends Typography ? T["typography"] : {}> : unknown;
-/**
- * Cross-section rule: SizeToken.fontSize -> Typography preset.
- *
- * Despite the name (kept for continuity with the ownership-tree
- * discussion, which described this as "the typography section" of
- * cross-section rules), the actual invalid DATA here always lives on
- * the `sizes` side (a bad fontSize value on a SizeToken), never on
- * `typography` itself — so the resulting error is keyed under
- * `sizes`, not `typography`. Keying it under `typography` would
- * collide with T's own real `typography` field when intersected onto
- * T in defineTheme's signature (T & ValidateTheme<T>), since TS would
- * then require the theme's actual typography VALUE to also satisfy
- * the Invalid<...> shape — which is a real bug that surfaced and was
- * fixed during end-to-end testing of defineTheme.
- */
-type ValidateTypographySection<T extends {
-    typography?: unknown;
-    sizes?: unknown;
-}> = ValidateTypography<T> extends infer Result ? Result extends Invalid<any> ? {
-    sizes: Result;
-} : unknown : never;
-/**
- * Validates a single TypographyStyle field: if its value is a
- * "{...}" reference, it MUST resolve against the theme's primitive
- * tokens (e.g. "{fonts.body}", "{fontWeights.bold}"). A raw literal
- * value (e.g. "16px", 400) is always valid — references are opt-in,
- * not required. This is DIFFERENT from the sizes.fontSize rule above:
- * there, a reference is REQUIRED; here, a reference is OPTIONAL but
- * must resolve if present.
- */
-type ValidateTypographyField<FieldValue, TokensTree> = FieldValue extends TokenReferenceString$1 ? ValidateReferenceExists<FieldValue, TokensTree> : unknown;
-/**
- * Walks every field of a single TypographyStyle variant (fontFamily,
- * fontSize, fontWeight, lineHeight, letterSpacing).
- */
-type ValidateTypographyStyleFields<Style, TokensTree> = {
-    [K in keyof Style]: ValidateTypographyField<Style[K], TokensTree>;
-}[keyof Style] extends infer Result ? Result extends Invalid<any> ? Result : unknown : never;
-/**
- * Walks every variant in the Typography collection (body, heading,
- * label, etc.), validating every field's token references.
- */
-type ValidateTypographyTokenReferences<TypographyTree, TokensTree> = {
-    [K in keyof TypographyTree]: ValidateTypographyStyleFields<TypographyTree[K], TokensTree>;
-}[keyof TypographyTree] extends infer Result ? Result extends Invalid<any> ? Result : unknown : never;
-/**
- * Cross-section rule: TypographyStyle fields (fontFamily, fontSize,
- * fontWeight, lineHeight, letterSpacing) MAY reference primitive
- * tokens (e.g. "{fonts.body}") — if they do, the reference must
- * resolve. This is a genuinely typography-owned rule (the invalid
- * data lives in `typography` itself, not `sizes`), so it's kept as
- * its own separately-exported section validator rather than folded
- * into ValidateTypographySection above — composing both under one
- * name would reintroduce the same key-collision risk that rule
- * already caused once, since this one's natural key IS `typography`.
- */
-type ValidateTypographyReferencesSection<T extends {
-    typography?: unknown;
-    tokens?: unknown;
-}> = (T["typography"] extends Typography ? ValidateTypographyTokenReferences<T["typography"], T["tokens"] extends DesignTokens ? T["tokens"] : {}> : unknown) extends infer Result ? Result extends Invalid<any> ? {
-    typography: Result;
-} : unknown : never;
-
-type ValidateRecipes<_T extends {
-    recipes?: unknown;
-}> = unknown;
-type ValidateRecipeSection<_T extends {
-    recipes?: unknown;
-}> = unknown;
-
-/**
- * Sizes section validator.
- *
- * Deliberately a no-op / pass-through. A SizeToken's fields are:
- * height, width, paddingX, paddingY, fontSize, gap, iconSize, radius,
- * separatorSize — and fontSize is the ONLY one of those that
- * references another theme section (a typography preset). Every
- * other field is a raw CSS length with no cross-section relationship
- * to validate.
- *
- * The fontSize -> typography-preset rule is already fully owned by
- * ValidateTypographySection (see typography.ts) — that's where it's
- * implemented and tested, since it's conceptually "does this
- * typography reference resolve", not "is this size valid". There is
- * currently no independent rule left for ValidateSizesSection to own.
- *
- * This slot still exists (rather than being omitted from
- * ValidateTheme's composition) so the "why is this empty" reasoning
- * is documented in code, and so a real future sizes-only rule has an
- * obvious home to land in without restructuring the composition.
- */
-type ValidateSizes<_T extends {
-    sizes?: unknown;
-}> = unknown;
-type ValidateSizesSection<_T extends {
-    sizes?: unknown;
-}> = unknown;
-
-/**
- * Composes all section validators into one type. Each section
- * resolves to `unknown` (a no-op in the intersection) on success, or
- * a section-named `{ sectionName: Invalid<...> }` object on failure
- * — so a failing theme surfaces as a legible, named error at the
- * defineTheme() call site instead of an anonymous intersection wall.
- *
- * ValidateRecipeSection and ValidateSizesSection are currently
- * documented no-ops (see recipes.ts / sizes.ts for why) but are kept
- * in the composition so the full section list is visible here and
- * either can gain real rules later without changing this shape.
- *
- * ValidateTypographySection and ValidateTypographyReferencesSection
- * are two DIFFERENT rules kept as separate types (not merged): the
- * former validates sizes.fontSize -> typography (keyed under `sizes`,
- * required reference), the latter validates typography's own fields
- * -> tokens (keyed under `typography`, optional reference). Merging
- * them would risk reintroducing the same key-collision bug already
- * found and fixed once during this effort.
- */
-type ValidateTheme<T extends Theme> = ValidateTokenSection<T> & ValidateSemanticTokenSection<T> & ValidateTypographySection<T> & ValidateTypographyReferencesSection<T> & ValidateRecipeSection<T> & ValidateSizesSection<T>;
-
-/**
- * Defines a Kreativ UI theme.
- *
- * Type-safe boundary for creating themes while preserving the exact
- * structure and types of the supplied theme. Does not merge with the
- * default theme or mutate the provided object — extension/resolution
- * are handled separately by extendTheme.
- *
- * `T & ValidateTheme<T>` is what actually enforces validation at the
- * call site: ValidateTheme<T> resolves to `unknown` (a no-op) when
- * every section passes, or a section-named `{ tokens: Invalid<...> }`
- * / `{ semanticTokens: Invalid<...> }` / etc. object when a section
- * fails. Intersecting that onto the parameter type means a failing
- * theme produces a real compile error naming the failing section and
- * message, not just a generic "not assignable to Theme".
- *
- * Reference *existence* (does "{colors.brand.500}" resolve to a real
- * token) is checked at compile time via ValidateSemanticTokenSection,
- * as part of ValidateTheme above. Reference *cycles* (semantic token
- * A -> B -> A) can't be reliably caught at the type level (hit TS
- * inference edge cases in recursive conditional types), so they're
- * checked here at call time instead, via assertNoCycles.
- */
-declare function defineTheme<T extends Theme>(theme: T & ValidateTheme<T>): T;
-
-interface CycleValidationResult {
-    valid: boolean;
-    cyclePath?: string[];
-}
-/**
- * Walks every semantic token's reference chain looking for a
- * semantic->semantic cycle. Reference *existence* (does the path
- * resolve at all) is validated separately at the type level via
- * ValidateSemanticTokenSection — this function only detects cycles
- * among references that do resolve to another semantic token.
- *
- * A reference that resolves to nothing (dangling) or to a primitive
- * token is a dead end for cycle-walking purposes here, not an error
- * this function raises — that's the type-level existence check's job.
- */
-declare function validateNoCycles(semanticTokens: SemanticTokens): CycleValidationResult;
-/**
- * Throws a descriptive error if a semantic->semantic cycle is found.
- * Intended to be called from defineTheme/extendTheme.
- */
-declare function assertNoCycles(semanticTokens: SemanticTokens): void;
-
-interface ThemeContextValue {
-    theme: Theme;
-    mode: ColorMode;
-    resolvedMode: "light" | "dark";
-    setMode: (mode: ColorMode) => void;
-    fallbackSize: string;
-    tokens: ResolvedTokens;
-}
-declare const ThemeContext: React.Context<ThemeContextValue | null>;
-
-declare function useTheme(): ThemeContextValue;
-
-export { ColorMode, type CycleValidationResult, DesignTokens, type ExtractPath, type Invalid, type IsTokenReference, type PathExists, RecipeDefinition, type ResolvePath, ResolvedTokens, SemanticToken, SemanticTokens, SizeScale, SizeToken, type SplitPath, Theme, ThemeContext, type ThemeContextValue, TokenDefinition, TokenReferenceString$1 as TokenReferenceString, TokenValue, Typography, type ValidateRecipeSection, type ValidateRecipes, type ValidateReferenceExists, type ValidateSemanticTokenSection, type ValidateSemanticTokens, type ValidateSizes, type ValidateSizesSection, type ValidateTheme, type ValidateTokenSection, type ValidateTokens, type ValidateTypography, type ValidateTypographyReferencesSection, type ValidateTypographySection, assertNoCycles, defineRecipe, defineSemanticToken, defineSemanticTokens, defineSize, defineSizes, defineTheme, defineToken, defineTokens, defineTypography, useTheme, validateNoCycles };

package/dist/types/index.cjs

@@ -1,4 +0,0 @@
-'use strict';
-
-//# sourceMappingURL=index.cjs.map
-//# sourceMappingURL=index.cjs.map

package/dist/types/index.cjs.map

@@ -1 +0,0 @@
-{"version":3,"sources":[],"names":[],"mappings":"","file":"index.cjs"}