Uh oh!
There was an error while loading. Please reload this page.
docs(components): name the overlay/feedback node slots at their declared type - #7107
Merged
Merged
Conversation
…red type Six pages spelled a node slot `ComponentSchema` — a real shipped export (`packages/types/src/blocks.ts`) that is not a node slot, but the concrete `type: 'component'` block. The keys carry `SchemaNode` (`base.ts`). Seven of the nine rows are corrected, each re-derived from its own declaration rather than by a string replace, because the declarations disagree on whether the array form is admitted: `context-menu`'s `trigger` and both `content` rows take `SchemaNode | SchemaNode[]`; the rest are singular. `dropdown-menu`'s `trigger` stays SINGULAR. Its mirror, its sibling `ContextMenuSchema` and its own shipped `defaultProps` all use the array form and the published TS type refuses it — which side is right is #7081, open on the maintainer floor. Publishing the array form would have pre-empted that ruling. Two rows are NOT renamed and are reported instead: `AlertDialogSchema.actions` is declared nowhere and read by nothing, and `EmptySchema.action` is declared nowhere but read by the renderer through a cast that requires an object — `SchemaNode` admits primitives, so it would have been a new false claim. `overlay-node-slot-doc-types-7082.test.ts` pins the result against the TS declarations, with a type-level leg compiled by `tsconfig.test.json`. No gate parses a `plaintext` fence, so without it a green CI run would say only that nothing else broke. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012wwHa4aaFybxXrfmfHioDM
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
This was referenced Sep 1, 2026
os-warren
marked this pull request as ready for review
September 1, 2026 00:33
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#7082
Six component pages spelled a node slot
ComponentSchema. That is a real shipped export (packages/types/src/blocks.ts) and it is not a node slot — it is the concretetype: 'component'block. The keys carrySchemaNode(packages/types/src/base.ts), which also admitsstring | number | boolean | null | undefined, so a reader who looked the published name up found a narrow, unrelated type.Re-derived on
2c3cd1b(the card measured592acafb; #7073 / #6521 / #6347's docs PRs landed in between). All nine rows were still present — onlycontext-menu.mdx's line number moved, 47 to 48. Nothing was already corrected, so there is no with-evidence no-op half.Per-row, derived from each declaration — not a string replace
The declarations disagree with each other on whether the array form is admitted, so every row was read separately.
mainalert-dialog.mdx:30triggertrigger?: SchemaNode—overlay.ts:91SchemaNodealert-dialog.mdx:33actionscontext-menu.mdx:48triggertrigger?: SchemaNode | SchemaNode[]—overlay.ts:486SchemaNode | SchemaNode[]hover-card.mdx:17triggertrigger: SchemaNode—overlay.ts:296SchemaNodehover-card.mdx:18contentcontent: SchemaNode | SchemaNode[]—overlay.ts:292SchemaNode | SchemaNode[]dropdown-menu.mdx:51triggertrigger: SchemaNode—overlay.ts:433SchemaNode(singular)sheet.mdx:26triggertrigger?: SchemaNode—overlay.ts:150SchemaNodesheet.mdx:29contentcontent?: SchemaNode | SchemaNode[]—overlay.ts:146SchemaNode | SchemaNode[]empty.mdx:28actionFive whitespace-only lines move with them: where a corrected row outgrew its fence's comment column (
hover-card,sheet,context-menu), that block's column is bumped so the comments stay aligned. No other row's text changes.dropdown-menustays SINGULAR, on purposeIts Zod mirror (
zod/overlay.zod.ts:176), its siblingContextMenuSchema, and its own shippeddefaultProps(renderers/overlay/dropdown-menu.tsx:130) all use the array form, and the published TS type refuses it. Which side is right is #7081 — open, on the maintainer floor, a published-type widening. Publishing the array form here would put a claim in the docs that the shipped type rejects and would silently pre-empt that ruling, so the page follows the type an author's editor reads. The docs are then locally incoherent with the validator, and that incoherence is#7081, recorded rather than resolved. I measured its three unmeasured siblings and posted the result on that card: all four overlaytriggers have the same asymmetry, andAlertDialogSchemahas the array-defaultPropsevidence too.Two rows are NOT renamed, and that is the finding
Both are documented but declared nowhere — neither the TS interface nor the mirror — so no honest docs-only edit follows a declaration that does not exist.
AlertDialogSchema.actions— read by nothing either (schema.actionsappears nowhere in the renderer). Renaming it would keep a phantom key alive under a second wrong type. The surrounding block turns out to be diverged far past this one row: the renderer reads four keys the type does not declare (content,cancelText,actionText,onAction) while the type declares five the renderer never reads (cancelLabel,confirmLabel,confirmVariant,onConfirm,onCancel), so a dialog authored strictly against the shipped type renders an empty footer. Filed as finding(types,components,docs):ui:alert-dialog's three surfaces name three DISJOINT key sets — every declared authoring key is inert, and every key the renderer reads is a type error #7104.EmptySchema.action— declared nowhere, but read by the shipped renderer through(schema as any).action, behind atypeof === 'object'guard.SchemaNodeadmitsstring | number | boolean, which that guard drops, so publishing it there would have been a new false claim rather than a correction. Filed as finding(types):EmptySchema.actionis read by the shipped renderer through anas anycast and declared by neither the type nor its mirror — a 14th key #6150's sweep missed #7105 (and it is a 14th key finding(types): 13 top-level schema keys that component renderers genuinely READ are declared by no shipped type — measured across all 76content/docs/componentspages #6150's sweep missed — plausibly because the cast hides it from aschema.KEYscan).Requiredness is likewise left alone and filed:
alert-dialog.mdx:30,sheet.mdx:26andsheet.mdx:29publish required against a declared optional. That is #7073's class, already fixed by it oncontext-menu.mdx. Filed as #7106.The pin — because green CI cannot tell you this is right
Every row here sits in a
plaintextfence.check:doc-snippetscompilests/tsx/typescriptonly andcheck:doc-typesreads only thetypestring literals, so no gate parses these rows (#5250 / #5867). Measured on this run:check:doc-snippetsreportsScanned 224 document(s): 181 covered (80 of them hold a ts/tsx block), and all six of these pages hold zerots/tsx/typescriptfences and oneplaintextfence each. A green CI here says "nothing else broke", not "the correction is right".So
packages/types/src/__tests__/overlay-node-slot-doc-types-7082.test.tsbrings the evidence, following PR #7078's model with one deliberate departure: its authority is the TS declaration, not the Zod mirror. That is load-bearing — the two disagree on fourtriggerrows, and pinning against the mirror would have published #7081's answer on all four. It asserts both legs of each corrected row (the page says X, and X is still what the declaration says), records the two undeclared rows and the three requiredness divergences as divergences, and carries a type-level leg compiled bypackages/types/tsconfig.test.json.Reverse verification — the pin can fail, in both legs
Implementation committed first; each mutation proven on disk by grep counts in both directions, each restore proven by
git diff HEADempty plus ahash-objectmatch against the HEAD blob. No build leg: the test's imports are type-only and its readings arereadFileSync, so nothing resolves throughdist.dropdown-menudocs row toComponentSchemaTests 3 failed | 31 passed— the two corrected-row assertions plus the #7081 no-pre-empt oneDropdownMenuSchema.triggerto the union atoverlay.ts:433Tests 4 failed | 30 passed;tsc -p tsconfig.test.jsonexit 2,error TS2344: Type 'false' does not satisfy the constraint 'true'at the_DropdownAdmitsArrayassertionThe second is the one that matters: whoever lands #7081 is told mechanically that these pages owe the union. It also proves the type-level assertions are live rather than vacuous — the failure is inside this file, so
tsconfig.test.jsondemonstrably compiles it.Gates run, on
5ba929b(the final commit)check:doc-snippetsSemantic phase: 271 of 271 block(s) judged, 0 failed.(first run was exit 2,PRECONDITION NOT MET— its 21-package closure was unbuilt; built it, re-ran, and this is the real reading)check:doc-typesEvery documented component type is registered.check:doc-fencesevery TypeScript block in 224 document(s) is fenced ts/tsx/typescript, except 80 declared file(s) carrying 90 block(s) … (SHRINK-ONLY)— unchanged, no fence movedcheck:docs-route-closuredocs:check-linksLinks are valid across 17 scan roots.check:changeset-presence1 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s) … Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate.check:changeset-no-majorNo changeset declares a 'major' bump.check:changeset-fixedAll workspace packages are in the changeset fixed group.check:changeset-overwriteNo pre-existing changeset was modified or deleted.check:control-bytesOK (scanned 5885 tracked text file(s); skipped 85 binary)pnpm --filter @object-ui/types type-checktsc --noEmit && tsc -p tsconfig.examples.json && tsc -p tsconfig.test.jsonpnpm --filter @object-ui/types lint260 problems (0 errors, 260 warnings)— all pre-existing; zero findings in the new filepnpm vitest run packages/types/Test Files 82 passed (82) · Tests 1040 passed (1040)0 of them published source of a package the release covers … no changeset is owed; withpackages/types/src/__tests__/…in the diff it counts 1 source file of 1 released package. The empty-frontmatter changeset is the right artifact under both readings — and it is required under the second — where apatchbump would have falsely claimed a released package changed.packages/types/tsconfig.jsonexcludes**/*.test.tsfrom the build, sopackages/types/distis unchanged.No declaration, mirror, renderer or fixture was edited. Docs plus one test file.
Generated with Claude Code in session https://claude.ai/code/session_012wwHa4aaFybxXrfmfHioDM
Generated by Claude Code
Generated by Claude Code