Found while type-checking @object-ui/react's tests for #4040 (tranche 4, PR #4351). Observation-class: nothing a user hits today, and no fix is proposed here.
What
packages/react/src/spec-bridge/bridges/list-view.ts maps a list view's rowHeight onto the renderer's density with a hand-written table of nine keys:
compact, short, comfortable, spacious, small, medium, large, tall, extra_tall
RowHeightSchema in @objectstack/spec admits five:
short | compact | medium | tall | extra_tall
So comfortable, spacious, small and large are unreachable from any spec-valid input. The bridge's own parameter type says so — it is Partial< ListView >, i.e. the spec shape — and mapDensity widens it back to rowHeight?: string to accept them.
Why it survived
SpecBridge.test.ts asserted three of the four (comfortable, spacious, small) as though they were live capability, and that file was compiled by nothing: the package's build tsconfig excludes tests and no other tsc invocation read them. Type-checking the tree is what surfaced it — the fixture would not compile against the type the function declares.
PR #4351 re-spells the fixture canonically and now covers all five spec values (gaining medium and tall, which the suite never had). It deliberately does not touch the source: deleting a lenient branch is a behaviour change for any host still passing a legacy spelling, which is a separate decision from the type-check graduation.
The decision, when someone takes it
This is AGENTS.md #0.1 territory (fix the metadata, not the renderer — one strict contract beats N dialects), so the default answer is to delete the four dead keys and let a non-spec rowHeight fall through to undefined density. The counter-consideration is empirical, not theoretical: whether any live metadata still authors comfortable/spacious, since the ADR-0087 conversions rewrote a lot of older pages. Worth a grep across the example apps and the console's own view metadata before removing.
Related: the same PR found ListColumn.link / .action asserted as { href } / { type } objects when the spec declares boolean / string; the bridge forwards them verbatim, so those assertions only ever proved pass-through. Re-spelled in #4351.
Found while type-checking
@object-ui/react's tests for #4040 (tranche 4, PR #4351). Observation-class: nothing a user hits today, and no fix is proposed here.What
packages/react/src/spec-bridge/bridges/list-view.tsmaps a list view'srowHeightonto the renderer's density with a hand-written table of nine keys:RowHeightSchemain@objectstack/specadmits five:So
comfortable,spacious,smallandlargeare unreachable from any spec-valid input. The bridge's own parameter type says so — it isPartial< ListView >, i.e. the spec shape — andmapDensitywidens it back torowHeight?: stringto accept them.Why it survived
SpecBridge.test.tsasserted three of the four (comfortable,spacious,small) as though they were live capability, and that file was compiled by nothing: the package's build tsconfig excludes tests and no othertscinvocation read them. Type-checking the tree is what surfaced it — the fixture would not compile against the type the function declares.PR #4351 re-spells the fixture canonically and now covers all five spec values (gaining
mediumandtall, which the suite never had). It deliberately does not touch the source: deleting a lenient branch is a behaviour change for any host still passing a legacy spelling, which is a separate decision from the type-check graduation.The decision, when someone takes it
This is AGENTS.md #0.1 territory (fix the metadata, not the renderer — one strict contract beats N dialects), so the default answer is to delete the four dead keys and let a non-spec
rowHeightfall through toundefineddensity. The counter-consideration is empirical, not theoretical: whether any live metadata still authorscomfortable/spacious, since the ADR-0087 conversions rewrote a lot of older pages. Worth a grep across the example apps and the console's own view metadata before removing.Related: the same PR found
ListColumn.link/.actionasserted as{ href }/{ type }objects when the spec declaresboolean/string; the bridge forwards them verbatim, so those assertions only ever proved pass-through. Re-spelled in #4351.