@trackunit/react-components 2.10.3 → 2.10.4

package/index.cjs.js

@@ -11178,6 +11178,12 @@ const useOverflowItems = ({ threshold = 1, childUniqueIdentifierAttribute = "id"
  * ### When to use
  * Use Sidebar for secondary in-page navigation (e.g., switching between views within a page). Works well with `Tabs` for page-level navigation.
  *
+ * If you need a persistent nav column beside a content region (a page-level sidebar+content
+ * layout, e.g. Site Home, Administration, Asset Home), use `SidebarContentLayout` instead - it
+ * composes `Sidebar` internally and keeps its stacking breakpoint in sync with the content grid.
+ * Use `Sidebar` directly only for a standalone collapsing nav list with no content pane (e.g.
+ * inside a `PageHeader`'s `tabsList`, see `Tabs.stories.tsx`'s `ResponsivenessTwo`/`Three`).
+ *
  * ### When not to use
  * Do not use Sidebar for primary app navigation (the main menu). For top-level navigation, use the app shell navigation.
  *
@@ -11237,6 +11243,205 @@ const Sidebar = ({ childContainerClassName, children, breakpoint = "lg", classNa
                     }) })) })) : null] }));
 };
 
+// Responsive-switch mechanism decision (GLU-1576 spike)
+// ------------------------------------------------------
+// Three mechanisms were considered for the stack<->side-by-side switch:
+//
+// 1. Native CSS `@container` (the `layout-dual-column-sections` precedent in
+//    `libs/css/core/src/generators/generate-css-theme.ts`) - responds to this component's own
+//    available space rather than the viewport, which is what the parent spec asks for as a
+//    best-effort goal. Rejected for two reasons:
+//    a. It cannot be meaningfully unit-tested in this repo's test environment. Vitest here runs
+//       against jsdom, which has no layout engine and does not evaluate `@container` conditions -
+//       the class list would be identical regardless of the (fake) container width, so a test
+//       asserting "stacks below the breakpoint" vs. "side-by-side above it" would pass or fail for
+//       reasons unrelated to the actual behavior it's meant to guard.
+//    b. More fundamentally, `Sidebar`'s own internal tab-bar<->vertical-list switch
+//       (`cvaSidebarChildContainer` in `../Sidebar/Sidebar.variants`) is hard-wired to viewport-based
+//       Tailwind breakpoint classes (`lg:grid-cols-1` etc.), not container queries. Changing only
+//       this component to a container query would let the two switches disagree whenever this
+//       component's own width diverges from the viewport's - precisely the scenario a future side
+//       panel would create by narrowing this component without narrowing the viewport. Migrating
+//       `Sidebar` itself to `@container` is out of scope for this phase (blast radius across every
+//       existing `Sidebar` consumer, not just this one).
+// 2. `useContainerBreakpoints` (`../../hooks/useContainerBreakpoints`) - real container-width-based
+//    and unit-testable (it's backed by a mockable `ResizeObserver`, see its own spec file), but
+//    suffers from the exact same mechanism-mismatch problem as (1): `Sidebar`'s own switch still
+//    only reacts to viewport width, so "passing a consistent breakpoint value through" would only
+//    guarantee a shared prop *label*, not a shared trigger *condition*.
+// 3. Viewport-based Tailwind breakpoint classes (chosen) - matches `Sidebar`'s own existing
+//    mechanism byte-for-byte, so both switches are driven by the identical `@media (min-width: ...)`
+//    condition for the identical breakpoint token and can never disagree, by construction. This is
+//    the specification's explicitly-sanctioned final fallback ("non-blocking... acceptable if both
+//    above prove impractical"). It also keeps this component a genuinely pure-presentation one - no
+//    refs, no ResizeObserver, no effects - which matches `HostPage`'s own hook-free design.
+//
+// Trade-off: this does not satisfy the parent spec's best-effort "respond to own available space"
+// user story. That gap is accepted deliberately (the spec tracks it as "a known gap rather than a
+// blocker") rather than solved by a mechanism that would make the two breakpoint switches capable
+// of disagreeing with each other.
+/**
+ * The root grid. `min-h-0 flex-1` opts this into an ancestor `HostPage`'s height-cascading flex-col
+ * fill contract (see `HostPage.tsx`), so it gets a real, bounded height instead of an auto-height
+ * block. No `gap-*` utility is applied here, ever: the single visible gap between sidebar and
+ * content at the side-by-side breakpoint is contributed entirely by the content cell's own
+ * `p-content-space` left padding (see `cvaSidebarContentLayoutContent`) - a grid gap on top of that
+ * would silently double it.
+ *
+ * Below the breakpoint (stacked, single column), `grid-rows-[min-content_minmax(0px,1fr)]` pins the
+ * sidebar's row to its own content height and gives the content row every pixel of leftover space.
+ * Without an explicit row template, both rows default to `auto` sizing, and this grid's own bounded
+ * height (from the `flex-1` fill contract above) is almost always taller than the two rows' combined
+ * natural content height - `align-content`'s default `normal` computes to `stretch` for a grid
+ * container, so that leftover space gets distributed *proportionally across every `auto` row*, not
+ * just content's. That silently inflates the sidebar's row (and thus its box) well past its own
+ * content's height, leaving a blank gap below the nav items before content starts - a stacked-only
+ * sibling of the `minmax(min-content,1fr)` grid-blowout class of bug already fixed once for Asset
+ * Home's own internal grid (GLU-1562/Phase 17). `{breakpoint}:grid-rows-none` resets this back to a
+ * single implicit `auto` row at/above the breakpoint, where sidebar and content share one grid row
+ * (as two columns) and must both keep stretching to the full available height per `{bp}:h-full`.
+ *
+ * Each breakpoint's arbitrary-value class is spelled out in full (rather than built via string
+ * interpolation) because Tailwind's build-time scanner extracts candidate class names via a static
+ * regex over each source file's raw text, not by evaluating JavaScript - an interpolated class name
+ * would never appear as a complete literal string anywhere in this file and so would silently fail
+ * to generate any CSS at all.
+ */
+const cvaSidebarContentLayout = cssClassVarianceUtilities.cvaMerge(["grid", "min-h-0", "flex-1", "grid-rows-[min-content_minmax(0px,1fr)]"], {
+    variants: {
+        breakpoint: {
+            xs: ["grid-cols-1", "xs:grid-cols-[200px_minmax(0px,1fr)]", "xs:grid-rows-none"],
+            sm: ["grid-cols-1", "sm:grid-cols-[200px_minmax(0px,1fr)]", "sm:grid-rows-none"],
+            md: ["grid-cols-1", "md:grid-cols-[200px_minmax(0px,1fr)]", "md:grid-rows-none"],
+            lg: ["grid-cols-1", "lg:grid-cols-[200px_minmax(0px,1fr)]", "lg:grid-rows-none"],
+            xl: ["grid-cols-1", "xl:grid-cols-[200px_minmax(0px,1fr)]", "xl:grid-rows-none"],
+            "2xl": ["grid-cols-1", "2xl:grid-cols-[200px_minmax(0px,1fr)]", "2xl:grid-rows-none"],
+            "3xl": ["grid-cols-1", "3xl:grid-cols-[200px_minmax(0px,1fr)]", "3xl:grid-rows-none"],
+        },
+    },
+    defaultVariants: {
+        breakpoint: "lg",
+    },
+});
+/**
+ * The sidebar's own grid cell. `pt-4 pl-4` give it a fixed top/left inset (matching
+ * `p-content-space`'s own `spacing-4`) now that there's no ambient ancestor padding left to inherit
+ * one from.
+ *
+ * The right edge is a genuinely different edge depending on the breakpoint, so it's handled
+ * accordingly rather than uniformly:
+ * - Below the breakpoint, the grid is a single column (see `cvaSidebarContentLayout`), so the
+ *   sidebar spans the grid's full width and this edge is a true page edge, exactly like the left
+ *   edge - it gets the same `pr-4` inset.
+ * - At/above the breakpoint, this edge instead borders the content column, and *most* of it is
+ *   owned entirely by content's own `p-content-space` left padding (see module doc comment above and
+ *   `cvaSidebarContentLayoutContent`) - stacking this cell's own `pr-4` on top of that would silently
+ *   double the gap. `{breakpoint}:pr-2` cancels *most*, but not all, of it there - see below for the
+ *   deliberate remainder.
+ *
+ * `h-full min-h-0 overflow-y-auto` (applied only from the breakpoint upward, matching `Sidebar`'s
+ * own vertical-list mode) give the sidebar its own bounded height and local scroll: `Sidebar`'s
+ * vertical nav list is unclipped by default, so a long list could otherwise be taller than the
+ * grid row's available height, silently growing the row (the classic CSS grid "blowout") instead of
+ * scrolling locally.
+ *
+ * `[scrollbar-gutter:stable]` rides along with that same `overflow-y-auto`, reserving genuine,
+ * platform-correct scrollbar space (0 on overlay-scrollbar platforms like macOS, the native width
+ * elsewhere) on the same edge, so a long enough nav list's scrollbar never overlaps the items - and
+ * so the sidebar's rendered width stays consistent whether or not a *particular* page's item list
+ * happens to be long enough to overflow. Supported by every evergreen browser (Chrome/Edge 94+,
+ * Firefox 97+, Safari 18.2+); a no-op elsewhere, i.e. today's pre-fix behavior, so no regression risk.
+ *
+ * That reservation alone butts the items directly against the scrollbar track with zero breathing
+ * room, though - `scrollbar-gutter` only guarantees no *overlap*, it isn't a visual gap. `{bp}:pr-2`
+ * is the deliberate small remainder of the otherwise-cancelled `pr-4` that supplies that breathing
+ * room, sized independently of both the scrollbar's own width (which the browser already reserves via
+ * `scrollbar-gutter`) and of the sidebar/content gap above (which is `p-content-space`'s job, not
+ * this padding's) - it exists purely so the sidebar's own content doesn't look glued to the sidebar's
+ * own scrollbar. Keeping it a small fraction of the full `pr-4` (rather than restoring all of it, or
+ * clawing space back from the reserved gutter) avoids meaningfully inflating the sidebar/content gap
+ * `p-content-space` already owns - it is deliberately *not* zero, but not enough to look like a second
+ * gap either.
+ */
+const cvaSidebarContentLayoutSidebar = cssClassVarianceUtilities.cvaMerge(["pt-4", "pl-4", "pr-4"], {
+    variants: {
+        breakpoint: {
+            xs: ["xs:pr-2", "xs:h-full", "xs:min-h-0", "xs:overflow-y-auto", "xs:[scrollbar-gutter:stable]"],
+            sm: ["sm:pr-2", "sm:h-full", "sm:min-h-0", "sm:overflow-y-auto", "sm:[scrollbar-gutter:stable]"],
+            md: ["md:pr-2", "md:h-full", "md:min-h-0", "md:overflow-y-auto", "md:[scrollbar-gutter:stable]"],
+            lg: ["lg:pr-2", "lg:h-full", "lg:min-h-0", "lg:overflow-y-auto", "lg:[scrollbar-gutter:stable]"],
+            xl: ["xl:pr-2", "xl:h-full", "xl:min-h-0", "xl:overflow-y-auto", "xl:[scrollbar-gutter:stable]"],
+            "2xl": ["2xl:pr-2", "2xl:h-full", "2xl:min-h-0", "2xl:overflow-y-auto", "2xl:[scrollbar-gutter:stable]"],
+            "3xl": ["3xl:pr-2", "3xl:h-full", "3xl:min-h-0", "3xl:overflow-y-auto", "3xl:[scrollbar-gutter:stable]"],
+        },
+    },
+    defaultVariants: {
+        breakpoint: "lg",
+    },
+});
+/**
+ * The content's own grid cell: `relative` (a positioning context for a future side panel/drawer to
+ * anchor into), a definite height (`h-full`, chained from the root grid's own fill contract) with
+ * its own local `overflow-y-auto` (this cell's content may be a third-party iframe, which must
+ * contain its own overflow rather than bubbling it up).
+ *
+ * `p-content-space` is applied here by default (`contentSpace: true`): the padding decision is
+ * exposed on the component that owns the content's box, not silently forced by some invisible
+ * ancestor. Callers rendering a route that must sit flush (e.g. a full-page extension iframe) opt
+ * out with `contentSpace={false}`.
+ */
+const cvaSidebarContentLayoutContent = cssClassVarianceUtilities.cvaMerge(["relative", "h-full", "min-h-0", "overflow-y-auto"], {
+    variants: {
+        contentSpace: {
+            true: ["p-content-space"],
+            false: [],
+        },
+    },
+    defaultVariants: {
+        contentSpace: true,
+    },
+});
+
+/**
+ * SidebarContentLayout is the shared page shell for any screen built from a persistent navigation
+ * sidebar next to a main content area - the pattern behind Site Home, Administration, and Asset
+ * Home. It keeps that pairing consistent everywhere it's used: the same breakpoint decides both
+ * when the sidebar collapses to a tab bar and when content drops below it, so the two can never
+ * disagree, and every page gets identical spacing without reimplementing it by hand.
+ *
+ * The content slot renders whatever it's given untouched - a routed `Outlet`, a form, a table - and
+ * never imposes padding on it from the outside (see `contentSpace` to opt out of this component's
+ * own default inset, e.g. for a full-page extension iframe that needs to sit flush to the edges).
+ *
+ * ### When to use
+ * Use as the layout directly inside a `HostPage` for any page that needs a persistent navigation
+ * sidebar alongside routed/tabbed content (e.g. Site Home, Administration, Asset Home).
+ *
+ * ### When not to use
+ * Do not use for pages without a persistent sidebar - use `HostPage` directly instead.
+ *
+ * @example SidebarContentLayout with navigation items and routed content
+ * ```tsx
+ * import { SidebarContentLayout, SidebarItemProps } from "@trackunit/react-components";
+ *
+ * const SitePage = () => (
+ *   <SidebarContentLayout
+ *     content={<Outlet />}
+ *     sidebar={
+ *       <Button id="overview" variant="ghost-neutral">
+ *         Overview
+ *       </Button>
+ *     }
+ *   />
+ * );
+ * ```
+ * @param {SidebarContentLayoutProps} props - The props for the SidebarContentLayout component
+ * @returns {ReactElement} SidebarContentLayout component
+ */
+const SidebarContentLayout = ({ breakpoint = "lg", className, content, contentSpace = true, "data-testid": dataTestId = "sidebar-content-layout", sidebar, style, ref, }) => {
+    return (jsxRuntime.jsxs("div", { className: cvaSidebarContentLayout({ breakpoint, className }), "data-testid": dataTestId, ref: ref, style: style, children: [jsxRuntime.jsx("div", { className: cvaSidebarContentLayoutSidebar({ breakpoint }), "data-testid": `${dataTestId}-sidebar`, children: jsxRuntime.jsx(Sidebar, { breakpoint: breakpoint, children: sidebar }) }), jsxRuntime.jsx("div", { className: cvaSidebarContentLayoutContent({ contentSpace }), "data-testid": `${dataTestId}-content`, children: content })] }));
+};
+
 const cvaTabsRoot = cssClassVarianceUtilities.cvaMerge([]);
 const cvaTabList = cssClassVarianceUtilities.cvaMerge([
     "flex",
@@ -14395,6 +14600,7 @@ exports.SectionHeader = SectionHeader;
 exports.SegmentedValueBar = SegmentedValueBar;
 exports.Sheet = Sheet;
 exports.Sidebar = Sidebar;
+exports.SidebarContentLayout = SidebarContentLayout;
 exports.SkeletonBlock = SkeletonBlock;
 exports.SkeletonLabel = SkeletonLabel;
 exports.SkeletonLines = SkeletonLines;

package/index.esm.js

@@ -11177,6 +11177,12 @@ const useOverflowItems = ({ threshold = 1, childUniqueIdentifierAttribute = "id"
  * ### When to use
  * Use Sidebar for secondary in-page navigation (e.g., switching between views within a page). Works well with `Tabs` for page-level navigation.
  *
+ * If you need a persistent nav column beside a content region (a page-level sidebar+content
+ * layout, e.g. Site Home, Administration, Asset Home), use `SidebarContentLayout` instead - it
+ * composes `Sidebar` internally and keeps its stacking breakpoint in sync with the content grid.
+ * Use `Sidebar` directly only for a standalone collapsing nav list with no content pane (e.g.
+ * inside a `PageHeader`'s `tabsList`, see `Tabs.stories.tsx`'s `ResponsivenessTwo`/`Three`).
+ *
  * ### When not to use
  * Do not use Sidebar for primary app navigation (the main menu). For top-level navigation, use the app shell navigation.
  *
@@ -11236,6 +11242,205 @@ const Sidebar = ({ childContainerClassName, children, breakpoint = "lg", classNa
                     }) })) })) : null] }));
 };
 
