@jbrowse/core 4.3.0 → 5.0.0-beta.10

package/esm/ui/parseError.d.ts

@@ -0,0 +1,4 @@
+export declare function parseError(str: string): {
+    snapshotValue: unknown;
+    message: string;
+};

package/esm/ui/parseError.js

@@ -0,0 +1,18 @@
+function tryParseJson(str) {
+    try {
+        return JSON.parse(str);
+    }
+    catch {
+        return str;
+    }
+}
+export function parseError(str) {
+    let snapshotValue;
+    let message = '';
+    const match = /(?:at path "([^"]*)" )?snapshot `([^`]*)` is not assignable/.exec(str);
+    if (match) {
+        snapshotValue = tryParseJson(match[2]);
+        message = match[1] ? `Snapshot at path "${match[1]}":` : 'Snapshot:';
+    }
+    return { snapshotValue, message };
+}

package/esm/ui/persistentScrollbarStyle.d.ts

@@ -0,0 +1,49 @@
+import type { JBrowseStyleTheme } from './styleTheme.ts';
+/**
+ * Makes a scroll container's native scrollbar always visible.
+ *
+ * macOS (and iOS, and Android) browsers default to *overlay* scrollbars: zero
+ * layout width, drawn only while a scroll is in flight, faded out a moment
+ * later. A stack of views taller than the window then offers nothing to grab
+ * and no hint that it scrolls at all. `scrollbar-gutter` cannot fix that — it
+ * is defined to have no effect on overlay scrollbars — but giving
+ * `::-webkit-scrollbar` an explicit width does: Chromium and Safari switch that
+ * container to a classic, always-drawn, space-occupying scrollbar.
+ *
+ * Deliberately no `scrollbar-gutter: stable`, which would work once the lane is
+ * classic: it reserves the lane whether or not anything overflows, so a
+ * container showing one short view would pay 12px for a scrollbar it never
+ * draws. The lane appearing is the signal, so it has to mean something — which
+ * puts the burden on the container to overflow only when it has content to
+ * scroll to, rather than by trailing space it renders for its own reasons.
+ *
+ * Deliberately no `scrollbar-width`/`scrollbar-color`: in Chromium the standard
+ * properties win over the `::-webkit-` pseudo-elements and put the overlay
+ * behavior back. Firefox on macOS ignores both approaches and follows the OS
+ * "Show scroll bars" setting; there is no CSS that overrides it.
+ *
+ * Thumb geometry matches {@link VerticalScrollbar}, the scrollbar the
+ * canvas-backed displays draw for themselves, so the two read as one control.
+ */
+export declare const persistentScrollbarStyle: (theme: JBrowseStyleTheme) => {
+    readonly '&::-webkit-scrollbar': {
+        readonly width: 12;
+        readonly height: 12;
+    };
+    readonly '&::-webkit-scrollbar-track': {
+        readonly background: 'transparent';
+    };
+    readonly '&::-webkit-scrollbar-thumb': {
+        readonly background: string;
+        readonly borderRadius: number;
+        readonly border: "3px solid transparent";
+        readonly backgroundClip: 'content-box';
+    };
+    readonly '&::-webkit-scrollbar-thumb:hover': {
+        readonly background: string;
+        readonly backgroundClip: 'content-box';
+    };
+    readonly '&::-webkit-scrollbar-corner': {
+        readonly background: 'transparent';
+    };
+};

package/esm/ui/persistentScrollbarStyle.js

