@akinon/pz-theme 2.0.78-rc.1 → 2.0.78

package/src/custom/section-definitions.ts

@@ -0,0 +1,59 @@
+import type { CustomSectionDefinition } from './define-section';
+
+/**
+ * The RENDER half of section registration: which component draws a
+ * `custom:<vendor>:<name>` section.
+ *
+ * A map of its own rather than an entry in `sectionRendererRegistry`, for two
+ * measured reasons:
+ *
+ * 1. `sections/__tests__/custom-renderer-section-types.test.ts` asserts that
+ *    `CUSTOM_RENDERER_SECTION_TYPES` — a hand-maintained literal the CSS
+ *    generator reads because it cannot import the registry without closing a
+ *    module cycle — equals `sectionRendererRegistry.registeredTypes()` exactly.
+ *    A brand registering into that registry would make `registeredTypes()`
+ *    non-static and break the lock on every build that loaded a brand barrel.
+ * 2. `SectionRendererProps` carries no `pageContext`, and widening it is a
+ *    package-wide type edit for one consumer. `theme-section.tsx` dispatches to
+ *    this map directly and hands the host whatever it needs.
+ *
+ * Directive-free: it stores values and imports nothing that calls a hook, so
+ * both graphs can hold a copy. Only the client graph ever fills one, because
+ * `registerCustomSections` is client-only for the same reason
+ * `registerCustomBlocks` is.
+ */
+const definitions = new Map<string, CustomSectionDefinition>();
+
+/**
+ * Registers the component for a type, refusing rather than overwriting.
+ *
+ * The refusal is the point. Both stores are checked at registration — this one
+ * and the catalog — because a type present in only one of them is a section the
+ * editor offers and the storefront cannot draw, or the reverse.
+ */
+export const addSectionDefinition = (
+  type: string,
+  definition: CustomSectionDefinition
+): void => {
+  if (definitions.has(type)) {
+    throw new Error(
+      `[pz-theme] Custom section "${type}" already has a renderer in this build. ` +
+        `Registration refuses to overwrite it — the second component would draw every placement ` +
+        `of the first with no signal on either side.`
+    );
+  }
+
+  definitions.set(type, definition);
+};
+
+export const getCustomSectionDefinition = (
+  type: string
+): CustomSectionDefinition | undefined => definitions.get(type);
+
+export const hasCustomSectionDefinition = (type: string): boolean =>
+  definitions.has(type);
+
+/** Test-only. Module state outlives a test file otherwise. */
+export const resetCustomSectionDefinitions = (): void => {
+  definitions.clear();
+};

package/src/custom/section-host.tsx

