@sesamehr/react-design-system 3.6.0 → 3.7.0

package/dist/Display/RichText/RichText.d.ts

@@ -0,0 +1,31 @@
+export interface RichTextProps extends Omit<React.HTMLAttributes<HTMLDivElement>, 'dangerouslySetInnerHTML'> {
+    /**
+     * Markup to render as a formatted document.
+     *
+     * **This is a prop carrying content, which the composition rules forbid, and
+     * it is here because the rule has no reading under which this could be
+     * `children`.** `children` takes *nodes*; what a caller has is a *string* —
+     * HTML out of a database, out of an API, out of a TipTap `getHTML()`. Hand a
+     * string to `children` and React renders it as text, escaped. So the string
+     * path is a prop, and the component owns the sanitising that makes it safe —
+     * which is the other half of why it is a prop at all. A caller reaching for
+     * `dangerouslySetInnerHTML` themselves is what this exists to replace, and
+     * the one use of it in the package is inside here.
+     *
+     * `children` is still the composition-first path and the one to reach for
+     * when the caller already has nodes: `<OxRichText><h2>…</h2></OxRichText>`
+     * needs no sanitising, because those are theirs and never went through a
+     * string. Both paths are styled by the same selectors, so neither is a
+     * second-class way to use this.
+     *
+     * Pass one or the other. With `html` set, `children` is not rendered.
+     */
+    html?: string;
+}
+/**
+ * RichText — mirrors `sesame/orxata-core` RichText.
+ *
+ * Content that was written somewhere else, rendered so it reads as a formatted
+ * document. It depends on nothing: no editor, no TipTap, not even installed.
+ */
+export declare const RichText: import('react').ForwardRefExoticComponent<RichTextProps & import('react').RefAttributes<HTMLDivElement>>;

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

@@ -0,0 +1,26 @@
+export { RichText } from './RichText.tsx';
+export { sanitizeHtml } from './sanitizeHtml.ts';
+/**
+ * Every node and mark the prose stylesheet in `RichText.module.css` draws — the
+ * ceiling the editor is allowed to produce, named rather than only documented.
+ *
+ * It is here, beside the stylesheet, and not beside the editor, because the
+ * stylesheet is what decides it. `OxRichTextEditor` reads this list in
+ * development and warns about anything in the caller's schema that is missing
+ * from it, and `RichText.test.tsx` asserts the other direction: that every name
+ * below has a selector in the stylesheet and that no `ox-rich-text` selector
+ * styles something absent from it. Between the two, adding an extension to the
+ * preset without styling it fails a test, and a consumer adding one of their
+ * own gets told at the console.
+ *
+ * The spellings are ProseMirror's schema names, which is what
+ * `editor.schema.nodes` and `editor.schema.marks` are keyed by — not TipTap's
+ * package names and not CSS tags. The tag each one renders is in
+ * `SELECTOR_FOR`, which only the test needs.
+ */
+export declare const RICH_TEXT_SCHEMA: {
+    readonly nodes: readonly ["doc", "text", "paragraph", "heading", "bulletList", "orderedList", "listItem", "blockquote", "codeBlock", "horizontalRule", "hardBreak"];
+    readonly marks: readonly ["bold", "italic", "strike", "underline", "code", "link"];
+};
+export type RichTextSchemaNode = (typeof RICH_TEXT_SCHEMA.nodes)[number];
+export type RichTextSchemaMark = (typeof RICH_TEXT_SCHEMA.marks)[number];

package/dist/Display/RichText/sanitizeHtml.d.ts

@@ -0,0 +1,18 @@
+/**
+ * The sanitiser itself could not be loaded — a failed chunk request, or a
+ * `dompurify` that is somehow not installed.
+ *
+ * What the caller must do with this is leave the content **empty**, which is
+ * what both components do. The one outcome that is not available is rendering
+ * the markup anyway: "the sanitiser is unavailable" is not a reason to skip
+ * sanitising, it is a reason to show nothing.
+ */
+export declare const SANITIZER_UNAVAILABLE_ERROR: string;
+/**
+ * Sanitised markup, ready to be written as HTML.
+ *
+ * Always a promise, including on the native path where nothing has to load. One
+ * microtask is not a frame, and a signature that is sometimes a string would
+ * make every caller branch on it.
+ */
+export declare const sanitizeHtml: (html: string) => Promise<string>;

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

