Org Blocks

Blocks & themesStable

@wabbit/tome-blocks-org-packv0.6.4

Render-ready organization/community blocks — division card, member card, member grid, event calendar, event list item, org chart, document link, and campaign banner; static today, scaffolded for future @wabbit/tome-org hydration.

Install

Get a registry token from your credentials page. You need a purchase that includes this package, or a Craft Library membership.
Add the registry and your token to the .npmrc at the root of your project, with your token in place of YOUR_TOKEN:
```
@wabbit:registry=https://npm.wabbit.com/
//npm.wabbit.com/:_authToken=YOUR_TOKEN
```

Then install:

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

Overview

@wabbit/tome-blocks-org-pack

Organization block pack for the Tome platform — render-ready blocks (DivisionCard, MemberCard, MemberGrid, EventCalendar, EventListItem, OrgChart, DocumentLink, CampaignBanner) for org/community surfaces.

Config descriptors are exported from .; React render components from ./render. All blocks are fully static today — they render exactly the props an author enters, and carry no @wabbit/tome-org peer dependency. The pack does detect whether @wabbit/tome-org is registered (isOrgLayerPresent/resolveOrgLayer in src/index.ts) and each block's config retains fields shaped to match the org layer's records — this is scaffolding for a future hydration wave, not a live integration. Trigger to build it: when a consumer needs a block in this pack to render live @wabbit/tome-org data, wire the resolver into a server-side wrapper at that seam.

Install

On a Tome site (meta-package path)

