Documentation / blocks-catalog-pack

Commerce Blocks

Blocks & Themes

@wabbit/tome-blocks-catalog-packv0.18.0

Pro-tier catalog/e-commerce blocks — product card, product grid, category strip, price table, inventory badge, and featured product, with optional live-data hydration from @wabbit/tome-catalog.

Installnpm install @wabbit/tome-blocks-catalog-pack

Overview

@wabbit/tome-blocks-catalog-pack

Pro-tier Payload block bundle for catalog (e-commerce) use cases. Designed to work with @wabbit/tome-catalog for rich integrations, with graceful fallback to static props when @wabbit/tome-catalog is absent.

Status: 6 blocks shipped (Product Card, Product Grid, Category Strip, Price Table, Inventory Badge, Featured Product), each with 2–3 variants. Product Card, Featured Product, and Category Strip additionally support v1 live-data hydration via the separate /server subpath — see "Hydration (v1)" below.

Install

On a Tome site (meta-package path)

The @wabbit/tome-blocks meta-package re-exports all first-party bundles. No extra install needed if you are already on @wabbit/tome-blocks.

On a stock Payload site — add to an existing blocks field

npm install @wabbit/tome-blocks-catalog-pack

@wabbit/tome-blocks-core is a required peer and installs automatically (npm 7+/pnpm). Add the blocks you want alongside your existing ones and render them — see @wabbit/tome-blocks-core's "Add Tome blocks to an existing Payload project" for the full walkthrough:

// payload.config.ts
import { productCardBlock, productGridBlock } from '@wabbit/tome-blocks-catalog-pack'
// blocks: [...existingBlocks, productCardBlock.block(), productGridBlock.block()]

// blockComponents.ts
import { renderers as catalogRenderers } from '@wabbit/tome-blocks-catalog-pack/render/register'
import { adaptRenderersForPayload } from '@wabbit/tome-blocks-core/render'
// blockComponents: { ...adaptRenderersForPayload(catalogRenderers) }

@import '@wabbit/tome-blocks-core/styles.css';

Registering everything from scratch instead:

import { BlockRegistry, BundleRegistry } from '@wabbit/tome-blocks-core/registry'
import { register } from '@wabbit/tome-blocks-catalog-pack'

const blockRegistry = new BlockRegistry()
const bundleRegistry = new BundleRegistry()

register(blockRegistry, bundleRegistry)

// Use blockRegistry.resolveAll() to get Payload Block configs

Peer dependencies

Generated from package.json#peerDependencies (the README gate fails if this table and the manifest disagree).

| Peer | Range | Required | |---|---|---| | lucide-react | >=0.460.0 | yes | | payload | >=3.67.0 | yes | | react | >=19.0.0 | yes | | react-dom | >=19.0.0 | yes | | @wabbit/tome-blocks-core | >=0.18.0 <1.0.0 | yes |

Hydration (v1) — `@wabbit/tome-blocks-catalog-pack/server`

Every block renders exactly the authored props by default — that never changes, with no peer required. A consumer who additionally wires the separate /server subpath gets live @wabbit/tome-catalog data overlaid on top of the authored fallback for three blocks. This is a server concern only: the static renderers above are unchanged and unaware of it.

import { registerRenderers, renderers as staticComponents } from '@wabbit/tome-blocks-catalog-pack/render/register'
import { createHydratedRenderers } from '@wabbit/tome-blocks-catalog-pack/server'
import { getPayload } from 'payload'
import config from '@payload-config'

const components = {
  ...staticComponents,
  ...createHydratedRenderers({ getPayload: () => getPayload({ config }) }),
}
// pass `components` into RenderBlock/RenderBlocks

v1 hydration matrix (verified against the real `@wabbit/tome-catalog` schema)

| Block | Lookup key | Live fields overlaid | Fallback | Notes | |---|---|---|---|---| | product-card | sku → catalog-products | title, description (from Product.excerpt) | all authored fields | price/comparePrice/badge/CTA stay authored — @wabbit/tome-catalog v1 has no pricing field at all, and this block has no image prop for featuredImage to fill | | featured-product | sku → catalog-products | title, description (from Product.excerpt) | all authored fields | same reasoning as product-card; highlights/price/CTA stay authored | | category-strip | each item's slug → catalog-categories (one batched query) | label (from Category.name) | authored label per item | url always stays authored (no live "route" concept); no live count — this block's render component has no count slot to receive one into even though payload.count() could compute it | | inventory-badge | — | none | fully static, deliberately | @wabbit/tome-catalog v1 has no stock/inventory field anywhere, and its status (draft/active/archived) is a publish flag, not availability — anonymous reads only ever see status: active regardless, so it carries no usable signal. Trigger to revisit: a future stock/quantity field or inventory collection in @wabbit/tome-catalog | | price-table | — | none | fully static, by design | authored pricing artifact — see its own meta | | product-grid | — | — | out of scope for v1 | this pack's one 'use client' renderer; a future wave could hydrate its products array from getProductsByCategory/getProductsByVendor |

