efficient-easel 21.0.0 → 21.1.0

package/dist/screen/lib/document/palette-sections.d.ts

@@ -0,0 +1,103 @@
+import { Config } from '../../../blocks/index.js';
+import 'react';
+import '../../../types-Cq53lL8d.js';
+import '../../../data/index.js';
+import '../../../types-41704JE4.js';
+import '../../../resolve-D68pb3Bx.js';
+import '../../../plan-CZS902DV.js';
+
+/** One offerable section, with the category it is grouped under. */
+type PaletteSection = {
+    type: string;
+    cat: string;
+    name: string;
+    desc: string;
+    /**
+     * The heading of the category this section sits under, resolved once at build
+     * time — SEARCHED, and already SHOWN as the nav row this card sits beneath.
+     *
+     * ⚠️ IT IS HERE BECAUSE THE NAV AND THE SEARCH DISAGREED. Seven of the
+     * thirteen category names returned NOTHING when typed: "Blog & journal" reads
+     * 5 in the nav, and "blog" found 0, because not one of Issue Header, Featured
+     * Cover, Article Text, Recurring Columns or Latest Posts carries the word. Same
+     * for shop, about, promotions, navigation, legal and layout. A merchant reads
+     * the word off the screen, types it, and is told no section matches.
+     *
+     * Resolved HERE, not in `matchesQuery`, because the label needs the `config`
+     * (`categoryLabel`) and the matcher is given only a section — passing config
+     * into the matcher would make every caller carry it.
+     */
+    catLabel: string;
+    /**
+     * Another word this section is known by, searched but never shown.
+     *
+     * ⚠️ THIS EXISTS FOR ONE NODE AND ONE REASON. `Flex` is offered here as
+     * "Blank section" and is called "Box" everywhere it is nested — so a merchant
+     * who met it in a Layers row, or in last week's handoff, types "box" and must
+     * still find it. Without this they would find NOTHING: the card is pinned out
+     * of its group, so a search that misses it misses it completely.
+     */
+    alias?: string;
+};
+/**
+ * What the layer says of its sections for the palette: the word for a type at
+ * a level, a group's short heading where it has one, and the blurbs. The
+ * screen's `blockLook` is one (lib/screen-parts); so is the website's own
+ * (lib/document/add-palette).
+ */
+interface PaletteLook {
+    /** What a node of `type` is called at a level, given the label the config
+     *  holds for it. */
+    labelAtLevel: (type: string, level: "section" | "block", base: string) => string;
+    /** A group's short heading, by its key, where the layer has one; undefined,
+     *  and the config's own title is the heading. */
+    categoryLabel: (id: string) => string | undefined;
+    /** The one-line blurb for a section, by type. */
+    descriptions: Record<string, string>;
+}
+/**
+ * Flatten `config.categories` into an ordered section list.
+ *
+ * Grouping and order ARE the category order in the config — which is the
+ * catalog's order — so this adds no opinion of its own. A component listed in a
+ * category but absent from `components` is skipped: a stale catalog row cannot
+ * render and certainly cannot insert, so offering it would be a card that fails
+ * on click.
+ *
+ * Child-only blocks (HeroSlide / CollectionCard / ProductRef) and the four
+ * generic primitives (Heading / Text / ImageBlock / ButtonBlock) sit in NO
+ * category on purpose, so they never appear here — they are added from their
+ * parent's slot instead. See the note above `categories:` in lib/document/config.tsx.
+ *
+ * A category the config marks `visible: false` is NOT offered (0.105.0, seam
+ * E9): it is a registry's way of keeping blocks it has out of the picker — the
+ * campaign designer's Product parts, its retired blocks, its Sections — and a
+ * palette that listed them would offer things that may not be put on a page.
+ * Puck's own palette read the flag the same way. No website category carries
+ * it, so the website's palette is the list it was.
+ */
+declare function buildPaletteSections(config: Config, look: PaletteLook): PaletteSection[];
+/** A category's display label — the layer's short one where there is one, else the config's title. */
+declare function categoryLabel(config: Config, id: string, shortLabel: (id: string) => string | undefined): string;
+/**
+ * Does a section match a search query?
+ *
+ * The query is matched against the NAME, any ALIAS, the blurb, the component
+ * TYPE and the CATEGORY HEADING — the type because a merchant who knows the
+ * section by the word they saw in a handoff should still find it, the alias
+ * because one node is called something else everywhere it is nested (see
+ * `PaletteSection.alias`), and the category because it is PRINTED IN THE NAV
+ * BESIDE THE RESULTS: seven of thirteen headings used to match nothing at all
+ * (see `PaletteSection.catLabel`). A word a merchant can read off this screen
+ * must find what it is labelling.
+ *
+ * `q` is expected already lower-cased and trimmed; an empty query matches
+ * everything.
+ */
+declare function matchesQuery(s: PaletteSection, q: string): boolean;
+/** The pinned section, or `null` if the layer pins none or the config does not offer it. */
+declare function pinnedSection(sections: PaletteSection[], pinned: string | null): PaletteSection | null;
+/** Every OTHER section — what the grouped grid below the pinned card draws. */
+declare function paletteWithoutPinned(sections: PaletteSection[], pinned: string | null): PaletteSection[];
+
+export { type PaletteLook, type PaletteSection, buildPaletteSections, categoryLabel, matchesQuery, paletteWithoutPinned, pinnedSection };

