@cueplusplus/ui 0.13.0

package/dist/system/use-density.d.ts

@@ -0,0 +1,50 @@
+import { Density } from "@cueplusplus/theme-base";
+//#region src/system/use-density.d.ts
+/** Rung of the control ladder to measure. */
+type ControlSize = "sm" | "md" | "lg";
+/**
+ * The density level that actually applies here: the nearest `<Density>` island,
+ * else the `<ThemeProvider>` level, else `"compact"`.
+ *
+ * This is a JS read for code that cannot use CSS (virtualised row heights,
+ * canvas drawing, layout math). Styling should use the density tokens or the
+ * per-rung variants (`density-ultra-compact:` … `density-ultra-large:`) instead.
+ *
+ * @returns The applicable density level.
+ * @example
+ * const density = useDensity();
+ * const rowHeight = useControlHeight("sm");
+ * // Shorter rows mean more of them on screen, so the reserve moves with the level.
+ * useVirtualizer({
+ *   count: rows.length,
+ *   estimateSize: () => rowHeight,
+ *   overscan: density === "ultra-compact" ? 12 : 6,
+ * });
+ */
+declare function useDensity(): Density;
+/**
+ * The pixel height of a control at the ambient density — what a virtualiser or a
+ * canvas renderer needs when it cannot ask CSS.
+ *
+ * Measured from a throwaway `document.body` probe stamped with the ambient
+ * density *and the ambient theme*, so app-wide token overrides, the `@media
+ * (pointer: coarse)` re-raise of `ultra-compact`, and a rung a theme adds are
+ * all honoured. Overrides scoped to a subtree the probe is not in are still
+ * not: the probe hangs off `document.body`, outside every provider root.
+ *
+ * Falls back to the authored ladder × 16px during SSR and before the first
+ * layout effect, which keeps hydration stable. A rung the ambient theme does
+ * not declare falls back to the default ladder with a development warning
+ * rather than throwing — the probe corrects it on the next tick either way.
+ *
+ * Safe outside a `<ThemeProvider>`: it reads the theme and the registry from
+ * context directly instead of through `useTheme()`, which throws.
+ *
+ * @param size - Which rung to measure. Defaults to `"md"`.
+ * @returns Height in CSS pixels.
+ * @example
+ * const rowHeight = useControlHeight("sm"); // → 20 at compact density
+ */
+declare function useControlHeight(size?: ControlSize): number;
+//#endregion
+export { ControlSize, useControlHeight, useDensity };

package/dist/system/use-density.js