@@ -0,0 +1,53 @@
+const LANE_WIDTH = 12;
+const THUMB_INSET = 3;
+/**
+ * Makes a scroll container's native scrollbar always visible.
+ *
+ * macOS (and iOS, and Android) browsers default to *overlay* scrollbars: zero
+ * layout width, drawn only while a scroll is in flight, faded out a moment
+ * later. A stack of views taller than the window then offers nothing to grab
+ * and no hint that it scrolls at all. `scrollbar-gutter` cannot fix that — it
+ * is defined to have no effect on overlay scrollbars — but giving
+ * `::-webkit-scrollbar` an explicit width does: Chromium and Safari switch that
+ * container to a classic, always-drawn, space-occupying scrollbar.
+ *
+ * Deliberately no `scrollbar-gutter: stable`, which would work once the lane is
+ * classic: it reserves the lane whether or not anything overflows, so a
+ * container showing one short view would pay 12px for a scrollbar it never
+ * draws. The lane appearing is the signal, so it has to mean something — which
+ * puts the burden on the container to overflow only when it has content to
+ * scroll to, rather than by trailing space it renders for its own reasons.
+ *
+ * Deliberately no `scrollbar-width`/`scrollbar-color`: in Chromium the standard
+ * properties win over the `::-webkit-` pseudo-elements and put the overlay
+ * behavior back. Firefox on macOS ignores both approaches and follows the OS
+ * "Show scroll bars" setting; there is no CSS that overrides it.
+ *
+ * Thumb geometry matches {@link VerticalScrollbar}, the scrollbar the
+ * canvas-backed displays draw for themselves, so the two read as one control.
+ */
+export const persistentScrollbarStyle = (theme) => ({
+    '&::-webkit-scrollbar': {
+        width: LANE_WIDTH,
+        height: LANE_WIDTH,
+    },
+    '&::-webkit-scrollbar-track': {
+        background: 'transparent',
+    },
+    '&::-webkit-scrollbar-thumb': {
+        background: theme.palette.action.disabled,
+        borderRadius: LANE_WIDTH / 2,
+        // paints the thumb inside a transparent border so the lane keeps its
+        // full hit area while the visible thumb stays the same 6px the
+        // in-display scrollbar uses
+        border: `${THUMB_INSET}px solid transparent`,
+        backgroundClip: 'content-box',
+    },
+    '&::-webkit-scrollbar-thumb:hover': {
+        background: theme.palette.action.active,
+        backgroundClip: 'content-box',
+    },
+    '&::-webkit-scrollbar-corner': {
+        background: 'transparent',
+    },
+});

package/esm/ui/radioSubMenu.d.ts

@@ -0,0 +1,33 @@
+import type { MenuItem } from './MenuTypes.ts';
+import type React from 'react';
+/**
+ * Build a radio submenu from a `[value, label]` option table keyed on the
+ * current `value`. Lets a display keep one option table as the single source of
+ * truth for both its config enumeration and its track menu, so the two can't
+ * drift. Generic over the value's string-literal union. `extraItems` are
+ * appended after the radios (e.g. a related checkbox) within the same submenu.
+ *
+ * Every display has a submenu of this shape naming the one thing it draws —
+ * wiggle's "Plot type", MAF's "Row coloring", Hi-C's "Color scheme", the arc
+ * display's "Display mode". The labels stay display-specific (they name
+ * genuinely different choices); the construction is shared so a hand-rolled
+ * copy can't forget that a settings row keeps the menu open.
+ *
+ * React-free: `React.ElementType` is a type-only import, so this stays inside
+ * the `menuItems.ts` purity boundary.
+ */
+/** #menuBuilder makeRadioSubMenu | a radio group wrapped in a submenu row */
+export declare function makeRadioSubMenu<T extends string>(opts: {
+    label: string;
+    icon?: React.ElementType;
+    value: T;
+    onChange: (value: T) => void;
+    options: readonly (readonly [T, string])[];
+    extraItems?: MenuItem[];
+    /**
+     * Prose for the group, on the row that opens it. One "?" here rather than one
+     * per radio, which is where a group whose options differ by a word each would
+     * otherwise repeat itself three times.
+     */
+    helpText?: string;
+}): MenuItem;

package/esm/ui/radioSubMenu.js