package/dist/screen/lib/document/palette-sections.js

@@ -0,0 +1 @@
+export{buildPaletteSections,categoryLabel,matchesQuery,paletteWithoutPinned,pinnedSection}from"../../../chunk-VKPOH6MK.js";

package/dist/screen/lib/document/panel-fields.d.ts

@@ -0,0 +1,47 @@
+/**
+ * THE ROWS A PANEL IS REALLY DRAWING — not the ones its component declares.
+ *
+ * `config.components[type].fields` is a DECLARATION. A component's
+ * `resolveFields` then culls it for the state that node is in: the Booking Form
+ * gives its head rows away to the boxes that own them, Spec Table drops its Rows
+ * array on a linked product, Image & Text Columns takes its text-position row
+ * away once it has Boxes.
+ *
+ * `Puck.Fields` honours all of that. Every list built beside it from the raw
+ * declaration does not — and one of them is the copy list in
+ * `components/SectionEditor`. So a merchant met the SAME heading twice: once in
+ * the panel Puck drew, and once in a list drawn from rows the resolver had
+ * already dropped (owner, 2026-09-10, on a Booking Form's Head box).
+ *
+ * ⚠️ PUCK DOES NOT EXPOSE ITS RESOLVED SET. The store slice that holds it is
+ * internal — `useEasel((s) => s)` and `createUsePuck()` both hand back `PuckApi`, which
+ * has no `fields` on it (checked against 0.20.2's own types, not remembered). So
+ * the resolver is asked here, the same way Puck asks it.
+ *
+ * ⚠️ AND AN ASYNC RESOLVER IS ANSWERED WITH THE DECLARATION. A promise cannot be
+ * read during a render, and a list that waited would flicker rows in and out.
+ * Falling back is the same answer this code gave before, so an async resolver is
+ * no worse off than it was — it simply is not helped either. Stated because a
+ * silent half-fix is the thing worth naming.
+ */
+type PanelFieldMap = Record<string, unknown>;
+interface PanelComponent {
+    fields?: PanelFieldMap;
+    resolveFields?: (data: unknown, params: Record<string, unknown>) => unknown;
+}
+/**
+ * The field map to build a panel-side list from, for one node.
+ *
+ * `parent` is passed as null and `appState` as an empty object because the ONE
+ * caller uses the result for authored-copy rows, which no resolver decides from
+ * either. A caller that needs the width rows — which DO read `parent` — must ask
+ * Puck rather than this.
+ */
+declare function panelFieldsOf(config: {
+    components?: Record<string, PanelComponent>;
+}, node: {
+    type: string;
+    props: Record<string, unknown>;
+} | null | undefined): PanelFieldMap | null;
+
+export { type PanelFieldMap, panelFieldsOf };

package/dist/screen/lib/document/panel-fields.js

@@ -0,0 +1 @@
+export{panelFieldsOf}from"../../../chunk-5XL2RXFU.js";import"../../../chunk-BPXEFVSQ.js";

package/dist/screen/lib/document/panel-no-control-mark.d.ts