@@ -1,11 +1,6 @@
 import { CalendarDayState } from './CalendarDay.tsx';
 import { CalendarConstraints } from './constraints.ts';
 import { CalendarNav } from './nav.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.
@@ -27,6 +22,43 @@ export interface CalendarProps extends Pick<React.HTMLAttributes<HTMLDivElement>
     /** The initially selected day, for the uncontrolled case. */
     defaultValue?: Date;
     onValueChange?: (value: Date | undefined) => void;
+    /**
+     * The first month on screen, to follow or drive the view from outside
+     * `header`. Any day within the month will do; only its year and month are
+     * read.
+     *
+     * ⚠️ **`visibleMonth` and not `month`, which is already taken** — by the
+     * month-name renderer below. Vue writes that as a *slot*, so it can also
+     * have a `month` prop; React writes a slot as a prop, so the two would
+     * collide on this one interface, and renaming the renderer would break a
+     * published API. Vue uses `visibleMonth` too rather than leaving the two
+     * packages with different names for the same new prop: props are the one part
+     * of the public API no lint rule compares, so a difference here is the kind
+     * nothing would catch.
+     *
+     * The handler is `onVisibleMonthChange`, derived from the prop the way the
+     * parity rules derive it (`update:field` → `field` + `onFieldChange`), and
+     * deliberately *not* `onMonthChange` — that is `react-day-picker`'s name for
+     * its own prop, which is our implementation detail and not our surface.
+     *
+     * Left out, the calendar picks its own starting month and moves itself.
+     * Passed, it still moves itself and reports every move — there is no
+     * controlled/uncontrolled split here, because the month is one piece of state
+     * that both sides write. See `moveMonth`.
+     */
+    visibleMonth?: Date;
+    onVisibleMonthChange?: (month: Date) => void;
+    /**
+     * The day the cursor moved to, every time it moves — including between days
+     * of one month.
+     *
+     * Emit-only on purpose, with no `focusedDay` prop to pair it with, which is
+     * why it is a plain `onFocusDay` and not a `focusedDay`/`onFocusedDayChange`
+     * couple. The focused day is `react-day-picker`'s own, and a second writable
+     * prop over it would fight `visibleMonth` for the same state. Vue spells this
+     * `@focus-day` for the same reasons.
+     */
+    onFocusDay?: (day: Date) => void;
     /** How many month grids to render. */
     months?: number;
     /** What can be picked, and where navigation stops. */
@@ -44,14 +76,25 @@ export interface CalendarProps extends Pick<React.HTMLAttributes<HTMLDivElement>
     month?: (props: {
         month: Date;
     }) => React.ReactNode;
-    /** One day. Falls back to `OxCalendarDay`. */
-    day?: DayRenderer;
+    /**
+     * One day. Falls back to `OxCalendarDay`.
+     *
+     * Written out rather than as the `DayRenderer` alias it is elsewhere in
+     * this file, and that is load-bearing: `orxata/max-props` decides a prop
+     * is a slot by looking for `ReactNode` in the annotation *text*, and it
+     * resolves no aliases. Behind the alias this render prop was counted as
+     * configuration, which put the component a prop over the limit it was
+     * nowhere near. The pickers already spell it out for the same reason.
+     */
+    day?: (props: {
+        date: Date;
+        state: CalendarDayState;
+    }) => React.ReactNode;
     /** How long a month takes to come in, in milliseconds. `0` turns it off. */
     animationDuration?: number;
     dataTestid: string;
 }
 export declare const Calendar: {
-    ({ className, value, defaultValue, onValueChange, months, month: renderMonth, constraints, header, day, animationDuration, dataTestid, }: CalendarProps): import("react/jsx-runtime").JSX.Element;
+    ({ className, value, defaultValue, onValueChange, visibleMonth, onVisibleMonthChange, onFocusDay, months, month: renderMonth, constraints, header, day, animationDuration, dataTestid, }: CalendarProps): import("react/jsx-runtime").JSX.Element;
     displayName: string;
 };