@@ -0,0 +1,125 @@
+'use client';
+
+import React, { useEffect, useMemo } from 'react';
+import type { Block } from '../theme-block';
+import type { Section } from '../theme-section';
+import { CustomBlockContext } from './block-context';
+import type { CustomBlockContextValue } from './block-context';
+import { CustomBlockErrorBoundary } from './block-host';
+import { finishCollection, getCollectSink, isCollecting } from './collect';
+import type { CustomSectionDefinition } from './define-section';
+
+/**
+ * Adapts a developer SECTION component to the composition.
+ *
+ * The section twin of `CustomBlockHost`, and deliberately its near-copy: it
+ * converts the section node into the same `CustomBlockContext` the block host
+ * provides, so `useThemeSetting`, `ThemeEditable` and `ThemeSlot` work
+ * identically inside a section without a second implementation of any of them.
+ * The one thing only a section carries is `declaredRegionNames`, which
+ * `ThemeRegion` reads.
+ *
+ * IT DRAWS NO BOX OF ITS OWN. `SectionWrapper` in `theme-section.tsx` already
+ * supplies the `<section data-section-id>`, the designer outline, the action
+ * toolbar and the `data-section-content` element the content-width rule targets
+ * — that wrapper is precisely what gives a custom section the full section root
+ * panel. A host that drew its own element would put an unstyleable div between
+ * the two and quietly break both.
+ */
+export interface CustomSectionHostProps {
+  /** The `custom:<vendor>:<name>` this instance renders. */
+  type: string;
+  /** Picker label, reused by the error box. */
+  label: string;
+  definition: CustomSectionDefinition;
+  section: Section;
+  placeholderId: string;
+  isDesigner: boolean;
+  selectedBlockId?: string | null;
+  currentBreakpoint?: string;
+}
+
+export const CustomSectionHost = ({
+  type,
+  label,
+  definition,
+  section,
+  placeholderId,
+  isDesigner,
+  selectedBlockId,
+  currentBreakpoint = 'desktop'
+}: CustomSectionHostProps) => {
+  const BrandSection = definition.component;
+
+  // Read during render, not in the effect: the sink has to be in the context
+  // BEFORE the developer component runs, because that is when
+  // `useThemeSetting`/`ThemeEditable` report themselves.
+  const collecting = isCollecting(type);
+
+  // Closing on commit rather than on the render call is what makes the
+  // StrictMode double render harmless — see `finishCollection`.
+  useEffect(() => {
+    finishCollection(type);
+  }, [type]);
+
+  // Read off the DEFINITION rather than the catalog descriptor, for the reason
+  // the block host spells out: runtime collection appends to the descriptor's
+  // slot list as slots render, and a list that grew mid-render would resolve a
+  // bare `<ThemeSlot />` onto whichever name happened to render first.
+  const declaredSlotNames = useMemo(
+    () => (definition.options.slots ?? []).map((slot) => slot.name ?? ''),
+    [definition]
+  );
+
+  const declaredRegionNames = useMemo(
+    () => (definition.options.regions ?? []).map((region) => region.name),
+    [definition]
+  );
+
+  const value = useMemo<CustomBlockContextValue>(
+    () => ({
+      node: section,
+      scope: 'section',
+      // A `Section` carries every field `Block` requires, so the compatibility
+      // alias stays type-correct. New readers take `node`.
+      block: section as unknown as Block,
+      placeholderId,
+      // The section IS the parent of its regions, so its own id is the address
+      // every editor action for a region child is sent with.
+      sectionId: section.id,
+      isDesigner,
+      currentBreakpoint,
+      selectedBlockId,
+      declaredSlotNames,
+      declaredRegionNames,
+      collect: collecting ? getCollectSink(type) : undefined
+    }),
+    [
+      type,
+      section,
+      placeholderId,
+      isDesigner,
+      currentBreakpoint,
+      selectedBlockId,
+      declaredSlotNames,
+      declaredRegionNames,
+      collecting
+    ]
+  );
+
+  return (
+    <CustomBlockContext.Provider value={value}>
+      <CustomBlockErrorBoundary
+        type={type}
+        label={label}
+        isDesigner={isDesigner}
+      >
+        <BrandSection />
+      </CustomBlockErrorBoundary>
+    </CustomBlockContext.Provider>
+  );
+};
+
+// Named for the React devtools tree: without this every custom section on the
+// page appears as the same anonymous arrow function.
+CustomSectionHost.displayName = 'CustomSectionHost';

package/src/custom/section-types.ts