Why the overlay matrix is narrow: an earlier design guessed price/image/availability as overlay targets for product-card/featured-product and "stock state" for inventory-badge — none of those have a live source (@wabbit/tome-catalog's Product type carries no pricing or stock field at all — "catalog spec excludes pricing" per packages/catalog/src/registry/defaultProductHooks.ts — and neither block has an image render prop). description (overlaid from Product.excerpt) was added because the field exists, type-matches, and is literally documented as "Short summary for cards/listings" in the catalog schema. Category-strip's "counts" were dropped for the same no-render-slot reason as product-card's image.

Access boundary

Every hydration query runs overrideAccess: false with no user in the request context — Payload evaluates access as an anonymous visitor. @wabbit/tome-catalog's publicReadActiveOnly restricts that to status: 'active' products; Categories are read: () => true (always public). Personalized/authenticated hydration is explicitly out of scope for v1.

Fallback contract

Layer absent (site doesn't have @wabbit/tome-catalog installed), entity missing (no doc matches the lookup key), or the query throws — all three collapse to the same outcome: the authored props pass through untouched. Hydration never removes or blanks an authored field; it only overlays a field once a live value was actually found. There is no isCatalogLayerPresent() gate in the resolvers — that flag is a fire-and-forget async check (see src/index.ts) that can still read false after the layer registers; attempting the query directly and catching failure handles every case correctly, including that race.

Per-request dedup

Resolvers use React.cache() where the host runtime provides it (Next.js App Router / React 19) so two blocks referencing the same SKU on one page cost one query, not two. This pack's own peer range ("react": ">=18.0.0") allows plain React 18, where cache doesn't exist at runtime — verified against this workspace's own installed react@18.3.1. Where it's unavailable, the pack falls back to calling straight through (no dedup, never a crash). There is no cache/tag machinery beyond this — cross-request freshness (ISR, ISR revalidation, ...) stays the consumer's concern.

Known v1 limitation

Collection slugs (catalog-products / catalog-categories) are hardcoded to @wabbit/tome-catalog's defaults rather than configurable through createHydratedRenderers's fixed { getPayload } contract. A site that renamed its catalog collections away from the defaults gets no hydration (safe fallback to authored props), not a crash — a slug-override option is the natural v2 extension if that's ever needed.

Detection mechanism (static blocks only)

This package uses hasLayer('@wabbit/tome-catalog') from @wabbit/tome-core/utilities/layerRegistry via a dynamic import() to expose isCatalogLayerPresent(). The import is wrapped in a try/catch so the package boots cleanly even when @wabbit/tome-core itself is not installed. The /server subpath does not use this detection mechanism — see "Fallback contract" above.

Compatibility matrix

Required peers:

| Payload | React | React DOM | lucide-react | |---------|-------|-----------|--------------| | >=3.67.0 | >=18.0.0 | >=18.0.0 | >=0.460.0 |

Optional integrations (not required peers, and not the same mechanism as each other):

@wabbit/tome-core — optionalDependencies (a real, auto-attempted npm install, not a peer). Used only for hasLayer('@wabbit/tome-catalog') detection via a try/catch dynamic import.
@wabbit/tome-catalog — optional peer (peerDependenciesMeta only; no enforced version range). This pack never imports it directly — hydration queries the Payload collections it registers (catalog-products, catalog-categories) by slug and falls back to authored props if absent.

Block list

product-card — Product title, description, price, CTA (v1 hydration: title/description)
product-grid — Grid of product cards with filtering controls (client component; not part of v1 hydration)
category-strip — Horizontal/grid category navigation strip (v1 hydration: label)
price-table — Tiered pricing comparison table (fully static, by design)
inventory-badge — In-stock / low-stock / out-of-stock indicator (fully static, deliberately — see its meta)
featured-product — Hero-style featured product showcase (v1 hydration: title/description)

Each block carries 2–3 variants with SVG thumbnails per the thumbnail-authoring guide.

Public API

| Export | Subpath | Description | |---|---|---| | Block descriptors (CategoryStrip, FeaturedProduct, InventoryBadge, PriceTable, ProductCard, ProductGrid configs) + register(blockRegistry, bundleRegistry) + isCatalogLayerPresent() | . | Payload block config descriptors, bundle registration, and the @wabbit/tome-catalog layer-detection flag | | CategoryStrip, FeaturedProduct, InventoryBadge, PriceTable, ProductCard, ProductGrid | ./render | Legacy self-registering render barrel | | renderers map + registerRenderers() | ./render/register | Explicit registration (server-safe adapter contract) — no side effects on import | | getDemoProps(blockSlug, variant, ctx?) (plus tree-shakeable per-block demo functions) | ./demo | Pack-level demo-props dispatcher feeding the auto-gallery route; returns null for unknown slugs | | Bundle/block metadata (slugs + variants) | ./meta | Payload-free surface for the gallery storefront | | createHydratedRenderers(), resolveProductCardData(), resolveFeaturedProductData(), resolveCategoryStripData() | ./server | v1 hydration contract — server-only (import 'server-only'); see "Hydration (v1)" above |

Server / client posture

5 of the pack's 6 renderers under src/render/ (CategoryStrip, FeaturedProduct, InventoryBadge, PriceTable, ProductCard) are plain static components with no 'use client' directive. ProductGrid alone is a client component (verified 2026-07-12; scripts/assert-rsc-boundaries.mjs MANIFEST: blocks-catalog-pack: 1) — its filtering UI needs a client boundary the other five don't. Prefer the ./render/register subpath (registerRenderers()) when registering from payload.config.ts or any Node/server context — the legacy ./render barrel re-exports CSS Modules at its root, which crashes Node's ESM loader outside a bundler (see @wabbit/tome-blocks's README, "Two rules for consumers"); ./render/register imports each component directly and sidesteps that barrel-level hazard.

Blocks

`product-card`

A single product tile — title, description, price (with optional compare-at strike), a label badge, and an add-to-cart CTA. Renders the authored props by default; no @wabbit/tome-catalog peer required. When a consumer wires `createHydratedRenderers` from `@wabbit/tome-blocks-catalog-pack/server` AND the SKU matches an active `catalog-products` doc, title and description hydrate live over the authored fallback — anonymous-visible data only (see the /server README). Three variants: default card, minimal (title + price only), and horizontal (image left, details right).

When to use

Highlighting one product on a landing, marketing, or about page
A "featured item" or "shop this" callout inside editorial or campaign content
A single hand-picked product where a full grid would be overkill

Page types

marketing
landing
about

How to use

Author title (required), description, price and compare-at price, SKU, an optional badge, and the CTA label/URL. The SKU is the v1 hydration lookup key: with @wabbit/tome-catalog present and `createHydratedRenderers` wired in, a matching `catalog-products` doc overlays its `title` and `excerpt` (into description) over these authored fields — nothing else. Price, compare-at price, badge, and the CTA are ALWAYS the authored values: @wabbit/tome-catalog carries no pricing or stock field at all (v1, by design), and this block has no `image` prop for a live featuredImage to fill. Choose the variant: default for a full card, minimal for a sparse price-led row, horizontal for a compact list-style item. For a set of products, use `product-grid` instead of stacking many cards — same product shape, but the grid takes the array (product-grid is not part of the v1 hydration wave).

Pairs with

product-grid
inventory-badge
price-table
featured-product

Precedes

inventory-badge

Avoid when

Showing several products at once — that is `product-grid` (it takes the array)
Spotlighting one product as a full-width hero — use `featured-product`
Comparing pricing tiers of a plan — use `price-table`

marketing-landing

`product-grid`

A responsive grid of products — a heading, a column count (2/3/4), an array of product items, optional filter controls, and a max-items cap. Fully static — always renders the authored list; no @wabbit/tome-catalog peer required. Three variants: default 3-column, compact dense 4-column, and editorial masonry.

When to use

A catalog, shop, or collection page listing many products at once
A "shop the collection" or "new arrivals" section on a marketing/landing page
Any place you would otherwise stack several product cards

Page types

marketing
landing
about

How to use

Set a heading and column count, then author the `products` array (title, price, badge, image, CTA per item) — this array is the only data source today; the filter controls have no effect on it yet. @wabbit/tome-catalog is not wired in yet; the isCatalogLayerPresent/resolveCatalogLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs a live query and working filters to supply products instead. Choose the variant by density: default for standard cards, compact for a dense catalog wall, editorial for a varied masonry feel. This is the multi-product block — for a single product use `product-card`, and for a hero spotlight use `featured-product`.

Pairs with

product-card
category-strip
featured-product
inventory-badge

Follows

category-strip
featured-product

Avoid when

You only have one product to show — use `product-card`
The goal is to spotlight one hero product — use `featured-product`
Navigating between categories rather than listing products — use `category-strip`

marketing-landing

`category-strip`

A wayfinding row of product categories — a heading and an array of category tiles (label, slug, URL, icon), scrollable or wrapped. Renders the authored labels/URLs by default; no @wabbit/tome-catalog peer required. When a consumer wires `createHydratedRenderers` from `@wabbit/tome-blocks-catalog-pack/server`, each tile's `slug` is looked up (one batched query) against `catalog-categories` and a match overlays the live category name onto the label — the authored URL always stays the route (there is no live "route" field), and there is no live product count (this block has no count display slot). Three variants: scrollable default tiles, minimal text links, and a fixed-column grid with thumbnails.

When to use

A shop or catalog landing page that needs top-level category navigation
A "browse by category" row above a product grid
A homepage entry point that routes visitors into product collections

Page types

marketing
landing
about

How to use

Author a `categories` array (label required; optional slug, URL, and icon/emoji); toggle horizontal scrolling. The slug is the v1 hydration lookup key: with @wabbit/tome-catalog present and hydration wired in, a matching `catalog-categories` doc overlays its live `name` onto the tile's label — nothing else. The authored URL is always the route used (there is no live route to overlay it with), and an unmatched slug simply keeps its authored label. Choose the variant: default for icon tiles in a scroll strip, minimal for a clean text-link row, grid for a thumbnailed category board. This is navigation — it routes to product listings rather than displaying products, so it typically sits above a `product-grid`.

Pairs with

product-grid
product-card
featured-product

Precedes

product-grid
featured-product

Avoid when

You want to display products, not links to category pages — use `product-grid`
There is only one category — a strip of one is pointless
The page needs a product spotlight, not navigation — use `featured-product`

structural

`price-table`

A side-by-side pricing comparison — up to five tiers, each with a name, price, billing note, description, a per-tier feature checklist (included/excluded), a recommended-highlight flag, and its own CTA. Fully authored content with no catalog peer required. Three variants: default multi-tier table, minimal single highlighted plan, and dark with an accent on the recommended tier.

When to use

A pricing page comparing plan or package tiers where features differ by tier
A "choose your plan" section where the visitor picks among recurring options
A product page offering good/better/best variants of the same offering

Page types

pricing
landing
marketing

How to use

Author a `tiers` array (1-5): each tier needs a name, price, and CTA label/URL, plus optional price-note, description, a features array (each with an included checkbox), and a highlight flag for the recommended plan. Choose the variant: default for two-to-four comparable tiers, minimal when there is effectively one plan to present, dark to make the table the page's focal band. Use this when features-per-tier is the decision; for a single product's buy action use `product-card` or `featured-product`.

Pairs with

featured-product
product-card
product-grid
category-strip

Follows

featured-product

Avoid when

There is a single offer with one price — a `product-card` or `featured-product` CTA is enough
You are listing distinct products rather than tiers of one offering — use `product-grid`
Tiers have identical features and differ only in price — a simple list beats a comparison table

marketing-landing

`inventory-badge`

A small inline stock-status indicator — In Stock / Low Stock / Out of Stock, with a low-stock threshold and an optional exact count. Fully static — always shows the authored status; no @wabbit/tome-catalog peer required. Three variants: colored pill default, text-only minimal, and a with-count form ("Only 3 left").

When to use

Inline beside a product title or price to signal availability
A scarcity cue ("Low Stock") on a product or featured-product block
A catalog row where stock state affects whether the visitor can buy

Page types

marketing
landing
about

How to use

Provide a SKU, the status to show, a low-stock threshold, and an optional exact count for the with-count variant. Unlike product-card/featured-product/category-strip, this block is NOT part of the v1 hydration wave (`@wabbit/tome-blocks-catalog-pack/server`) — a deliberate decision, not an oversight: @wabbit/tome-catalog's Product schema (packages/catalog/src/collections/Products.ts) has no stock/quantity/inventory field at all, and its `status` (draft/active/archived) is a content-publish flag, not availability — anonymous reads only ever see `status: active` anyway (publicReadActiveOnly), so it carries zero real signal for this badge even if repurposed. The SKU field is kept (matching product-card/featured-product's shape for pairing) but is not looked up against anything. Trigger to revisit: if @wabbit/tome-catalog ever ships a stock/quantity field or a dedicated inventory collection, wire a resolveInventoryBadgeData resolver into @wabbit/tome-blocks-catalog-pack/server the same way the other three blocks are wired. Choose the variant: default for a colored pill, minimal for an unobtrusive text status, with-count when exact remaining quantity adds urgency. This is a status accent, not a standalone section — pair it with a product block rather than placing it alone.