@@ -0,0 +1,232 @@
+"use client";
+import { useIsomorphicLayoutEffect } from "./use-isomorphic-layout-effect.js";
+import { DEFAULT_DENSITY, DensityContext } from "./density.js";
+import { warnOnce } from "./vocabulary.js";
+import { ThemeRegistryContext } from "./theme-registry.js";
+import { ThemeContext } from "./theme-provider.js";
+import * as React from "react";
+//#region src/system/use-density.ts
+/**
+* The **base** control ladder in rem, mirroring
+* `packages/tokens/src/density/*.tokens.json`.
+*
+* Keyed by `BaseDensity` — the closed five — and not by the open `Density`,
+* because those five are the only rungs this package can know at build time. A
+* rung a theme adds exists nowhere in `ui`'s source; it arrives at runtime on a
+* manifest, and {@link ladderFor} is what goes and gets it.
+*
+* Only a fallback either way: {@link useControlHeight} measures the live CSS
+* first, so per-app token overrides and the `@media (pointer: coarse)` re-raise
+* win.
+*/
+const CONTROL_REM = {
+	"ultra-compact": {
+		sm: 1.125,
+		md: 1.25,
+		lg: 1.5
+	},
+	"compact": {
+		sm: 1.25,
+		md: 1.5,
+		lg: 1.75
+	},
+	"normal": {
+		sm: 1.75,
+		md: 2,
+		lg: 2.25
+	},
+	"large": {
+		sm: 2.25,
+		md: 2.5,
+		lg: 2.75
+	},
+	"ultra-large": {
+		sm: 2.75,
+		md: 3,
+		lg: 3.25
+	}
+};
+/** Root font size assumed before the first measurement, so SSR and hydration agree. */
+const ASSUMED_ROOT_FONT_SIZE = 16;
+/** The three tokens the ladder is made of, in the order a warning should name them. */
+const CONTROL_TOKENS = [
+	"control-sm",
+	"control-md",
+	"control-lg"
+];
+/**
+* A `"1.25rem"` geometry value as a number of rem, or `null`.
+*
+* `null` rather than a throw, and rem rather than any length, because the three
+* `control-*` tokens are rem *by convention*: `validateManifest` requires only a
+* non-empty string, and the base geometry block itself ships `radius-control:
+* "3px"`, so a manifest that passes validation can perfectly well carry a value
+* this cannot use. See {@link ladderFor} for what happens then.
+*
+* Strictly positive, too. `"0rem"` and `"-1rem"` parse perfectly well and are
+* not control heights: a virtualiser handed a row height of zero divides by it
+* or renders every row in the list, and a negative one is not a height at all.
+* Both are manifest defects, and a defect is better reported than propagated.
+*/
+function rem(value) {
+	if (value === void 0) return null;
+	const match = /^(-?\d*\.?\d+)rem$/.exec(value.trim());
+	if (match === null) return null;
+	const parsed = Number.parseFloat(match[1]);
+	return Number.isFinite(parsed) && parsed > 0 ? parsed : null;
+}
+/**
+* The rem ladder for a rung: the base table, else the registry, else a warning.
+*
+* The registry is the only place an added rung's geometry exists on the client.
+* The stylesheet has it — `theme-tools` emitted a `[data-theme="foo"]
+* [data-density="foo-dense"]` block for it — but CSS is not readable as data
+* before layout, and this value is needed by a `useState` initializer, which is
+* the one moment nothing has been laid out yet.
+*
+* Every failure degrades rather than throws, and the reason is that this runs
+* during render from a `useState` initializer with no error boundary anywhere
+* near it: a throw there unmounts the application, in production, over a
+* pre-measurement seed. And the seed really is only a seed — the added rung's
+* CSS exists whatever this returns, so the layout effect's probe measures the
+* true height one tick later and the fallback is visible for one commit. A
+* `control-*` rem rule in `validateManifest` is what would make this
+* impossible, and that is a Plan 4 carry.
+*/
+function ladderFor(registry, density) {
+	const base = CONTROL_REM[density];
+	if (base !== void 0) return base;
+	const added = registry?.densities.find((d) => d.name === density)?.geometry;
+	if (added !== void 0) {
+		const ladder = {
+			sm: rem(added["control-sm"]),
+			md: rem(added["control-md"]),
+			lg: rem(added["control-lg"])
+		};
+		if (ladder.sm !== null && ladder.md !== null && ladder.lg !== null) return ladder;
+		const offender = CONTROL_TOKENS.find((token) => rem(added[token]) === null);
+		warnOnce(`density "${density}" declares ${offender} as ${JSON.stringify(added[offender])}, which is not a positive rem length; the ${DEFAULT_DENSITY} ladder seeds the measurement instead`);
+		return CONTROL_REM[DEFAULT_DENSITY];
+	}
+	warnOnce(`density "${density}" is not a base rung and no registered theme adds it; the ${DEFAULT_DENSITY} ladder is used until the probe measures it`);
+	return CONTROL_REM[DEFAULT_DENSITY];
+}
+function rootFontSize() {
+	if (typeof document === "undefined") return ASSUMED_ROOT_FONT_SIZE;
+	const size = Number.parseFloat(getComputedStyle(document.documentElement).fontSize);
+	return Number.isFinite(size) && size > 0 ? size : ASSUMED_ROOT_FONT_SIZE;
+}
+/**
+* Measure `--cue-control-<size>` on a throwaway element stamped like the caller.
+*
+* `theme` as well as `density`, because a rung a theme adds is emitted under
+* that theme's `[data-theme]`: a bare `data-density` div on `document.body`
+* matches the **root** theme's rules, so under a nested provider of another
+* theme it would measure a ladder the caller is not on. `null` stamps nothing,
+* which is right for a caller with no provider above it at all.
+*
+* `data-cue-theme` rides beside `data-theme`, both from the same value: an
+* inert attribute nothing here reads back, but the emitters' exact-match
+* selector does — see `densityRules`/`themeSelector`'s comment on why a CSS
+* ancestor guard alone cannot tell *nearest* theme from *any* theme in the
+* chain, and how a runtime-published stamp closes that where the DOM shape
+* lets it.
+*
+* `ladder` is passed in rather than looked up here so that both reads — this
+* one and the state seed — go through {@link ladderFor} exactly once each, and
+* so this stays a plain function that a test can reason about without a tree.
+*
+* What this element cannot see is the standing concession of the whole
+* approach, and it is worth naming where it is caused rather than where it is
+* felt: hanging off `document.body` puts the probe outside every provider
+* root, so a rule scoped under `[data-cue-root]` does not reach it. That is the
+* reason the provider's density override layer is emitted as one
+* document-scoped `<style>` instead — a subtree-scoped rule would leave this
+* measuring unoverridden geometry while the control beside it rendered the
+* override, and the two would disagree by exactly the override.
+*/
+function measureControlHeight(ladder, density, theme, size) {
+	const fallback = ladder[size] * rootFontSize();
+	if (typeof document === "undefined" || document.body === null) return fallback;
+	const probe = document.createElement("div");
+	probe.setAttribute("data-density", density);
+	if (theme !== null) {
+		probe.setAttribute("data-theme", theme);
+		probe.setAttribute("data-cue-theme", theme);
+	}
+	probe.setAttribute("aria-hidden", "true");
+	probe.style.cssText = `position:absolute;top:-9999px;left:-9999px;width:0;visibility:hidden;pointer-events:none;height:var(--cue-control-${size})`;
+	document.body.appendChild(probe);
+	const measured = probe.getBoundingClientRect().height;
+	probe.remove();
+	return measured > 0 ? measured : fallback;
+}
+/**
+* The density level that actually applies here: the nearest `<Density>` island,
+* else the `<ThemeProvider>` level, else `"compact"`.
+*
+* This is a JS read for code that cannot use CSS (virtualised row heights,
+* canvas drawing, layout math). Styling should use the density tokens or the
+* per-rung variants (`density-ultra-compact:` … `density-ultra-large:`) instead.
+*
+* @returns The applicable density level.
+* @example
+* const density = useDensity();
+* const rowHeight = useControlHeight("sm");
+* // Shorter rows mean more of them on screen, so the reserve moves with the level.
+* useVirtualizer({
+*   count: rows.length,
+*   estimateSize: () => rowHeight,
+*   overscan: density === "ultra-compact" ? 12 : 6,
+* });
+*/
+function useDensity() {
+	return React.useContext(DensityContext) ?? "compact";
+}
+/**
+* The pixel height of a control at the ambient density — what a virtualiser or a
+* canvas renderer needs when it cannot ask CSS.
+*
+* Measured from a throwaway `document.body` probe stamped with the ambient
+* density *and the ambient theme*, so app-wide token overrides, the `@media
+* (pointer: coarse)` re-raise of `ultra-compact`, and a rung a theme adds are
+* all honoured. Overrides scoped to a subtree the probe is not in are still
+* not: the probe hangs off `document.body`, outside every provider root.
+*
+* Falls back to the authored ladder × 16px during SSR and before the first
+* layout effect, which keeps hydration stable. A rung the ambient theme does
+* not declare falls back to the default ladder with a development warning
+* rather than throwing — the probe corrects it on the next tick either way.
+*
+* Safe outside a `<ThemeProvider>`: it reads the theme and the registry from
+* context directly instead of through `useTheme()`, which throws.
+*
+* @param size - Which rung to measure. Defaults to `"md"`.
+* @returns Height in CSS pixels.
+* @example
+* const rowHeight = useControlHeight("sm"); // → 20 at compact density
+*/
+function useControlHeight(size = "md") {
+	const density = useDensity();
+	const theme = React.useContext(ThemeContext)?.theme ?? null;
+	const ladder = ladderFor(React.useContext(ThemeRegistryContext), density);
+	const { sm, md, lg } = ladder;
+	const [height, setHeight] = React.useState(() => ladder[size] * ASSUMED_ROOT_FONT_SIZE);
+	useIsomorphicLayoutEffect(() => {
+		setHeight(measureControlHeight({
+			sm,
+			md,
+			lg
+		}, density, theme, size));
+	}, [
+		sm,
+		md,
+		lg,
+		density,
+		theme,
+		size
+	]);
+	return height;
+}
+//#endregion
+export { useControlHeight, useDensity };