@@ -0,0 +1,32 @@
+import { radioItems } from './toggleMenuItems.js';
+/**
+ * Build a radio submenu from a `[value, label]` option table keyed on the
+ * current `value`. Lets a display keep one option table as the single source of
+ * truth for both its config enumeration and its track menu, so the two can't
+ * drift. Generic over the value's string-literal union. `extraItems` are
+ * appended after the radios (e.g. a related checkbox) within the same submenu.
+ *
+ * Every display has a submenu of this shape naming the one thing it draws —
+ * wiggle's "Plot type", MAF's "Row coloring", Hi-C's "Color scheme", the arc
+ * display's "Display mode". The labels stay display-specific (they name
+ * genuinely different choices); the construction is shared so a hand-rolled
+ * copy can't forget that a settings row keeps the menu open.
+ *
+ * React-free: `React.ElementType` is a type-only import, so this stays inside
+ * the `menuItems.ts` purity boundary.
+ */
+/** #menuBuilder makeRadioSubMenu | a radio group wrapped in a submenu row */
+export function makeRadioSubMenu(opts) {
+    const { label, icon, value, onChange, options, extraItems = [] } = opts;
+    return {
+        label,
+        icon,
+        helpText: opts.helpText,
+        subMenu: [
+            // via radioItems so these keep the menu open like every other
+            // setting row — a plot type is usually picked by trying a couple
+            ...radioItems(options.map(([value, label]) => ({ value, label })), value, onChange),
+            ...extraItems,
+        ],
+    };
+}

package/esm/ui/react-colorful.js