-export {};

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

@@ -1,11 +1,6 @@
 import { CalendarDayState } from './CalendarDay.tsx';
 import { CalendarConstraints } from './constraints.ts';
 import { CalendarNav } from './nav.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
@@ -28,6 +23,24 @@ export interface CalendarRangeProps extends Pick<React.HTMLAttributes<HTMLDivEle
     /** The initially selected span, for the uncontrolled case. */
     defaultValue?: CalendarDateRange;
     onValueChange?: (value: CalendarDateRange) => void;
+    /**
+     * The first month on screen, to follow or drive the view from outside
+     * `header`. Any day within the month will do; only its year and month are
+     * read.
+     *
+     * ⚠️ `visibleMonth` and not `month`: `month` is already the month-name
+     * renderer below, because React writes Vue's `month` *slot* as a prop and the
+     * two names collide on one interface. Vue uses the same name for the same
+     * prop. `OxCalendar` carries the long version.
+     */
+    visibleMonth?: Date;
+    onVisibleMonthChange?: (month: Date) => void;
+    /**
+     * The day the cursor moved to, every time it moves — including between days
+     * of one month. Emit-only, with no `focusedDay` prop to pair it with. See
+     * `OxCalendar`.
+     */
+    onFocusDay?: (day: Date) => void;
     /** How many month grids to render. */
     months?: number;
     /** What can be picked, and where navigation stops. */
@@ -45,12 +58,23 @@ export interface CalendarRangeProps extends Pick<React.HTMLAttributes<HTMLDivEle
     month?: (props: {
         month: Date;
     }) => React.ReactNode;
-    /** One day. Falls back to `OxCalendarDay`. */
-    day?: DayRenderer;
+    /**
+     * One day. Falls back to `OxCalendarDay`.
+     *
+     * Written out rather than as the `DayRenderer` alias it is elsewhere in
+     * this file, and that is load-bearing: `orxata/max-props` decides a prop
+     * is a slot by looking for `ReactNode` in the annotation *text*, and it
+     * resolves no aliases. Behind the alias this render prop was counted as
+     * configuration, which put the component a prop over the limit it was
+     * nowhere near. The pickers already spell it out for the same reason.
+     */
+    day?: (props: {
+        date: Date;
+        state: CalendarDayState;
+    }) => React.ReactNode;
     dataTestid: string;
 }
 export declare const CalendarRange: {
-    ({ className, value, defaultValue, onValueChange, months, month: renderMonth, constraints, header, day, dataTestid, }: CalendarRangeProps): import("react/jsx-runtime").JSX.Element;
+    ({ className, value, defaultValue, onValueChange, visibleMonth, onVisibleMonthChange, onFocusDay, months, month: renderMonth, constraints, header, day, dataTestid, }: CalendarRangeProps): import("react/jsx-runtime").JSX.Element;
     displayName: string;
 };
-export {};

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

@@ -24,6 +24,24 @@ export interface DatePickerProps extends Pick<React.ButtonHTMLAttributes<HTMLBut
     /** The initially chosen day, for the uncontrolled case. */
     defaultValue?: Date;
     onValueChange?: (value: Date | undefined) => void;
+    /**
+     * The first month the panel shows, to follow or drive the view from
+     * outside. Handed to `OxCalendar` untouched.
+     *
+     * ⚠️ `visibleMonth` and not `month`. Nothing on *this* interface is
+     * called `month`, so the name was free here — but `OxCalendar` cannot have
+     * it, because React writes Vue's `month` slot as a prop and the two
+     * collide there. One name across the family, and across both packages,
+     * beats a different one on each half of it.
+     */
+    visibleMonth?: Date;
+    onVisibleMonthChange?: (month: Date) => void;
+    /**
+     * The day the cursor moved to, every time it moves — including between
+     * days of one month, where `onVisibleMonthChange` stays silent. Emit-only,
+     * with no `focusedDay` prop to pair it with. See `OxCalendar`.
+     */
+    onFocusDay?: (day: Date) => void;
     /** How many month grids the popover shows. */
     months?: number;
     /** What can be picked, and where navigation stops. Passed straight through. */
