Fix saving a TipTap rich text that ends with a list

[SebiVPS]

Problem

Since 10.8.0 (#6382), a TipTap rich text that ends with a list got an empty bulletList appended by the editor. A list without items is invalid, so the API rejected the content on save with "Validation failed". Deleting the list did not help: the empty list stayed in the content, rendered as an empty <ul></ul>, and editors could not see, select or remove it until they reloaded. Selecting all content and deleting it was affected too. It produced a bulletList with a listItem and a text block instead of one empty text block, and in a block that only allows headings it produced a horizontalRule.

ProseMirror needs a default block type in some places, and no setting defines it: it is the first node of the block group in schema order (schema.topNodeType.contentMatch.defaultType). TipTap's TrailingNode inserts it after content that ends with a list or a child block, and ProseMirror's createAndFill fills an emptied document with it. The schema order follows the extensions' priority. TipTap's Paragraph has priority 1000, so the paragraph used to be the default block type. #6382 replaced the paragraph and heading nodes with the textBlock node, which had no priority and is registered after StarterKit's lists, so bulletList became the default block type.

Solution

textBlock now has priority: 1000 in the Admin and in the API (the API schema must match the Admin schema). This restores what #6382 removed: textBlock takes the paragraph's place in the schema, so every place that uses the default block type gets a text block again, not only TrailingNode. The editor adds an empty text block after a trailing list, as it did before 10.8.0. Other approaches only fix part of the problem:

• Setting the node option of TrailingNode to textBlock fixes TrailingNode only. An emptied document would still become a list.
• Without TrailingNode, nothing follows a child block at the end of the content, so editors could not type after it.
• Removing empty lists in the API hides the symptom. The editor would still create invalid content.
• Registering textBlock before StarterKit gives the same schema order, but only as long as nobody changes the order of the extensions. priority is TipTap's way to define it, with the same value as TipTap's Paragraph.

With maxTextBlocks, this empty text block must not be added when the content is already at the limit. Otherwise a list as the last allowed block is followed by a block over the limit, and the API rejects the content. 10.8.0 had the same problem for ordered lists. It only avoided it for bullet lists by accident, because TrailingNode never adds a block after its own default type. The maxTextBlocks extension now sets TipTap's skipTrailingNodeMeta on transactions that leave the content at or over the limit. A filter that rejects these transactions would also reject pastes over the limit instead of cutting them off.

@tiptap/extensions exports skipTrailingNodeMeta, so it is now a direct dependency of @dextinity/cms-admin. StarterKit already depends on it.

The "List Text Block Styles" story clicked the editor to put the caret at the end of the list item. With the empty text block after the list, that click lands below the list, so the story now clicks the list item text.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Fixes rich text editor behavior when content ends with a list.

The PR appears safe to merge; no new actionable issue was established.

Summary

The PR restores textBlock as TipTap’s default block type in the Admin and API, so a rich text ending in a list no longer gains an invalid empty list.

• It suppresses the trailing text block when adding one would exceed maxTextBlocks.
• It updates tests, story interactions, and the package dependency used by that suppression.

_{Reviews (2) · Last reviewed commit: "cms-admin: Don't add the trailing empty ..." · Reviewed by Greptile}

[VPS-Obi]

@SebiVPS please resolve conflicts.