@@ -0,0 +1,74 @@
+import { ReactElement } from 'react';
+
+/**
+ * panel-no-control-mark — what a settings field draws when it draws NO CONTROL
+ * on the screen it is on (card 66178).
+ *
+ * WHY A FIELD HAS TO SAY THIS OUT LOUD. Puck lays the inspector out as a FLAT
+ * list and owns the wrapper around every top-level field, and its own stylesheet
+ * rules the gap between two of them:
+ *
+ *   ._PuckFields--wrapFields_ ._PuckFields-field_ + ._PuckFields-field_ {
+ *     border-top: 1px solid var(--puck-color-grey-09); margin-top: 8px; }
+ *
+ * That rule is right — a line between two adjacent rows. But a field whose
+ * `render` returns `null` still gets the wrapper, still takes its `16px 16px
+ * 12px` of padding and still draws the line, so the panel shows a hairline with
+ * nothing on one side of it. Measured on the Collections Content tab before this
+ * card: two 29px-tall wrappers whose whole content was
+ * `<div class="_InputWrapper_"></div>`, and three rules stacked with only blank
+ * space between them. Across the catalogue it was 338 such rows in 74 panels.
+ *
+ * We cannot stop Puck emitting the wrapper, so the wrapper is collapsed from the
+ * outside: the field renders this zero-size marker and ONE declarative rule in
+ * `components/storefront-editor.css` takes the wrapper out of the layout
+ * entirely — `display: none`, so the row leaves the accessibility tree with it
+ * rather than lingering as an unlabelled blank. That is exactly the shape the
+ * bucket boundary markers (`data-sf-bucket`) and the device-gated fields
+ * (`data-sf-device-hidden`) already use, and it is declarative for the same
+ * reason: it cannot race the tab pass.
+ *
+ * IT IS NOT A WAY TO HIDE A SETTING. A field that draws nothing here must still
+ * be reachable somewhere — as an entry row in the section screen's TEXT group,
+ * or through another control on the same panel. `scripts/test-panel-no-empty-rows.tsx`
+ * §2 fails a field that draws no control and has no way back to it, which is how
+ * the lost "Anchor name" box was found.
+ */
+
+/** The attribute the marker carries — the single source, read by the stylesheet
+ *  rule and by the guard that proves the rule is there. */
+declare const NO_CONTROL_ATTR = "data-sf-no-control";
+/** The marker itself. `hidden` as well as the CSS rule, so a field that renders
+ *  it in a context the editor stylesheet has not reached (a test harness, a
+ *  bundled preview) still draws nothing rather than an empty inline box. */
+declare function NoControlMark(): ReactElement;
+/**
+ * …AND THE SAME FACT SAID ON THE FIELD OBJECT (card 66201).
+ *
+ * The attribute above is drawn, so only a render can see it. The pass that drops
+ * a heading standing over nothing runs in `resolveFields`, where there is no DOM
+ * and no React — it has a field list and nothing else. So a field that draws no
+ * control has to say so twice, in the two places the answer is asked, and both
+ * are stamped by the ONE `if` that decides it: see `textField` in
+ * `lib/document/controls`, which wraps the render and stamps the marker together.
+ *
+ * The two reasons are not the same shape, hence a word rather than a boolean:
+ *   • `"always"` — it draws nothing wherever it appears. A device scope note, a
+ *     key whose one control is a row elsewhere on the same panel.
+ *   • `"authored-copy"` — a scalar copy box card 8819 moved to the DRILL screen.
+ *     It draws nothing on the section screen unless its prop is STRUCTURAL, which
+ *     is the one question `SuppressibleText` also asks at render time.
+ */
+declare const NO_CONTROL_FIELD: "__noControl";
+/** The payload on {@link NO_CONTROL_FIELD}. */
+type NoControlFieldMeta = "always" | "authored-copy";
+/** Read a field's no-control payload, or `null` when it draws a control of its
+ *  own. The ONE place that knows the marker's shape. */
+declare function noControlMetaOf(field: unknown): NoControlFieldMeta | null;
+/** Stamp {@link NO_CONTROL_FIELD} on a field. The cast is here and nowhere else:
+ *  Puck's field types have no slot for a marker, so an object literal carrying
+ *  one trips the excess-property check at every call site otherwise — the same
+ *  reason `group()` and the text/link markers have their own builders. */
+declare function noControlField<F>(field: F, reason: NoControlFieldMeta): F;
+
+export { NO_CONTROL_ATTR, NO_CONTROL_FIELD, type NoControlFieldMeta, NoControlMark, noControlField, noControlMetaOf };

package/dist/screen/lib/document/panel-no-control-mark.js