@@ -46,6 +64,6 @@ export interface DatePickerProps extends Pick<React.ButtonHTMLAttributes<HTMLBut
     dataTestid: string;
 }
 export declare const DatePicker: {
-    ({ className, value, defaultValue, onValueChange, months, constraints, disabled, children, icon, day, dataTestid, }: DatePickerProps): import("react/jsx-runtime").JSX.Element;
+    ({ className, value, defaultValue, onValueChange, visibleMonth, onVisibleMonthChange, onFocusDay, months, constraints, disabled, children, icon, day, dataTestid, }: DatePickerProps): import("react/jsx-runtime").JSX.Element;
     displayName: string;
 };

package/dist/Forms/Inputs/DatePicker/DateRangePicker.d.ts

@@ -25,6 +25,24 @@ export interface DateRangePickerProps extends Pick<React.ButtonHTMLAttributes<HT
     /** The initially chosen span, for the uncontrolled case. */
     defaultValue?: CalendarDateRange;
     onValueChange?: (value: CalendarDateRange) => void;
+    /**
+     * The first month the panel shows, to follow or drive the view from
+     * outside. Handed to `OxCalendarRange` untouched.
+     *
+     * ⚠️ `visibleMonth` and not `month`. Nothing on *this* interface is
+     * called `month`, so the name was free here — but `OxCalendarRange` cannot have
+     * it, because React writes Vue's `month` slot as a prop and the two
+     * collide there. One name across the family, and across both packages,
+     * beats a different one on each half of it.
+     */
+    visibleMonth?: Date;
+    onVisibleMonthChange?: (month: Date) => void;
+    /**
+     * The day the cursor moved to, every time it moves — including between
+     * days of one month, where `onVisibleMonthChange` stays silent. Emit-only,
+     * with no `focusedDay` prop to pair it with. See `OxCalendarRange`.
+     */
+    onFocusDay?: (day: Date) => void;
     /** How many month grids the popover shows. */
     months?: number;
     /** What can be picked, and where navigation stops. Passed straight through. */
@@ -56,6 +74,6 @@ export interface DateRangePickerProps extends Pick<React.ButtonHTMLAttributes<HT
     dataTestid: string;
 }
 export declare const DateRangePicker: {
-    ({ className, value, defaultValue, onValueChange, months, constraints, disabled, children, icon, aside, day, dataTestid, }: DateRangePickerProps): import("react/jsx-runtime").JSX.Element;
+    ({ className, value, defaultValue, onValueChange, visibleMonth, onVisibleMonthChange, onFocusDay, months, constraints, disabled, children, icon, aside, day, dataTestid, }: DateRangePickerProps): import("react/jsx-runtime").JSX.Element;
     displayName: string;
 };

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

