@pilotiq/tiptap 3.15.0 → 3.16.0

package/CHANGELOG.md

@@ -1,5 +1,26 @@
 # @pilotiq/tiptap
 
+## 3.16.0
+
+### Minor Changes
+
+- 58e9461: Export the default content-block node specs (`contentBlockNodes`, plus `Faq` / `FaqItem` / `FaqQuestion` / `FaqAnswer` / `Alert` / `AlertTitle` / `AlertBody` / `Summary` / `KeyTakeaways` / `ProsCons` / `ProsColumn` / `ConsColumn` / `ContentBlockKeymap` and the `AlertType` helpers) from the package entry. `contentBlockNodes` is the exact array `TiptapEditor` registers, so consumers can build a headless editor whose schema matches the live one — e.g. to parse content-block HTML or drive the surgical-op planners (`planInsertBlockBefore` & co.) in a test — without mounting React. Additive; no behavior change.
+
+## 3.15.1
+
+### Patch Changes
+
+- 2bc1e54: Slash menu now ranks results by relevance instead of definition order.
+
+  A query that matches an entry's **label** (exactly, by prefix, or by word) now
+  ranks above an entry that only mentions the word in its `searchKey`. Previously
+  the menu was a plain substring filter that preserved definition order, so typing
+  `/summary` surfaced **Collapsible block** first — its `searchKey` lists
+  "summary" and it's defined before the Summary block — and pressing Enter
+  inserted the wrong block. The matched set is unchanged (every entry that matched
+  before still matches); only the ordering improves. Ties keep their original menu
+  order.
+
 ## 3.15.0
 
 ### Minor Changes

package/dist/extensions/SlashCommandExtension.js

