@sesamehr/react-design-system 2.0.0-beta.4 → 2.0.0-beta.6

package/dist/Button/IconButton/IconButton.d.ts

@@ -0,0 +1,32 @@
+import { ButtonVariants } from '../index.ts';
+import { IconButtonVariants } from './index.ts';
+export interface IconButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+    /**
+     * `Button`'s colours, by its own words — the design file calls the filled
+     * one `primary`, but `Button` has called it `default` since it shipped and a
+     * caller swapping one for the other should not relearn the one word that
+     * differs. No `link`: the design has no such icon button, and a link with no
+     * text has no accessible name by construction.
+     */
+    variant?: Exclude<ButtonVariants['variant'], 'link'>;
+    size?: IconButtonVariants['size'];
+    /**
+     * What a screen reader announces. Required — it narrows the optional
+     * `aria-label` this inherits from `ButtonHTMLAttributes` — because the glyph
+     * is the whole control, so there is no text for the browser to fall back to
+     * and an unlabelled one announces as "button" and nothing else. No default
+     * can describe what an icon a caller chose is for, so there is not one.
+     */
+    'aria-label': string;
+    /** Render as the child element instead of a `<button>` (Radix Slot). */
+    asChild?: boolean;
+}
+/**
+ * IconButton — mirrors `@sesame/orxata-core` IconButton.
+ *
+ * A button whose entire content is an icon, circular at every size. The icon
+ * comes from the caller as `children`; this sizes it and never picks it.
+ * `asChild` renders the child element instead of a `<button>`, via
+ * `@radix-ui/react-slot`.
+ */
+export declare const IconButton: import('react').ForwardRefExoticComponent<IconButtonProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Button/IconButton/index.d.ts

@@ -0,0 +1,27 @@
+import { VariantProps } from 'class-variance-authority';
+export { IconButton, type IconButtonProps } from './IconButton.tsx';
+/**
+ * The shape half only — the radius and the four square boxes. That is all this
+ * component adds.
+ *
+ * The colours are `Button`'s, and not a copy of them: `IconButton.tsx` calls
+ * `buttonVariants` for the variant and this for the size, so the six colour
+ * rules live in one file and a token changes in one place. Use both together if
+ * you are putting the classes on your own element:
+ *
+ * ```ts
+ * cn(buttonVariants({ variant, size: null }), iconButtonVariants({ size }))
+ * ```
+ *
+ * `size: null` is cva's opt-out, and it is load-bearing: `buttonVariants`
+ * defaults to `md`, which would bring `px-5`, `h-12` and `rounded-2xl` along
+ * and stop the box being a square circle.
+ *
+ * Class names, not utilities — see the long note in `../index.ts` for why a
+ * utility in a variant forces the package to publish `.size-12` into the
+ * consumer's cascade.
+ */
+export declare const iconButtonVariants: (props?: ({
+    size?: "xs" | "sm" | "md" | "lg" | null | undefined;
+} & import('class-variance-authority/types').ClassProp) | undefined) => string;
+export type IconButtonVariants = VariantProps<typeof iconButtonVariants>;

package/dist/Data/Table/Table.d.ts

@@ -37,7 +37,7 @@ export interface TableComponentProps<TData = unknown> {
     /** Center table content (default slot) — custom mode only. */
     children?: ReactNode;
 }
-export declare function Table<TData = unknown>({ enableDragToScroll, table, renderCell, renderHeader, detailRow: detailRowSlot, bulkHeader, bulkActions, pagination, empty, fixedLeft, fixedRight, children, }: TableComponentProps<TData>): import("react/jsx-runtime").JSX.Element;
+export declare function Table<TData = unknown>({ loading, enableDragToScroll, table, renderCell, renderHeader, detailRow: detailRowSlot, bulkHeader, bulkActions, pagination, empty, fixedLeft, fixedRight, children, }: TableComponentProps<TData>): import("react/jsx-runtime").JSX.Element;
 export declare namespace Table {
     var displayName: string;
 }