@@ -0,0 +1,48 @@
+import { RichTextSource } from './useRichTextAdapter.ts';
+export interface RichTextEditorProps extends React.HTMLAttributes<HTMLDivElement> {
+    /**
+     * The editor, which the **caller** owns — created, configured and destroyed
+     * in their component, not in this one.
+     *
+     * Build it with `useEditor` from `@tiptap/react`:
+     *
+     * ```ts
+     * const editor = useEditor({
+     *   extensions: oxRichTextExtensions(StarterKit),
+     *   content: '<p>…</p>',
+     * });
+     * ```
+     *
+     * **Never `new Editor()`.** `useEditor` is what destroys the editor when the
+     * component unmounts; a hand-built one is never destroyed, so its ProseMirror
+     * view, its plugins and its DOM listeners outlive the component that made it.
+     * Nothing fails — it leaks, which is worse, because a leak shows up as a page
+     * that gets slower rather than as an error anyone can attribute.
+     *
+     * `undefined` is an ordinary value, not a mistake: `useEditor` returns `null`
+     * under `immediatelyRender: false`, and a caller may well render this before
+     * they have an editor. The surface renders at its full height meanwhile and
+     * the toolbar's buttons are disabled.
+     *
+     * A `RichTextAdapter` is accepted in place of an editor. That is the seam for
+     * an editor that is not TipTap: implement three methods and the toolbar works
+     * unchanged. In that case the surface is yours to render — put it in
+     * `children` — because an adapter has no DOM for this component to mount.
+     */
+    editor?: RichTextSource | null;
+}
+/**
+ * RichTextEditor — mirrors `sesame/orxata-core` RichTextEditor.
+ *
+ * `role="group"` is unconditional rather than only inside a field, for the same
+ * reason as `OxInputOtp`: this is a `<div>`, and a bare `<div>` cannot take a
+ * name from the author, so without the role the `aria-labelledby` is dropped on
+ * the floor. Outside an `<OxFieldGroup>` the group has no name, which is correct
+ * — this package ships no strings, so there is nothing to call it.
+ *
+ * It is a group and not a `textbox` because the toolbar's buttons are inside it:
+ * there are several focusable things here and one `id` cannot sit on all of
+ * them, which is why the wiring is `useFieldControlGroup()` rather than
+ * `useFieldControl()`.
+ */
+export declare const RichTextEditor: import('react').ForwardRefExoticComponent<RichTextEditorProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/RichTextEditor/RichTextToolbar/RichTextToolbar.d.ts

@@ -0,0 +1,19 @@
+import { Toolbar } from '@radix-ui/react-toolbar';
+export type RichTextToolbarProps = React.ComponentPropsWithoutRef<typeof Toolbar>;
+/**
+ * RichTextToolbar — mirrors `sesame/orxata-core` RichTextToolbar.
+ *
+ * The row above the editable surface. It holds buttons and nothing else of its
+ * own.
+ *
+ * Built on Radix's `Toolbar` rather than a `<div role="toolbar">`, and the
+ * difference is the keyboard: a toolbar is **one tab stop**, with the arrow
+ * keys moving between its controls. Written by hand that is a roving tabindex,
+ * a focus collection and `Home`/`End` handling; Radix already has all three,
+ * the same way reka does on the Vue side.
+ *
+ * No `data-slot`: a toolbar is not a controller, a label, a description, a
+ * message or an icon, and the attribute is only for those five roles. The
+ * control the field's label names is the `OxRichTextEditor` around this.
+ */
+export declare const RichTextToolbar: import('react').ForwardRefExoticComponent<Omit<import('@radix-ui/react-toolbar').ToolbarProps & import('react').RefAttributes<HTMLDivElement>, "ref"> & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/RichTextEditor/RichTextToolbar/index.d.ts

@@ -0,0 +1 @@
+export { RichTextToolbar } from './RichTextToolbar.tsx';

package/dist/Forms/Inputs/RichTextEditor/RichTextToolbarButton/RichTextToolbarButton.d.ts

@@ -0,0 +1,19 @@
+import { RichTextCommand } from '../commands.ts';
+export interface RichTextToolbarButtonProps extends Omit<React.ButtonHTMLAttributes<HTMLButtonElement>, 'aria-label' | 'aria-pressed' | 'children' | 'disabled' | 'onClick' | 'type'> {
+    /** Which command this button toggles. See `RichTextCommand`. */
+    command: RichTextCommand;
+}
+/**
+ * RichTextToolbarButton — mirrors `sesame/orxata-core` RichTextToolbarButton.
+ *
+ * One command, drawn as a toggle.
+ *
+ * `command` is the whole API, which is the point: the icon, the accessible name
+ * and the pressed state all come out of `RICH_TEXT_COMMANDS` and the adapter,
+ * so there is no way to write a button whose glyph says bold and whose click
+ * says italic. Props for those three would put that combination one typo away,
+ * and it is the kind of typo nobody catches in review because each line reads
+ * correctly on its own — which is also why all six of them are `Omit`ted above
+ * rather than left overridable.
+ */
+export declare const RichTextToolbarButton: import('react').ForwardRefExoticComponent<RichTextToolbarButtonProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Forms/Inputs/RichTextEditor/RichTextToolbarButton/index.d.ts