@@ -1,4 +1,8 @@
-import e, { useRef as r, useMemo as t, useEffect as o, useState as a, useCallback as l, useLayoutEffect as n, } from 'react';
+/* eslint-disable */
+// @ts-nocheck
+// vendored (e.g. copied into our source tree) because the tooling picks up "import" statements that confuse jest, could confuse other consumers of our modules
+// copy of react-colorful/dist/index.esmodule.js
+import e, { useState as a, useCallback as l, useLayoutEffect as n, useEffect as o, useRef as r, useMemo as t, } from 'react';
 function s() {
     return (s =
         Object.assign ||

package/esm/ui/replaceViewAction.d.ts

@@ -0,0 +1,31 @@
+import type { AbstractViewContainer, AbstractViewModel } from '../util/types/index.ts';
+import type { SubmitFormProps } from './SubmitForm.tsx';
+/**
+ * The two destinations a launch dialog offers, as `SubmitDialog` props: Submit
+ * opens the launched view in a new one, and a second button puts it in the slot
+ * the launching view occupies.
+ *
+ * Every launcher anchored on what a view is already showing — the synteny
+ * launches, "read vs ref" — wants exactly this
+ * pair, and each had written the same four lines around
+ * {@link ReplaceCurrentViewButton}: the guard, the button, its disabled state,
+ * and the renaming of Submit that only makes sense once there are two buttons.
+ * The guard is the part worth having in one place; see {@link canReplaceView}
+ * for the case each copy got wrong.
+ *
+ * Spread it into the dialog *before* any explicit props, so a caller that words
+ * its own Submit differently still can:
+ *
+ * ```tsx
+ * <SubmitDialog
+ *   {...replaceViewAction({ session, sourceView, disabled, onReplace: launch })}
+ *   submitText="Open in new view"
+ * />
+ * ```
+ */
+export declare function replaceViewAction({ session, sourceView, disabled, onReplace, }: {
+    session: AbstractViewContainer;
+    sourceView: AbstractViewModel | undefined;
+    disabled?: boolean;
+    onReplace: (replacing: AbstractViewModel) => void;
+}): Pick<SubmitFormProps, 'submitText' | 'actions'>;

package/esm/ui/replaceViewAction.js

@@ -0,0 +1,39 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+import { canReplaceView } from '../util/types/index.js';
+import ReplaceCurrentViewButton from './ReplaceCurrentViewButton.js';
+/**
+ * The two destinations a launch dialog offers, as `SubmitDialog` props: Submit
+ * opens the launched view in a new one, and a second button puts it in the slot
+ * the launching view occupies.
+ *
+ * Every launcher anchored on what a view is already showing — the synteny
+ * launches, "read vs ref" — wants exactly this
+ * pair, and each had written the same four lines around
+ * {@link ReplaceCurrentViewButton}: the guard, the button, its disabled state,
+ * and the renaming of Submit that only makes sense once there are two buttons.
+ * The guard is the part worth having in one place; see {@link canReplaceView}
+ * for the case each copy got wrong.
+ *
+ * Spread it into the dialog *before* any explicit props, so a caller that words
+ * its own Submit differently still can:
+ *
+ * ```tsx
+ * <SubmitDialog
+ *   {...replaceViewAction({ session, sourceView, disabled, onReplace: launch })}
+ *   submitText="Open in new view"
+ * />
+ * ```
+ */
+export function replaceViewAction({ session, sourceView, disabled, onReplace, }) {
+    return canReplaceView(session, sourceView)
+        ? {
+            // named only when there is a second way out to tell it apart from —
+            // otherwise Submit is the only button and "Submit" is what it has
+            // always said
+            submitText: 'Open in new view',
+            actions: (_jsx(ReplaceCurrentViewButton, { disabled: disabled, onClick: () => {
+                    onReplace(sourceView);
+                } })),
+        }
+        : {};
+}

package/esm/ui/rewriteExternalAnchors.d.ts

@@ -0,0 +1 @@
+export declare function rewriteExternalAnchors(el: HTMLElement): void;

package/esm/ui/rewriteExternalAnchors.js

@@ -0,0 +1,8 @@
+// Harden anchors in sanitized HTML: open in a new tab without leaking the
+// opener reference. Shared by the setHTML and dompurify sanitizer paths.
+export function rewriteExternalAnchors(el) {
+    for (const a of el.querySelectorAll('a')) {
+        a.setAttribute('rel', 'noopener noreferrer');
+        a.setAttribute('target', '_blank');
+    }
+}

package/esm/ui/scrollZoomLabels.d.ts

@@ -0,0 +1,17 @@
+/**
+ * The preference's name. One string, because it had four spellings across three
+ * headers and a menu, and a user who meets it twice has to recognize it as the
+ * same thing.
+ */
+export declare const SCROLL_ZOOM_LABEL = "Zoom on scroll";
+/**
+ * One paragraph doing two jobs: the control's tooltip and the menu item's help
+ * text. Short enough to hover, because it is the only explanation there is —
+ * nothing else on screen names the gesture.
+ *
+ * It names where the page still scrolls, which is the part users cannot guess:
+ * with this on, the wheel over a track is the view's, and no modifier takes it
+ * back — the browser turns shift+wheel into horizontal scroll, ctrl/meta+wheel
+ * is a trackpad pinch, and Firefox binds alt+wheel to history navigation.
+ */
+export declare const SCROLL_ZOOM_HELP = "The mouse wheel zooms over the tracks instead of scrolling the page; the view header above them still scrolls. ctrl+scroll (\u2318+scroll on a Mac) zooms either way. Applies to every view in the app.";

package/esm/ui/scrollZoomLabels.js

@@ -0,0 +1,22 @@
+// What every surface calls scroll-to-zoom, in a module with no React in it:
+// LinearGenomeView's `menuItems.ts` is evaluated eagerly and must not pull a
+// Material component graph in behind a pair of strings (see
+// agent-docs/reference/EAGER_BUNDLE.md). The control that renders them is
+// ScrollZoomToggle.
+/**
+ * The preference's name. One string, because it had four spellings across three
+ * headers and a menu, and a user who meets it twice has to recognize it as the
+ * same thing.
+ */
+export const SCROLL_ZOOM_LABEL = 'Zoom on scroll';
+/**
+ * One paragraph doing two jobs: the control's tooltip and the menu item's help
+ * text. Short enough to hover, because it is the only explanation there is —
+ * nothing else on screen names the gesture.
+ *
+ * It names where the page still scrolls, which is the part users cannot guess:
+ * with this on, the wheel over a track is the view's, and no modifier takes it
+ * back — the browser turns shift+wheel into horizontal scroll, ctrl/meta+wheel
+ * is a trackpad pinch, and Firefox binds alt+wheel to history navigation.
+ */
+export const SCROLL_ZOOM_HELP = 'The mouse wheel zooms over the tracks instead of scrolling the page; the view header above them still scrolls. ctrl+scroll (⌘+scroll on a Mac) zooms either way. Applies to every view in the app.';

package/esm/ui/showSubMenu.d.ts

@@ -0,0 +1,19 @@
+import type { MenuItem } from './MenuTypes.ts';
+/**
+ * The "Show..." submenu every display groups its visibility toggles under, and
+ * the empty-omit that goes with it: a display whose toggles are all
+ * inapplicable right now (wiggle in density mode with no cross hatches, a
+ * multi-row painting with no legend) drops the row rather than opening an empty
+ * submenu.
+ *
+ * One helper because this was eleven hand-written literals that had already
+ * drifted three ways: the wiggle family said `'Show'` where everyone else said
+ * `'Show...'`, only some set the redundant `type: 'subMenu'`, and only the
+ * wiggle family omitted the empty submenu.
+ *
+ * Not exported from `ui/menuItems.ts`: the icon is a value import, and that
+ * entry is the React-free one (see its header). Import this module directly —
+ * `@jbrowse/core/ui/showSubMenu` — which costs one icon rather than the
+ * `@jbrowse/core/ui` barrel's ~80 Material components.
+ */
+export declare function makeShowSubMenu(items: MenuItem[]): MenuItem[];

package/esm/ui/showSubMenu.js

@@ -0,0 +1,30 @@
+import VisibilityIcon from '@mui/icons-material/Visibility';
+/**
+ * The "Show..." submenu every display groups its visibility toggles under, and
+ * the empty-omit that goes with it: a display whose toggles are all
+ * inapplicable right now (wiggle in density mode with no cross hatches, a
+ * multi-row painting with no legend) drops the row rather than opening an empty
+ * submenu.
+ *
+ * One helper because this was eleven hand-written literals that had already
+ * drifted three ways: the wiggle family said `'Show'` where everyone else said
+ * `'Show...'`, only some set the redundant `type: 'subMenu'`, and only the
+ * wiggle family omitted the empty submenu.
+ *
+ * Not exported from `ui/menuItems.ts`: the icon is a value import, and that
+ * entry is the React-free one (see its header). Import this module directly —
+ * `@jbrowse/core/ui/showSubMenu` — which costs one icon rather than the
+ * `@jbrowse/core/ui` barrel's ~80 Material components.
+ */
+export function makeShowSubMenu(items) {
+    return items.length
+        ? [
+            {
+                label: 'Show...',
+                icon: VisibilityIcon,
+                type: 'subMenu',
+                subMenu: items,
+            },
+        ]
+        : [];
+}

package/esm/ui/sliderScale.d.ts

@@ -0,0 +1,6 @@
+export type SliderScale = 'linear' | 'log' | 'cubic';
+export declare function sliderScale(scale: SliderScale): {
+    toSlider: (n: number) => number;
+    fromSlider: (v: number) => number;
+    sliderStep: number | undefined;
+};

package/esm/ui/sliderScale.js

@@ -0,0 +1,30 @@
+// Maps a real-unit value to/from a MUI Slider's internal thumb position for
+// non-linear controls, so callers pass real-unit min/max/value and read
+// real-unit values back. 'log' (log2 × 100) suits quantities spanning orders of
+// magnitude (bp window/step/length, read-support counts); 'cubic' gives fine
+// control near 0 where small changes read as large (opacity). `sliderStep` is
+// the step in slider space (undefined for linear — the caller supplies a
+// real-unit step). Single source for these transforms across the inline
+// track-menu sliders (makeSizeMenu) and the slider submenus behind
+// makeSizeSubMenu (the dotplot's and synteny's settings menus).
+export function sliderScale(scale) {
+    if (scale === 'log') {
+        return {
+            toSlider: (n) => Math.log2(Math.max(1, n)) * 100,
+            fromSlider: (v) => Math.round(2 ** (v / 100)),
+            sliderStep: 1,
+        };
+    }
+    if (scale === 'cubic') {
+        return {
+            toSlider: (n) => Math.cbrt(n),
+            fromSlider: (v) => v ** 3,
+            sliderStep: 0.01,
+        };
+    }
+    return {
+        toSlider: (n) => n,
+        fromSlider: (v) => v,
+        sliderStep: undefined,
+    };
+}

package/esm/ui/statusProgressKeyframes.d.ts

@@ -0,0 +1,6 @@
+export declare const indeterminateSweep: {
+    name: string;
+    styles: string;
+    anim: 1;
+    toString: () => string;
+} & string;

package/esm/ui/statusProgressKeyframes.js

@@ -0,0 +1,14 @@
+import { keyframes } from '../util/tss-react/index.js';
+// The indeterminate sweep. One bar rather than MUI's two: two say nothing the
+// first does not, and this one is drawn over work that is already saturating a
+// thread.
+//
+// `transform` alone, like `loadingDotKeyframes`, because the compositor owns it
+// — a `left` or `width` animation runs on the main thread and freezes during
+// exactly the jank this bar exists to explain. The bar is 40% of the track, so
+// -100% of its own width parks it clear of the left edge and 350% carries its
+// left edge past the right one.
+export const indeterminateSweep = keyframes `
+  from { transform: translateX(-100%); }
+  to { transform: translateX(350%); }
+`;

package/esm/ui/stripStackTraceMessage.d.ts

@@ -0,0 +1 @@
+export declare function stripStackTraceMessage(trace: string, message: string): string;

package/esm/ui/stripStackTraceMessage.js

@@ -0,0 +1,9 @@
+// Chrome prepends the error message to the stack trace; Firefox doesn't. Strip
+// it to avoid duplication (the message is already shown above the trace). The
+// message is the stringified error, e.g. "TypeError: foo" for any Error
+// subclass, so compare against it rather than a hardcoded "Error:" prefix.
+export function stripStackTraceMessage(trace, message) {
+    return message && trace.startsWith(message)
+        ? trace.slice(message.length)
+        : trace;
+}

package/esm/ui/styleTheme.d.ts

@@ -0,0 +1,158 @@
+import type { JBrowsePalette, ThemeInput } from './palette.ts';
+/**
+ * JBrowse's grid unit, in px. Half Material's 8, because a genome browser packs
+ * far more controls into a toolbar than a Material layout expects.
+ */
+export declare const DEFAULT_SPACING = 4;
+/** Base font size, in px. Material's default is 14; JBrowse's chrome is denser. */
+export declare const DEFAULT_FONT_SIZE = 12;
+/** What `pxToRem` assumes the `<html>` font size is. */
+export declare const HTML_FONT_SIZE = 16;
+export declare const DEFAULT_FONT_FAMILY = "\"Roboto\", \"Helvetica\", \"Arial\", sans-serif";
+export declare const DEFAULT_BORDER_RADIUS = 4;
+/**
+ * One entry of the type scale. `letterSpacing` is absent for a non-Roboto
+ * family rather than reset to `normal`, which is what MUI does and what lets a
+ * host's own tracking through.
+ */
+export interface TypeVariant {
+    fontFamily: string;
+    fontWeight: number | string;
+    fontSize: string;
+    lineHeight: number;
+    letterSpacing?: string;
+}
+export interface JBrowseTypography {
+    fontFamily: string;
+    fontSize: number;
+    htmlFontSize: number;
+    fontWeightLight: number | string;
+    fontWeightRegular: number | string;
+    fontWeightMedium: number | string;
+    fontWeightBold: number | string;
+    pxToRem: (size: number) => string;
+    body1: TypeVariant;
+    body2: TypeVariant;
+}
+/**
+ * What a `makeStyles` block is handed.
+ *
+ * Deliberately a subset of Material UI's `Theme` rather than a copy of it: it
+ * carries what the 268 call sites read and nothing else, so anything reaching
+ * further is a compile error naming the file rather than a silent dependency on
+ * a component library. `transitions`, `zIndex` and `shadows` are the three that
+ * used to be reached for; a literal reads better at each of those five sites,
+ * and `ui/zIndexes.ts` already owns the layering that matters.
+ */
+/**
+ * Where a portaled overlay is mounted. An element, a function returning one
+ * (which is what a shadow-DOM host writes, since its root does not exist when
+ * the config is built), or absent for `document.body`.
+ */
+export type PortalContainer = Element | (() => Element | null | undefined) | null | undefined;
+export interface JBrowseStyleTheme {
+    palette: JBrowsePalette;
+    spacing: (...args: number[]) => string;
+    shape: {
+        borderRadius: number;
+    };
+    typography: JBrowseTypography;
+    /**
+     * Where JBrowse's own portaled overlays mount. Read by `BaseTooltip`, which
+     * is the one piece of display chrome that has to escape its track's
+     * `contain: strict` box and so cannot render in place.
+     *
+     * It exists here so that reading it costs no UI toolkit. The tooltip used to
+     * take it off the Material theme (`useTheme().components.MuiPopper`), which
+     * put `@mui/material` in the import graph of a component every display
+     * renders on hover — including for a host that mounted `DisplayUIProvider`
+     * precisely to avoid that. Nothing Material was drawn, so neither half of
+     * jbrowse-build-your-own's census could see it: `Portal` emits no classed
+     * element, and the chip sets `fontFamily: inherit`, which is what defeats the
+     * Roboto fingerprint.
+     */
+    portalContainer?: PortalContainer;
+}
+export interface TypographyInput {
+    fontFamily?: string;
+    fontSize?: number;
+    htmlFontSize?: number;
+    fontWeightLight?: number | string;
+    fontWeightRegular?: number | string;
+    fontWeightMedium?: number | string;
+    fontWeightBold?: number | string;
+}
+/**
+ * The non-color half of what a theme may declare — `spacing` and `typography`,
+ * the two documented in the theming guide's "Sizing".
+ *
+ * Both admit a function arm, and that is not overbuilding: the config `theme`
+ * slot is typed as MUI's `ThemeOptions`, which has one, so this has to accept
+ * it for a caller to hand `themeOptions` straight in. Neither survives JSON, so
+ * neither reaches here from a config; `resolveStyleTheme` falls back to the
+ * defaults if one somehow does, rather than calling it.
+ */
+export interface SizingInput {
+    spacing?: number | string | readonly (number | string)[] | ((abs: never) => unknown);
+    typography?: TypographyInput | ((palette: never) => unknown);
+}
+/**
+ * A number is a grid unit and an array is a lookup table indexed by the
+ * argument, which is Material's contract and what a JSON config slot can
+ * express. An array entry that is already a string carries its own unit.
+ */
+export declare function createSpacing(input: SizingInput['spacing']): (...args: number[]) => string;
+export declare function createTypography(input?: TypographyInput): {
+    fontFamily: string;
+    fontSize: number;
+    htmlFontSize: number;
+    fontWeightLight: string | number;
+    fontWeightRegular: string | number;
+    fontWeightMedium: string | number;
+    fontWeightBold: string | number;
+    pxToRem: (size: number) => string;
+    body1: TypeVariant;
+    body2: TypeVariant;
+};
+/**
+ * The portal container, as a config theme states it.
+ *
+ * Deliberately the slot Material UI's own portaled components already read, so
+ * a shadow-DOM embed keeps stating it once and every portal — MUI's popovers
+ * and menus, and JBrowse's tooltip — lands in the same node. Moving JBrowse's
+ * tooltip off the Material theme was about its *import graph*, not about giving
+ * embedders a second thing to configure, so the vocabulary stays put.
+ */
+export interface PortalInput {
+    components?: {
+        MuiPopper?: {
+            defaultProps?: {
+                container?: PortalContainer;
+            };
+        };
+    };
+}
+/** A theme, as far as the style theme is concerned: colors plus sizing. */
+export interface StyleThemeInput extends ThemeInput, SizingInput, PortalInput {
+}
+/** What `resolveStyleTheme` reads — `resolvePalette`'s arguments, plus sizing. */
+export interface StyleThemeArgs {
+    configTheme?: StyleThemeInput;
+    themeName?: string;
+    extraThemes?: Record<string, StyleThemeInput>;
+}
+/**
+ * Build the style theme for a set of theme args.
+ *
+ * The colors come from `resolvePalette`, so this and the MUI theme cannot
+ * disagree about them by construction. Sizing follows the same rule the palette
+ * does: only the `default` theme draws from the config, since the named presets
+ * are fixed.
+ */
+export declare function resolveStyleTheme(args?: StyleThemeArgs): JBrowseStyleTheme;
+/**
+ * The style theme a component gets with no provider above it, resolved once
+ * rather than per call — a fresh object each render would defeat the
+ * memoization every `makeStyles` hook depends on.
+ */
+export declare const defaultStyleTheme: JBrowseStyleTheme;