@@ -0,0 +1,158 @@
+import type {
+  CustomSettingDescriptor,
+  CustomSlotDescriptor
+} from './types';
+
+/**
+ * The wire grammar for developer-authored SECTIONS.
+ *
+ * A section reuses the block grammar for its type (`custom:<vendor>:<name>` —
+ * `CUSTOM_TYPE_PATTERN` in `types.ts`) because the two namespaces are checked
+ * against each other at registration: one type string can be claimed by a block
+ * or by a section, never by both. Sharing the pattern is what makes that check
+ * a single lookup instead of two spellings that could drift apart.
+ *
+ * Directive-free, like `types.ts` and for the same reason: `section-catalog.ts`
+ * is read from `placeholder-registry.ts`, which carries no directive of its own.
+ */
+
+/**
+ * The property carrying a region's name on the block that was seeded for it.
+ *
+ * The exact mirror of `SLOT_NAME_PROPERTY`, and reserved for exactly the same
+ * reason: `block.label` is renameable from the layer tree (`RENAME_BLOCK`), so
+ * binding a region to its label would let a merchant detach the region by
+ * renaming a row, with nothing anywhere to say why the area went empty.
+ *
+ * A region is NOT a reserved-type wrapper node. It is an ordinary block of a
+ * real type — a `search-box`, an `image`, a `mini-basket` — that happens to
+ * carry this property, which is the whole point: the merchant gets that block's
+ * own panel, its shared controls and its part groups with no new machinery.
+ */
+export const REGION_NAME_PROPERTY = 'regionName';
+
+/**
+ * A region name. Deliberately the same shape as a slot name: it is never
+ * interpolated into a selector, but it must match LITERALLY between the
+ * component's `<ThemeRegion name="…">` and the block the editor seeded, across
+ * a JSON round trip.
+ */
+export const REGION_NAME_PATTERN = /^[a-z][a-zA-Z0-9-]{0,31}$/;
+
+/**
+ * Caps for the section catalog. Every one is a LITERAL and none is derived
+ * from `CUSTOM_LIMITS`, for the reason spelled out there: each is mirrored
+ * independently in the editor, and the receiver's answer to an over-cap catalog
+ * is to drop all of it. An expression here would let one number move on the
+ * sender alone and empty a brand's whole section band.
+ *
+ * `catalogBytes` is measured over the SECTION catalog on its own. The section
+ * payload rides as a sibling field of `customBlocks` rather than inside it
+ * (see `placeholder-registry.ts`), so the two budgets are separate on both
+ * sides — a brand with a large block palette does not lose its sections, and a
+ * single oversized section descriptor does not empty the block palette.
+ */
+export const CUSTOM_SECTION_LIMITS = {
+  /**
+   * Lower than the block cap on purpose. A section descriptor is the larger of
+   * the two — it carries a region list with seeded properties and styles — and
+   * a brand needs far fewer of them: sections are pages and chrome regions,
+   * blocks are the vocabulary inside them.
+   */
+  sectionTypesPerBuild: 16,
+  settingsPerType: 24,
+  regionsPerType: 24,
+  slotsPerType: 8,
+  partsPerType: 32,
+  catalogBytes: 256 * 1024
+} as const;
+
+/**
+ * One child the developer named and PLACED in JSX.
+ *
+ * `block` is the built-in (or already-registered custom) block type the region
+ * is born as. The developer writes no descriptor for it: the block registry
+ * supplies the panel, the shared controls, the 161 advanced CSS controls and
+ * the part groups, exactly as it does for a block the merchant dropped by hand.
+ *
+ * `properties` and `styles` are the SEED — what the block looks like the moment
+ * the merchant adds the section, before anyone has touched it. They are written
+ * once, at insert; nothing re-applies them afterwards, so a merchant's edit is
+ * never overwritten by a later load.
+ */
+export interface CustomRegionDescriptor {
+  name: string;
+  label?: string;
+  block: string;
+  properties?: Record<string, unknown>;
+  styles?: Record<string, unknown>;
+  /**
+   * The block's own `value`, for the block types that keep their content there
+   * rather than in `properties` — an `image` reads `block.value` for its src, a
+   * `text` reads it for its text. Without this a seeded logo would come up
+   * blank and the merchant would have to find and re-upload an asset the brand
+   * already ships.
+   *
+   * Seeded ONCE, at insert, like `properties` and `styles`.
+   */
+  value?: unknown;
+}
+
+export interface CustomSectionDescriptor {
+  type: string;
+  name: string;
+  label: string;
+  icon?: string;
+  group?: string;
+  /**
+   * Always true. A section always hosts children — its regions, its slots, or
+   * both — and the editor's `SectionRegistryItem` carries the same field, so
+   * this maps straight across rather than being re-derived there.
+   */
+  hasChildren: boolean;
+  settings: CustomSettingDescriptor[];
+  regions: CustomRegionDescriptor[];
+  slots: CustomSlotDescriptor[];
+  /** ONE FLAT LIST OF STRINGS — see `CustomBlockDescriptor.parts`. */
+  parts: string[];
+  partStates?: Record<string, string[]>;
+  /** The section root's styles at insert. Same seed rule as a region's. */
+  styles?: Record<string, unknown>;
+  /**
+   * Placeholder slugs this section is offered on. Absent means anywhere.
+   *
+   * A brand's header section has no meaning on the basket page, and the editor
+   * already has the machinery to scope a catalogue entry
+   * (`isTemplateOfferedForPlaceholder`) — this is the developer's handle on it.
+   */
+  placeholders?: string[];
+  /**
+   * Removes `rotate`, `scale`, `translate`, `filter` and `backdrop-filter` from
+   * the section root's advanced controls.
+   *
+   * Not tidiness. Each of those five creates a containing block for a
+   * `position: fixed` descendant, so setting any one of them on the root of a
+   * fixed header collapses it into the root's own box — measured at 1247px
+   * becoming 600px. A section whose design depends on a fixed or sticky child
+   * sets this and the trap stops being reachable from the panel.
+   */
+  lockRootTransforms?: boolean;
+}
+
+export interface CustomSectionCatalog {
+  vendor: string;
+  sections: CustomSectionDescriptor[];
+}
+
+/** The reason a region name is refused, or null. Shared by every door. */
+export const regionNameError = (name: unknown): string | null => {
+  if (typeof name !== 'string' || !REGION_NAME_PATTERN.test(name)) {
+    return (
+      `region name ${JSON.stringify(name)} is not valid. Use a lowercase name ` +
+      `starting with a letter (letters, digits and hyphens, max 32 characters) — the name is ` +
+      `matched literally against the block the editor seeded for it`
+    );
+  }
+
+  return null;
+};