@@ -0,0 +1 @@
+export { RichTextToolbarButton } from './RichTextToolbarButton.tsx';

package/dist/Forms/Inputs/RichTextEditor/commands.d.ts

@@ -0,0 +1,67 @@
+import { ChainedCommands } from '@tiptap/core';
+/**
+ * Everything `<OxRichTextToolbarButton command="…" />` accepts.
+ *
+ * Eleven, and the boundary is not arbitrary: **every one of these is a pure
+ * toggle with an exact glyph in `@sesame/orxata-icons`.** The things a toolbar
+ * usually also has are missing for two different reasons, and both are worth
+ * knowing before reaching for them:
+ *
+ *  - **Undo, redo, a code block and a horizontal rule have no icon.** The
+ *    package has `icon-arrow-back-up` and `icon-corner-up-right-double`, which
+ *    are an arrow and a pair of arrows rather than the history glyphs; drawing
+ *    undo with either would be a different control wearing the wrong sign. A
+ *    code *block* has only `icon-code`, already spoken for by inline code, and
+ *    a rule has only `icon-minus`. The commands themselves are all in the
+ *    preset — `undoRedo` and `horizontalRule` are StarterKit extensions, and
+ *    the keyboard shortcuts work — so what is missing is the buttons, not the
+ *    behaviour.
+ *  - **A link is not a toggle.** `toggleLink` needs an `href`, and a button
+ *    whose whole API is `command` has nowhere to get one. Wiring a URL prompt
+ *    in here would be deciding what that prompt looks like for everybody. The
+ *    toolbar takes arbitrary children instead, so a caller puts their own
+ *    control in it and calls `editor.chain().setLink(…)` — which is also how
+ *    anything else outside this list gets into a toolbar. The mark is styled
+ *    either way; see `RICH_TEXT_SCHEMA`.
+ */
+export type RichTextCommand = 'bold' | 'italic' | 'underline' | 'strike' | 'code' | 'heading1' | 'heading2' | 'heading3' | 'bulletList' | 'orderedList' | 'blockquote';
+export interface RichTextCommandSpec {
+    /**
+     * The asset itself, not a name. `@sesame/orxata-icons` exports each icon as
+     * the raw SVG string and `<Icon :icon="…">` takes it that way, and importing
+     * the eleven by subpath is what `orxata/icon-import-per-icon` asks for — the
+     * barrel would pull all 511 into the graph to draw eleven.
+     */
+    icon: string;
+    /**
+     * Lokalise key for the button's accessible name. The glyph is the whole
+     * control, so this is the only name a screen reader gets.
+     */
+    label: string;
+    /**
+     * What the command turns on, spelled the way `editor.isActive()` asks for
+     * it: a ProseMirror schema name, plus the attributes that distinguish one
+     * heading level from another.
+     */
+    schema: {
+        name: string;
+        attrs?: Record<string, unknown>;
+    };
+    /**
+     * Applied to a chain. A closure rather than a method name and an argument
+     * list, so the TipTap command names live in exactly one place and stay type
+     * checked — a union of method names would type the call as the intersection
+     * of their parameters, which `toggleHeading` and `toggleBold` do not share.
+     */
+    apply: (chain: ChainedCommands) => ChainedCommands;
+}
+/**
+ * The toolbar's whole vocabulary, in the order a toolbar reads: marks, then
+ * headings, then blocks.
+ *
+ * A record and not a function, because the button resolves its own icon, label
+ * and pressed state from it — the only thing a caller writes is `command`.
+ */
+export declare const RICH_TEXT_COMMANDS: Record<RichTextCommand, RichTextCommandSpec>;
+/** Every command, in toolbar order. */
+export declare const RICH_TEXT_COMMAND_NAMES: RichTextCommand[];

package/dist/Forms/Inputs/RichTextEditor/devChecks.d.ts