package/dist/system/use-isomorphic-layout-effect.js

@@ -0,0 +1,33 @@
+"use client";
+import * as React from "react";
+//#region src/system/use-isomorphic-layout-effect.ts
+/**
+* `useLayoutEffect` in the browser, `useEffect` on the server.
+*
+* The theme system stamps DOM attributes and creates portal containers in
+* layout effects so they land *before* the browser paints — a density flash
+* reflows the whole page, which is worse than a colour flash (spec §6). React
+* warns when `useLayoutEffect` runs during SSR, so the server gets the
+* (never-invoked) passive variant instead.
+*/
+const useIsomorphicLayoutEffect = typeof document === "undefined" ? React.useEffect : React.useLayoutEffect;
+/**
+* `useInsertionEffect` in the browser, `useEffect` on the server.
+*
+* One step earlier than the layout variant above, and the difference is the
+* whole reason it exists. React runs **every** insertion effect in the tree
+* during the mutation phase, before **any** layout effect runs; layout effects
+* then run child-first, so a provider near the root is the last thing in the
+* commit to get one. Anything a descendant's layout effect measures — Base UI
+* calls `getComputedStyle` in several — is measured against whatever the
+* document element is wearing at that moment.
+*
+* That matters exactly once: putting back what React 19 takes off `<html>` when
+* it hydrates the document element. See the `<html>` stamp in
+* `theme-provider.tsx`.
+*
+* Write only. An insertion effect must not read layout or schedule state.
+*/
+const useIsomorphicInsertionEffect = typeof document === "undefined" ? React.useEffect : React.useInsertionEffect;
+//#endregion
+export { useIsomorphicInsertionEffect, useIsomorphicLayoutEffect };