package/src/custom/theme-editable.tsx

@@ -298,7 +298,9 @@ export function ThemeEditable({
     });
   }
 
-  const properties = (context.block.properties ?? {}) as Record<
+  // `node` rather than `block`: a field authored inside a custom SECTION lives
+  // in the section's own properties, which is where the editor writes it.
+  const properties = (context.node.properties ?? {}) as Record<
     string,
     unknown
   >;

package/src/custom/theme-region.tsx

@@ -0,0 +1,213 @@
+'use client';
+
+import React, { useEffect, useId } from 'react';
+import { DesignerPlaceholder } from '../blocks/product-block-utils';
+import { renderComposedChildren } from '../blocks/render-composed-children';
+import { devWarn } from '../utils/dev-warn';
+import { useCustomBlockContext } from './block-context';
+import type { CustomBlockContextValue } from './block-context';
+import { findRegionChild } from './region-nodes';
+import { regionNameError } from './section-types';
+
+export interface ThemeRegionProps {
+  /**
+   * Which declared region this places. Required — there is no unnamed region,
+   * because a section's direct children are the merchant's ordinary composed
+   * blocks and a nameless fallback would swallow all of them.
+   */
+  name: string;
+  /** Shown on the empty band in the designer. Defaults to the region name. */
+  label?: string;
+}
+
+/**
+ * Which `ThemeRegion` instance owns each NAME in this section instance.
+ *
+ * Keyed by the context VALUE rather than the section id, for the reasons the
+ * slot claim map documents: the scope is one section instance in one render
+ * pass, two concurrent server renders cannot see each other's claim, and the
+ * entry is collected with the context object instead of leaking.
+ *
+ * Two `<ThemeRegion name="search" />` in one component is a REAL duplicate —
+ * both resolve to the SAME seeded block, so the block would render twice and
+ * two `data-block-id` wrappers would answer to one id, which breaks selection
+ * on the canvas.
+ */
+const regionOwners = new WeakMap<
+  CustomBlockContextValue,
+  Map<string, string>
+>();
+
+const claimRegion = (
+  context: CustomBlockContextValue,
+  name: string,
+  instanceId: string
+): boolean => {
+  const claims = regionOwners.get(context) ?? new Map<string, string>();
+  regionOwners.set(context, claims);
+
+  const owner = claims.get(name);
+  if (owner === undefined) {
+    claims.set(name, instanceId);
+    return true;
+  }
+
+  return owner === instanceId;
+};
+
+const releaseRegion = (
+  context: CustomBlockContextValue,
+  name: string,
+  instanceId: string
+): void => {
+  const claims = regionOwners.get(context);
+  if (claims?.get(name) === instanceId) claims.delete(name);
+};
+
+/**
+ * A child the developer NAMED and PLACED: the block seeded for this region
+ * renders exactly here.
+ *
+ * A REGION IS NOT A SLOT. A slot is an opening the merchant fills with whatever
+ * they choose; a region is one block the developer chose the type of, put in a
+ * particular place in the markup, and handed to the merchant to style, configure
+ * and — if they want — delete. The merchant cannot reorder it or insert beside
+ * it: the JSX owns the layout, and no drag in the layer tree can change where
+ * this renders.
+ *
+ * ONE ARRAY ELEMENT THROUGH THE SAME FUNCTION EVERY CONTAINER USES. Passing the
+ * seeded block through `renderComposedChildren` is what gives it the visibility
+ * filter, all six editor actions, its `data-block-id` wrapper and therefore the
+ * CSS the panel writes for it — for free, and identically to a block the
+ * merchant dropped by hand. Rendering `<ThemeBlock>` directly here would lose
+ * every one of those and each loss would be silent.
+ *
+ * A MISSING CHILD IS NOT AN ERROR. The merchant may have deleted it, which is an
+ * ordinary composition edit and must stay durable — a header whose language
+ * switcher was removed does not grow one back on the next load. The designer
+ * gets a labelled band so the hole is visible and the region can be re-added;
+ * the live storefront renders nothing.
+ */
+export function ThemeRegion({ name, label }: ThemeRegionProps) {
+  const context = useCustomBlockContext();
+  // Stable for the life of the instance and distinct between two instances,
+  // which is what separates "the same region re-rendering" from "a second
+  // region claiming the same name".
+  const instanceId = useId();
+
+  const nameError = regionNameError(name);
+  const inSection = context?.scope === 'section';
+  const claimable = context && inSection && !nameError;
+  const ownsRegion = claimable ? claimRegion(context, name, instanceId) : false;
+
+  useEffect(() => {
+    if (!context || !claimable || !ownsRegion) return;
+
+    // Hand the claim back on unmount so a region behind a condition
+    // (`{isWide && <ThemeRegion name="search" />}`) does not lock the section
+    // out of that name for the rest of the page's life.
+    return () => releaseRegion(context, name, instanceId);
+  }, [context, claimable, ownsRegion, name, instanceId]);
+
+  if (!context) {
+    devWarn(
+      'ThemeRegion',
+      'A ThemeRegion rendered outside a custom section, so there is no ' +
+        'composition to read the region from and nothing is rendered. Render ' +
+        'this component through a section registered with registerCustomSections().'
+    );
+    return null;
+  }
+
+  const { node, isDesigner } = context;
+
+  if (!inSection) {
+    devWarn(
+      'ThemeRegion',
+      `A ThemeRegion rendered inside the custom BLOCK "${node.type}". Regions are ` +
+        'placed by a custom section and resolve against the section\'s own children; ' +
+        'inside a block there is nothing to resolve. Use <ThemeSlot /> for a ' +
+        'merchant-fillable opening in a block.'
+    );
+
+    return isDesigner ? (
+      <DesignerPlaceholder label="ThemeRegion only works inside a custom section" />
+    ) : null;
+  }
+
+  if (nameError) {
+    devWarn(
+      'ThemeRegion',
+      `The custom section "${node.type}" renders a region that cannot be resolved: ${nameError}.`
+    );
+
+    return isDesigner ? (
+      <DesignerPlaceholder label={`Unresolved region — ${nameError}`} />
+    ) : null;
+  }
+
+  if (!ownsRegion) {
+    devWarn(
+      'ThemeRegion',
+      `The custom section "${node.type}" renders the region "${name}" more than once. ` +
+        'Both resolve to the same seeded block, so it would render twice and two wrappers ' +
+        'would answer to one block id; the extra region renders nothing.'
+    );
+
+    return isDesigner ? (
+      <DesignerPlaceholder
+        label={`Duplicate region — "${name}" is already placed in this section`}
+      />
+    ) : null;
+  }
+
+  const declared = context.declaredRegionNames;
+
+  // A name the section never declared can never have been seeded, so this is a
+  // typo rather than a merchant edit — and the two look identical on screen.
+  // Warned once per render pass rather than swallowed, because the alternative
+  // is a developer staring at an empty band that the editor has no row for.
+  if (declared && !declared.includes(name)) {
+    devWarn(
+      'ThemeRegion',
+      `The custom section "${node.type}" places a region "${name}" it never declared, so nothing ` +
+        `was ever seeded for it. Add it to the regions list in defineCustomSection(). ` +
+        `Declared: ${declared.length > 0 ? declared.join(', ') : '(none)'}.`
+    );
+  }
+
+  const child = findRegionChild(node, name);
+
+  if (!child) {
+    return isDesigner ? (
+      <DesignerPlaceholder
+        label={`${label ?? name} — removed, add it back from the editor`}
+      />
+    ) : null;
+  }
+
+  const children = renderComposedChildren({
+    blocks: [child],
+    placeholderId: context.placeholderId,
+    // The section IS the parent here, so its own id is the address every editor
+    // action for this child is sent with.
+    sectionId: context.sectionId,
+    isDesigner,
+    selectedBlockId: context.selectedBlockId,
+    currentBreakpoint: context.currentBreakpoint
+  });
+
+  // Empty is decided AFTER the pipeline, not from the array length: a region
+  // whose block is hidden renders nothing on the storefront and a selectable
+  // row in the designer, and both sides have to draw what they actually
+  // rendered.
+  if (children.length === 0) {
+    return isDesigner ? (
+      <DesignerPlaceholder label={`${label ?? name} — hidden`} />
+    ) : null;
+  }
+
+  return <>{children}</>;
+}
+
+export default ThemeRegion;