@@ -0,0 +1,92 @@
+/**
+ * Checks that only run in development, kept out of the component so they can be
+ * tested without mounting anything and so the component reads as a component.
+ *
+ * Both replace an error that names nothing. That is the whole bar for putting a
+ * check here: not "this could go wrong", but "when this goes wrong, the message
+ * the developer gets does not say what happened".
+ *
+ * This file is identical in both packages. Nothing in it is framework-specific,
+ * which is the point — the schema, the extension preset and these checks port
+ * across unchanged because `@tiptap/vue-3` and `@tiptap/react` sit on the same
+ * `@tiptap/core`. Only the mount layer differs.
+ */
+/**
+ * The shape both checks need from `editor.schema`, written structurally rather
+ * than imported from `prosemirror-model`.
+ *
+ * Importing the real `Schema` type would be harmless — types are erased — but
+ * writing it out is what lets a test call these functions with a plain object
+ * instead of standing up an editor.
+ */
+export interface SchemaShape {
+    nodes: Record<string, unknown>;
+    marks: Record<string, unknown>;
+}
+/**
+ * Node and mark names in the editor's schema that the stylesheet does not draw.
+ *
+ * This is the ceiling made to tell you rather than only be documented. A
+ * consumer may pass any extension list they like — that is the point of owning
+ * the editor — and an extension the stylesheet has never heard of renders as
+ * unstyled markup: a task list with no checkboxes, a table with no cell
+ * borders, each looking like a bug in the design system rather than a gap in
+ * it.
+ *
+ * Comparing names rather than rendering is what makes this cheap enough to run
+ * on every schema change. The other direction — a styled name no extension
+ * produces — is a test's job rather than a runtime warning: see
+ * `RichText.test.*`.
+ */
+export declare const uncoveredSchemaNames: (schema: SchemaShape) => string[];
+export declare const schemaCoverageWarning: (uncovered: string[]) => string;
+/**
+ * A dynamic import of one of the optional peers came back rejected.
+ *
+ * Which, for an optional peer, is the ordinary consequence of not installing
+ * it — so the one thing this must not be is an unhandled rejection reading
+ * "Failed to fetch dynamically imported module". Logged rather than thrown: the
+ * editor then renders its surface with nothing in it, which degrades visibly
+ * instead of taking the page down, and the rest of the design system does not
+ * depend on TipTap at all.
+ */
+export declare const missingTipTapError: (specifier: string) => string;
+/**
+ * A class, as far as `instanceof` is concerned. `abstract` so a class with a
+ * protected constructor still satisfies it.
+ */
+type AnyClass = abstract new (..._args: never[]) => unknown;
+/** What the editable component hands the probe, once its dynamic import lands. */
+export interface DuplicateProbe {
+    /** `@tiptap/core`'s `Editor`, from the same import as the mount binding. */
+    Editor?: AnyClass;
+}
+export declare const DUPLICATE_TIPTAP_ERROR: string;
+/**
+ * Two copies of TipTap in the dependency tree.
+ *
+ * ProseMirror reports it as `RangeError: Invalid content`, thrown from inside a
+ * transaction, pointing at a minified vendor frame and naming neither the
+ * package nor the version. Near-undebuggable the first time you meet it, and
+ * completely obvious once named — which is exactly the trade this makes.
+ *
+ * The probe is an identity test on `@tiptap/core`'s `Editor`, which arrives
+ * through the same dynamic import as the mount binding: if the editor we were
+ * handed is not an instance of it, it was built by a different copy of
+ * `@tiptap/core`, and the binding that is about to mount it reaches into
+ * `editor.view` and the renderer internals of the wrong one.
+ *
+ * `Editor` and not `prosemirror-model`'s `Schema`, which was the original
+ * brief. Two reasons: `@tiptap/vue-3` and `@tiptap/react` both subclass the
+ * core `Editor`, so a `useEditor` editor and a hand-built one both pass a
+ * healthy check; and mismatched `@tiptap/*` versions are the duplication npm
+ * actually produces, which is the one a developer can act on. A `Schema` probe
+ * would need `prosemirror-model` resolved from the *consumer's* tree to mean
+ * anything, which is a fourth optional peer for a narrower answer.
+ *
+ * `Editor` may be `undefined` — the import is dynamic and the first render
+ * happens before it lands — and an absent probe reports nothing rather than
+ * guessing.
+ */
+export declare const duplicateCopyError: (editor: object, probe: DuplicateProbe) => string | undefined;
+export {};