package/dist/system/use-theme.d.ts

@@ -0,0 +1,30 @@
+import { ThemeContextValue } from "./theme-provider.js";
+//#region src/system/use-theme.d.ts
+/**
+ * Read and drive the ambient theme state.
+ *
+ * Returns `{ theme, manifest, density, mode, font, styleSet, resolvedMode,
+ * setTheme, setDensity, setMode, setFont, setStyleSet }`.
+ * `density` here is the *provider's* level — a nested `<Density>` island does not
+ * change it; use `useDensity()` when you want the level that actually applies
+ * where you are. `font` is the pairing the provider holds; it has no island, so
+ * it is always the one in force. `manifest` is the active theme's, or `null`
+ * when that name is not in the provider's `themes` — which is every name in an
+ * app that has registered none; `useThemes()` is what was registered.
+ *
+ * `styleSet` is the page-composition set in force, or `null` when nothing has
+ * chosen one — which is every application that has not asked for it. *In
+ * force*, not *named here*: a provider that names no set of its own reports the
+ * one stamped around it — a `<Density styleSet>` island between it and an outer
+ * provider included — exactly as the DOM resolves it, so this and the set a
+ * portal or a `<Preview>` stage carries are one value.
+ *
+ * @throws If called outside a `<ThemeProvider>`. Theme state is never guessed:
+ *   a missing provider is a wiring bug, not a fallback situation.
+ * @example
+ * const { resolvedMode, setMode } = useTheme();
+ * <Switch checked={resolvedMode === "light"} onCheckedChange={(on) => setMode(on ? "light" : "dark")} />
+ */
+declare function useTheme(): ThemeContextValue;
+//#endregion
+export { useTheme };

package/dist/system/use-theme.js

@@ -0,0 +1,36 @@
+"use client";
+import { ThemeContext } from "./theme-provider.js";
+import * as React from "react";
+//#region src/system/use-theme.ts
+/**
+* Read and drive the ambient theme state.
+*
+* Returns `{ theme, manifest, density, mode, font, styleSet, resolvedMode,
+* setTheme, setDensity, setMode, setFont, setStyleSet }`.
+* `density` here is the *provider's* level — a nested `<Density>` island does not
+* change it; use `useDensity()` when you want the level that actually applies
+* where you are. `font` is the pairing the provider holds; it has no island, so
+* it is always the one in force. `manifest` is the active theme's, or `null`
+* when that name is not in the provider's `themes` — which is every name in an
+* app that has registered none; `useThemes()` is what was registered.
+*
+* `styleSet` is the page-composition set in force, or `null` when nothing has
+* chosen one — which is every application that has not asked for it. *In
+* force*, not *named here*: a provider that names no set of its own reports the
+* one stamped around it — a `<Density styleSet>` island between it and an outer
+* provider included — exactly as the DOM resolves it, so this and the set a
+* portal or a `<Preview>` stage carries are one value.
+*
+* @throws If called outside a `<ThemeProvider>`. Theme state is never guessed:
+*   a missing provider is a wiring bug, not a fallback situation.
+* @example
+* const { resolvedMode, setMode } = useTheme();
+* <Switch checked={resolvedMode === "light"} onCheckedChange={(on) => setMode(on ? "light" : "dark")} />
+*/
+function useTheme() {
+	const context = React.useContext(ThemeContext);
+	if (context === null) throw new Error("useTheme() must be called inside a <ThemeProvider>.");
+	return context;
+}
+//#endregion
+export { useTheme };

