@mohasinac/appkit 4.61.0 → 4.62.1

package/dist/ui/components/tabs-overflow.js

@@ -20,9 +20,16 @@
  */
 import { useCallback, useEffect, useLayoutEffect, useRef, useState } from "react";
 /**
- * Slack used by the hysteresis rule below, in px. Matches
- * 2 x --appkit-tabs-arrow-size (2rem) — the width the two in-flow arrows
- * reclaim from the list when they unmount.
+ * Slack used by the hysteresis rule below, in px. Nominally
+ * 2 x --appkit-tabs-arrow-size (2rem), the width of the two in-flow arrows.
+ *
+ * 🛑 It is a SAFETY MARGIN, not a measurement, and the distinction is what
+ * this file got wrong badly enough to crash production. The arrows are not
+ * the only thing `data-arrows="true"` changes — it also hides the list's
+ * scrollbar — so the real width reclaimed on unmount is this number minus the
+ * platform scrollbar, and on a machine with overlay scrollbars it is this
+ * number exactly. The rule below is written to be stable for every value in
+ * that range rather than assuming one of them.
  */
 const ARROW_SLACK_PX = 64;
 /** Sub-pixel tolerance: scrollWidth/clientWidth can differ by <1px at some zooms. */
@@ -51,19 +58,65 @@ export function useTabsOverflow(listRef, activeKey) {
         const overflow = el.scrollWidth - el.clientWidth;
         const previous = stateRef.current.hasArrows;
         /*
-         * 🛑 HYSTERESIS — do not collapse this to a single threshold.
+         * 🛑 HYSTERESIS — do not collapse this to a single threshold, and do not
+         * "tidy" the negative one below back to a positive number.
          *
          * The arrows are IN-FLOW, so mounting them shrinks the list's clientWidth
-         * by ~ARROW_SLACK_PX, which INCREASES the measured overflow. With one
-         * threshold a strip 10px wider than its container oscillates forever:
-         *   hidden -> overflow 10 -> show -> overflow 74 -> still overflowing
-         *   -> ... -> hide -> overflow -54 -> hide -> widen -> overflow 10 -> show
+         * and INCREASES the measured overflow. With one threshold a strip 10px
+         * wider than its container oscillates forever.
+         *
+         * ## 🛑 THE PREVIOUS RULE WAS `overflow > ARROW_SLACK_PX` AND IT CRASHED
+         * ## EVERY STORE PAGE IN PRODUCTION WITH React #185 (max update depth).
          *
-         * Once the arrows are up they may only come down if the content would
+         * Its stability proof — "they may only come down if the content would
          * STILL fit after reclaiming their width, which by construction leaves
-         * overflow <= 0 afterwards. That makes the rule provably stable.
+         * overflow <= 0" — rests on mounting the arrows changing the measured
+         * overflow by EXACTLY `ARROW_SLACK_PX`. That is true of the arrows alone
+         * and FALSE of the net effect, because of a rule 100 lines away in
+         * `Tabs.style.css`:
+         *
+         *     .appkit-tabs-shell[data-arrows="true"] .appkit-tabs-list {
+         *       scrollbar-width: none;
+         *     }
+         *     …__arrow is 2rem; …-list::-webkit-scrollbar { display: none }
+         *
+         * The same `data-arrows="true"` that mounts the arrows also HIDES the
+         * scrollbar, handing the list back ~15px of clientWidth. So the net
+         * reclaimed width is ~49px, not 64 — and for any strip overflowing by
+         * 2..15px the two thresholds each imply the other:
+         *
+         *   hidden, overflow 10  -> 10 > 1    -> SHOW
+         *   shown,  overflow 59  -> 59 > 64?  -> no -> HIDE
+         *   hidden, overflow 10  -> …forever
+         *
+         * `useLayoutEffect` below runs on every render by design, so the loop is
+         * unbounded and React tears the tree down. The `sameState` guard cannot
+         * help: the state genuinely differs each pass.
+         *
+         * ## The rule now, stable for ANY reclaimed width
+         *
+         * Let r = whatever mounting the arrows adds to `overflow` (unknown, and
+         * provably NOT a constant — it depends on CSS this file cannot see, the
+         * platform's scrollbar width, and whether the user has overlay
+         * scrollbars). All we know is 0 <= r.
+         *
+         *   show:  hidden AND overflow >  EPSILON
+         *   hide:  shown  AND overflow <= -ARROW_SLACK_PX
+         *
+         * After SHOWING:  overflow' = overflow + r > EPSILON >= -ARROW_SLACK_PX,
+         *                 so the hide test cannot fire. No loop.
+         * After HIDING:   overflow' = overflow - r <= -ARROW_SLACK_PX <= EPSILON,
+         *                 so the show test cannot fire. No loop.
+         *
+         * Stable for every r >= 0, which is the point: the previous rule was
+         * stable only for one exact value of r that nothing enforced.
+         *
+         * The cost is deliberate conservatism — once up, the arrows stay up until
+         * the strip has a full ARROW_SLACK_PX of genuine slack. An arrow that
+         * lingers on a strip that just fits is a cosmetic blemish; the thing it
+         * replaces is a white screen.
          */
-        const hasArrows = previous ? overflow > ARROW_SLACK_PX : overflow > EPSILON;
+        const hasArrows = previous ? overflow > -ARROW_SLACK_PX : overflow > EPSILON;
         const max = el.scrollWidth - el.clientWidth;
         // Math.abs: scrollLeft is negative (or inverted) in RTL depending on engine.
         const position = Math.abs(el.scrollLeft);

package/dist/ui/forms/FieldCheckbox.js

@@ -34,5 +34,5 @@ export function FieldCheckbox({ name, label, hint, checked, onChange, onBlur, di
         ctx?.setFieldTouched(name);
         onBlur?.();
     }
-    return (_jsxs("div", { className: ["appkit-form-field", className].filter(Boolean).join(" "), children: [_jsx(Checkbox, { id: inputId, name: name, checked: checked, onChange: handleChange, onBlur: handleBlur, label: label, disabled: disabled, "aria-describedby": showError ? errorId : undefined }), !showError && hint && (_jsx(Text, { size: "sm", variant: "secondary", className: "appkit-form-field__hint", children: hint })), showError && (_jsx(Text, { id: errorId, size: "sm", variant: "error", className: "appkit-form-field__error", role: "alert", children: error }))] }));
+    return (_jsxs("div", { className: ["appkit-form-field", className].filter(Boolean).join(" "), children: [_jsx(Checkbox, { id: inputId, name: name, checked: checked, onChange: handleChange, onBlur: handleBlur, label: label, disabled: disabled, "aria-invalid": showError || undefined, "aria-describedby": showError ? errorId : undefined }), !showError && hint && (_jsx(Text, { size: "sm", variant: "secondary", className: "appkit-form-field__hint", children: hint })), showError && (_jsx(Text, { id: errorId, size: "sm", variant: "error", className: "appkit-form-field__error", role: "alert", children: error }))] }));
 }

package/dist/ui/forms/FormErrorList.d.ts

@@ -9,21 +9,5 @@ export interface FormErrorListProps {
     ctx?: FormShellContextValue;
     className?: string;
 }
-/**
- * The `<ul>` of current validation errors, with a jump link per entry when
- * the form declares sections.
- *
- * WHY it is its own file: two surfaces render this exact list — the inline
- * `<FormErrorSummary>` beside the submit button on desktop, and the mobile
- * "Fix N issues" sheet in the bottom-chrome tier. Writing it twice would mean
- * a jump-link fix, an empty-state fix or a wording fix landing in one and not
- * the other, which is the bug-fix multiplier the Duplication Framework calls
- * out. There are exactly two consumers and they are the same list, so this is
- * a consolidation, not speculative abstraction.
- *
- * Renders nothing when there are no errors. It does NOT gate on
- * `submitAttempted` — that is the *summary's* decision, not the list's, and
- * the sheet needs to keep rendering while open.
- */
 export declare function FormErrorList({ ctx: ctxProp, className }: FormErrorListProps): import("react").JSX.Element | null;
 export default FormErrorList;

package/dist/ui/forms/FormErrorList.js

@@ -19,6 +19,39 @@ import { Span } from "../components/Typography.js";
  * `submitAttempted` — that is the *summary's* decision, not the list's, and
  * the sheet needs to keep rendering while open.
  */
+/*
+ * 🛑 The two sides of this lookup use DIFFERENT key shapes, so an exact match
+ * silently loses every nested error.
+ *
+ * `errors` is keyed by the full dotted Zod path — `applyZodIssues` does
+ * `issue.path.map(String).join(".")`, giving `"address.line1"`. But
+ * `fieldToStepIndex` is built by `buildFieldToSectionIndex` from
+ * `SectionDef.fields`, which lists BARE field names — `"address"`. So
+ * `fieldToStepIndex["address.line1"]` was always `undefined`, the entry fell
+ * through to the plain `<Span>`, and the error that a section demonstrably
+ * owned rendered with no jump link.
+ *
+ * `SectionForm` already solved this for its own badge counts
+ * (`erroringSectionIds`, `errorCountFor`) with a prefix match. This is the same
+ * rule, so the list and the badges can no longer disagree about which section
+ * an error belongs to.
+ *
+ * Exact match is tried first: a field genuinely named `"address.line1"` must
+ * beat a prefix match on `"address"`.
+ */
+function resolveStepIndex(ctx, key) {
+    const map = ctx.fieldToStepIndex;
+    if (!map)
+        return undefined;
+    const exact = map[key];
+    if (exact != null)
+        return exact;
+    for (const [field, index] of Object.entries(map)) {
+        if (key.startsWith(`${field}.`))
+            return index;
+    }
+    return undefined;
+}
 export function FormErrorList({ ctx: ctxProp, className }) {
     const ambient = useContext(FormShellContext);
     const ctx = ctxProp ?? ambient;
@@ -28,7 +61,7 @@ export function FormErrorList({ ctx: ctxProp, className }) {
     if (entries.length === 0)
         return null;
     return (_jsx("ul", { className: ["appkit-formshell__error-summary__list", className].filter(Boolean).join(" "), children: entries.map(([key, message]) => {
-            const stepIndex = ctx.fieldToStepIndex?.[key];
+            const stepIndex = resolveStepIndex(ctx, key);
             const stepLabel = stepIndex != null ? ctx.steps[stepIndex]?.label : undefined;
             return (_jsx("li", { children: stepLabel ? (_jsxs("button", { type: "button", className: "appkit-formshell__error-summary__step-link", onClick: () => ctx.goToStep(stepIndex), children: [_jsxs(Span, { weight: "semibold", children: [stepLabel, ":"] }), " ", message] })) : (_jsx(Span, { children: message })) }, key));
         }) }));

package/dist/ui/forms/apply-zod-issues.d.ts

@@ -22,7 +22,16 @@
  *
  * Root-level `.refine()` issues (empty `path: []`, no owning field) are still
  * skipped — there is no field to attach them to, so the caller must surface
- * those some other way (they fall through to a toast in `surfaceError`).
+ * those some other way.
+ *
+ * 🛑 That last sentence used to end "(they fall through to a toast in
+ * `surfaceError`)", which was only true when EVERY issue was root-level.
+ * In the mixed case — one field error plus one cross-field `.refine()`, which
+ * is the common shape for "passwords must match" or "end date must be after
+ * start date" — `hasAttachableIssue` returned true, this function skipped the
+ * root issue, and `surfaceError` returned without a toast. The cross-field
+ * rule was enforced, the save was refused, and the user was told nothing
+ * about why. `rootLevelMessages` below is how a caller surfaces them.
  */
 export declare function applyZodIssues(issues: ReadonlyArray<{
     path?: ReadonlyArray<PropertyKey>;
@@ -32,3 +41,12 @@ export declare function applyZodIssues(issues: ReadonlyArray<{
 export declare function hasAttachableIssue(issues: ReadonlyArray<{
     path?: ReadonlyArray<PropertyKey>;
 }> | undefined): boolean;
+/**
+ * The messages `applyZodIssues` cannot attach — the root-level `.refine()`
+ * ones with no owning field. A caller that has just run `applyZodIssues`
+ * should surface these separately, or they are silently discarded.
+ */
+export declare function rootLevelMessages(issues: ReadonlyArray<{
+    path?: ReadonlyArray<PropertyKey>;
+    message: string;
+}> | undefined): string[];

package/dist/ui/forms/apply-zod-issues.js

@@ -22,7 +22,16 @@
  *
  * Root-level `.refine()` issues (empty `path: []`, no owning field) are still
  * skipped — there is no field to attach them to, so the caller must surface
- * those some other way (they fall through to a toast in `surfaceError`).
+ * those some other way.
+ *
+ * 🛑 That last sentence used to end "(they fall through to a toast in
+ * `surfaceError`)", which was only true when EVERY issue was root-level.
+ * In the mixed case — one field error plus one cross-field `.refine()`, which
+ * is the common shape for "passwords must match" or "end date must be after
+ * start date" — `hasAttachableIssue` returned true, this function skipped the
+ * root issue, and `surfaceError` returned without a toast. The cross-field
+ * rule was enforced, the save was refused, and the user was told nothing
+ * about why. `rootLevelMessages` below is how a caller surfaces them.
  */
 export function applyZodIssues(issues, setFieldError) {
     for (const issue of issues) {
@@ -36,3 +45,16 @@ export function applyZodIssues(issues, setFieldError) {
 export function hasAttachableIssue(issues) {
     return Boolean(issues?.some((i) => i.path && i.path.length > 0));
 }
+/**
+ * The messages `applyZodIssues` cannot attach — the root-level `.refine()`
+ * ones with no owning field. A caller that has just run `applyZodIssues`
+ * should surface these separately, or they are silently discarded.
+ */
+export function rootLevelMessages(issues) {
+    if (!issues)
+        return [];
+    return issues
+        .filter((i) => !i.path || i.path.length === 0)
+        .map((i) => i.message)
+        .filter((m) => typeof m === "string" && m.length > 0);
+}

package/dist/ui/index.d.ts

@@ -16,6 +16,8 @@ export type { SectionProps, SectionBackgroundConfig, ArticleProps, MainProps, As
 export { Section, sectionBackgroundStyle, Article, Main, Aside, Nav, BlockHeader, BlockFooter, Ul, Ol, Li, Table, Thead, Tbody, Tr, Th, Td, Code, Pre, Blockquote, Figure, Figcaption, Dl, Dt, Dd, } from "./components/Semantic";
 export type { DivProps } from "./components/Div";
 export { Div } from "./components/Div";
+export { Disclaimer } from "./components/Disclaimer";
+export type { DisclaimerProps } from "./components/Disclaimer";
 export type { SpecTableProps, SpecTableRow } from "./components/SpecTable";
 export { SpecTable } from "./components/SpecTable";
 export type { ColorVariant } from "./components/Typography";

package/dist/ui/index.js

@@ -30,6 +30,12 @@ export { FormErrorSummary } from "./forms/index.js";
 export { buildColumns, createColumnBuilder, renderBoolean, renderCurrency, renderCurrencyCompact, renderCount, renderNullable, renderRating, getStatusTone, getResourceIcon, } from "./columns/index.js";
 export { Section, sectionBackgroundStyle, Article, Main, Aside, Nav, BlockHeader, BlockFooter, Ul, Ol, Li, Table, Thead, Tbody, Tr, Th, Td, Code, Pre, Blockquote, Figure, Figcaption, Dl, Dt, Dd, } from "./components/Semantic.js";
 export { Div } from "./components/Div.js";
+/*
+ * Phase 12 — the one way to render a disclaimer. `id` only: there is no `text`
+ * prop, because an escape hatch would make it a styled box and the legally
+ * material disclaimers would be written at their call sites again.
+ */
+export { Disclaimer } from "./components/Disclaimer.js";
 export { SpecTable } from "./components/SpecTable.js";
 export { Heading, Text, Label, Caption, Span } from "./components/Typography.js";
 // --- Filter chip group (SB10-C completion, S8 2026-05-13) --------------------

package/dist/ui/rich-text/RichText.style.css

@@ -43,77 +43,42 @@
 
 
 /* --------------------------------------------------------------------------
- * THE PROSE PALETTE — rebound to appkit theme tokens.
+ * THE PROSE PALETTE LIVES IN THE CONSUMER, NOT HERE.
  *
- * 🛑 `dark:prose-invert` CANNOT COMPILE IN THIS PROJECT. Do not "fix" dark-mode
- * rich text by adding it to a call site, and do not add
- * `@source inline("dark:prose-invert")` to globals.css.
- *
- * Every `proseClass` string in appkit carries `dark:prose-invert` and NONE of
- * them has ever generated a rule, because:
- *   - the consumer build excludes appkit from scanning
- *     (`src/app/globals.css` → `@source not "../../appkit"`), and
- *   - `appkit/tailwind.config.js` does not load `@tailwindcss/typography`,
- *     so appkit's own `dist/tailwind-utilities.css` cannot emit it either.
- *
- * So `--tw-prose-invert-*` is DEFINED and never switched on. Every rich-text
- * surface on the site — product and auction descriptions, blog posts, policy
- * pages, FAQ answers, category `contentBody`, pre-orders, classifieds, digital
- * codes, live items, prize draws, events — rendered the light-theme palette in
- * every theme: body at gray-700 and links at gray-900, i.e. near-black on a
- * dark page. The links were effectively invisible.
+ * 🛑 Do NOT reinstate a `:root .prose { --tw-prose-*: ... !important }` block
+ * in this file. One lived here for months and it NEVER APPLIED.
  *
- * It was not merely unstyled, it was OVERRIDING: `important: true` in
- * `tailwind.config.js` emits `.prose :where(a) { color: var(--tw-prose-links)
- * !important }`, which beat the themed `.dark .appkit-rich-text a` rule further
- * down this file. All that theme-aware CSS was dead on arrival.
+ * The typography plugin emits `.prose { --tw-prose-*: <tailwind gray> }`, and
+ * the consumer's `important: true` makes each of those `!important` inside
+ * `@layer utilities`. The block here was unlayered, and justified itself with
+ * "`:root .prose` is (0,2,0) against `.prose`'s (0,1,0), so specificity
+ * decides and the outcome does not depend on bundle order."
  *
- * Rebinding the VARIABLES fixes it at the only point both problems meet: every
- * prose rule reads `var(--tw-prose-*)`, so one block re-themes body, links,
- * headings, bold, lists, quotes, captions, code and tables at once — in both
- * built-in themes AND in any admin-authored custom theme, which `prose-invert`
- * could never have done (its palette is hardcoded Tailwind grays).
+ * Specificity is never consulted. For the IMPORTANT tier, cascade-layer order
+ * is REVERSED and unlayered sorts LOWEST, so a layered `!important` beats an
+ * unlayered one at any specificity (Root Cause #106, measured in a browser).
+ * The plugin's hardcoded light-mode grays therefore won in every theme —
+ * links at gray-900, i.e. near-black on the near-black dark page, and
+ * black-instead-of-teal in light. The fix was invisible to every gate because
+ * the CSS was present and correct-looking in `dist/styles.css`; only a
+ * rendered page shows it losing.
  *
- * 🛑 The specificity is deliberate and must not be lowered. `.prose` declares
- * these variables with `!important`, so an equal-importance override is decided
- * by EMISSION ORDER between two separate stylesheets — the non-deterministic
- * trap of Root Cause #79. `:root .prose` is (0,2,0) against `.prose`'s (0,1,0),
- * so specificity decides and the outcome does not depend on bundle order. The
- * dark block at (0,3,0) also outranks `.dark .prose-invert` (0,2,0), so this
- * stays correct even if someone later makes `prose-invert` compile.
+ * Owner is now `tailwind.config.js` → `theme.extend.typography`, which makes
+ * the plugin emit the appkit tokens in the first place so there is exactly
+ * one declaration and no contest. Each binds to an `--appkit-color-*` that is
+ * redefined per theme, so prose re-themes for the built-in themes and for any
+ * admin-authored one.
  *
- * Not scoped to `.appkit-rich-text` on purpose: `PolicyPageView` and the scams
- * FAQ page apply `prose` to a bare `<div>` and had the identical defect.
+ * 🛑 `dark:prose-invert` CANNOT COMPILE IN THIS PROJECT. Do not "fix" dark
+ * rich text by adding it to a call site, and do not add
+ * `@source inline("dark:prose-invert")` to globals.css. Every `proseClass`
+ * string in appkit carries it and none has ever generated a rule, because the
+ * consumer build excludes appkit from scanning (`src/app/globals.css` →
+ * `@source not "../../appkit"`) and `appkit/tailwind.config.js` does not load
+ * `@tailwindcss/typography`, so appkit's own `dist/tailwind-utilities.css`
+ * cannot emit it either. It is moot now regardless: the tokens above invert on
+ * their own, which `prose-invert` could never do with its hardcoded grays.
  * -------------------------------------------------------------------------- */
-:root .prose {
-  --tw-prose-body: var(--appkit-color-text-muted) !important;
-  --tw-prose-headings: var(--appkit-color-text) !important;
-  --tw-prose-lead: var(--appkit-color-text-muted) !important;
-  --tw-prose-links: var(--appkit-color-primary-600) !important;
-  --tw-prose-bold: var(--appkit-color-text) !important;
-  --tw-prose-counters: var(--appkit-color-text-faint) !important;
-  --tw-prose-bullets: var(--appkit-color-text-faint) !important;
-  --tw-prose-hr: var(--appkit-color-border) !important;
-  --tw-prose-quotes: var(--appkit-color-text) !important;
-  --tw-prose-quote-borders: var(--appkit-color-primary) !important;
-  --tw-prose-captions: var(--appkit-color-text-faint) !important;
-  --tw-prose-kbd: var(--appkit-color-text) !important;
-  --tw-prose-kbd-shadows: 24 24 27 !important;
-  --tw-prose-code: var(--appkit-color-text) !important;
-  --tw-prose-pre-code: var(--appkit-color-slate-200) !important;
-  --tw-prose-pre-bg: var(--appkit-color-slate-800) !important;
-  --tw-prose-th-borders: var(--appkit-color-border) !important;
-  --tw-prose-td-borders: var(--appkit-color-border) !important;
-}
-
-/* Only the values that are genuinely theme-specific. Everything above already
- * inverts, because `--appkit-color-text`/`-text-muted`/`-border` are redefined
- * per theme in tokens.css — which is the whole point of binding to them. */
-:root.dark .prose {
-  --tw-prose-links: var(--appkit-color-secondary-400) !important;
-  --tw-prose-kbd-shadows: 250 250 250 !important;
-  --tw-prose-pre-bg: var(--appkit-color-surface) !important;
-}
 
 /* --------------------------------------------------------------------------
  * Base wrapper. All selectors are scoped to .appkit-rich-text so they
@@ -200,27 +165,31 @@
 }
 
 /* --- Links ---------------------------------------------------------------- */
+/* No `.dark` variant, deliberately: `--appkit-color-link` is redefined per
+ * theme, so one rule covers every theme including admin-authored ones. The two
+ * `.dark .appkit-rich-text a` rules that used to sit here were also dead —
+ * non-important against the plugin's `.prose :where(a){color:…!important}`.
+ *
+ * Decoration binds to `currentColor` rather than naming the token a second
+ * time. That matters beyond brevity: the colour here IS still overridden by
+ * the plugin on any element that also carries `.prose`, so a hardcoded
+ * decoration colour could disagree with the ink actually rendered. With
+ * `currentColor` the underline follows whatever won. */
 .appkit-rich-text a {
-  color: var(--appkit-color-primary-600);
+  color: var(--appkit-color-link);
   text-decoration: underline;
-  text-decoration-color: color-mix(in srgb, var(--appkit-color-primary-600) 60%, transparent);
+  text-decoration-color: color-mix(in srgb, currentColor 60%, transparent);
   text-underline-offset: 2px;
   transition: color 150ms, text-decoration-color 150ms;
 }
 
+/* Hover moves the link toward the page's own text colour, which darkens it in
+ * a light theme and lightens it in a dark one — so this needs no per-theme
+ * pair either. The plugin sets no `a:hover`, so unlike the resting colour
+ * above this rule is genuinely the one in effect. */
 .appkit-rich-text a:hover {
-  color: var(--appkit-color-primary-700);
-  text-decoration-color: color-mix(in srgb, var(--appkit-color-primary-700) 70%, transparent);
-}
-
-.dark .appkit-rich-text a {
-  color: var(--appkit-color-secondary-400);
-  text-decoration-color: color-mix(in srgb, var(--appkit-color-secondary-400) 60%, transparent);
-}
-
-.dark .appkit-rich-text a:hover {
-  color: var(--appkit-color-secondary-300);
-  text-decoration-color: color-mix(in srgb, var(--appkit-color-secondary-300) 60%, transparent);
+  color: color-mix(in srgb, var(--appkit-color-link) 80%, var(--appkit-color-text));
+  text-decoration-color: currentColor;
 }
 
 /* --- Tables --------------------------------------------------------------- */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mohasinac/appkit",
-  "version": "4.61.0",
+  "version": "4.62.1",
   "license": "MIT",
   "publishConfig": {
     "access": "public"