Pairs with

product-card
featured-product
product-grid

Follows

product-card
featured-product

Avoid when

As a standalone block with no product context — it is an accent on a product
Stock state is irrelevant to the page (e.g. digital/always-available goods)
You need full pricing or purchase UI — use `product-card` or `price-table`

application

`featured-product`

A full-width hero spotlight for one product — eyebrow, title, description, price with compare-at strike, a highlights list, a badge, and a primary CTA. Renders the authored props by default; no @wabbit/tome-catalog peer required. When a consumer wires `createHydratedRenderers` from `@wabbit/tome-blocks-catalog-pack/server` AND the SKU matches an active `catalog-products` doc, title and description hydrate live over the authored fallback — anonymous-visible data only. Three variants: split (image left / details right), centered (image above, details below), and dark for a premium treatment.

When to use

The hero of a product or campaign landing page built around a single item
A "product of the month" or new-release spotlight above the catalog grid
Any place one product deserves full-width emphasis rather than a card

Page types

marketing
landing
about

How to use

Author title (required) and CTA label (required), plus eyebrow, description, price/compare-at, SKU, a highlights array (up to 8), an optional badge, and the CTA URL. The SKU is the v1 hydration lookup key: with @wabbit/tome-catalog present and `createHydratedRenderers` wired in, a matching `catalog-products` doc overlays its `title` and `excerpt` (into description) over these authored fields — nothing else. Price, compare-at price, highlights, badge, and the CTA all ALWAYS stay authored: @wabbit/tome-catalog carries no pricing/stock/highlights field in v1. Choose the variant: split for a classic image-and-details hero, centered for a symmetrical full-width feel, dark for premium contrast. This is the single-product hero — for several products use `product-grid`, and for a compact single item use `product-card`. Typically the lead block, followed by a grid of related products.