package/dist/system/vocabulary.d.ts

@@ -0,0 +1,16 @@
+import { StyleSet } from "@cueplusplus/tokens";
+import { Density as Density$1, DensityEntry, FontEntry, FontName, ThemeManifest } from "@cueplusplus/theme-base";
+//#region src/system/vocabulary.d.ts
+/** What the three registry hooks read: the manifests, and the axes the ACTIVE theme offers. */
+interface ThemeRegistry {
+  /** Every registered manifest, in registration order. */
+  readonly themes: readonly ThemeManifest[];
+  /** First registered manifest's name, or `null` with nothing registered. */
+  readonly defaultTheme: string | null;
+  /** The rungs the ACTIVE theme offers: base five, then its adds. */
+  readonly densities: readonly DensityEntry[];
+  /** The pairings the ACTIVE theme offers, by the same rule. */
+  readonly fonts: readonly FontEntry[];
+}
+//#endregion
+export { ThemeRegistry };

package/dist/system/vocabulary.js

@@ -0,0 +1,125 @@
+import { DEFAULT_DENSITY, DEFAULT_FONT, STYLE_SETS } from "@cueplusplus/tokens";
+import { DENSITIES, FONTS, THEME_NAME_PATTERN, resolveDensities, resolveFonts } from "@cueplusplus/theme-base";
+//#region src/system/vocabulary.ts
+/**
+* The registry's pure half: what a set of manifests accepts, and what an app
+* may offer under one of them.
+*
+* No `"use client"` and no React, on purpose. `prepaint.ts` is server-safe by
+* contract — the docs app's root layout is a Server Component and calls
+* `prepaintScript()` during render — and it reaches this module to inline the
+* vocabulary into the blocking script. A module reached through a client
+* boundary arrives in a server graph as a client *reference* rather than a
+* function, and calling one throws at prerender. So the pure half lives here,
+* directive-free, and `theme-registry.tsx` holds the context and the hooks and
+* re-exports this file so the barrel still has one source.
+* `test/system/server-safe.test.ts` holds this file, and every file
+* `prepaint.ts` reaches, to that rule.
+*/
+/**
+* What each axis accepts, and the one place that is decided.
+*
+* Six code paths validated a name before this existed — three against a frozen
+* list from `@cueplusplus/tokens`, two against local copies, one against
+* nothing at all — and they disagreed with each other at the edges. They all
+* ask this now, so a stored preference means the same thing to the pre-paint
+* script, the restore effect, and a portal.
+*
+* An empty registry is the deliberate case, not the degenerate one: an app that
+* registers nothing has the base axes and no registry, and for one release that
+* is every app that has not migrated — this repository's own docs site
+* included. (It does not follow that such an app is unpainted: a stylesheet it
+* imported may well declare the block the provider stamps. Colour is a question
+* for CSS; this file only decides what a name is allowed to be.) Refusing every theme name there would reject a visitor's stored
+* preference on first paint. So with nothing registered, theme validation is
+* *off* (any name the selector grammar allows), and density and font validate
+* against the base ladder and pairings alone. A registered set closes all
+* three: only registered themes, and a theme's added rung or pairing only under
+* that theme, which is what the cascade actually scopes it to.
+*
+* The order matters wherever a whole stored quadruple is read: resolve the
+* theme first, then each axis under the theme resolution chose. See
+* `acceptedPreferences()` in `theme-provider.tsx`, which is the one place that
+* rule is applied, and the pre-paint script, which applies it the same way.
+*/
+function vocabulary(themes) {
+	const byName = /* @__PURE__ */ new Map();
+	for (const manifest of themes) if (!byName.has(manifest.name)) byName.set(manifest.name, manifest);
+	const names = themes.length === 0 ? null : [...byName.keys()];
+	const densitiesFor = (theme) => [...DENSITIES, ...Object.keys((theme === null ? void 0 : byName.get(theme))?.densities.adds ?? {})];
+	const fontsFor = (theme) => [...FONTS, ...Object.keys((theme === null ? void 0 : byName.get(theme))?.fontPairings.adds ?? {})];
+	const preferredDensity = (theme) => {
+		const wanted = (theme === null ? void 0 : byName.get(theme))?.densities.default;
+		return wanted !== void 0 && densitiesFor(theme).includes(wanted) ? wanted : DEFAULT_DENSITY;
+	};
+	const preferredFont = (theme) => {
+		const wanted = (theme === null ? void 0 : byName.get(theme))?.fontPairings.default;
+		return wanted !== void 0 && fontsFor(theme).includes(wanted) ? wanted : DEFAULT_FONT;
+	};
+	return {
+		themes: names,
+		densitiesFor,
+		fontsFor,
+		preferredDensity,
+		preferredFont,
+		acceptsTheme: (name) => typeof name === "string" && (names === null ? THEME_NAME_PATTERN.test(name) : names.includes(name)),
+		acceptsDensity: (theme, name) => typeof name === "string" && densitiesFor(theme).includes(name),
+		acceptsFont: (theme, name) => typeof name === "string" && fontsFor(theme).includes(name),
+		supportsLight: (theme) => theme === null ? true : byName.get(theme)?.supportsLight ?? true
+	};
+}
+/**
+* Whether a value is one of the three style sets.
+*
+* A standalone function rather than a member of {@link Vocabulary}, and the
+* asymmetry is the point: every other axis is asked *under a theme*, because a
+* theme may add a rung or a pairing and a name accepted under the wrong theme
+* stamps an attribute no block matches. No theme can add a style set — the axis
+* is emitted by `@cueplusplus/tokens` and no manifest field describes it — so
+* there is nothing per-theme to ask and a per-theme signature would be three
+* parameters pretending to be a rule.
+*/
+function isStyleSet(value) {
+	return typeof value === "string" && STYLE_SETS.includes(value);
+}
+/** Derive the context value. Pure; the provider memoises it on `themes` and the active name. */
+function buildRegistry(themes, active) {
+	return {
+		themes,
+		defaultTheme: themes[0]?.name ?? null,
+		densities: resolveDensities(themes, active),
+		fonts: resolveFonts(themes, active)
+	};
+}
+const seen = /* @__PURE__ */ new Set();
+/**
+* A development warning, once per distinct message per process.
+*
+* Once, because the things this warns about — a `themes` prop nobody passed, a
+* rung a theme does not offer — are configuration, and configuration is wrong
+* the same way on every render. A warning per render is a warning nobody reads,
+* and fourteen provider tests would otherwise be fourteen copies of one line.
+*/
+function warnOnce(message) {
+	if (process.env.NODE_ENV === "production" || seen.has(message)) return;
+	seen.add(message);
+	console.warn(`[cue] ${message}`);
+}
+/**
+* {@link warnOnce}, one tier quieter.
+*
+* `contrastReport()` keeps two lists on purpose — a *failure* is what makes a
+* screen unreadable, an *advisory* is a focus ring nobody has been failed on
+* yet — and folding the second into `console.warn` would either train a reader
+* to ignore the first or push a repository to turn both off. They share the
+* `seen` set so "once per distinct message" is one budget and `resetWarnings()`
+* clears both; the two message texts cannot collide, since a failure and an
+* advisory for one pair say different things about it.
+*/
+function noteOnce(message) {
+	if (process.env.NODE_ENV === "production" || seen.has(message)) return;
+	seen.add(message);
+	console.info(`[cue] ${message}`);
+}
+//#endregion
+export { buildRegistry, isStyleSet, noteOnce, vocabulary, warnOnce };