@@ -0,0 +1 @@
+export{NO_CONTROL_ATTR,NO_CONTROL_FIELD,NoControlMark,noControlField,noControlMetaOf}from"../../../chunk-INRERJU4.js";

package/dist/screen/lib/document/part-id.d.ts

@@ -0,0 +1,23 @@
+/**
+ * lib/document/part-id.ts — how one PART of a section is named: `"<nodeId>::<propKey>"`.
+ *
+ * A part is one authored text of a node (a heading, a button label) that the
+ * editor's inspector can drill into. Its id is read on both sides of the
+ * preview: the section's render marks each part with it, and the screen's part
+ * bridge (components/usePartBridge) opens the part it names. The codec moved
+ * here from lib/document/text-parts (which re-exports it) so the screen reads it
+ * without the text walk, and moves into efficient-easel with it (doc/adr/0004).
+ */
+/** Separates the node id from the prop key inside a part id. A doubled colon:
+ *  a Puck node id is `<Type>-<uuid>` and a compound zone is `<parentId>:<slot>`,
+ *  so a single colon is already taken. */
+declare const PART_SEP = "::";
+/** `"<nodeId>::<propKey>"`, or `"<nodeId>::"` for "the whole section". */
+declare function encodePartId(nodeId: string, propKey: string | null): string;
+/** Inverse of {@link encodePartId}. `propKey: null` means the whole section. */
+declare function decodePartId(partId: string): {
+    nodeId: string;
+    propKey: string | null;
+} | null;
+
+export { PART_SEP, decodePartId, encodePartId };

package/dist/screen/lib/document/part-id.js

@@ -0,0 +1 @@
+export{PART_SEP,decodePartId,encodePartId}from"../../../chunk-R4AUZVA3.js";

package/dist/screen/lib/document/preview-click.d.ts

@@ -0,0 +1,49 @@
+/**
+ * "Did this come from a click INSIDE the preview?" — the one fact that decides
+ * whether the editor is allowed to scroll its canvas.
+ *
+ * Every in-preview selection bridge (a section's text PARTS, and a Hero's
+ * ticker / Background / Text) shares ONE handler with the matching row in the
+ * Layers tree. The handler ends in `scrollPreviewToSection`, and only one of its
+ * two callers should travel:
+ *
+ *   · from the LAYERS TREE — scroll. A row in a list can name a section that is
+ *     off-screen, and taking the merchant there is the whole point of clicking it.
+ *   · from a CLICK IN THE PREVIEW — do not. The merchant is already looking at
+ *     the thing they clicked, so moving the canvas under them is motion they did
+ *     not ask for (card 66392: "after clicking, the screen moves; cancel this
+ *     sliding motion" — measured at 409px of travel in the phone preview).
+ *
+ * The two callers are told apart HERE rather than at each of the eight call
+ * sites, because the difference is one rule and a rule spelled eight times is a
+ * rule that drifts. `useSelectHandler` (lib/document/preview-selection-context) is
+ * the single entry point every in-preview click already goes through — it is
+ * invoked from inside the portaled preview iframe — so wrapping it once covers
+ * both editor shells and all four bridges, and the tree keeps calling the same
+ * handlers directly and unchanged.
+ *
+ * ⚠️ AMBIENT, AND DELIBERATELY SO. Threading a "did this come from the preview"
+ * argument through the bridges would mean editing every handler and every one of
+ * its callers — exactly the call-site patching that left the last fix half-done.
+ * The cost is that the fact lives in a module variable, so two things are load-
+ * bearing: the flag is only ever read SYNCHRONOUSLY (see `scrollPreviewToSection`,
+ * which must not defer the check into its `requestAnimationFrame`), and it is
+ * restored in a `finally` so a throwing handler cannot leave the canvas
+ * permanently unable to scroll. Both are pinned by
+ * `scripts/test-preview-click-does-not-scroll.tsx`.
+ *
+ * No imports on purpose: `preview-dom` reads this and `preview-selection-context`
+ * writes it, and the latter is reached from inside the preview iframe — putting
+ * the flag in `preview-dom` would close a cycle back through HeroSection.
+ */
+/**
+ * Run `handler` as work caused by a click INSIDE the preview, so anything it
+ * reaches knows not to move the canvas. Returns whatever `handler` returns; the
+ * fact is restored even if it throws.
+ */
+declare function runAsPreviewClick<T>(handler: () => T): T;
+/** True while a `runAsPreviewClick` handler is on the stack. Read it
+ *  SYNCHRONOUSLY — deferred work runs after the click has already returned. */
+declare function isPreviewClick(): boolean;
+
+export { isPreviewClick, runAsPreviewClick };