package/dist/Forms/Inputs/RichTextEditor/extensions.d.ts

@@ -0,0 +1,54 @@
+import { Extensions } from '@tiptap/core';
+import { default as StarterKit } from '@tiptap/starter-kit';
+/**
+ * The extension list both ends of a rich text field agree on.
+ *
+ * **The silent failure this exists to stop:** content written with an extension
+ * the renderer does not know does not error — ProseMirror drops those nodes on
+ * the way in, and what comes back is the same document with the headings turned
+ * into paragraphs and nothing anywhere saying so. One list, used by whatever
+ * writes and whatever renders, is the only way the two cannot drift.
+ *
+ * A caller may pass a subset. The ceiling is what the stylesheet draws, which
+ * is `RICH_TEXT_SCHEMA`, and `OxRichTextEditor` warns in development about
+ * anything in the editor's schema that is not in it.
+ *
+ * ---
+ *
+ * **Why this takes StarterKit as an argument instead of importing it.** The
+ * intended design was a plain exported array. It cannot be one, and the reason
+ * is worth writing down because the signature otherwise looks like ceremony:
+ *
+ * `oxRichTextExtensions` is published from `src/main.ts`, the barrel every
+ * consumer imports — including the one who only wants `OxButton`. A static
+ * `import StarterKit from '@tiptap/starter-kit'` anywhere in that graph becomes
+ * a top-level import in the built `orxata-core.js`, and a bundler resolves
+ * every import it finds before it decides what to tree-shake. For a consumer
+ * who has not installed TipTap that is a module-resolution failure in their
+ * build — webpack calls it an error, Rollup leaves a bare specifier that fails
+ * at runtime — over a feature they never touched. "TipTap is an optional peer
+ * dependency" would be false the moment anything imported it eagerly.
+ *
+ * An `async` factory that `import()`s it was the other option, and it is worse
+ * where it matters: `useEditor` needs its extensions synchronously, so every
+ * caller would need a top-level `await` and a `<Suspense>` around their own
+ * component in order to use a text field.
+ *
+ * So the caller hands over the StarterKit they already have — one import, in a
+ * file that is already importing `useEditor` from TipTap — and this package
+ * contributes the part that is actually its own: the configuration. The
+ * parameter's type is `typeof StarterKit`, which is erased, so this module has
+ * no runtime dependency on TipTap at all.
+ *
+ * ```ts
+ * import StarterKit from '@tiptap/starter-kit';
+ * import { useEditor } from '@tiptap/vue-3';
+ * import { oxRichTextExtensions } from '@sesame/orxata-core';
+ *
+ * const editor = useEditor({
+ *   extensions: oxRichTextExtensions(StarterKit),
+ *   content: '<p>…</p>',
+ * });
+ * ```
+ */
+export declare const oxRichTextExtensions: (starterKit: typeof StarterKit) => Extensions;

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

@@ -0,0 +1,7 @@
+export { RichTextEditor } from './RichTextEditor.tsx';
+export { RichTextToolbar } from './RichTextToolbar/index.ts';
+export { RichTextToolbarButton } from './RichTextToolbarButton/index.ts';
+export { RICH_TEXT_COMMANDS, RICH_TEXT_COMMAND_NAMES, type RichTextCommand, type RichTextCommandSpec, } from './commands.ts';
+export { oxRichTextExtensions } from './extensions.ts';
+export { type RichTextAdapter, type RichTextSource, isRichTextAdapter, useRichTextAdapter, } from './useRichTextAdapter.ts';
+export { useRichTextToolbar } from './useRichTextToolbar.ts';