package/dist/theming/contrast.d.ts

@@ -0,0 +1,2 @@
+import { CONTRAST_REQUIREMENTS, ContrastCheck, ContrastInput, ContrastReport, ContrastRequirement, WCAG_AAA_TEXT, WCAG_AA_NON_TEXT, WCAG_AA_TEXT, contrastRatio, contrastReport as contrastReport$1, relativeLuminance } from "@cueplusplus/theme-base/contrast";
+export { CONTRAST_REQUIREMENTS, type ContrastCheck, type ContrastInput, type ContrastReport, type ContrastRequirement, WCAG_AAA_TEXT, WCAG_AA_NON_TEXT, WCAG_AA_TEXT, contrastRatio, contrastReport$1 as contrastReport, relativeLuminance };

package/dist/theming/contrast.js

@@ -0,0 +1,2 @@
+import { CONTRAST_REQUIREMENTS, WCAG_AAA_TEXT, WCAG_AA_NON_TEXT, WCAG_AA_TEXT, contrastRatio, contrastReport as contrastReport$1, relativeLuminance } from "@cueplusplus/theme-base/contrast";
+export { CONTRAST_REQUIREMENTS, WCAG_AAA_TEXT, WCAG_AA_NON_TEXT, WCAG_AA_TEXT, contrastRatio, contrastReport$1 as contrastReport, relativeLuminance };