+// Responsive-switch mechanism decision (GLU-1576 spike)
+// ------------------------------------------------------
+// Three mechanisms were considered for the stack<->side-by-side switch:
+//
+// 1. Native CSS `@container` (the `layout-dual-column-sections` precedent in
+//    `libs/css/core/src/generators/generate-css-theme.ts`) - responds to this component's own
+//    available space rather than the viewport, which is what the parent spec asks for as a
+//    best-effort goal. Rejected for two reasons:
+//    a. It cannot be meaningfully unit-tested in this repo's test environment. Vitest here runs
+//       against jsdom, which has no layout engine and does not evaluate `@container` conditions -
+//       the class list would be identical regardless of the (fake) container width, so a test
+//       asserting "stacks below the breakpoint" vs. "side-by-side above it" would pass or fail for
+//       reasons unrelated to the actual behavior it's meant to guard.
+//    b. More fundamentally, `Sidebar`'s own internal tab-bar<->vertical-list switch
+//       (`cvaSidebarChildContainer` in `../Sidebar/Sidebar.variants`) is hard-wired to viewport-based
+//       Tailwind breakpoint classes (`lg:grid-cols-1` etc.), not container queries. Changing only
+//       this component to a container query would let the two switches disagree whenever this
+//       component's own width diverges from the viewport's - precisely the scenario a future side
+//       panel would create by narrowing this component without narrowing the viewport. Migrating
+//       `Sidebar` itself to `@container` is out of scope for this phase (blast radius across every
+//       existing `Sidebar` consumer, not just this one).
+// 2. `useContainerBreakpoints` (`../../hooks/useContainerBreakpoints`) - real container-width-based
+//    and unit-testable (it's backed by a mockable `ResizeObserver`, see its own spec file), but
+//    suffers from the exact same mechanism-mismatch problem as (1): `Sidebar`'s own switch still
+//    only reacts to viewport width, so "passing a consistent breakpoint value through" would only
+//    guarantee a shared prop *label*, not a shared trigger *condition*.
+// 3. Viewport-based Tailwind breakpoint classes (chosen) - matches `Sidebar`'s own existing
+//    mechanism byte-for-byte, so both switches are driven by the identical `@media (min-width: ...)`
+//    condition for the identical breakpoint token and can never disagree, by construction. This is
+//    the specification's explicitly-sanctioned final fallback ("non-blocking... acceptable if both
+//    above prove impractical"). It also keeps this component a genuinely pure-presentation one - no
+//    refs, no ResizeObserver, no effects - which matches `HostPage`'s own hook-free design.
+//
+// Trade-off: this does not satisfy the parent spec's best-effort "respond to own available space"
+// user story. That gap is accepted deliberately (the spec tracks it as "a known gap rather than a
+// blocker") rather than solved by a mechanism that would make the two breakpoint switches capable
+// of disagreeing with each other.
+/**
+ * The root grid. `min-h-0 flex-1` opts this into an ancestor `HostPage`'s height-cascading flex-col
+ * fill contract (see `HostPage.tsx`), so it gets a real, bounded height instead of an auto-height
+ * block. No `gap-*` utility is applied here, ever: the single visible gap between sidebar and
+ * content at the side-by-side breakpoint is contributed entirely by the content cell's own
+ * `p-content-space` left padding (see `cvaSidebarContentLayoutContent`) - a grid gap on top of that
+ * would silently double it.
+ *
+ * Below the breakpoint (stacked, single column), `grid-rows-[min-content_minmax(0px,1fr)]` pins the
+ * sidebar's row to its own content height and gives the content row every pixel of leftover space.
+ * Without an explicit row template, both rows default to `auto` sizing, and this grid's own bounded
+ * height (from the `flex-1` fill contract above) is almost always taller than the two rows' combined
+ * natural content height - `align-content`'s default `normal` computes to `stretch` for a grid
+ * container, so that leftover space gets distributed *proportionally across every `auto` row*, not
+ * just content's. That silently inflates the sidebar's row (and thus its box) well past its own
+ * content's height, leaving a blank gap below the nav items before content starts - a stacked-only
+ * sibling of the `minmax(min-content,1fr)` grid-blowout class of bug already fixed once for Asset
+ * Home's own internal grid (GLU-1562/Phase 17). `{breakpoint}:grid-rows-none` resets this back to a
+ * single implicit `auto` row at/above the breakpoint, where sidebar and content share one grid row
+ * (as two columns) and must both keep stretching to the full available height per `{bp}:h-full`.
+ *
+ * Each breakpoint's arbitrary-value class is spelled out in full (rather than built via string
+ * interpolation) because Tailwind's build-time scanner extracts candidate class names via a static
+ * regex over each source file's raw text, not by evaluating JavaScript - an interpolated class name
+ * would never appear as a complete literal string anywhere in this file and so would silently fail
+ * to generate any CSS at all.
+ */
+const cvaSidebarContentLayout = cvaMerge(["grid", "min-h-0", "flex-1", "grid-rows-[min-content_minmax(0px,1fr)]"], {
+    variants: {
+        breakpoint: {
+            xs: ["grid-cols-1", "xs:grid-cols-[200px_minmax(0px,1fr)]", "xs:grid-rows-none"],
+            sm: ["grid-cols-1", "sm:grid-cols-[200px_minmax(0px,1fr)]", "sm:grid-rows-none"],
+            md: ["grid-cols-1", "md:grid-cols-[200px_minmax(0px,1fr)]", "md:grid-rows-none"],
+            lg: ["grid-cols-1", "lg:grid-cols-[200px_minmax(0px,1fr)]", "lg:grid-rows-none"],
+            xl: ["grid-cols-1", "xl:grid-cols-[200px_minmax(0px,1fr)]", "xl:grid-rows-none"],
+            "2xl": ["grid-cols-1", "2xl:grid-cols-[200px_minmax(0px,1fr)]", "2xl:grid-rows-none"],
+            "3xl": ["grid-cols-1", "3xl:grid-cols-[200px_minmax(0px,1fr)]", "3xl:grid-rows-none"],
+        },
+    },
+    defaultVariants: {
+        breakpoint: "lg",
+    },
+});
+/**
+ * The sidebar's own grid cell. `pt-4 pl-4` give it a fixed top/left inset (matching
+ * `p-content-space`'s own `spacing-4`) now that there's no ambient ancestor padding left to inherit
+ * one from.
+ *
+ * The right edge is a genuinely different edge depending on the breakpoint, so it's handled
+ * accordingly rather than uniformly:
+ * - Below the breakpoint, the grid is a single column (see `cvaSidebarContentLayout`), so the
+ *   sidebar spans the grid's full width and this edge is a true page edge, exactly like the left
+ *   edge - it gets the same `pr-4` inset.
+ * - At/above the breakpoint, this edge instead borders the content column, and *most* of it is
+ *   owned entirely by content's own `p-content-space` left padding (see module doc comment above and
+ *   `cvaSidebarContentLayoutContent`) - stacking this cell's own `pr-4` on top of that would silently
+ *   double the gap. `{breakpoint}:pr-2` cancels *most*, but not all, of it there - see below for the
+ *   deliberate remainder.
+ *
+ * `h-full min-h-0 overflow-y-auto` (applied only from the breakpoint upward, matching `Sidebar`'s
+ * own vertical-list mode) give the sidebar its own bounded height and local scroll: `Sidebar`'s
+ * vertical nav list is unclipped by default, so a long list could otherwise be taller than the
+ * grid row's available height, silently growing the row (the classic CSS grid "blowout") instead of
+ * scrolling locally.
+ *
+ * `[scrollbar-gutter:stable]` rides along with that same `overflow-y-auto`, reserving genuine,
+ * platform-correct scrollbar space (0 on overlay-scrollbar platforms like macOS, the native width
+ * elsewhere) on the same edge, so a long enough nav list's scrollbar never overlaps the items - and
+ * so the sidebar's rendered width stays consistent whether or not a *particular* page's item list
+ * happens to be long enough to overflow. Supported by every evergreen browser (Chrome/Edge 94+,
+ * Firefox 97+, Safari 18.2+); a no-op elsewhere, i.e. today's pre-fix behavior, so no regression risk.
+ *
+ * That reservation alone butts the items directly against the scrollbar track with zero breathing
+ * room, though - `scrollbar-gutter` only guarantees no *overlap*, it isn't a visual gap. `{bp}:pr-2`
+ * is the deliberate small remainder of the otherwise-cancelled `pr-4` that supplies that breathing
+ * room, sized independently of both the scrollbar's own width (which the browser already reserves via
+ * `scrollbar-gutter`) and of the sidebar/content gap above (which is `p-content-space`'s job, not
+ * this padding's) - it exists purely so the sidebar's own content doesn't look glued to the sidebar's
+ * own scrollbar. Keeping it a small fraction of the full `pr-4` (rather than restoring all of it, or
+ * clawing space back from the reserved gutter) avoids meaningfully inflating the sidebar/content gap
+ * `p-content-space` already owns - it is deliberately *not* zero, but not enough to look like a second
+ * gap either.
+ */
+const cvaSidebarContentLayoutSidebar = cvaMerge(["pt-4", "pl-4", "pr-4"], {
+    variants: {
+        breakpoint: {
+            xs: ["xs:pr-2", "xs:h-full", "xs:min-h-0", "xs:overflow-y-auto", "xs:[scrollbar-gutter:stable]"],
+            sm: ["sm:pr-2", "sm:h-full", "sm:min-h-0", "sm:overflow-y-auto", "sm:[scrollbar-gutter:stable]"],
+            md: ["md:pr-2", "md:h-full", "md:min-h-0", "md:overflow-y-auto", "md:[scrollbar-gutter:stable]"],
+            lg: ["lg:pr-2", "lg:h-full", "lg:min-h-0", "lg:overflow-y-auto", "lg:[scrollbar-gutter:stable]"],
+            xl: ["xl:pr-2", "xl:h-full", "xl:min-h-0", "xl:overflow-y-auto", "xl:[scrollbar-gutter:stable]"],
+            "2xl": ["2xl:pr-2", "2xl:h-full", "2xl:min-h-0", "2xl:overflow-y-auto", "2xl:[scrollbar-gutter:stable]"],
+            "3xl": ["3xl:pr-2", "3xl:h-full", "3xl:min-h-0", "3xl:overflow-y-auto", "3xl:[scrollbar-gutter:stable]"],
+        },
+    },
+    defaultVariants: {
+        breakpoint: "lg",
+    },
+});
+/**
+ * The content's own grid cell: `relative` (a positioning context for a future side panel/drawer to
+ * anchor into), a definite height (`h-full`, chained from the root grid's own fill contract) with
+ * its own local `overflow-y-auto` (this cell's content may be a third-party iframe, which must
+ * contain its own overflow rather than bubbling it up).
+ *
+ * `p-content-space` is applied here by default (`contentSpace: true`): the padding decision is
+ * exposed on the component that owns the content's box, not silently forced by some invisible
+ * ancestor. Callers rendering a route that must sit flush (e.g. a full-page extension iframe) opt
+ * out with `contentSpace={false}`.
+ */
+const cvaSidebarContentLayoutContent = cvaMerge(["relative", "h-full", "min-h-0", "overflow-y-auto"], {
+    variants: {
+        contentSpace: {
+            true: ["p-content-space"],
+            false: [],
+        },
+    },
+    defaultVariants: {
+        contentSpace: true,
+    },
+});
+
+/**
+ * SidebarContentLayout is the shared page shell for any screen built from a persistent navigation
+ * sidebar next to a main content area - the pattern behind Site Home, Administration, and Asset
+ * Home. It keeps that pairing consistent everywhere it's used: the same breakpoint decides both
+ * when the sidebar collapses to a tab bar and when content drops below it, so the two can never
+ * disagree, and every page gets identical spacing without reimplementing it by hand.
+ *
+ * The content slot renders whatever it's given untouched - a routed `Outlet`, a form, a table - and
+ * never imposes padding on it from the outside (see `contentSpace` to opt out of this component's
+ * own default inset, e.g. for a full-page extension iframe that needs to sit flush to the edges).
+ *
+ * ### When to use
+ * Use as the layout directly inside a `HostPage` for any page that needs a persistent navigation
+ * sidebar alongside routed/tabbed content (e.g. Site Home, Administration, Asset Home).
+ *
+ * ### When not to use
+ * Do not use for pages without a persistent sidebar - use `HostPage` directly instead.
+ *
+ * @example SidebarContentLayout with navigation items and routed content
+ * ```tsx
+ * import { SidebarContentLayout, SidebarItemProps } from "@trackunit/react-components";
+ *
+ * const SitePage = () => (
+ *   <SidebarContentLayout
+ *     content={<Outlet />}
+ *     sidebar={
+ *       <Button id="overview" variant="ghost-neutral">
+ *         Overview
+ *       </Button>
+ *     }
+ *   />
+ * );
+ * ```
+ * @param {SidebarContentLayoutProps} props - The props for the SidebarContentLayout component
+ * @returns {ReactElement} SidebarContentLayout component
+ */
+const SidebarContentLayout = ({ breakpoint = "lg", className, content, contentSpace = true, "data-testid": dataTestId = "sidebar-content-layout", sidebar, style, ref, }) => {
+    return (jsxs("div", { className: cvaSidebarContentLayout({ breakpoint, className }), "data-testid": dataTestId, ref: ref, style: style, children: [jsx("div", { className: cvaSidebarContentLayoutSidebar({ breakpoint }), "data-testid": `${dataTestId}-sidebar`, children: jsx(Sidebar, { breakpoint: breakpoint, children: sidebar }) }), jsx("div", { className: cvaSidebarContentLayoutContent({ contentSpace }), "data-testid": `${dataTestId}-content`, children: content })] }));
+};
+
 const cvaTabsRoot = cvaMerge([]);
 const cvaTabList = cvaMerge([
     "flex",
@@ -14325,4 +14530,4 @@ const useWindowActivity = ({ onFocus, onBlur, skip = false } = { onBlur: undefin
  */
 setupLibraryTranslations();
 
-export { Alert, Badge, Breadcrumb, Button, Card, CardBody, CardFooter, CardHeader, Collapse, CompletionStatusIndicator, CopyButton, CopyableText, DEFAULT_SKELETON_PREFERENCE_CARD_PROPS, DetailsList, EmptyState, EmptyValue, ExternalLink, GridAreas, Heading, Highlight, HorizontalOverflowScroller, Icon, IconButton, Indicator, KPI, KPICard, KPICardSkeleton, KPISkeleton, LabeledValue, LabeledValueList, List, ListItem, MAX_HASH_LENGTH, MAX_URL_LENGTH, MenuContent, MenuDivider, MenuItem, MenuTree, MoreMenu, Notice, PackageNameStoryComponent, Page, PageContent, PageHeader, PageHeaderKpiMetrics, PageHeaderSecondaryActions, PageHeaderTitle, Pagination, Polygon, Popover, PopoverContent, PopoverTitle, PopoverTrigger, Portal, PreferenceCard, PreferenceCardSkeleton, Prompt, ROLE_CARD, SHEET_TRANSITION_DURATION, SHEET_TRANSITION_DURATION_MS, SHEET_TRANSITION_EASING, SectionHeader, SegmentedValueBar, Sheet, Sidebar, SkeletonBlock, SkeletonLabel, SkeletonLines, Spacer, Spinner, StarButton, Tab, TabContent, TabList, Tabs, Tag, Text, ToggleGroup, Tooltip, TrendIndicator, TrendIndicators, ValueBar, ZStack, createGrid, cvaButton, cvaButtonPrefixSuffix, cvaButtonSpinner, cvaButtonSpinnerContainer, cvaClickable, cvaContainerStyles, cvaContentContainer, cvaContentWrapper, cvaDescriptionCard, cvaIconBackground, cvaIconButton, cvaImgStyles, cvaIndicator, cvaIndicatorIcon, cvaIndicatorIconBackground, cvaIndicatorLabel, cvaIndicatorPing, cvaInputContainer, cvaInteractableItem, cvaList, cvaListContainer, cvaListItem$1 as cvaListItem, cvaMenu, cvaMenuItem, cvaMenuItemLabel, cvaMenuItemPrefix, cvaMenuItemStyle, cvaMenuItemSuffix, cvaMenuList, cvaMenuListDivider, cvaMenuListItem, cvaMenuListMultiSelect, cvaPageHeader, cvaPageHeaderContainer, cvaPageHeaderHeading, cvaPreferenceCard, cvaTitleCard, cvaToggleGroup, cvaToggleGroupWithSlidingBackground, cvaToggleItem, cvaToggleItemContent, cvaToggleItemText, cvaZStackContainer, cvaZStackItem, defaultPageSize, docs, getDevicePixelRatio, getValueBarColorByValue, iconColorNames, iconPalette, noPagination, preferenceCardGrid, useBidirectionalScroll, useClickOutside, useContainerBreakpoints, useContinuousTimeout, useCopyToClipboard, useCursorUrlSync, useCustomEncoding, useDebounce, useDevicePixelRatio, useElevatedReducer, useElevatedState, useGridAreas, useHashParamSync, useHover, useInfiniteScroll, useIsFirstRender, useIsFullscreen, useIsTextTruncated, useKeyboardShortcut, useList, useListItemHeight, useLocalStorage, useLocalStorageReducer, useMeasure, useMenuTree, useMergeRefs, useModifierKey, useOptionalPopoverContext, useOverflowBorder, useOverflowItems, usePersistedState, usePopoverContext, usePrevious, usePrompt, useRandomCSSLengths, useRelayPagination, useResize, useScrollBlock, useScrollDetection, useSearchParamSync, useSelfUpdatingRef, useSessionStorage, useSessionStorageReducer, useSheet, useSheetSnap, useStorageKey, useTextSearch, useTimeout, useViewportBreakpoints, useWatch, useWindowActivity };
+export { Alert, Badge, Breadcrumb, Button, Card, CardBody, CardFooter, CardHeader, Collapse, CompletionStatusIndicator, CopyButton, CopyableText, DEFAULT_SKELETON_PREFERENCE_CARD_PROPS, DetailsList, EmptyState, EmptyValue, ExternalLink, GridAreas, Heading, Highlight, HorizontalOverflowScroller, Icon, IconButton, Indicator, KPI, KPICard, KPICardSkeleton, KPISkeleton, LabeledValue, LabeledValueList, List, ListItem, MAX_HASH_LENGTH, MAX_URL_LENGTH, MenuContent, MenuDivider, MenuItem, MenuTree, MoreMenu, Notice, PackageNameStoryComponent, Page, PageContent, PageHeader, PageHeaderKpiMetrics, PageHeaderSecondaryActions, PageHeaderTitle, Pagination, Polygon, Popover, PopoverContent, PopoverTitle, PopoverTrigger, Portal, PreferenceCard, PreferenceCardSkeleton, Prompt, ROLE_CARD, SHEET_TRANSITION_DURATION, SHEET_TRANSITION_DURATION_MS, SHEET_TRANSITION_EASING, SectionHeader, SegmentedValueBar, Sheet, Sidebar, SidebarContentLayout, SkeletonBlock, SkeletonLabel, SkeletonLines, Spacer, Spinner, StarButton, Tab, TabContent, TabList, Tabs, Tag, Text, ToggleGroup, Tooltip, TrendIndicator, TrendIndicators, ValueBar, ZStack, createGrid, cvaButton, cvaButtonPrefixSuffix, cvaButtonSpinner, cvaButtonSpinnerContainer, cvaClickable, cvaContainerStyles, cvaContentContainer, cvaContentWrapper, cvaDescriptionCard, cvaIconBackground, cvaIconButton, cvaImgStyles, cvaIndicator, cvaIndicatorIcon, cvaIndicatorIconBackground, cvaIndicatorLabel, cvaIndicatorPing, cvaInputContainer, cvaInteractableItem, cvaList, cvaListContainer, cvaListItem$1 as cvaListItem, cvaMenu, cvaMenuItem, cvaMenuItemLabel, cvaMenuItemPrefix, cvaMenuItemStyle, cvaMenuItemSuffix, cvaMenuList, cvaMenuListDivider, cvaMenuListItem, cvaMenuListMultiSelect, cvaPageHeader, cvaPageHeaderContainer, cvaPageHeaderHeading, cvaPreferenceCard, cvaTitleCard, cvaToggleGroup, cvaToggleGroupWithSlidingBackground, cvaToggleItem, cvaToggleItemContent, cvaToggleItemText, cvaZStackContainer, cvaZStackItem, defaultPageSize, docs, getDevicePixelRatio, getValueBarColorByValue, iconColorNames, iconPalette, noPagination, preferenceCardGrid, useBidirectionalScroll, useClickOutside, useContainerBreakpoints, useContinuousTimeout, useCopyToClipboard, useCursorUrlSync, useCustomEncoding, useDebounce, useDevicePixelRatio, useElevatedReducer, useElevatedState, useGridAreas, useHashParamSync, useHover, useInfiniteScroll, useIsFirstRender, useIsFullscreen, useIsTextTruncated, useKeyboardShortcut, useList, useListItemHeight, useLocalStorage, useLocalStorageReducer, useMeasure, useMenuTree, useMergeRefs, useModifierKey, useOptionalPopoverContext, useOverflowBorder, useOverflowItems, usePersistedState, usePopoverContext, usePrevious, usePrompt, useRandomCSSLengths, useRelayPagination, useResize, useScrollBlock, useScrollDetection, useSearchParamSync, useSelfUpdatingRef, useSessionStorage, useSessionStorageReducer, useSheet, useSheetSnap, useStorageKey, useTextSearch, useTimeout, useViewportBreakpoints, useWatch, useWindowActivity };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trackunit/react-components",
-  "version": "2.10.3",
+  "version": "2.10.4",
   "repository": "https://github.com/Trackunit/manager",
   "license": "SEE LICENSE IN LICENSE.txt",
   "migrations": "./migrations.json",
@@ -14,16 +14,16 @@
     "@floating-ui/react": "^0.26.25",
     "string-ts": "^2.0.0",
     "tailwind-merge": "^2.0.0",
-    "@trackunit/ui-design-tokens": "1.15.5",
-    "@trackunit/css-class-variance-utilities": "1.14.16",
-    "@trackunit/shared-utils": "1.16.19",
-    "@trackunit/ui-icons": "1.14.15",
+    "@trackunit/ui-design-tokens": "1.15.6",
+    "@trackunit/css-class-variance-utilities": "1.14.17",
+    "@trackunit/shared-utils": "1.16.20",
+    "@trackunit/ui-icons": "1.14.16",
     "es-toolkit": "^1.39.10",
     "@tanstack/react-virtual": "^3.14.3",
     "dequal": "^2.0.3",
     "fflate": "^0.8.2",
     "zod": "^3.25.76",
-    "@trackunit/i18n-library-translation": "2.4.12"
+    "@trackunit/i18n-library-translation": "2.4.13"
   },
   "peerDependencies": {
     "react": "^19.0.0",

package/src/components/Sidebar/Sidebar.d.ts

@@ -58,6 +58,12 @@ export interface SidebarProps extends CommonProps, Styleable, Refable<HTMLDivEle
  * ### When to use
  * Use Sidebar for secondary in-page navigation (e.g., switching between views within a page). Works well with `Tabs` for page-level navigation.
  *
+ * If you need a persistent nav column beside a content region (a page-level sidebar+content
+ * layout, e.g. Site Home, Administration, Asset Home), use `SidebarContentLayout` instead - it
+ * composes `Sidebar` internally and keeps its stacking breakpoint in sync with the content grid.
+ * Use `Sidebar` directly only for a standalone collapsing nav list with no content pane (e.g.
+ * inside a `PageHeader`'s `tabsList`, see `Tabs.stories.tsx`'s `ResponsivenessTwo`/`Three`).
+ *
  * ### When not to use
  * Do not use Sidebar for primary app navigation (the main menu). For top-level navigation, use the app shell navigation.
  *

package/src/components/SidebarContentLayout/SidebarContentLayout.d.ts

@@ -0,0 +1,70 @@
+import { ReactElement, ReactNode } from "react";
+import { CommonProps } from "../../common/CommonProps";
+import { Refable } from "../../common/Refable";
+import type { Styleable } from "../../common/Styleable";
+import { Breakpoints, SidebarItemProps } from "../Sidebar/Sidebar";
+export interface SidebarContentLayoutProps extends CommonProps, Styleable, Refable<HTMLDivElement> {
+    /**
+     * The sidebar's own navigation items, rendered through the shared `Sidebar` component. Passed as
+     * `Sidebar`'s `children` internally - see `Sidebar`'s own docs for the expected item shape.
+     */
+    sidebar: Array<ReactElement<SidebarItemProps>> | ReactElement<SidebarItemProps>;
+    /**
+     * The main content, rendered in a bare, unpadded grid cell. Whatever is passed here owns its own
+     * padding - this component never mutates or wraps it in a way that would strip a class it applies
+     * to itself (see `contentSpace` for this component's own opt-in inset).
+     */
+    content: ReactNode;
+    /**
+     * The breakpoint at which sidebar and content switch from stacked to side-by-side. Passed straight
+     * through to `Sidebar`'s own `breakpoint` prop, so the grid's own switch and `Sidebar`'s internal
+     * tab-bar/vertical-list switch are driven by the identical condition and can never disagree.
+     *
+     * @default "lg"
+     */
+    breakpoint?: Breakpoints;
+    /**
+     * Whether the content cell applies its own `p-content-space` inset. Set to `false` for routes that
+     * must render flush against this cell's true edges (e.g. a full-page extension iframe).
+     *
+     * @default true
+     */
+    contentSpace?: boolean;
+}
+/**
+ * SidebarContentLayout is the shared page shell for any screen built from a persistent navigation
+ * sidebar next to a main content area - the pattern behind Site Home, Administration, and Asset
+ * Home. It keeps that pairing consistent everywhere it's used: the same breakpoint decides both
+ * when the sidebar collapses to a tab bar and when content drops below it, so the two can never
+ * disagree, and every page gets identical spacing without reimplementing it by hand.
+ *
+ * The content slot renders whatever it's given untouched - a routed `Outlet`, a form, a table - and
+ * never imposes padding on it from the outside (see `contentSpace` to opt out of this component's
+ * own default inset, e.g. for a full-page extension iframe that needs to sit flush to the edges).
+ *
+ * ### When to use
+ * Use as the layout directly inside a `HostPage` for any page that needs a persistent navigation
+ * sidebar alongside routed/tabbed content (e.g. Site Home, Administration, Asset Home).
+ *
+ * ### When not to use
+ * Do not use for pages without a persistent sidebar - use `HostPage` directly instead.
+ *
+ * @example SidebarContentLayout with navigation items and routed content
+ * ```tsx
+ * import { SidebarContentLayout, SidebarItemProps } from "@trackunit/react-components";
+ *
+ * const SitePage = () => (
+ *   <SidebarContentLayout
+ *     content={<Outlet />}
+ *     sidebar={
+ *       <Button id="overview" variant="ghost-neutral">
+ *         Overview
+ *       </Button>
+ *     }
+ *   />
+ * );
+ * ```
+ * @param {SidebarContentLayoutProps} props - The props for the SidebarContentLayout component
+ * @returns {ReactElement} SidebarContentLayout component
+ */
+export declare const SidebarContentLayout: ({ breakpoint, className, content, contentSpace, "data-testid": dataTestId, sidebar, style, ref, }: SidebarContentLayoutProps) => ReactElement;

package/src/components/SidebarContentLayout/SidebarContentLayout.variants.d.ts

@@ -0,0 +1,87 @@
+/**
+ * The root grid. `min-h-0 flex-1` opts this into an ancestor `HostPage`'s height-cascading flex-col
+ * fill contract (see `HostPage.tsx`), so it gets a real, bounded height instead of an auto-height
+ * block. No `gap-*` utility is applied here, ever: the single visible gap between sidebar and
+ * content at the side-by-side breakpoint is contributed entirely by the content cell's own
+ * `p-content-space` left padding (see `cvaSidebarContentLayoutContent`) - a grid gap on top of that
+ * would silently double it.
+ *
+ * Below the breakpoint (stacked, single column), `grid-rows-[min-content_minmax(0px,1fr)]` pins the
+ * sidebar's row to its own content height and gives the content row every pixel of leftover space.
+ * Without an explicit row template, both rows default to `auto` sizing, and this grid's own bounded
+ * height (from the `flex-1` fill contract above) is almost always taller than the two rows' combined
+ * natural content height - `align-content`'s default `normal` computes to `stretch` for a grid
+ * container, so that leftover space gets distributed *proportionally across every `auto` row*, not
+ * just content's. That silently inflates the sidebar's row (and thus its box) well past its own
+ * content's height, leaving a blank gap below the nav items before content starts - a stacked-only
+ * sibling of the `minmax(min-content,1fr)` grid-blowout class of bug already fixed once for Asset
+ * Home's own internal grid (GLU-1562/Phase 17). `{breakpoint}:grid-rows-none` resets this back to a
+ * single implicit `auto` row at/above the breakpoint, where sidebar and content share one grid row
+ * (as two columns) and must both keep stretching to the full available height per `{bp}:h-full`.
+ *
+ * Each breakpoint's arbitrary-value class is spelled out in full (rather than built via string
+ * interpolation) because Tailwind's build-time scanner extracts candidate class names via a static
+ * regex over each source file's raw text, not by evaluating JavaScript - an interpolated class name
+ * would never appear as a complete literal string anywhere in this file and so would silently fail
+ * to generate any CSS at all.
+ */
+export declare const cvaSidebarContentLayout: (props?: ({
+    breakpoint?: "sm" | "xs" | "md" | "lg" | "xl" | "2xl" | "3xl" | null | undefined;
+} & import("class-variance-authority/types").ClassProp) | undefined) => string;
+/**
+ * The sidebar's own grid cell. `pt-4 pl-4` give it a fixed top/left inset (matching
+ * `p-content-space`'s own `spacing-4`) now that there's no ambient ancestor padding left to inherit
+ * one from.
+ *
+ * The right edge is a genuinely different edge depending on the breakpoint, so it's handled
+ * accordingly rather than uniformly:
+ * - Below the breakpoint, the grid is a single column (see `cvaSidebarContentLayout`), so the
+ *   sidebar spans the grid's full width and this edge is a true page edge, exactly like the left
+ *   edge - it gets the same `pr-4` inset.
+ * - At/above the breakpoint, this edge instead borders the content column, and *most* of it is
+ *   owned entirely by content's own `p-content-space` left padding (see module doc comment above and
+ *   `cvaSidebarContentLayoutContent`) - stacking this cell's own `pr-4` on top of that would silently
+ *   double the gap. `{breakpoint}:pr-2` cancels *most*, but not all, of it there - see below for the
+ *   deliberate remainder.
+ *
+ * `h-full min-h-0 overflow-y-auto` (applied only from the breakpoint upward, matching `Sidebar`'s
+ * own vertical-list mode) give the sidebar its own bounded height and local scroll: `Sidebar`'s
+ * vertical nav list is unclipped by default, so a long list could otherwise be taller than the
+ * grid row's available height, silently growing the row (the classic CSS grid "blowout") instead of
+ * scrolling locally.
+ *
+ * `[scrollbar-gutter:stable]` rides along with that same `overflow-y-auto`, reserving genuine,
+ * platform-correct scrollbar space (0 on overlay-scrollbar platforms like macOS, the native width
+ * elsewhere) on the same edge, so a long enough nav list's scrollbar never overlaps the items - and
+ * so the sidebar's rendered width stays consistent whether or not a *particular* page's item list
+ * happens to be long enough to overflow. Supported by every evergreen browser (Chrome/Edge 94+,
+ * Firefox 97+, Safari 18.2+); a no-op elsewhere, i.e. today's pre-fix behavior, so no regression risk.
+ *
+ * That reservation alone butts the items directly against the scrollbar track with zero breathing
+ * room, though - `scrollbar-gutter` only guarantees no *overlap*, it isn't a visual gap. `{bp}:pr-2`
+ * is the deliberate small remainder of the otherwise-cancelled `pr-4` that supplies that breathing
+ * room, sized independently of both the scrollbar's own width (which the browser already reserves via
+ * `scrollbar-gutter`) and of the sidebar/content gap above (which is `p-content-space`'s job, not
+ * this padding's) - it exists purely so the sidebar's own content doesn't look glued to the sidebar's
+ * own scrollbar. Keeping it a small fraction of the full `pr-4` (rather than restoring all of it, or
+ * clawing space back from the reserved gutter) avoids meaningfully inflating the sidebar/content gap
+ * `p-content-space` already owns - it is deliberately *not* zero, but not enough to look like a second
+ * gap either.
+ */
+export declare const cvaSidebarContentLayoutSidebar: (props?: ({
+    breakpoint?: "sm" | "xs" | "md" | "lg" | "xl" | "2xl" | "3xl" | null | undefined;
+} & import("class-variance-authority/types").ClassProp) | undefined) => string;
+/**
+ * The content's own grid cell: `relative` (a positioning context for a future side panel/drawer to
+ * anchor into), a definite height (`h-full`, chained from the root grid's own fill contract) with
+ * its own local `overflow-y-auto` (this cell's content may be a third-party iframe, which must
+ * contain its own overflow rather than bubbling it up).
+ *
+ * `p-content-space` is applied here by default (`contentSpace: true`): the padding decision is
+ * exposed on the component that owns the content's box, not silently forced by some invisible
+ * ancestor. Callers rendering a route that must sit flush (e.g. a full-page extension iframe) opt
+ * out with `contentSpace={false}`.
+ */
+export declare const cvaSidebarContentLayoutContent: (props?: ({
+    contentSpace?: boolean | null | undefined;
+} & import("class-variance-authority/types").ClassProp) | undefined) => string;

package/src/index.d.ts

@@ -89,6 +89,7 @@ export { useSheet } from "./components/Sheet/useSheet";
 export { useSheetSnap } from "./components/Sheet/useSheetSnap";
 export * from "./components/Sidebar/Sidebar";
 export * from "./components/Sidebar/useOverflowItems";
+export * from "./components/SidebarContentLayout/SidebarContentLayout";
 export { useRandomCSSLengths } from "./components/Skeleton/Skeleton.helpers";
 export type { CSSLength, CSSLengthUnit } from "./components/Skeleton/Skeleton.helpers";
 export { SkeletonBlock } from "./components/Skeleton/SkeletonBlock/SkeletonBlock";