This pack is a declared dependency of @wabbit/tome-blocks, and its renderers ARE registered by that package's registerAllRenderers() — no separate renderer wiring needed if you already call that. Its block descriptors are a different story: they are NOT re-exported from @wabbit/tome-blocks and NOT included in registerAll() (a pre-existing scope decision — see that package's README, "Public API" section). To add these blocks to a Payload blocks field, import the descriptors from this pack directly (or call this pack's own register()), even on a Tome site.

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

npm install @wabbit/tome-blocks-org-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 { memberCardBlock, eventCalendarBlock } from '@wabbit/tome-blocks-org-pack'
// blocks: [...existingBlocks, memberCardBlock.block(), eventCalendarBlock.block()]

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

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

Registering everything from scratch instead:

// payload.config.ts
import { BlockRegistry, BundleRegistry } from '@wabbit/tome-blocks-core/registry'
import { register } from '@wabbit/tome-blocks-org-pack'

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

register(blockRegistry, bundleRegistry)

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

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

@wabbit/tome-org is not declared as a dependency or peer: the pack never imports it, and detection goes through @wabbit/tome-core's layer registry by name — see the detection note above.

Block list

| Slug | Name | Notes | |---|---|---| | division-card | Division Card | Org sub-unit/division summary card | | member-card | Member Card | Individual member profile card | | member-grid | Member Grid | Grid of member cards | | event-calendar | Event Calendar | Calendar view of org events | | event-list-item | Event List Item | Single event row (list context) | | org-chart | Org Chart | Hierarchical org structure display | | document-link | Document Link | Linked document/resource reference | | campaign-banner | Campaign Banner | Announcement/campaign call-out banner |

Public API

// config (Payload collections / Pages block list)
import { divisionCardBlock } from '@wabbit/tome-blocks-org-pack'
// render — DivisionCard (and every other block component) is exported from
// the `./render` barrel; there is no per-component subpath in the exports map
import { DivisionCard } from '@wabbit/tome-blocks-org-pack/render'

| Export | Subpath | Description | |---|---|---| | Block descriptors (divisionCardBlock, memberCardBlock, memberGridBlock, eventCalendarBlock, eventListItemBlock, orgChartBlock, documentLinkBlock, campaignBannerBlock) + register(blockRegistry, bundleRegistry) + isOrgLayerPresent() | . | Payload block config descriptors, bundle registration, and the @wabbit/tome-org layer-detection flag | | DivisionCard, MemberCard, MemberGrid, EventCalendar, EventListItem, OrgChart, DocumentLink, CampaignBanner + orgPackRenders map | ./render | Legacy self-registering render barrel | | renderers map + registerRenderers() | ./render/register | Explicit registration (server-safe adapter contract) — imports each component directly, 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 | | orgPackBlockMeta (per-block meta + variants, in registration order) | ./meta | Payload-free surface for the gallery storefront |

Server / client posture

All 8 renderers under src/render/ are plain static components — zero carry a 'use client' directive (verified 2026-07-12; scripts/assert-rsc-boundaries.mjs MANIFEST: blocks-org-pack: 0). They render safely from either a server or client component graph. Both render subpaths (./render/register and the legacy ./render barrel) load under plain Node — each renderer's per-block stylesheet ships precompiled as a JS module — so seed scripts and tests can import them. Keep payload.config.ts on the root entry point (block descriptors + register(), no React): that keeps React out of your config. Between the two render subpaths, prefer ./render/register: it has no import-time side effects.

Built with tsup (bundle: false, dual ESM/CJS, CSS mirrored to dist/).

Blocks

`division-card`

A single division/department display — logo, name, description, member count, and named leader. The unit-level companion to member-card, summarizing a sub-org rather than a person. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Introducing a division, department, or regional sub-unit on an about/structure page
A "Our divisions" section where each unit gets a summary card with its leader and headcount
Leading into a member-grid or org-chart that drills into that division

Page types

about
docs
dossier

How to use

Provide name (required) plus description, memberCount, logoUrl, and leaderName — these are the only data source today, not a static fallback. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this card to render a live Division record. Use one card per unit, or several side by side, as the header for the people that belong to it. One variant (default).

Pairs with

member-grid
member-card
org-chart
document-link

Follows

org-chart

Precedes

member-grid
member-card

Avoid when

Profiling an individual rather than a unit — use member-card
You need the full three-level structure tree — use org-chart

application

`member-card`

A single member profile card — avatar, display name, role, and position for one person. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Spotlighting one person on an about/leadership page (a director, a guild leader, a founder)
A "meet the director" callout where a single profile carries the section
Inside a custom layout where you place individual cards by hand rather than a generated grid

Page types

about
portfolio
dossier

How to use

Provide one member: displayName (required), plus avatarUrl, rank, and position — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this card to render a live Member record. This is the single-member primitive — to lay out many people in a generated grid use member-grid, which renders the same card shape from an array. One variant (default).

Pairs with

member-grid
division-card
org-chart

Follows

division-card

Precedes

member-grid

Avoid when

Showing a team or roster — use member-grid (array-driven) instead of hand-placing cards
You need the org hierarchy itself rather than individuals — use org-chart

application

`member-grid`

A responsive grid of member cards under an optional heading — the team/roster directory block. Renders the same card shape as member-card from a list, with column count and an item cap. Fully static — renders the authored members array; no @wabbit/tome-org peer required.

When to use

A "Meet the team" / "Our people" / "Leadership" section listing many members at once
A company or community directory page where you want every member tiled in a grid
Any directory of people you want generated from data rather than placed card by card

Page types

about
portfolio
dossier

How to use

Set a heading, pick columns (2, 3, or 4), and cap with maxItems. Supply the members array — it is the only data source today, not a static fallback. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this grid to render a live Member collection. This is the array/layout counterpart to member-card — same per-person card, generated in bulk. One variant (default).

Pairs with

member-card
division-card
org-chart
campaign-banner

Follows

division-card
org-chart

Precedes

event-calendar

Avoid when

Featuring a single person — use member-card
You want the reporting hierarchy rather than a flat people grid — use org-chart

application

`event-calendar`

An upcoming-events list under an optional heading — each row carries a title, start time, status (scheduled/live/completed/cancelled), and location. The array/section counterpart to event-list-item. Fully static — renders the authored events array; no @wabbit/tome-org peer required.

When to use

An "Upcoming events" / "What's on" section on an org, community, or company page
A schedule of workshops, meetups, or streams where each entry needs date and status
Any place you want the next N events generated from data with a single block

Page types

about
docs
dossier

How to use

Set a heading and cap with maxItems, then supply the events array (title required, plus startsAt ISO string, status, location) — it is the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this block to render the live Event collection. Use this for the full list; drop a single event-list-item into a sidebar or feed when you only need one row. One variant (default).

Pairs with

event-list-item
campaign-banner
member-grid

Follows

campaign-banner
member-grid

Precedes

document-link

Avoid when

You only need one event row in a sidebar or feed — use event-list-item
Promoting a single flagship campaign rather than a dated list — use campaign-banner

application

`event-list-item`

A single event row — title, start time, status, and an optional click-through — sized for feeds, sidebars, and inline placement. The single-item primitive behind event-calendar. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Surfacing one upcoming event in a sidebar, footer, or "next event" callout
Inline within editorial content where a full calendar would be too heavy
Hand-placing individual event rows rather than generating a list

Page types

about
docs
blog

How to use

Provide title (required) plus startsAt (ISO string), status, and an optional href — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this row to render a live Event record. This is the single-row counterpart to event-calendar — same row shape, one at a time. One variant (default).

Pairs with

event-calendar
member-card
document-link

Follows

event-calendar

Avoid when

Listing several upcoming events — use event-calendar (array-driven) instead of stacking rows
You need date, status, and location laid out as a section header — use event-calendar

application

`org-chart`

A simple three-level hierarchy display — a top-level unit, its teams, and their groups — the structure-of-the-org block, showing reporting lines rather than individual profiles. Fully static — renders the authored teams array; no @wabbit/tome-org peer required.

When to use

An "Org structure" / "How we are organized" section showing the levels from department down to working groups
Orienting a reader before they meet the people — the map that member-grid then fills in
A dossier page where the unit hierarchy itself is the information

Page types

about
docs
dossier

How to use

Set divisionName (required) and supply the teams array (each team carries its squads) — it is the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this chart to render live org-structure records. Use it once near the top of a structure page to frame the divisions and people that follow. One variant (default).

Pairs with

division-card
member-grid
member-card

Precedes

division-card
member-grid

Avoid when

Showing people rather than structure — use member-grid or member-card
Summarizing one unit with its leader and headcount — use division-card

application

`document-link`

A linked document card — title, category label (SOP, Policy, Handbook), and last-updated timestamp pointing at a document URL. The resource/reference primitive for an org. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

A "Resources" / "Documents" / "Policies" section linking out to SOPs, handbooks, or forms
A knowledge-base or onboarding page where members find the canonical documents
Anywhere you want a clean, dated link card instead of a bare hyperlink

Page types

docs
about
dossier

How to use

Provide title (required) and href (required) plus category and updatedAt (ISO string) — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this card to render a live Document record. Stack several to form a resource list, often under a division-card or near an org-chart on a structure/docs page. One variant (default).

Pairs with

division-card
org-chart
event-calendar

Follows

division-card
org-chart

Avoid when

Linking to an event rather than a document — use event-list-item
You want rich body content inline rather than a link out — use a richText/content block

application

`campaign-banner`

A full-width campaign hero — campaign name, tagline, full-bleed banner image, objective count, and a CTA. The promotional top-of-page block for an org campaign or initiative. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Topping a campaign or initiative page with a cinematic banner and a single call to action
Announcing an active campaign on a community/org home or landing section
Driving members toward a campaign detail view or sign-up via the CTA

Page types

about
portfolio
dossier

How to use

Set codename (the campaign's display name, required) plus tagline, bannerUrl, objectiveCount, and the ctaLabel/ctaUrl pair — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this banner to render a live Campaign record. Place it at the very top of the page as the hero, with the objective list, member-grid, or event-calendar following beneath. One variant (default).

Pairs with

event-calendar
member-grid
org-chart

Precedes

event-calendar
member-grid

Avoid when

You need a generic marketing hero outside the org-campaign context — use a marketing hero block
Listing dated events rather than promoting one campaign — use event-calendar

application

Exports

@wabbit/tome-blocks-org-pack
@wabbit/tome-blocks-org-pack/render
@wabbit/tome-blocks-org-pack/render/register
@wabbit/tome-blocks-org-pack/demo
@wabbit/tome-blocks-org-pack/meta

Changelog

v0.6.4patch

775f90a: Published packages now contain compiled JavaScript and type declarations under a one-line licence banner, and no longer include source maps. What you install: one compiled `.js` (ESM) and `.cjs` (CommonJS) file per source module, its `.d.ts` / `.d.cts` declarations, and the stylesheets, fonts and other assets a package already shipped. Every JavaScript module opens with a comment naming the package and its licence: `/*! @wabbit/<package> — © Wabbit, LLC. Wabbit Tome Commercial License (see LICENSE.md). Not for redistribution. */`. The `.map` files and the `sourceMappingURL` comments that pointed at them are gone, which roughly halves the size of each tarball. Debugging: the code is still unbundled and unminified, one readable file per module, so a stack trace points at real code with real names. Line numbers in a stack trace are one higher than before, because of the banner line. A `'use client'` directive stays the first statement of its module (the banner is a comment above it), so React Server Component boundaries are unchanged. No API change, no runtime behaviour change, and nothing to do on upgrade. In `@wabbit/tome-blocks-gallery`, the source snapshots `extractGallerySource` writes from an installed pack leave out the licence banner line, so a component or config snapshot starts at the code and a paid block's preview shows its first 15 lines of real code.

775f90a: Published packages now contain compiled JavaScript and type declarations under a one-line licence banner, and no longer include source maps. What you install: one compiled `.js` (ESM) and `.cjs` (CommonJS) file per source module, its `.d.ts` / `.d.cts` declarations, and the stylesheets, fonts and other assets a package already shipped. Every JavaScript module opens with a comment naming the package and its licence: `/*! @wabbit/<package> — © Wabbit, LLC. Wabbit Tome Commercial License (see LICENSE.md). Not for redistribution. */`. The `.map` files and the `sourceMappingURL` comments that pointed at them are gone, which roughly halves the size of each tarball. Debugging: the code is still unbundled and unminified, one readable file per module, so a stack trace points at real code with real names. Line numbers in a stack trace are one higher than before, because of the banner line. A `'use client'` directive stays the first statement of its module (the banner is a comment above it), so React Server Component boundaries are unchanged. No API change, no runtime behaviour change, and nothing to do on upgrade. In `@wabbit/tome-blocks-gallery`, the source snapshots `extractGallerySource` writes from an installed pack leave out the licence banner line, so a component or config snapshot starts at the code and a paid block's preview shows its first 15 lines of real code.

v0.6.3patch

5884e65: The event-list-item block now fits a 320px phone screen: the date moves above the title and the title track can shrink. The fixed date track no longer competes with the status chip at phone width.

5884e65: The event-list-item block now fits a 320px phone screen: the date moves above the title and the title track can shrink. The fixed date track no longer competes with the status chip at phone width.

v0.6.2patch

483e0a1: The organization pack's event calendar preview now uses a fictional venue name. The event calendar preview locations name an invented headquarters. Block fields and variants are unchanged.

483e0a1: The organization pack's event calendar preview now uses a fictional venue name. The event calendar preview locations name an invented headquarters. Block fields and variants are unchanged.
d08fc38: The event calendar block no longer overflows a phone-width screen; each event's date moves to its own row. The fixed date column is kept from 768px up. Below that, the date sits above the title and status, and long titles wrap.

v0.6.1patch

c14a133: The pack works on a stock Next.js site: its per-block stylesheets now ship precompiled, so the site needs no next.config plugin. Each renderer's `.tome-css` stylesheet is compiled when the pack is built, into a JS module next to it (`<Name>.tome-css.js` / `.cjs`), and the renderers import that. A site no longer has to wrap next.config with `withTomeBlockStyles` to use the pack, and `./render` and `./render/register` now load under plain Node, so seed scripts, tests and the Payload CLI can import them. Each block's CSS is still inlined only on pages that render the block. A site that already uses `withTomeBlockStyles` needs no change. Scoped class names change once, because they are now keyed on the package rather than on where it is installed. The raw `.tome-css` files stay in the package as readable source.

c14a133: The pack works on a stock Next.js site: its per-block stylesheets now ship precompiled, so the site needs no next.config plugin. Each renderer's `.tome-css` stylesheet is compiled when the pack is built, into a JS module next to it (`<Name>.tome-css.js` / `.cjs`), and the renderers import that. A site no longer has to wrap next.config with `withTomeBlockStyles` to use the pack, and `./render` and `./render/register` now load under plain Node, so seed scripts, tests and the Payload CLI can import them. Each block's CSS is still inlined only on pages that render the block. A site that already uses `withTomeBlockStyles` needs no change. Scoped class names change once, because they are now keyed on the package rather than on where it is installed. The raw `.tome-css` files stay in the package as readable source.

v0.6.0minor

**Breaking: block stylesheets are now per-block (`.tome-css`).** Each block's CSS ships only on pages that render it, instead of in every page's CSS bundle. The 8 stylesheets moved from `X.module.css` to `X.tome-css`, and each renderer renders `<BlockStyles sheet={styles} />` from `@wabbit/tome-blocks-core/block-styles`. **Required in the consuming site:** wrap next.config with `withTomeBlockStyles` (`@wabbit/tome-blocks-core/next`, blocks-core 0.22.0 or later); without it the `.tome-css` imports fail to build. See the blocks-core README, "Per-block stylesheets". - The `@wabbit/tome-blocks-core` peer range is now `>=0.22.0 <1.0.0`. - No client renderers. Exported names and props are unchanged. - Block CSS now loads after all bundled CSS. A site-level rule that overrode one of this pack's classes at equal specificity, and won only by loading later, no longer wins.

**Breaking: block stylesheets are now per-block (`.tome-css`).** Each block's CSS ships only on pages that render it, instead of in every page's CSS bundle. The 8 stylesheets moved from `X.module.css` to `X.tome-css`, and each renderer renders `<BlockStyles sheet={styles} />` from `@wabbit/tome-blocks-core/block-styles`. **Required in the consuming site:** wrap next.config with `withTomeBlockStyles` (`@wabbit/tome-blocks-core/next`, blocks-core 0.22.0 or later); without it the `.tome-css` imports fail to build. See the blocks-core README, "Per-block stylesheets". - The `@wabbit/tome-blocks-core` peer range is now `>=0.22.0 <1.0.0`. - No client renderers. Exported names and props are unchanged. - Block CSS now loads after all bundled CSS. A site-level rule that overrode one of this pack's classes at equal specificity, and won only by loading later, no longer wins.

v0.5.6patch

30a0060: Three display-family headings now read the `--tome-type-weight-display` token instead of a hard-coded weight. `@wabbit/tome-blocks-org-pack`: the `member-grid` block's heading and member-name headings now read the `--tome-type-weight-display` token (falling back to their existing 600 weight when a theme leaves it unset), so a theme that serves its display face at a lighter weight is no longer browser-faked bold. `@wabbit/tome-blocks-lms-pack`: the `course-card` block's title heading gets the same `--tome-type-weight-display` token treatment. `@wabbit/tome-blocks-catalog-pack`: the `featured-product` block's title heading gets the same `--tome-type-weight-display` token treatment.

30a0060: Three display-family headings now read the `--tome-type-weight-display` token instead of a hard-coded weight. `@wabbit/tome-blocks-org-pack`: the `member-grid` block's heading and member-name headings now read the `--tome-type-weight-display` token (falling back to their existing 600 weight when a theme leaves it unset), so a theme that serves its display face at a lighter weight is no longer browser-faked bold. `@wabbit/tome-blocks-lms-pack`: the `course-card` block's title heading gets the same `--tome-type-weight-display` token treatment. `@wabbit/tome-blocks-catalog-pack`: the `featured-product` block's title heading gets the same `--tome-type-weight-display` token treatment.

v0.5.5patch

9ac8d3d: Seven org blocks now render their muted panels and heading sizes instead of falling back to nothing. Affected: campaign banner, document link, event calendar, event list, member card, member grid and org chart. They read `--tome-color-muted`, `--tome-text-xl`, `--tome-text-2xl` and `--tome-text-base` without a fallback, and no package declares those names. They now read `--tome-color-surface-muted`, `--tome-type-size-xl`, `--tome-type-size-2xl` and `--tome-text-body`.

9ac8d3d: Seven org blocks now render their muted panels and heading sizes instead of falling back to nothing. Affected: campaign banner, document link, event calendar, event list, member card, member grid and org chart. They read `--tome-color-muted`, `--tome-text-xl`, `--tome-text-2xl` and `--tome-text-base` without a fallback, and no package declares those names. They now read `--tome-color-surface-muted`, `--tome-type-size-xl`, `--tome-type-size-2xl` and `--tome-text-body`.

v0.5.4

v0.5.3patch

6530765: CSS files are now copied to `dist/` by a post-build script instead of a tsup `onSuccess` hook; no behaviour change, and the published `dist/` is identical.

6530765: CSS files are now copied to `dist/` by a post-build script instead of a tsup `onSuccess` hook; no behaviour change, and the published `dist/` is identical.

v0.5.2patch

2d8409e: Drops the no-op `peerDependenciesMeta` entry for `@wabbit/tome-org`, which was never a declared peer and is never imported.

2d8409e: Drops the no-op `peerDependenciesMeta` entry for `@wabbit/tome-org`, which was never a declared peer and is never imported.

v0.5.1patch

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.5.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.4.5patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.4patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.3patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.2patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.1patch

c1f3830: Demo imagery now resolves without a network. Every org-pack image field is a plain-text URL (no Payload upload), and the demos pointed at `https://cdn.wabbit.example/…`, a domain that does not exist — so member-card, member-grid, division-card and campaign-banner rendered broken-image glyphs in any gallery preview or thumbnail capture. New `demo-media.ts` emits a self-contained SVG data URI per subject (neutral tonal field + initials; no brand colour), and `DemoContext` gains `placeholderImageUrl` so a host can substitute real imagery. Found while registering Org Blocks on wabbit.com/blocks (2026-09-05).

c1f3830: Demo imagery now resolves without a network. Every org-pack image field is a plain-text URL (no Payload upload), and the demos pointed at `https://cdn.wabbit.example/…`, a domain that does not exist — so member-card, member-grid, division-card and campaign-banner rendered broken-image glyphs in any gallery preview or thumbnail capture. New `demo-media.ts` emits a self-contained SVG data URI per subject (neutral tonal field + initials; no brand colour), and `DemoContext` gains `placeholderImageUrl` so a host can substitute real imagery. Found while registering Org Blocks on wabbit.com/blocks (2026-09-05).
Updated dependencies - @wabbit/tome-blocks-core@0.16.0

v0.4.0minor

b01ca1f: Raise the `react` / `react-dom` peer floor to `>=19.0.0` (ruled 2026-09-01). The platform declared React peers in five different shapes — `>=18.0.0`, `>=18`, `^18 || ^19`, `^18.3.0 || ^19.0.0`, `^19.0.0` — while its kernel (`@wabbit/tome-core`) and five app-layer packages already required `>=19`. Any package advertising React 18 was advertising a configuration that could not be installed alongside the kernel, so the split was never a supported matrix; it was drift. One shape now, and it is the honest one. These nine version independently of the `linked` blocks family (which gets its own coordinated bump), so they are listed here: - `@wabbit/tome-admin`, `@wabbit/tome-admin-pro` — from `^18.3.0 || ^19.0.0` - `@wabbit/tome-blocks-gallery` — from `^18 || ^19`; devDeps `react`/`@types/react` `^18.0.0` → `^19.0.0` - `@wabbit/tome-blocks-org-pack` — from `>=18.0.0`; same devDep correction - `@wabbit/tome-engine`, `@wabbit/tome-motion`, `@wabbit/tome-rpg`, `@wabbit/tome-webgl` — from `>=18` - `@wabbit/tome-ui` — from `>=18.0.0` The `^18` devDependency pins on the two block-shaped packages were already fiction: the root `pnpm.overrides` pins `@types/react` to `19.2.14`, so both have been building against React 19 types regardless. Correcting them changes the manifest, not the resolved tree. Consumer impact: a React 18 consumer can no longer install these. That install was already impossible with the kernel in the graph.

b01ca1f: Raise the `react` / `react-dom` peer floor to `>=19.0.0` (ruled 2026-09-01). The platform declared React peers in five different shapes — `>=18.0.0`, `>=18`, `^18 || ^19`, `^18.3.0 || ^19.0.0`, `^19.0.0` — while its kernel (`@wabbit/tome-core`) and five app-layer packages already required `>=19`. Any package advertising React 18 was advertising a configuration that could not be installed alongside the kernel, so the split was never a supported matrix; it was drift. One shape now, and it is the honest one. These nine version independently of the `linked` blocks family (which gets its own coordinated bump), so they are listed here: - `@wabbit/tome-admin`, `@wabbit/tome-admin-pro` — from `^18.3.0 || ^19.0.0` - `@wabbit/tome-blocks-gallery` — from `^18 || ^19`; devDeps `react`/`@types/react` `^18.0.0` → `^19.0.0` - `@wabbit/tome-blocks-org-pack` — from `>=18.0.0`; same devDep correction - `@wabbit/tome-engine`, `@wabbit/tome-motion`, `@wabbit/tome-rpg`, `@wabbit/tome-webgl` — from `>=18` - `@wabbit/tome-ui` — from `>=18.0.0` The `^18` devDependency pins on the two block-shaped packages were already fiction: the root `pnpm.overrides` pins `@types/react` to `19.2.14`, so both have been building against React 19 types regardless. Correcting them changes the manifest, not the resolved tree. Consumer impact: a React 18 consumer can no longer install these. That install was already impossible with the kernel in the graph.
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.
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.3.17patch