package/dist/screen/lib/document/preview-click.js

@@ -0,0 +1 @@
+export{isPreviewClick,runAsPreviewClick}from"../../../chunk-MGVI67QV.js";

package/dist/screen/lib/document/preview-dom.d.ts

@@ -0,0 +1,8 @@
+declare const previewFrame: () => HTMLIFrameElement | null;
+declare function scrollPreviewToSection(id: string): void;
+declare function gotoPreviewSlide(heroId: string, index: number): void;
+declare function scrollPreviewToTop(): void;
+declare function pinPreviewToSection(id: string): () => void;
+declare function pinPreviewToBottom(onPinned?: () => void): () => void;
+
+export { gotoPreviewSlide, pinPreviewToBottom, pinPreviewToSection, previewFrame, scrollPreviewToSection, scrollPreviewToTop };

package/dist/screen/lib/document/preview-dom.js

@@ -0,0 +1 @@
+export{gotoPreviewSlide,pinPreviewToBottom,pinPreviewToSection,previewFrame,scrollPreviewToSection,scrollPreviewToTop}from"../../../chunk-DDH2DYQP.js";import"../../../chunk-AJ2SUSET.js";import"../../../chunk-LF3FUSCQ.js";import"../../../chunk-MGVI67QV.js";

package/dist/screen/lib/document/preview-events.d.ts

@@ -0,0 +1,25 @@
+/**
+ * lib/document/preview-events.ts — events the editor's screen sends INTO the preview.
+ *
+ * Moved from components/HeroSection (which re-exports them) so the screen's
+ * preview bridge (lib/document/preview-dom) can send them without importing a
+ * section, and moves into efficient-easel with the screen (doc/adr/0004). A
+ * section listens for its own; the name is the contract between the two.
+ */
+/**
+ * Event the editor chrome dispatches INTO the preview iframe to jump a Hero's
+ * slider to a slide by index. The chrome (section tree + "Add slide") lives
+ * outside this iframe and can't reach the slider's React state, and Puck's
+ * selection overlay is portaled to the iframe `<body>` (not inside `.hero-track`),
+ * so selection alone can't be observed from here — this is the explicit bridge.
+ * See {@link ScreenChrome} `selectChild` / `addChild`.
+ */
+declare const HERO_SLIDER_GOTO_EVENT = "hero-slider:goto";
+interface HeroSliderGotoDetail {
+    /** Target Hero's stable Puck id (`data-easel-block`); omit to hit all Heroes. */
+    id?: string;
+    /** Zero-based slide index to show. */
+    index: number;
+}
+
+export { HERO_SLIDER_GOTO_EVENT, type HeroSliderGotoDetail };

package/dist/screen/lib/document/preview-events.js

@@ -0,0 +1 @@
+export{HERO_SLIDER_GOTO_EVENT}from"../../../chunk-AJ2SUSET.js";

package/dist/screen/lib/document/preview-selection-context.d.ts

