Found while implementing #5856. Filed unassigned, not claiming. Observation, not a live defect — everything renders correctly today.
What was measured
apps/site/app/components/registerCatalogBlocks.ts registers the plugin blocks the catalog gallery renders, as eleven side-effect imports:
plugin-dashboard plugin-charts plugin-calendar plugin-chatbot plugin-editor
plugin-gantt plugin-kanban plugin-map plugin-markdown plugin-timeline
plugin-view
@object-ui/plugin-grid is not among them, and examples/schema-catalog/test/catalog-gallery-render.test.tsx mirrors that list exactly in HOST_PACKAGES — a parity case at the end of the file fails if the two drift.
Yet object-grid resolves in both. Measured under the test harness on d2fb6efb4:
ComponentRegistry.get('object-grid') -> truthy
The reason is a transitive import: packages/plugin-view/src/ObjectView.tsx:37 does import { ObjectGrid } from '@object-ui/plugin-grid', which loads that package's entry module, which runs its three ComponentRegistry.register(...) calls — including object-grid and import-wizard.
So the gallery's registration of object-grid is a side effect of plugin-view needing the component, not a declared intent of the host.
Why it is worth recording
Before #5856 nothing depended on it, because plugin-grid's two catalog entries authored no object-grid node at all — they were hand-built card layouts. As of #5856 both entries are real object-grid nodes, so the gallery now genuinely depends on this transitive path. If plugin-view ever stopped importing ObjectGrid — a plausible refactor, since it is a component import rather than a plugin dependency — those tiles would paint the OBJUI-001 "Unknown component type" panel, and the reason would be several files away from the symptom.
Also note registerCatalogBlocks.ts's own header describes its imports as "exactly the packages that census resolves to — not a curated list", which reads as a complete statement of what the gallery registers. It is complete for the census it was written against; it is no longer a complete statement of what the gallery depends on.
Partial mitigation already in place
#5856's PR adds a case that asserts the type is registered before its render case runs, with a message naming the transitive path, so a break surfaces as a named failure instead of an unexplained red tile. That makes the failure legible; it does not make the registration declared.
Possible fixes, not chosen here
- Add
import '@object-ui/plugin-grid'; to registerCatalogBlocks.ts and to the test's HOST_PACKAGES (they must move together — the parity case enforces it), plus @object-ui/plugin-grid as a devDependency of examples/schema-catalog. Straightforward, and makes the dependency say what it is. - Leave it transitive and rely on the new registration assertion.
Not done in #5856 because apps/site/** was outside that card's declared file surface, and it is a separate question from whether the entries author the right type.
Triage note
Severity left to triage. Nothing is broken; this is a latent fragility plus a header that is now slightly stale.
Found while implementing #5856. Filed unassigned, not claiming. Observation, not a live defect — everything renders correctly today.
What was measured
apps/site/app/components/registerCatalogBlocks.tsregisters the plugin blocks the catalog gallery renders, as eleven side-effect imports:@object-ui/plugin-gridis not among them, andexamples/schema-catalog/test/catalog-gallery-render.test.tsxmirrors that list exactly inHOST_PACKAGES— a parity case at the end of the file fails if the two drift.Yet
object-gridresolves in both. Measured under the test harness ond2fb6efb4:The reason is a transitive import:
packages/plugin-view/src/ObjectView.tsx:37doesimport { ObjectGrid } from '@object-ui/plugin-grid', which loads that package's entry module, which runs its threeComponentRegistry.register(...)calls — includingobject-gridandimport-wizard.So the gallery's registration of
object-gridis a side effect ofplugin-viewneeding the component, not a declared intent of the host.Why it is worth recording
Before #5856 nothing depended on it, because
plugin-grid's two catalog entries authored noobject-gridnode at all — they were hand-built card layouts. As of #5856 both entries are realobject-gridnodes, so the gallery now genuinely depends on this transitive path. Ifplugin-viewever stopped importingObjectGrid— a plausible refactor, since it is a component import rather than a plugin dependency — those tiles would paint the OBJUI-001 "Unknown component type" panel, and the reason would be several files away from the symptom.Also note
registerCatalogBlocks.ts's own header describes its imports as "exactly the packages that census resolves to — not a curated list", which reads as a complete statement of what the gallery registers. It is complete for the census it was written against; it is no longer a complete statement of what the gallery depends on.Partial mitigation already in place
#5856's PR adds a case that asserts the type is registered before its render case runs, with a message naming the transitive path, so a break surfaces as a named failure instead of an unexplained red tile. That makes the failure legible; it does not make the registration declared.
Possible fixes, not chosen here
import '@object-ui/plugin-grid';toregisterCatalogBlocks.tsand to the test'sHOST_PACKAGES(they must move together — the parity case enforces it), plus@object-ui/plugin-gridas a devDependency ofexamples/schema-catalog. Straightforward, and makes the dependency say what it is.Not done in #5856 because
apps/site/**was outside that card's declared file surface, and it is a separate question from whether the entries author the right type.Triage note
Severity left to triage. Nothing is broken; this is a latent fragility plus a header that is now slightly stale.