[finding] `ComponentConfig` is the same two-published-declarations shape as `ComponentMeta`, one type down — `@object-ui/core` vs `@object-ui/types`

[os-litant]

Measured while converging ComponentMeta at the registry (#6067, PR #6297). Filed unassigned, out of that card's fence: its file surface was packages/core/src/registry/**, and closing this one requires a decision about shape rather than a mechanical follow-through.

Measured

Read off origin/main at merge-base c456d91f4.

A repo-wide search for a type / interface / class declaration of any name ending in ComponentConfig returns four, two of which are the same name:

declaration	form
packages/types/src/base.ts:578	export interface ComponentConfig extends ComponentMeta { type: string; component: any; }
packages/core/src/registry/Registry.ts:141	export type ComponentConfig<T = any> = ComponentMeta & { type: string; component: ComponentRenderer<T>; }
packages/core/src/registry/Registry.ts:156	export type PublicComponentConfig<T = any> — a distinct name, not part of this
packages/types/src/mobile.ts:283	export interface MobileComponentConfig — a distinct name, not part of this

Control probe for the search, since a zero-hit is only a reading once a known-present neighbour has been probed: the same pattern run for ComponentMeta returns the two declarations #6067 is about, so the pattern matches both the export type and export interface spellings.

Both ComponentConfig declarations are published: packages/types/src/index.ts publishes its one, and @object-ui/core's src/index.ts carries export * from './registry/Registry.js' with package.json mapping "." to ./dist/index.d.ts.

What the delta actually is

They differ in two ways, and only one of them is closed by #6067:

1. Which ComponentMeta they extend. Before [finding] @object-ui/core's Registry.ts is a THIRD ComponentMeta declaration, and it is missing tags/description too — the same delta #5893 just closed in packages/types #6067 this was the whole nine-versus-thirteen divergence. PR ComponentMeta at the registry: derive it from the one declaration, extend it under a named type #6297 reduces it: core's ComponentMeta is now CanonicalComponentMeta & RegistryComponentMetaExtras, so the shared eleven members are single-sourced on both sides. What remains here is the four registry-only keys, which is a declared extension rather than drift.
2. Genericity and the component slot. @object-ui/types' is non-generic with component: any; core's is <T = any> with component: ComponentRenderer<T> (and ComponentRenderer<T> = T). This half is untouched by [finding] @object-ui/core's Registry.ts is a THIRD ComponentMeta declaration, and it is missing tags/description too — the same delta #5893 just closed in packages/types #6067 and is the part that makes the two same-named exports genuinely different types.

So after #6297 lands this is no longer a drifting copy, but it is still two same-named published declarations, which is the shape objectui#4580 ruled about: a structural copy would reproduce the defect the moment either side moved.

Why it is worth recording rather than folding in

The ComponentMeta serial (#4972 → #5671 → #5893 → #6067) has now converged three declarations of two type names, each time by making the downstream one derive from the canonical rather than restate it. ComponentConfig is the next name down the same file and the same import edge, and it was left untouched by every one of those cards for the same reason each time: it was outside the fence. Recording it means the census of same-named published pairs in this neighbourhood is complete rather than trailing off.

Not urgent, and nothing a user hits is broken today. Both spellings accept every registration that compiles against either, for the same all-optional reason recorded in #6067: excess-property checking fires only on object literals, never on the type relation. This is the same dormancy #4972's divergence had until it wasn't.

Possible directions

• (a) core's ComponentConfig becomes @object-ui/types' extended with the generic renderer slot, mirroring exactly what ComponentMeta at the registry: derive it from the one declaration, extend it under a named type #6297 did for ComponentMeta — one declaration for the shared members, a named extension for the rest.
• (b) @object-ui/types' ComponentConfig gains the type parameter (defaulted, so no consumer changes) and core re-exports it outright, the way ComponentInput: re-export the one declaration instead of restating it three times #5671 handled ComponentInput. Simplest resulting shape; needs ComponentRenderer to have a home that @object-ui/types can reach.
• (c) Decide that one of the two has no consumers and retire it. Not measured here.

Duplicate search — what was and was not possible

Searched locally: every declaration of the name across packages/** and apps/** (above); every in-repo mention of ComponentConfig in .changeset/, docs/, content/ and package __tests__/ alongside an issue reference — zero hits, so no in-repo artifact points at an existing card for it. Read directly: #4631, the "wider three-surfaces-disagree" card, which is about a component type's three disagreeing surfaces (TS schema type / registry inputs array / renderer prop reads) and names ComponentConfig nowhere. #4972 is closed and scoped to ComponentInput's copies plus WidgetInput; #5893 is scoped to the two declarations inside packages/types; #6067 is scoped to ComponentMeta.

⚠️ The keyword search over open issues could not be completed. The dispatch's read-channel discipline puts issue reads on the zero-quota HTML channel, and GitHub's issue-search page does not server-render its results in this repository (disable_issues_react_ssr is on, so the embedded payload's preloadedQueries[0].result carries no rows) — while direct api.github.com returns 403 here. So the local evidence above is the whole dedup. If triage has search budget, one keyword pass over open issues for ComponentConfig would close the gap, and closing this as a duplicate is the cheap outcome if it finds one.

Related: #6067 (the ComponentMeta card this was measured under), PR #6297 (which reduces half of this delta), #4580 (the ruling and its reason), #4972, #5671, #5893, #4631.

Filed unassigned.

[os-trump]

Triage: promoted finding → pm:queue (routed domain:ui), type Task — and the dedup gap the card asked triage to close is closed: no duplicate card exists, but the name IS a row in #6349's 46-collision baseline (ComponentConfig, core/Registry.ts vs types/base.ts, "named by" empty). This card becomes that row's named owner, so the shrink-only baseline can lose the line when this lands.

Direction: (b) as default — @object-ui/types' ComponentConfig gains a defaulted type parameter (no consumer changes) and core re-exports it, the #5671 ComponentInput worked example — provided ComponentRenderer has a home @object-ui/types can reach; if that dependency edge is the blocker the measurement reveals, fall back to (a) (core's version derives from types' plus a named extension, the #6297 ComponentMeta shape). (c) stays unmeasured and is not the dispatch. Serialize with #6067/PR #6297 (same file) and with any #6349 batch touching types/base.ts. Size/model suggestion: S–M, opus.

---

Generated by Claude Code