Only include used blocks in block-meta.json - #6340
Conversation
Blocks are registered as a side effect of createBlock. Blocks a library creates on import, such as the deprecated SpaceBlock, therefore ended up in the application's block-meta.json even when the application doesn't use them. Besides generating types for unused blocks, this breaks the generated types when an application defines a block with the same name: the demo's own Space block and the library's Space block were both written to block-meta.json, so the generated SpaceBlockData interfaces merged into one containing the fields of both blocks. Determine the used blocks from the application instead: all root blocks discovered from the entities and, recursively, all blocks they reference. Blocks that reference other blocks without exposing them in their block meta - the link block embedded in rich text content - declare them in the new optional referencedBlocks property of Block. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NN1pwjLehGbk1ChEtWmvqu
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (9)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe API now generates block metadata from discovered root blocks and their recursively referenced blocks. It adds explicit block references, updates rich-text blocks, changes metadata generation inputs, adds traversal tests, and removes unused demo metadata. ChangesUsed block metadata
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant NestLifecycle
participant BlocksMetaService
participant DiscoverService
participant getUsedBlocks
participant getBlocksMeta
NestLifecycle->>BlocksMetaService: onModuleInit()
BlocksMetaService->>DiscoverService: discoverRootBlocks()
DiscoverService-->>BlocksMetaService: root blocks
BlocksMetaService->>getUsedBlocks: collect used blocks
getUsedBlocks-->>BlocksMetaService: deduplicated blocks
BlocksMetaService->>getBlocksMeta: generate metadata
Merge Risk: ⚪ Minimal · up to Metadata generation now includes only discovered and referenced blocks, with coverage for nested dependencies and unused-block exclusion. No actionable merge-blocking risk is evidenced. Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error, 1 warning)
✅ Passed checks (2 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 7 files. (1 skipped: 1 unsupported.) Full details: Requires Human ReviewExplanation The PR changes the public API. It adds
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@greptileai review. |
Greptile SummaryThis PR limits generated block metadata to root blocks discovered from annotated entities and their recursively referenced dependencies.
|
| Filename | Overview |
|---|---|
| packages/api/cms-api/src/blocks/blocks-meta.service.ts | Generates metadata from discovered root blocks and their dependency closure rather than every globally registered block. |
| packages/api/cms-api/src/blocks/used-blocks.ts | Recursively traverses all block-bearing metadata kinds and explicit references while preventing repeated object traversal. |
| packages/api/cms-api/src/blocks/block.ts | Extends the public Block shape with optional explicit references for dependencies not represented in metadata. |
| packages/api/cms-api/src/blocks/blocks-meta.ts | Allows callers to provide a filtered block collection while preserving the registered-block fallback. |
| packages/api/cms-api/src/blocks/factories/createRichTextBlock.ts | Declares the embedded link block as an explicit dependency. |
| packages/api/cms-api/src/blocks/tipTap/createTipTapRichTextBlock.ts | Declares the optional link block as an explicit dependency while child blocks remain discoverable through metadata. |
| packages/api/cms-api/src/blocks/used-blocks.spec.ts | Covers recursive references, exclusion of unused registrations, TipTap dependencies, and deduplication. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Annotated root-block entities] --> B[DiscoverService.discoverRootBlocks]
B --> C[getUsedBlocks]
C --> D[Traverse blockMeta]
C --> E[Traverse blockInputMeta]
C --> F[Traverse referencedBlocks]
D --> C
E --> C
F --> C
C --> G[getBlocksMeta]
G --> H[Write block-meta.json]
Reviews (1): Last reviewed commit: "cms-api: Only write used blocks to block..." | Re-trigger Greptile
|
@greptileai why didn't you approve? |
|
You're right to ask. I found no actionable defects and rated the PR safe to merge, but I posted that as a summary instead of submitting a formal GitHub approval. So there wasn't a technical reason to withhold approval—the approval state simply wasn't created. Sorry for the confusion. |
|
@greptileai approve then? |
|
Yes — approved from my side. I found no actionable defects in the implementation; the remaining CodeRabbit “Requires Human Review” item is an automated public-API confirmation, not a code issue. |
2 participants
Blocks are registered as a side effect of
createBlock. Therefore, blocks that a library creates on import (e.g., the deprecatedSpaceBlock) end up in the application'sblock-meta.jsoneven when the application doesn't use them. This leads to generating types for unused blocks and may lead to broken types when an application defines a block with the same name (e.g., its ownSpaceblock).This is a well known issue. It came up once again while creating a MCP tool that returns a block's schema, so it's time to finally fix it. 😁
I tried to fix this awhile ago by making the block registration explicit when a block is used (see #2889). For instance,
RootBlockTypewould callthis.block.register()in its constructor. I can't remember why we didn't continue down this path, but I believe it may be because we were unsure if this would correctly register all used blocks.This PR takes a different approach: Blocks continue to be registered as a side effect of
createBlock.getBlocksMeta()gets support for passing used blocks via theblocksoption (with a fallback togetRegisteredBlocks().BlocksMetaServicediscovers all used root blocks and passes them togetBlocksMeta()when generatingblock-meta.json.https://claude.ai/code/session_01NN1pwjLehGbk1ChEtWmvqu