Pairs with

product-grid
product-card
inventory-badge
price-table
category-strip

Precedes

product-grid
price-table
inventory-badge

Avoid when

Showing many products — use `product-grid`; this block is for one hero item
A compact list-style product entry — use `product-card`
Comparing plan tiers rather than spotlighting a product — use `price-table`

marketing-landing

Exports

@wabbit/tome-blocks-catalog-pack
@wabbit/tome-blocks-catalog-pack/render
@wabbit/tome-blocks-catalog-pack/render/register
@wabbit/tome-blocks-catalog-pack/demo
@wabbit/tome-blocks-catalog-pack/meta
@wabbit/tome-blocks-catalog-pack/server

Changelog

v0.18.0patch

c3468b0: Layer detection now runs through blocks-core's `createLayerProbe` instead of a local `tryGetLayerRegistry` copy. The dynamic core import stays in this pack, and memo semantics are unchanged. The `@wabbit/tome-blocks-core` peer floor goes up to `>=0.18.0` because that is the first version exporting the helper.

c3468b0: Layer detection now runs through blocks-core's `createLayerProbe` instead of a local `tryGetLayerRegistry` copy. The dynamic core import stays in this pack, and memo semantics are unchanged. The `@wabbit/tome-blocks-core` peer floor goes up to `>=0.18.0` because that is the first version exporting the helper.