@@ -298,7 +298,46 @@ export function buildSlashItems(blocks, mergeTags, query, insert) {
     if (!query)
         return all;
     const needle = query.toLowerCase();
-    return all.filter((item) => `${item.label} ${item.searchKey} ${item.group ?? ''}`.toLowerCase().includes(needle));
+    // Membership is unchanged from a plain substring match (an item shows iff the
+    // query appears anywhere in its label / searchKey / group). On top of that we
+    // RANK by relevance so a query that hits an item's LABEL beats one that only
+    // mentions the word in some other item's searchKey — otherwise "/summary"
+    // surfaces "Collapsible block" first (its searchKey lists "summary") instead
+    // of the Summary block. Stable: equal scores keep their original menu order.
+    return all
+        .map((item, i) => ({ item, i, score: slashRelevance(item, needle) }))
+        .filter((m) => m.score > 0)
+        .sort((a, b) => b.score - a.score || a.i - b.i)
+        .map((m) => m.item);
+}
+/**
+ * Score a slash item against the lowercased query. Higher = more relevant.
+ * Returns 0 when nothing matches (the item is filtered out). The tiers mirror
+ * how people expect a command palette to rank: an exact/prefix LABEL hit wins,
+ * then any label word, then label substring, then searchKey words, then a bare
+ * searchKey/group substring. `needle` is assumed already lowercased.
+ */
+function slashRelevance(item, needle) {
+    const label = item.label.toLowerCase();
+    const labelWords = label.split(/\s+/).filter(Boolean);
+    if (label === needle)
+        return 7;
+    if (label.startsWith(needle))
+        return 6;
+    if (labelWords.some((w) => w.startsWith(needle)))
+        return 5;
+    if (label.includes(needle))
+        return 4;
+    const searchWords = item.searchKey.toLowerCase().split(/\s+/).filter(Boolean);
+    if (searchWords.some((w) => w === needle))
+        return 3;
+    if (searchWords.some((w) => w.startsWith(needle)))
+        return 2;
+    // Matched only via a searchKey / group substring (no word boundary) — still
+    // shown, but ranked below every label and word-boundary hit.
+    if (`${item.searchKey} ${item.group ?? ''}`.toLowerCase().includes(needle))
+        return 1;
+    return 0;
 }
 function defaultsFromSchema(block) {
     const out = {};

package/dist/index.d.ts

@@ -11,4 +11,5 @@ export { useAiSuggestionBridge } from './react/useAiSuggestionBridge.js';
 export { AiInlineDiffExtension, aiInlineDiffPluginKey, getAiInlineDiffState, type AiInlineDiffExtensionOptions, } from './extensions/AiInlineDiffExtension.js';
 export { planReplaceBlock, planInsertBlockBefore, planDeleteBlock, planUpdateBlockMark, summarizeBlockStructure, type BlockMarkRange, type TransactionModifier, } from './surgicalOps.js';
 export { renderRichTextToHtml, isRichTextValue, type RenderRichTextOptions, type TiptapNode, type TiptapMark, } from './render.js';
+export { contentBlockNodes, Faq, FaqItem, FaqQuestion, FaqAnswer, Alert, AlertTitle, AlertBody, Summary, KeyTakeaways, ProsCons, ProsColumn, ConsColumn, ContentBlockKeymap, ALERT_VARIANTS, ALERT_VARIANT_LABEL, coerceAlertType, type AlertType, } from './extensions/contentBlocks.js';
 //# sourceMappingURL=index.d.ts.map

package/dist/index.js

@@ -11,3 +11,9 @@ export { useAiSuggestionBridge } from './react/useAiSuggestionBridge.js';
 export { AiInlineDiffExtension, aiInlineDiffPluginKey, getAiInlineDiffState, } from './extensions/AiInlineDiffExtension.js';
 export { planReplaceBlock, planInsertBlockBefore, planDeleteBlock, planUpdateBlockMark, summarizeBlockStructure, } from './surgicalOps.js';
 export { renderRichTextToHtml, isRichTextValue, } from './render.js';
+// Default content-block node specs (FAQ / Alert / Summary / Key takeaways /
+// Pros & cons). `contentBlockNodes` is the exact array `TiptapEditor` registers,
+// so a consumer can build a headless editor whose schema matches the live
+// editor — e.g. to parse the content-block HTML or drive the surgical-op
+// planners (`planInsertBlockBefore` & co.) in a test, without mounting React.
+export { contentBlockNodes, Faq, FaqItem, FaqQuestion, FaqAnswer, Alert, AlertTitle, AlertBody, Summary, KeyTakeaways, ProsCons, ProsColumn, ConsColumn, ContentBlockKeymap, ALERT_VARIANTS, ALERT_VARIANT_LABEL, coerceAlertType, } from './extensions/contentBlocks.js';

package/dist/react/BlockGearShell.d.ts

@@ -0,0 +1,37 @@
+import { type ReactNode, type ReactElement } from 'react';
+import { type NodeViewProps } from '@tiptap/react';
+import { type BlockSetting } from './BlockSettingsMenu.js';
+/**
+ * Shared chrome for the width-aware content blocks (labelled blocks + Pros &
+ * cons). Every one of them renders the same two-layer shell — a full-width
+ * outer anchor (`cssClass`, stable so the gear doesn't jump on a width toggle)
+ * hosting the in-block **gear menu**, with the block's own content as
+ * `children`. This component owns the parts that are byte-identical across
+ * those blocks so they can't drift:
+ *
+ *  - read the `width` attr → `data-width`,
+ *  - build the **Width** setting (contained / full) for the gear,
+ *  - render the `NodeViewWrapper` + the hover-revealed `BlockSettingsMenu`
+ *    (editor-only), deriving the hover selector from `cssClass`.
+ *
+ * The caller supplies only what actually varies: the anchor `cssClass`, the
+ * gear's accessible `settingsLabel`, the inner content, and (optionally) any
+ * block-specific settings to show alongside Width.
+ *
+ * `data-type` always mirrors the node's own type name — every block that uses
+ * this shell wants exactly that.
+ */
+export interface BlockGearShellProps {
+    node: NodeViewProps['node'];
+    editor: NodeViewProps['editor'];
+    updateAttributes: NodeViewProps['updateAttributes'];
+    /** Outer anchor class — also drives the gear's hover-reveal selector. */
+    cssClass: string;
+    /** Accessible label for the gear trigger, e.g. `"Summary settings"`. */
+    settingsLabel: string;
+    /** Block-specific settings shown after Width (none today; future-proofing). */
+    extraSettings?: BlockSetting[];
+    children: ReactNode;
+}
+export declare function BlockGearShell({ node, editor, updateAttributes, cssClass, settingsLabel, extraSettings, children, }: BlockGearShellProps): ReactElement;
+//# sourceMappingURL=BlockGearShell.d.ts.map

package/dist/react/BlockGearShell.js

@@ -0,0 +1,21 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { NodeViewWrapper } from '@tiptap/react';
+import { BlockSettingsMenu } from './BlockSettingsMenu.js';
+export function BlockGearShell({ node, editor, updateAttributes, cssClass, settingsLabel, extraSettings, children, }) {
+    const width = node.attrs['width'] === 'full' ? 'full' : 'contained';
+    const settings = [
+        {
+            kind: 'select',
+            key: 'width',
+            label: 'Width',
+            value: width,
+            options: [
+                { value: 'contained', label: 'Contained' },
+                { value: 'full', label: 'Full width' },
+            ],
+            onChange: (w) => updateAttributes({ width: w }),
+        },
+        ...(extraSettings ?? []),
+    ];
+    return (_jsxs(NodeViewWrapper, { "data-type": node.type.name, "data-width": width, className: cssClass + ' relative', children: [editor.isEditable && (_jsx(BlockSettingsMenu, { settings: settings, label: settingsLabel, hoverClass: '[.' + cssClass + ':hover_&]:opacity-100' })), children] }));
+}

package/dist/react/LabeledBlockNodeView.d.ts

@@ -7,12 +7,10 @@ import { type NodeViewProps } from '@tiptap/react';
  * bespoke component each; the per-block `label` + `cssClass` ride the node's
  * `addOptions()` (see `labeledBlock()` in `extensions/contentBlocks.ts`).
  *
- * Mirrors the FAQ/Alert layout: a full-width outer anchor (`cssClass`, stays
- * put so the gear doesn't move on a width toggle) wrapping an inner
- * `.pilotiq-block-content` that carries the max-width / centering. The only
- * setting today is **Width** (contained vs full) via the in-block gear menu;
- * the `width` attr drives `data-width`, which the consumer's CSS reads (shared
- * with the read-side `render.ts`).
+ * The two-layer shell (full-width anchor + gear + the inner
+ * `.pilotiq-block-content` that carries the max-width / centering) lives in the
+ * shared `BlockGearShell`, alongside the Width gear setting. This component
+ * only supplies the label + body content hole.
  */
 export declare function LabeledBlockNodeView({ node, updateAttributes, editor, extension }: NodeViewProps): ReactElement;
 //# sourceMappingURL=LabeledBlockNodeView.d.ts.map

package/dist/react/LabeledBlockNodeView.js

@@ -1,6 +1,6 @@
 import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
-import { NodeViewWrapper, NodeViewContent } from '@tiptap/react';
-import { BlockSettingsMenu } from './BlockSettingsMenu.js';
+import { NodeViewContent } from '@tiptap/react';
+import { BlockGearShell } from './BlockGearShell.js';
 /**
  * Shared React NodeView for the simple **labelled** content blocks — the ones
  * that are just a non-editable label above a `block+` body (Key takeaways,
@@ -8,28 +8,12 @@ import { BlockSettingsMenu } from './BlockSettingsMenu.js';
  * bespoke component each; the per-block `label` + `cssClass` ride the node's
  * `addOptions()` (see `labeledBlock()` in `extensions/contentBlocks.ts`).
  *
- * Mirrors the FAQ/Alert layout: a full-width outer anchor (`cssClass`, stays
- * put so the gear doesn't move on a width toggle) wrapping an inner
- * `.pilotiq-block-content` that carries the max-width / centering. The only
- * setting today is **Width** (contained vs full) via the in-block gear menu;
- * the `width` attr drives `data-width`, which the consumer's CSS reads (shared
- * with the read-side `render.ts`).
+ * The two-layer shell (full-width anchor + gear + the inner
+ * `.pilotiq-block-content` that carries the max-width / centering) lives in the
+ * shared `BlockGearShell`, alongside the Width gear setting. This component
+ * only supplies the label + body content hole.
  */
 export function LabeledBlockNodeView({ node, updateAttributes, editor, extension }) {
     const { label, cssClass } = extension.options;
-    const width = node.attrs['width'] === 'full' ? 'full' : 'contained';
-    const settings = [
-        {
-            kind: 'select',
-            key: 'width',
-            label: 'Width',
-            value: width,
-            options: [
-                { value: 'contained', label: 'Contained' },
-                { value: 'full', label: 'Full width' },
-            ],
-            onChange: (w) => updateAttributes({ width: w }),
-        },
-    ];
-    return (_jsxs(NodeViewWrapper, { "data-type": node.type.name, "data-width": width, className: cssClass + ' relative', children: [editor.isEditable && (_jsx(BlockSettingsMenu, { settings: settings, label: label + ' settings', hoverClass: '[.' + cssClass + ':hover_&]:opacity-100' })), _jsxs("div", { className: "pilotiq-block-content", children: [_jsx("div", { className: "pilotiq-block-label", contentEditable: false, children: label }), _jsx(NodeViewContent, { className: "pilotiq-block-body" })] })] }));
+    return (_jsx(BlockGearShell, { node: node, editor: editor, updateAttributes: updateAttributes, cssClass: cssClass, settingsLabel: label + ' settings', children: _jsxs("div", { className: "pilotiq-block-content", children: [_jsx("div", { className: "pilotiq-block-label", contentEditable: false, children: label }), _jsx(NodeViewContent, { className: "pilotiq-block-body" })] }) }));
 }

package/dist/react/ProsConsNodeView.d.ts

@@ -4,11 +4,10 @@ import { type NodeViewProps } from '@tiptap/react';
  * React NodeView for the `prosCons` container — hosts the in-block **gear menu**
  * (Width) at the top-end corner. The two `prosColumn` / `consColumn` children
  * keep their plain `renderHTML` (label + body); only the container needs React,
- * for the gear. Two layers like FAQ/Alert: a full-width outer anchor
- * (`.pilotiq-pros-cons`, stable so the gear doesn't move on a width toggle)
- * wrapping the inner `.pilotiq-pros-cons-content`, which carries the two-column
- * grid + max-width / centering. The `width` attr drives `data-width` (read by
- * the consumer CSS, shared with the read-side renderer).
+ * for the gear. The two-layer shell (full-width anchor + gear) lives in the
+ * shared `BlockGearShell`; this component only supplies the inner
+ * `.pilotiq-pros-cons-content`, which carries the two-column grid + max-width /
+ * centering.
  */
 export declare function ProsConsNodeView({ node, updateAttributes, editor }: NodeViewProps): ReactElement;
 //# sourceMappingURL=ProsConsNodeView.d.ts.map

package/dist/react/ProsConsNodeView.js

@@ -1,30 +1,15 @@
-import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
-import { NodeViewWrapper, NodeViewContent } from '@tiptap/react';
-import { BlockSettingsMenu } from './BlockSettingsMenu.js';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { NodeViewContent } from '@tiptap/react';
+import { BlockGearShell } from './BlockGearShell.js';
 /**
  * React NodeView for the `prosCons` container — hosts the in-block **gear menu**
  * (Width) at the top-end corner. The two `prosColumn` / `consColumn` children
  * keep their plain `renderHTML` (label + body); only the container needs React,
- * for the gear. Two layers like FAQ/Alert: a full-width outer anchor
- * (`.pilotiq-pros-cons`, stable so the gear doesn't move on a width toggle)
- * wrapping the inner `.pilotiq-pros-cons-content`, which carries the two-column
- * grid + max-width / centering. The `width` attr drives `data-width` (read by
- * the consumer CSS, shared with the read-side renderer).
+ * for the gear. The two-layer shell (full-width anchor + gear) lives in the
+ * shared `BlockGearShell`; this component only supplies the inner
+ * `.pilotiq-pros-cons-content`, which carries the two-column grid + max-width /
+ * centering.
  */
 export function ProsConsNodeView({ node, updateAttributes, editor }) {
-    const width = node.attrs['width'] === 'full' ? 'full' : 'contained';
-    const settings = [
-        {
-            kind: 'select',
-            key: 'width',
-            label: 'Width',
-            value: width,
-            options: [
-                { value: 'contained', label: 'Contained' },
-                { value: 'full', label: 'Full width' },
-            ],
-            onChange: (w) => updateAttributes({ width: w }),
-        },
-    ];
-    return (_jsxs(NodeViewWrapper, { "data-type": "prosCons", "data-width": width, className: "pilotiq-pros-cons relative", children: [editor.isEditable && (_jsx(BlockSettingsMenu, { settings: settings, label: "Pros & cons settings", hoverClass: "[.pilotiq-pros-cons:hover_&]:opacity-100" })), _jsx(NodeViewContent, { className: "pilotiq-pros-cons-content" })] }));
+    return (_jsx(BlockGearShell, { node: node, editor: editor, updateAttributes: updateAttributes, cssClass: "pilotiq-pros-cons", settingsLabel: "Pros & cons settings", children: _jsx(NodeViewContent, { className: "pilotiq-pros-cons-content" }) }));
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pilotiq/tiptap",
-  "version": "3.15.0",
+  "version": "3.16.0",
   "description": "Tiptap rich-text editor adapter for @pilotiq/pilotiq — slash menu, draggable blocks, custom-block API",
   "license": "MIT",
   "repository": {