@@ -0,0 +1,72 @@
+import * as react from 'react';
+import { ReactNode } from 'react';
+
+/**
+ * Shared machinery for the editor preview's "selection bridges" — the click-to-
+ * select plumbing every piece of site CHROME needs because it is NOT a Puck node
+ * and so can't route through Puck's own selection. The header, the chat bubble,
+ * and a Hero's ticker / background / text overlay each expose the SAME two-way
+ * bridge, and all built it by hand until this file:
+ *
+ *  - `select(…)` / `setSelectHandler(fn)` — a ref-backed handler the chrome
+ *    registers (it opens the matching inspector panel), invoked from inside the
+ *    portaled preview iframe when the element is clicked. It lives behind a ref so
+ *    the chrome can re-register without re-rendering the preview; `select` itself
+ *    stays stable. See {@link useSelectHandler}.
+ *  - a mirrored SELECTION the preview reads to draw its own "selected" outline.
+ *
+ * Two entry points reuse the bridge:
+ *  - {@link useSelectHandler} — just the ref-backed `select` / `setSelectHandler`
+ *    pair, for the header + chat bridges. They keep a plain boolean `selected` and
+ *    layer their own live-config state around it, so they compose this hook rather
+ *    than the whole context factory.
+ *  - {@link createPreviewSelectionContext} — a whole context + provider + hook for
+ *    an ID-SCOPED bridge (a Hero's ticker / background / text), where the mirrored
+ *    selection is "which sibling id is selected" (`selected<Thing>Id`), scoped by
+ *    id so sibling heroes never cross-select. The three such contexts differ ONLY
+ *    in that field's name, so they are each one call to this factory.
+ */
+/**
+ * The ref-backed `select` / `setSelectHandler` pair shared by every selection
+ * bridge. `Args` is the click payload the chrome's handler receives — `[]` for a
+ * lone toggle (header / chat) or `[id: string]` for an id-scoped bridge (ticker /
+ * hero media / hero text). `select` is stable across renders; registering a new
+ * handler never re-renders the portaled preview.
+ */
+declare function useSelectHandler<Args extends unknown[]>(): {
+    select: (...args: Args) => void;
+    setSelectHandler: (fn: (...args: Args) => void) => void;
+};
+/**
+ * The context value of an id-scoped selection bridge, keyed by the id field's
+ * name `Key` (e.g. `"selectedHeroId"`): the mirrored id + its `set…` setter, plus
+ * the shared `select(id)` / `setSelectHandler` pair. Keeping the field name in the
+ * type is what lets one factory reproduce each context's exact public API.
+ */
+type PreviewIdSelection<Key extends string> = {
+    [P in Key]: string | null;
+} & {
+    [P in Key as `set${Capitalize<P>}`]: (id: string | null) => void;
+} & {
+    select: (id: string) => void;
+    setSelectHandler: (fn: (id: string) => void) => void;
+};
+/**
+ * Build a complete id-scoped selection-bridge context — the shared body of
+ * PreviewTickerContext / PreviewHeroMediaContext / PreviewHeroTextContext, which
+ * differ only in the id field's NAME. Pass that field name and the returned
+ * `Provider` + `useSelection` expose exactly `{ [idKey], set<IdKey>, select,
+ * setSelectHandler }`, so each context's existing consumers read unchanged.
+ *
+ * @example
+ * export const { Provider: PreviewTickerProvider, useSelection: usePreviewTicker } =
+ *   createPreviewSelectionContext("selectedHeroId");
+ */
+declare function createPreviewSelectionContext<Key extends string>(idKey: Key): {
+    Provider: ({ children }: {
+        children: ReactNode;
+    }) => react.JSX.Element;
+    useSelection: () => PreviewIdSelection<Key>;
+};
+
+export { type PreviewIdSelection, createPreviewSelectionContext, useSelectHandler };

package/dist/screen/lib/document/preview-selection-context.js

@@ -0,0 +1 @@
+export{createPreviewSelectionContext,useSelectHandler}from"../../../chunk-TIAWIOGD.js";import"../../../chunk-MGVI67QV.js";

package/dist/screen/lib/document/section-doc.d.ts

@@ -0,0 +1,24 @@
+import { Data } from '../../../blocks/index.js';
+import { TreeItem } from './content-tree.js';
+import 'react';
+import '../../../types-Cq53lL8d.js';
+import '../../../data/index.js';
+import '../../../types-41704JE4.js';
+import '../../../resolve-D68pb3Bx.js';
+import '../../../plan-CZS902DV.js';
+
+declare function nodeToDoc(node: TreeItem): Data;
+declare function docToNode(data: Data): TreeItem | null;
+/**
+ * Deep-copy a stored section node with FRESH ids — the node's own and every
+ * inline slot child's, recursively — so inserting the same template twice never
+ * lands two nodes with colliding ids (Puck keys selection/replace on id, and
+ * React keys render on it).
+ *
+ * `strip` (0.106.0) sees each copied node once its children are copied, and
+ * answers it as the copy should hold it — the layer's `blockRules.stripCopy`,
+ * which takes out what only an original may hold. It keeps the fresh id.
+ */
+declare function cloneNodeWithFreshIds(node: TreeItem, strip?: (node: TreeItem) => TreeItem): TreeItem;
+
+export { cloneNodeWithFreshIds, docToNode, nodeToDoc };

package/dist/screen/lib/document/section-doc.js

@@ -0,0 +1 @@
+export{cloneNodeWithFreshIds,docToNode,nodeToDoc}from"../../../chunk-BDSLF5BR.js";import"../../../chunk-TCAAOYQY.js";