v0.17.0minor

404d325: Tome block packs now install into an existing Payload project the way the README says: one `npm install`, one CSS import, no undocumented steps. Proven by the new fresh-install smoke test (`scripts/blocks-fresh-install-smoke.mjs`) against a brand-new `create-payload-app` website-template site. **Consumers: list `@wabbit/tome-blocks-core` and `@wabbit/tome-ui` in your own `package.json`** if you import from them (npm 7+ and pnpm install required peers automatically, so a fresh `npm install` of a pack already brings them in). - **One shared `blocks-core` per site.** Every pack, `blocks-house` and `blocks-extras` now declare `@wabbit/tome-blocks-core` (and, where used, `-house` / `-extras`) as a required peer with an explicit range instead of a regular dependency, so a site gets exactly one hoisted copy and one adapter registry. - **No more ERESOLVE in plain Payload sites.** `blocks-core` no longer declares `@wabbit/tome-core` or `@wabbit/tome-catalog` (their optional peer graph pulled `better-auth` → `@sveltejs/kit` → `vite@8` against a site's `vite@7`). The `block-bundle` product type still auto-registers when both are installed; new structural types `BlockBundleProductTypeDeps`, `BlockBundleProductTypeRegistryLike`, `RegisterProductTypeHooksLike`. - **Tokens in one line:** `@import '@wabbit/tome-blocks-core/styles.css';` (new export; imports `@wabbit/tome-ui/tokens`). `@wabbit/tome-ui` is now a required peer of `blocks-core`. - **Rich text and images render with no adapter setup.** Built-in defaults render Lexical through `@payloadcms/richtext-lexical/react` and resolve populated Payload uploads; an unpopulated upload id warns once in every environment (previously content vanished silently in production). Registered adapters still win. - **Payload's spread-props convention:** new `adaptRenderersForPayload(renderers)` / `adaptRendererForPayload(Component)` wrap any pack's `renderers` map for a site that renders `<Block {...block} />`. - **Slug collisions with Payload's templates** (`cta`, `banner`, `archive`, `content`, `code`): new `applyBlockSlugOverrides(blocks, overrides)` and `remapRendererSlugs(renderers, overrides)` (`@wabbit/tome-blocks-core/slugOverrides`). Defaults are unchanged; no stored data migrates. - **`blocks-house`** owns `gsap` and `hls.js` as dependencies (previously optional peers that still broke the build when missing), and registers GSAP's `ScrollTrigger` itself before first use. - **Full-bleed bands actually span the grid.** Eight `pinnedBand` blocks (cinema-pack AmbientBand, MediaPanel, PullInterlude, SceneCaption, ScenePlate, ScrubStory, StatementBand; blocks-house FullBleedInterstitial) now declare `grid-column: 1 / -1` at their root as the contract requires. **Visible change:** inside a tome-ui `.grid`, these render edge to edge where they were previously squeezed to content width. - **`@wabbit/tome-ui`:** `.grid` declares `reading-start` / `reading-end` below 768px (aliased to the content column), so blocks placed on the reading column no longer collapse to a sliver on phones. - Every pack README gains an "Install into an existing Payload project" section and a peer table that matches `package.json`; `blocks-core`'s README carries the full walkthrough.

404d325: Tome block packs now install into an existing Payload project the way the README says: one `npm install`, one CSS import, no undocumented steps. Proven by the new fresh-install smoke test (`scripts/blocks-fresh-install-smoke.mjs`) against a brand-new `create-payload-app` website-template site. **Consumers: list `@wabbit/tome-blocks-core` and `@wabbit/tome-ui` in your own `package.json`** if you import from them (npm 7+ and pnpm install required peers automatically, so a fresh `npm install` of a pack already brings them in). - **One shared `blocks-core` per site.** Every pack, `blocks-house` and `blocks-extras` now declare `@wabbit/tome-blocks-core` (and, where used, `-house` / `-extras`) as a required peer with an explicit range instead of a regular dependency, so a site gets exactly one hoisted copy and one adapter registry. - **No more ERESOLVE in plain Payload sites.** `blocks-core` no longer declares `@wabbit/tome-core` or `@wabbit/tome-catalog` (their optional peer graph pulled `better-auth` → `@sveltejs/kit` → `vite@8` against a site's `vite@7`). The `block-bundle` product type still auto-registers when both are installed; new structural types `BlockBundleProductTypeDeps`, `BlockBundleProductTypeRegistryLike`, `RegisterProductTypeHooksLike`. - **Tokens in one line:** `@import '@wabbit/tome-blocks-core/styles.css';` (new export; imports `@wabbit/tome-ui/tokens`). `@wabbit/tome-ui` is now a required peer of `blocks-core`. - **Rich text and images render with no adapter setup.** Built-in defaults render Lexical through `@payloadcms/richtext-lexical/react` and resolve populated Payload uploads; an unpopulated upload id warns once in every environment (previously content vanished silently in production). Registered adapters still win. - **Payload's spread-props convention:** new `adaptRenderersForPayload(renderers)` / `adaptRendererForPayload(Component)` wrap any pack's `renderers` map for a site that renders `<Block {...block} />`. - **Slug collisions with Payload's templates** (`cta`, `banner`, `archive`, `content`, `code`): new `applyBlockSlugOverrides(blocks, overrides)` and `remapRendererSlugs(renderers, overrides)` (`@wabbit/tome-blocks-core/slugOverrides`). Defaults are unchanged; no stored data migrates. - **`blocks-house`** owns `gsap` and `hls.js` as dependencies (previously optional peers that still broke the build when missing), and registers GSAP's `ScrollTrigger` itself before first use. - **Full-bleed bands actually span the grid.** Eight `pinnedBand` blocks (cinema-pack AmbientBand, MediaPanel, PullInterlude, SceneCaption, ScenePlate, ScrubStory, StatementBand; blocks-house FullBleedInterstitial) now declare `grid-column: 1 / -1` at their root as the contract requires. **Visible change:** inside a tome-ui `.grid`, these render edge to edge where they were previously squeezed to content width. - **`@wabbit/tome-ui`:** `.grid` declares `reading-start` / `reading-end` below 768px (aliased to the content column), so blocks placed on the reading column no longer collapse to a sliver on phones. - Every pack README gains an "Install into an existing Payload project" section and a peer table that matches `package.json`; `blocks-core`'s README carries the full walkthrough.

v0.16.5patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.16.4patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.16.3patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.16.2patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.16.1patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.16.0minor

b01ca1f: Raise the `react` / `react-dom` peer floor to `>=19.0.0` across the linked blocks family. Every pack advertised `react: >=18.0.0` while `@wabbit/tome-core`, `chrome`, `forms`, `dispatch`, `longform` and `readout` all require `>=19` — so the React 18 support the packs claimed was **unreachable in any real Tome stack**: no consumer could satisfy both halves of the graph. The advertised range was not a supported configuration, it was a range nobody could install into. Ruled 2026-09-01: the floor becomes the truth. Their `devDependencies` said the same thing from the other direction: `react` and `@types/react` pinned to `^18.0.0` while the root `pnpm.overrides` has pinned `@types/react` to `19.2.14` for months, so every pack has in fact been developed and tested against React 19 types the whole time. Those pins move to `^19.0.0` — a manifest correction, not a version change; the resolved tree is byte-identical. One coordinated bump for the family (these eleven are `linked` in `.changeset/config.json`, so they version together by design). Consumer impact: a consumer genuinely on React 18 can no longer install these packs. That consumer could not have had a working Tome install anyway — the kernel would have refused the same graph. Anyone on React 19 sees no change.

b01ca1f: Raise the `react` / `react-dom` peer floor to `>=19.0.0` across the linked blocks family. Every pack advertised `react: >=18.0.0` while `@wabbit/tome-core`, `chrome`, `forms`, `dispatch`, `longform` and `readout` all require `>=19` — so the React 18 support the packs claimed was **unreachable in any real Tome stack**: no consumer could satisfy both halves of the graph. The advertised range was not a supported configuration, it was a range nobody could install into. Ruled 2026-09-01: the floor becomes the truth. Their `devDependencies` said the same thing from the other direction: `react` and `@types/react` pinned to `^18.0.0` while the root `pnpm.overrides` has pinned `@types/react` to `19.2.14` for months, so every pack has in fact been developed and tested against React 19 types the whole time. Those pins move to `^19.0.0` — a manifest correction, not a version change; the resolved tree is byte-identical. One coordinated bump for the family (these eleven are `linked` in `.changeset/config.json`, so they version together by design). Consumer impact: a consumer genuinely on React 18 can no longer install these packs. That consumer could not have had a working Tome install anyway — the kernel would have refused the same graph. Anyone on React 19 sees no change.
0836ef5: dist now raw-Node loadable: relative specifiers get explicit extensions post-build. `build` gains `&& node ../../scripts/fix-dist-extensions.mjs --strict` as its last step, joining the 13 packages that already ran it. tsup builds `bundle: false` and emits relative specifiers exactly as the TypeScript source wrote them — extensionless — which bundlers resolve and raw Node does not (ESM `ERR_MODULE_NOT_FOUND`; CJS worse, `require('./x')` finds the ESM `.js` twin and Node 22+ `require(esm)` then dies on that file's own extensionless import). Every consumer outside a bundler hit this: the payload CLI under plain node, `generate:types`, `generate:importmap`, ops scripts, codegen tools. No source changes, no API changes, and bundler consumers are unaffected — extensioned relative specifiers are universally resolvable. Two supporting changes made the wiring possible, both in repo scripts rather than package source. `fix-dist-extensions.mjs` now skips bundler-asset specifiers (`.css`, `.module.css`, `.scss`, fonts, images, shaders) by explicit extension allowlist instead of reporting them as unresolvable — that single gap is why the 13 prior adopters were exactly the 13 packages that ship no CSS, since `--strict` exited 1 on any package with a relative stylesheet import. Dotted MODULE names (`./config.meta`, `./x.variants`, `./y.demo`) are deliberately NOT treated as assets and still get `.js`/`.cjs` appended. `assert-node-loadable.mjs` gained the matching carve-outs so the new repo-wide CI gate reports real defects only: a resolution failure whose path lands under `node_modules` is a peer SKIP (next@15 has no exports map, so `next/image` fails as an absolute path), and a bundler-asset load failure is an environmental SKIP (CJS surfaces it as `SyntaxError: Unexpected token '.'` raised from inside the stylesheet). Verified before/after on four packages built one at a time: print 8 FAIL → 0, readout 22 FAIL → 0, ai 3 FAIL → 0, gamification 2 FAIL → 0 (its failure was the other signature — a `directory import` missing `/index`). cop was already clean on a fresh build, so the audit's "27 of 46 fail" figure includes at least one package whose local dist was merely stale.
73081e6: Manifest metadata: `homepage`, `bugs`, `engines`. All 46 publishable manifests were missing the three fields a consumer sees before any code (2026-09-01 sale-readiness audit §6). Metadata only — no source, no build, no runtime change. - `homepage` deep-links to that package README on GitHub (`.../tree/main/packages/<dir>#readme`). Without it a registry page links to the monorepo root and the reader has to guess which of 46 folders they want. - `bugs.url` points at the repo issue tracker, so a paying customer has a place to report a defect that is not email. - `engines.node` is `>=22`, matching the root `engines` and `.nvmrc` set the same day. This is a real floor, not decoration: CI on Node 20 could not expand the glob the block packs use for `node --test`, and a package installed on Node 20 fails at a runtime the installer cannot connect back to the version. The forcing function ships with the change: `scripts/assert-manifest-metadata.mjs` (root `pnpm assert:manifest-metadata`, wired into `platform-discipline.yml` beside `assert:license-metadata`) fails when any publishable manifest lacks `description`, `repository.directory` matching its own folder, `homepage`, `bugs`, `engines.node` equal to the repo floor, `license`, `files` or `sideEffects`. It reported 138 violations before this change and 0 after.
73081e6: README peer tables, and the gate that now requires them. Sixteen packages declared `peerDependencies` and documented them nowhere a reader could scan — in prose inside an install paragraph, in a transposed "compatibility matrix" with the peers as columns, or not at all. Docs only; no source, no manifest, no runtime change (the one manifest change in this PR, admin's `sonner` peer, has its own changeset). Each of the sixteen gains a `## Peer dependencies` section generated from its own `package.json` — `| Peer | Range | Required |`, one row per peer, the range verbatim, `no (optional)` read from `peerDependenciesMeta`, plus one sentence on what is a real `dependency` rather than a peer and why the optional ones are optional. The worst omissions this surfaced: `@wabbit/tome-core` documented 2 of its 13 peers and left out both `next` and `@payloadcms/richtext-lexical`, which are required; `@wabbit/tome-admin` listed 5 of 20; `@wabbit/tome-readout` and `@wabbit/tome-sc` listed none. Eight block packs carried a hand-typed compatibility table that had drifted a full React major — still `>=18` after the peer floor moved to `>=19.0.0` — and none of the eight listed `react-dom` at all. Those tables are retired in favour of the generated one, with a line saying what they used to claim so the next reader does not reinstate them. The forcing function ships with the fix: `scripts/assert-readme-contract.mjs` now FAILS a package that declares peers without a peer table (a markdown table whose header row names a Peer and a Range column — the existing `Optional?` and `Notes` third columns still pass, so the thirty already-conforming READMEs were not touched). It is deliberately shape-only, not row-level: asserting that each row agrees with the manifest is the Tier 2 generation work. Verified non-vacuous by breaking one table's header and watching the gate fail, then restoring it. `CONTRIBUTING.md`'s assert-script list — which said "five" while sixteen existed — and the three guides that describe this gate were corrected in the same pass.
Updated dependencies [57875ba]
Updated dependencies [b01ca1f]
Updated dependencies [0836ef5]
Updated dependencies [73081e6]
Updated dependencies [090e984]
Updated dependencies [73081e6] - @wabbit/tome-blocks-core@0.16.0

v0.15.23patch