package/src/custom/theme-slot.tsx

@@ -134,21 +134,22 @@ export function ThemeSlot({ label, name }: ThemeSlotProps) {
   if (!context) {
     devWarn(
       'ThemeSlot',
-      'A ThemeSlot rendered outside a custom block, so there is no composition ' +
-        'to read children from and nothing is rendered. Render this component ' +
-        'through a block registered with registerCustomBlocks().'
+      'A ThemeSlot rendered outside a custom block or section, so there is no ' +
+        'composition to read children from and nothing is rendered. Render this ' +
+        'component through a unit registered with registerCustomBlocks() or ' +
+        'registerCustomSections().'
     );
     return null;
   }
 
-  const { block, isDesigner } = context;
+  const { node, isDesigner } = context;
 
   if (slotName === null) {
     const reason = (resolved as { error: string }).error;
 
     devWarn(
       'ThemeSlot',
-      `The custom block "${block.type}" renders a slot that cannot be resolved: ${reason}.`
+      `The custom unit "${node.type}" renders a slot that cannot be resolved: ${reason}.`
     );
 
     return isDesigner ? (
@@ -161,7 +162,7 @@ export function ThemeSlot({ label, name }: ThemeSlotProps) {
 
     devWarn(
       'ThemeSlot',
-      `The custom block "${block.type}" declares more than one ThemeSlot for ${named}. ` +
+      `The custom unit "${node.type}" declares more than one ThemeSlot for ${named}. ` +
         'Both resolve to the same slot node, so its children would render twice and two ' +
         'wrappers would answer to one block id; the extra slot renders nothing. Give each ' +
         'ThemeSlot its own name.'
@@ -180,7 +181,7 @@ export function ThemeSlot({ label, name }: ThemeSlotProps) {
     label === undefined ? { name: slotName } : { name: slotName, label }
   );
 
-  const slotChildren = resolveSlotChildren(block, slotName);
+  const slotChildren = resolveSlotChildren(node, slotName);
 
   const children = renderComposedChildren({
     // Null is "this slot has no node yet", which renders exactly like an empty

package/src/custom/types.ts

@@ -111,7 +111,16 @@ export const RESERVED_SETTING_KEYS: readonly string[] = [
   'customCss',
   'publish-window',
   'typographyVariant',
-  'role'
+  'role',
+  // The two reserved node properties. Neither is a panel key, so neither is
+  // here for the reason the ones above are — they are here because a setting
+  // sharing one of these names would write the SAME key on the same node the
+  // resolver reads: `useThemeSetting('regionName', …)` on a section writes
+  // `section.properties.regionName`, one level away from the region binding it
+  // would appear to be addressing. Refusing the name costs a developer nothing
+  // and closes a near-miss that would be very hard to see.
+  'slotName',
+  'regionName'
 ];
 
 /**

package/src/custom/use-theme-setting.ts

@@ -206,10 +206,12 @@ export function useThemeSetting<
 
   const breakpoint = context.currentBreakpoint;
 
-  // `block.properties[key]`, never `block.value` — `value` is one slot per
-  // block, so the second setting would overwrite the first, and the backend
-  // drops attribute keys that were never declared.
-  const stored = context.block.properties?.[key];
+  // `node.properties[key]`, never `node.value` — `value` is one slot per block,
+  // so the second setting would overwrite the first, and the backend drops
+  // attribute keys that were never declared. `node` rather than `block` so a
+  // setting declared inside a custom SECTION reads the section's own
+  // properties, which is where the editor writes it.
+  const stored = context.node.properties?.[key];
 
   // The sentinel again, for the same reason: handing `getResponsiveValue` an
   // undefined fallback would resolve an undeclared default to `''`, so a