package/dist/Data/Table/TableSelectCell/TableSelectCell.d.ts

@@ -4,6 +4,14 @@ export interface TableSelectCellProps extends Omit<React.ComponentPropsWithoutRe
     /** Usually fixed to left */
     fixed?: boolean;
     fixedOffset?: string;
+    /**
+     * Whether this row can be selected at all.
+     *
+     * On the header cell it disables select-all, which is the right thing when
+     * nothing in the table can be selected — a checkbox that ticks and then
+     * selects nothing is worse than one that says so.
+     */
+    disabled?: boolean;
     onChange?: (checked: boolean) => void;
 }
 export declare const TableSelectCell: import('react').ForwardRefExoticComponent<TableSelectCellProps & import('react').RefAttributes<HTMLTableCellElement>>;

package/dist/Data/Table/hooks/useTableVirtual/useTableVirtual.d.ts

@@ -7,7 +7,7 @@ import { UseTableVirtualOptions, UseTableVirtualReturn } from './useTableVirtual
  * the other nine thousand nine hundred and eighty.
  *
  * ```tsx
- * const virtual = useTableVirtual(employees, { height: '480px' });
+ * const virtual = useTableVirtual(employees, { maxHeight: '480px' });
  *
  * <TableVirtualized virtualizer={virtual}>
  *   <TableBody>

package/dist/Data/Table/hooks/useTableVirtual/useTableVirtual.types.d.ts

@@ -1,13 +1,25 @@
 import { RefObject } from 'react';
 export interface UseTableVirtualOptions {
     /**
-     * How tall the table's scrollport is, as a CSS length.
+     * How tall the table's scrollport is allowed to get, as a CSS length.
+     *
+     * A ceiling rather than a measurement: given fewer rows than it has room
+     * for, the table shrinks to them instead of leaving empty space under the
+     * last one.
+     *
+     * Any length the browser understands: `'480px'`, `'30vh'`,
+     * `'calc(100vh - 12rem)'`. It is written straight onto the element and the
+     * window is worked out from what that element ends up measuring, so nothing
+     * here cares which unit you used. `'100%'` works too, as long as whatever
+     * contains the table has a height of its own — a percentage of `auto` is
+     * `auto`, and a table that grows to fit its rows is the one case this cannot
+     * work with.
      *
      * Virtualising needs one. A table that grows to fit its rows has no scrollbar
      * of its own — the page scrolls instead — and with nothing scrolling there is
      * no position to work a window out from.
      */
-    height?: string;
+    maxHeight?: string;
     /**
      * How tall one row is, in pixels.
      *
@@ -48,7 +60,7 @@ export interface UseTableVirtualReturn<TData> {
      * stopped from taking it over.
      */
     claim: (element: HTMLElement | null) => void;
-    height: string | undefined;
+    maxHeight: string | undefined;
     /** The height of everything above the window, and of everything below it. */
     padStart: number;
     padEnd: number;

package/dist/Data/Table/index.d.ts

@@ -10,7 +10,6 @@ export { TableDragCell, type TableDragCellProps, } from './TableDragCell/TableDr
 export { TableBulkHeader, type TableBulkHeaderProps, } from './TableBulkHeader/TableBulkHeader.tsx';
 export { TablePagination, type TablePaginationProps, } from './TablePagination/TablePagination.tsx';
 export { TableEmpty, type TableEmptyProps } from './TableEmpty/TableEmpty.tsx';
-export { TableAvatar, type TableAvatarProps, } from './TableAvatar/TableAvatar.tsx';
 export { TableRowExpanded, type TableRowExpandedProps, } from './TableRowExpanded/TableRowExpanded.tsx';
 export { TableExpandCell, type TableExpandCellProps, } from './TableExpandCell/TableExpandCell.tsx';
 export { TableColumnVisibility, type TableColumnVisibilityProps, } from './TableColumnVisibility/TableColumnVisibility.tsx';

package/dist/Display/AvatarDetails/AvatarDetails.d.ts

@@ -0,0 +1,31 @@
+/**
+ * An avatar with a name and an optional second line beside it.
+ *
+ * `name` and `subtitle` are props and not `children`, which reads as a
+ * violation of composition-over-configuration and is a deliberate exception.
+ * Sameness is the whole product here: this pattern appears on every list, table
+ * and picker we ship, and the point of having a component for it is that all of
+ * them render the same two lines at the same sizes and weights. Taking a node
+ * hands that decision back to the caller, and the first one to put a badge, a
+ * link or a third line in it is the moment the component stops guaranteeing
+ * anything. Callers who genuinely need arbitrary content next to an avatar
+ * should compose `AvatarSquare` themselves rather than widen this.
+ *
+ * The prop list is full at five plus `dataTestid`, which is the cap. Anything
+ * further has to replace one of these or be argued as a separate component —
+ * there is no room left to slip one in.
+ */
+export interface AvatarDetailsProps extends React.ComponentPropsWithoutRef<'div'> {
+    /** Image source URL */
+    src?: string;
+    /** Fallback initials (max 2 characters) */
+    initials?: string;
+    /** Disabled state */
+    disabled?: boolean;
+    /** Full name to display */
+    name: string;
+    /** Subtitle (department, role, etc.) */
+    subtitle?: string;
+    dataTestid: string;
+}
+export declare const AvatarDetails: import('react').ForwardRefExoticComponent<AvatarDetailsProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Display/AvatarDetails/index.d.ts

@@ -0,0 +1 @@
+export { AvatarDetails, type AvatarDetailsProps } from './AvatarDetails.tsx';

package/dist/Display/Chip/Chip.d.ts

@@ -12,7 +12,13 @@ export interface ChipProps extends Omit<React.ButtonHTMLAttributes<HTMLButtonEle
      * `:focus-visible`, and there is no `:dragging`.
      */
     dragged?: boolean;
+    /** Render as the child element instead of a `<button>` (Radix Slot). */
+    asChild?: boolean;
     dataTestid: string;
 }
-/** Chip — mirrors `@sesame/orxata-core` Chip. */
+/**
+ * Chip — mirrors `@sesame/orxata-core` Chip.
+ * `asChild` renders the child element instead of a `<button>`, via
+ * `@radix-ui/react-slot`. It is what the Vue side spells `as` / `as-child`.
+ */
 export declare const Chip: import('react').ForwardRefExoticComponent<ChipProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Display/Chip/index.d.ts

@@ -2,10 +2,15 @@ import { VariantProps } from 'class-variance-authority';
 export { Chip } from './Chip.tsx';
 export type { ChipProps } from './Chip.tsx';
 /**
- * A chip is a control the user acts on — a value they picked and can drop, a
- * filter they can press. `Badge` is the system talking back: a status it
- * assigned, a count it worked out, nothing to click. That is the line between
- * them, and it is why this one is an outlined button and that one a solid fill.
+ * A chip is a value the user picked — one they can drop, a filter they can
+ * press. `Badge` is the system talking back: a status it assigned, a count it
+ * worked out. That is the line between them, and it is why this one is outlined
+ * and that one a solid fill.
+ *
+ * It renders a `<button>` by default because pressing one is the common case,
+ * but that is a default and not the component: `asChild` renders it as anything,
+ * and a chip that only shows a value should be a `<span>` rather than a control
+ * with nothing behind it.
  *
  * Class names, not utilities: the declarations live in `Chip.module.css` behind
  * `@apply`. See `Button/index.ts` for the full reasoning.

package/dist/Feedback/Loader/Loader.d.ts

@@ -0,0 +1,16 @@
+export interface LoaderProps extends React.HTMLAttributes<HTMLSpanElement> {
+    dataTestid: string;
+}
+/**
+ * The Sesame mark drawing itself, ported from the `HR-loading` After Effects
+ * composition the product ships as a Lottie.
+ *
+ * Nothing in that composition moves: all twelve layers have a static transform
+ * and the whole animation lives in trim paths, which is `stroke-dasharray` plus
+ * `stroke-dashoffset` under another name. So the port needs no player — the
+ * twelve layers collapse to two shapes drawn twice, and the trims become the
+ * `@keyframes` in the stylesheet. That is the reason there is no `lottie-web`
+ * here: 250 KB on every consumer to replay an animation the stylesheet can
+ * express itself.
+ */
+export declare const Loader: import('react').ForwardRefExoticComponent<LoaderProps & import('react').RefAttributes<HTMLSpanElement>>;

package/dist/Feedback/Loader/index.d.ts

@@ -0,0 +1,2 @@
+export { Loader } from './Loader.tsx';
+export type { LoaderProps } from './Loader.tsx';

package/dist/Feedback/Progress/Progress.d.ts

@@ -1,7 +1,10 @@
+import { ProgressVariants } from './index.ts';
 import * as ProgressPrimitive from '@radix-ui/react-progress';
 export interface ProgressProps extends Omit<React.ComponentPropsWithoutRef<typeof ProgressPrimitive.Root>, 'value'> {
     /** How far along, 0 to 100 */
     value?: number;
+    /** What the bar is saying: still going, done, done with a caveat, or failed */
+    variant?: ProgressVariants['variant'];
     dataTestid: string;
 }
 /** Progress — mirrors `@sesame/orxata-core` Progress. */

package/dist/Feedback/Progress/index.d.ts

@@ -1,2 +1,19 @@
+import { VariantProps } from 'class-variance-authority';
 export { Progress } from './Progress.tsx';
 export type { ProgressProps } from './Progress.tsx';
+/**
+ * What the bar is saying, not how far along it is.
+ *
+ * `brand` is a bar still filling. The other three are a bar that has stopped
+ * and has something to report: a job that finished, one that finished with
+ * something to look at, one that failed. They are the same three the rest of
+ * the system uses for that, and they read the same here.
+ *
+ * A determinate bar at 100% is not automatically `success` — an upload that
+ * reached the end and then failed to process is at 100% and is not good news.
+ * The variant is the caller's to say.
+ */
+export declare const progressVariants: (props?: ({
+    variant?: "success" | "warning" | "brand" | "error" | null | undefined;
+} & import('class-variance-authority/types').ClassProp) | undefined) => string;
+export type ProgressVariants = VariantProps<typeof progressVariants>;

package/dist/Forms/Inputs/Calendar/Calendar.d.ts

@@ -0,0 +1,60 @@
+import { CalendarDayState } from './CalendarDay.tsx';
+import { CalendarConstraints } from './constraints.ts';
+/** One day. Falls back to `OxCalendarDay`. */
+type DayRenderer = (props: {
+    date: Date;
+    state: CalendarDayState;
+}) => React.ReactNode;
+/**
+ * A month of days, and nothing around it. Mirrors `@sesame/orxata-core`
+ * Calendar.
+ *
+ * `Calendar` speaks `Date`. A `Date` at the boundary means the calendar day
+ * formed by its local year, month and day: the time is ignored on the way in,
+ * and is local midnight on the way out.
+ *
+ * There is no month title and no navigation — `header` is not called until you
+ * pass one, and is handed everything a header needs. The shared, opinionated
+ * one belongs a layer up, in `DatePicker`.
+ *
+ * Not `OxCalendarDate`, which also ships: that is a `<time>` chip showing a day
+ * and an abbreviated month, not a grid.
+ */
+export interface CalendarProps extends Pick<React.HTMLAttributes<HTMLDivElement>, 'className'> {
+    /** The selected day, or `undefined` for none. Controlled. */
+    value?: Date;
+    /** The initially selected day, for the uncontrolled case. */
+    defaultValue?: Date;
+    onValueChange?: (value: Date | undefined) => void;
+    /** How many month grids to render. */
+    months?: number;
+    /** What can be picked, and where navigation stops. */
+    constraints?: CalendarConstraints;
+    /**
+     * Empty by default. Receives the visible month and the navigation state,
+     * because without those nobody could build a header at all.
+     */
+    header?: (state: {
+        month: Date;
+        goToPrev: () => void;
+        goToNext: () => void;
+        canGoPrev: boolean;
+        canGoNext: boolean;
+    }) => React.ReactNode;
+    /**
+     * One month's name, above its grid. Falls back to the month and year from
+     * `Intl`, and only renders when `months` is more than one — a lone month is
+     * named by `header`, and naming it twice is worse than not at all.
+     */
+    month?: (props: {
+        month: Date;
+    }) => React.ReactNode;
+    /** One day. Falls back to `OxCalendarDay`. */
+    day?: DayRenderer;
+    dataTestid: string;
+}
+export declare const Calendar: {
+    ({ className, value, defaultValue, onValueChange, months, month: renderMonth, constraints, header, day, dataTestid, }: CalendarProps): import("react/jsx-runtime").JSX.Element;
+    displayName: string;
+};
+export {};

package/dist/Forms/Inputs/Calendar/CalendarDay.d.ts

@@ -0,0 +1,37 @@
+/**
+ * The five booleans are what `Calendar` hands to the `day` render prop, and
+ * they are the `data-*` vocabulary this emits. `range` is `CalendarRange`'s
+ * alone.
+ */
+export interface CalendarDayState {
+    selected: boolean;
+    today: boolean;
+    disabled: boolean;
+    outside: boolean;
+    focused: boolean;
+    range?: 'start' | 'middle' | 'end';
+}
+export interface CalendarDayProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+    /**
+     * Partial so a single state can be shown on its own, which is what the guide
+     * does. Inside a calendar the render prop always supplies all of it.
+     */
+    state?: Partial<CalendarDayState>;
+}
+/**
+ * One day in a calendar grid: a button that shows its number and paints the
+ * state it is told about. Mirrors `@sesame/orxata-core` CalendarDay.
+ *
+ * Not `OxCalendarDate`, which also ships and which the name invites confusing
+ * this with. That one is a `<time>` chip showing a day and an abbreviated
+ * month — no button, no selection, no keyboard. This one is the cell.
+ *
+ * It is **told** its state and never reads it from context, so it renders on
+ * its own — the guide shows the states as a legend, outside any calendar — and
+ * so that it is assembled the same way as its Vue original.
+ *
+ * `disabled` is applied before the prop spread on purpose: `DayPicker` passes
+ * its own, leaving a focused-but-disabled day focusable with `aria-disabled`
+ * instead, and its answer has to win over the one derived from `state`.
+ */
+export declare const CalendarDay: import('react').ForwardRefExoticComponent<CalendarDayProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Forms/Inputs/Calendar/CalendarRange.d.ts

@@ -0,0 +1,61 @@
+import { CalendarDayState } from './CalendarDay.tsx';
+import { CalendarConstraints } from './constraints.ts';
+/** One day. Falls back to `OxCalendarDay`. */
+type DayRenderer = (props: {
+    date: Date;
+    state: CalendarDayState;
+}) => React.ReactNode;
+/**
+ * `start` and `end`, not `from` and `to` — those two words are already the
+ * navigation bounds in `constraints`, and one word meaning two things inside
+ * the same component is the confusion this naming was chosen to avoid.
+ */
+export interface CalendarDateRange {
+    start?: Date;
+    end?: Date;
+}
+/**
+ * A month of days where two clicks pick a span. Mirrors `@sesame/orxata-core`
+ * CalendarRange. A sibling of `Calendar` with its own API, not a part of it.
+ *
+ * Same date contract: a `Date` at the boundary means the calendar day formed by
+ * its local year, month and day.
+ */
+export interface CalendarRangeProps extends Pick<React.HTMLAttributes<HTMLDivElement>, 'className'> {
+    /** The selected span. Either end may be absent while one is being picked. */
+    value?: CalendarDateRange;
+    /** The initially selected span, for the uncontrolled case. */
+    defaultValue?: CalendarDateRange;
+    onValueChange?: (value: CalendarDateRange) => void;
+    /** How many month grids to render. */
+    months?: number;
+    /** What can be picked, and where navigation stops. */
+    constraints?: CalendarConstraints;
+    /**
+     * Empty by default. Receives the visible month and the navigation state,
+     * because without those nobody could build a header at all.
+     */
+    header?: (state: {
+        month: Date;
+        goToPrev: () => void;
+        goToNext: () => void;
+        canGoPrev: boolean;
+        canGoNext: boolean;
+    }) => React.ReactNode;
+    /**
+     * One month's name, above its grid. Falls back to the month and year from
+     * `Intl`, and only renders at all when there is more than one grid — a lone
+     * month is named by `header`, and naming it twice is worse than not at all.
+     */
+    month?: (props: {
+        month: Date;
+    }) => React.ReactNode;
+    /** One day. Falls back to `OxCalendarDay`. */
+    day?: DayRenderer;
+    dataTestid: string;
+}
+export declare const CalendarRange: {
+    ({ className, value, defaultValue, onValueChange, months, month: renderMonth, constraints, header, day, dataTestid, }: CalendarRangeProps): import("react/jsx-runtime").JSX.Element;
+    displayName: string;
+};
+export {};

package/dist/Forms/Inputs/Calendar/constraints.d.ts

@@ -0,0 +1,19 @@
+/**
+ * What can be picked, and where navigation stops.
+ *
+ * Grouped on purpose: the three fields are one concept, and the range-length
+ * pair `CalendarRange` will eventually want has to fit here without a redesign.
+ *
+ * The bounds are `from` / `to`, not `min` / `max`. In `react-day-picker` those
+ * two words already mean the minimum and maximum *number of days* a range may
+ * span, which is the length limit this will grow. Keeping them free avoids the
+ * collision instead of explaining it forever.
+ */
+export interface CalendarConstraints {
+    /** The earliest month the calendar will navigate to. */
+    from?: Date;
+    /** The latest month the calendar will navigate to. */
+    to?: Date;
+    /** Called per day. Return `true` to make it unpickable. */
+    isDisabled?: (date: Date) => boolean;
+}

package/dist/Forms/Inputs/Calendar/index.d.ts

@@ -0,0 +1,20 @@
+import { VariantProps } from 'class-variance-authority';
+export { Calendar, type CalendarProps } from './Calendar.tsx';
+export { CalendarRange, type CalendarRangeProps, type CalendarDateRange, } from './CalendarRange.tsx';
+export { CalendarDay, type CalendarDayProps, type CalendarDayState, } from './CalendarDay.tsx';
+export type { CalendarConstraints } from './constraints.ts';
+/**
+ * Only the range position varies here. The other five states — selected,
+ * today, disabled, focused, outside — are `data-*` attributes rather than
+ * classes, because those five are the vocabulary a caller writes their own CSS
+ * against and a parallel set of class names would be a second spelling of the
+ * same thing.
+ *
+ * The range position is not in that vocabulary: it is `CalendarRange`'s alone,
+ * and `react-day-picker` and reka disagree about what to call it, so it stays
+ * ours and stays a class.
+ */
+export declare const calendarDayVariants: (props?: ({
+    range?: "end" | "start" | "middle" | null | undefined;
+} & import('class-variance-authority/types').ClassProp) | undefined) => string;
+export type CalendarDayVariants = VariantProps<typeof calendarDayVariants>;

package/dist/Forms/Inputs/Calendar/testids.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Test ids are derived from the root's, so `months: 12` still produces twelve
+ * distinct `day-12`s — the month precedes them.
+ *
+ * The month is numeric, not a name: a name derived from `Intl` becomes
+ * `month-marzo` the moment the locale changes, and takes every test with it.
+ *
+ *   calendar-for-vacations                       ← root, supplied by the caller
+ *   calendar-for-vacations-month-2026-03         ← each month grid
+ *   calendar-for-vacations-month-2026-03-day-12  ← each cell
+ */
+/** Built from the local parts, for the same reason `date.ts` is. */
+export declare const monthTestid: (root: string, month: Date) => string;
+/**
+ * `undefined` for a day borrowed from the neighbouring month, which is why the
+ * `outside` argument is not optional — the caller has to have answered it.
+ *
+ * Such a day is drawn in a grid it does not belong to, and with `months: 2` it
+ * is drawn twice: the 1st of April sits in April's grid and again in the tail
+ * of March's. Giving both the same id would hand `getByTestId` two elements and
+ * fail the query; giving them different ids would mean an id that does not say
+ * which grid it came from. Neither is worth it for a day that is decoration —
+ * a test that wants the 1st of April pins April.
+ */
+export declare const dayTestid: (monthId: string, day: Date, outside: boolean) => string | undefined;

package/dist/Forms/Inputs/Calendar/useCalendarLocale.d.ts

@@ -0,0 +1,22 @@
+/** Sunday through Saturday, the numbering both primitives take. */
+export type WeekStart = 0 | 1 | 2 | 3 | 4 | 5 | 6;
+/**
+ * Derived from the locale rather than taken as a prop. A prop would let an
+ * application put Monday first while every date it formats says otherwise, and
+ * the locale already carries the answer for every region ICU knows.
+ */
+export declare const weekStartsOnFor: (locale: string) => WeekStart;
+/**
+ * The locale the calendar formats in, and the week start that follows from it.
+ *
+ * `useLocale()` yields `undefined` when nothing provided one, which every other
+ * component hands straight to `Intl` to mean "follow the runtime".
+ * `react-day-picker` instead needs a `date-fns` locale *object*, and the one it
+ * falls back to is `en-US` — so the month names would disagree with the rest of
+ * the page. Resolving the runtime's own locale here, and formatting through
+ * `Intl`, keeps them in step without shipping a locale table.
+ */
+export declare const useCalendarLocale: () => {
+    locale: string;
+    weekStartsOn: WeekStart;
+};

package/dist/Forms/Inputs/Combobox/ComboboxCancel.d.ts

@@ -0,0 +1,14 @@
+export interface ComboboxCancelProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+    dataTestid: string;
+}
+/**
+ * ComboboxCancel — clears the search term without closing the popup.
+ *
+ * Radix ships no combobox at all, so there is no `Cancel` part to wrap: this
+ * reproduces reka's, which renders a `<button type="button" tabindex="-1">` and
+ * empties the filter on click. `tabindex="-1"` is reka's and is kept — the
+ * field's own clear affordances are the keyboard path, and a tab stop between
+ * the input and the trigger would be one more thing to pass through on the way
+ * to the list.
+ */
+export declare const ComboboxCancel: import('react').ForwardRefExoticComponent<ComboboxCancelProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Forms/Inputs/Combobox/ComboboxChipsInput.d.ts

@@ -10,5 +10,9 @@ export interface ComboboxChipsInputProps extends Omit<React.InputHTMLAttributes<
  * ComboboxChipsInput — the search field with the current selection as chips.
  * Multi-select field: renders the selected values as removable chips (read from
  * the shared `multiple` model) alongside the search field.
+ *
+ * The chips stay on one line. Those that do not fit are taken out of flow and
+ * stood in for by a `+N` counter; see `useChipOverflow` for how the line is
+ * measured.
  */
 export declare const ComboboxChipsInput: import('react').ForwardRefExoticComponent<ComboboxChipsInputProps & import('react').RefAttributes<HTMLInputElement>>;

package/dist/Forms/Inputs/Combobox/index.d.ts

@@ -1,4 +1,5 @@
 export { Combobox, type ComboboxProps } from './Combobox.tsx';
+export { ComboboxCancel, type ComboboxCancelProps } from './ComboboxCancel.tsx';
 export { ComboboxInput, type ComboboxInputProps } from './ComboboxInput.tsx';
 export { ComboboxChipsInput, type ComboboxChipsInputProps, } from './ComboboxChipsInput.tsx';
 export { ComboboxContent, type ComboboxContentProps, } from './ComboboxContent.tsx';

package/dist/Forms/Inputs/Combobox/useChipOverflow.d.ts

@@ -0,0 +1,30 @@
+import { RefObject } from 'react';
+export interface ChipOverflowTargets {
+    /**
+     * The single-line row holding the chips, the `+N` counter and the query
+     * field. Its width is the whole budget, which only holds because the row is
+     * laid out `flex: 1 1 0` with `min-width: 0` — its width is then whatever its
+     * siblings leave behind and owes nothing to its own content. Measuring an
+     * element whose size depends on how many chips we decided to show is exactly
+     * what turns this into an infinite loop.
+     */
+    row: RefObject<HTMLElement | null>;
+    /** Offscreen stand-in for the `+N` counter, rendered at its widest. */
+    sizer: RefObject<HTMLElement | null>;
+}
+/**
+ * Decides how many chips of a multi-select field fit on one line.
+ *
+ * The chips past the edge are not removed from the DOM — the component keeps
+ * them rendered and takes them out of flow — so every chip reports its natural
+ * width on every pass, whether or not it is currently shown. That is the whole
+ * trick: nothing measured here changes as a result of what is decided here, so
+ * a measurement can never provoke the measurement that follows it.
+ *
+ * With no layout at all — a test environment, the tick before styles land —
+ * every width reads zero, `0 <= 0` holds, and the answer is "all of them".
+ * Showing the full selection is the right way to be wrong: it is what the field
+ * did before, and it fails towards markup that shows too much rather than a
+ * field that hides its own contents.
+ */
+export declare function useChipOverflow({ row, sizer }: ChipOverflowTargets, total: number): number;

package/dist/Forms/Inputs/SearchBar/SearchBar.d.ts

@@ -0,0 +1,35 @@
+import { SearchBarVariants } from './index.ts';
+export interface SearchBarProps extends Omit<React.InputHTMLAttributes<HTMLInputElement>, 'size' | 'type' | 'value' | 'defaultValue'> {
+    variant?: SearchBarVariants['variant'];
+    size?: SearchBarVariants['size'];
+    /**
+     * Milliseconds of no typing before `onSearch` fires. `0` fires on every
+     * keystroke.
+     */
+    delay?: number;
+    /** Controlled term. Pair with `onValueChange`; omit for uncontrolled. */
+    value?: string;
+    /** Starting term when uncontrolled. */
+    defaultValue?: string;
+    /** Called on every keystroke with the next term, without waiting. */
+    onValueChange?: (value: string) => void;
+    /** Called once typing has been quiet for `delay` ms — and at once on Enter or clear. */
+    onSearch?: (term: string) => void;
+    dataTestid: string;
+}
+/**
+ * A search field: magnifier, term, and a clear button once there is something
+ * to clear. Mirrors `@sesame/orxata-core` SearchBar.
+ *
+ * Written on a native `<input type="search">` rather than on a primitive
+ * because there is no primitive to start from — Radix has no search component,
+ * and shadcn's own `Input` is a bare element too. Nothing here needs what a
+ * primitive would bring: no portal, no focus trap, no escape handling. The one
+ * browser affordance it *does* bring — WebKit's built-in cancel button — is
+ * turned off in the stylesheet, since we draw our own.
+ *
+ * `className` lands on the root, which is the box; everything else a native
+ * `<input>` takes — `placeholder`, `name`, `disabled`, `aria-label` — falls
+ * through to the control. The `ref` is the root for the same reason.
+ */
+export declare const SearchBar: import('react').ForwardRefExoticComponent<SearchBarProps & import('react').RefAttributes<HTMLDivElement>>;