fix(types,layout): nav item type component joins NavigationItemType and its zod enum - #3039
Merged
Merged
Conversation
… and its zod enum (#2918) The renderers have carried a full `type: 'component'` implementation (componentRef → /component/<ns>/<name>, params → querystring, metadata:* special-cases), and @objectstack/spec has ComponentNavItem — but the local vocabulary never gained the member. NavigationItemTypeSchema rejected `type: 'component'` at validation time, so authors could not declare one: the feature was dead on arrival rather than dead code. - NavigationItemType + NavigationItemTypeSchema gain 'component'; NavigationItem gains componentRef/params (declared in zod too, so parse no longer strips them), mirroring spec's ComponentNavItem. - The `(item as any)` casts in the two renderer sites become typed. - NavigationDesigner's exhaustive Record gains a component entry, with appDesigner.navTypeComponent in the designer fallback + 10 locales. - layout gains "type-check" (src + tests via tsconfig.test.json, with the #2915 paths override); its DEBT entry is deleted — coverage is now 42/45. Proof: navigation-model.test.ts validates a component item end-to-end, resolveHref.test.ts covers the /component and metadata:* routing, and AppSchemaRenderer.test.tsx renders one through the real sidebar. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
xuyushun441-sys
pushed a commit
that referenced
this pull request
Jul 30, 2026
Conflict was structural, not semantic: #3039 (issue #2918, the `layout` nav-type gap) and this branch (issue #2916) each removed a different entry from the same three-line `DEBT` object in `scripts/check-type-check-coverage.mjs`. Both removals are correct and independent, so the resolution keeps neither — `DEBT` is now empty, which the guard reports as `0 known-broken`. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #2918.
The zod enum was the part that bit
Both renderer sites (
NavigationRenderer.tsx,AppSchemaRenderer.tsx) carry a full, fleshed-outcomponentnav item implementation —componentRefcolon-split to/component/<ns>/<name>,paramsserialised as querystring,metadata:*special-cases — and the route (component/:ns/:name→ComponentNavView) exists in app-shell. ButNavigationItemTypenever gained the member, andNavigationItemTypeSchemarejectedtype: 'component'at validation time, so authors could not declare one. The feature was dead on arrival rather than dead code.Not a cross-repo change:
@objectstack/specalready shipsComponentNavItemSchema(componentRef: string,params?: Record<string, unknown>, doc examplecomponentRef: 'metadata:resource'). objectui's local copy of the vocabulary was simply behind; the new fields mirror spec's shape.What moved
@object-ui/types—'component'in both the TS union and the zod enum (two copies of one vocabulary, moved together).NavigationItemgainscomponentRef+params(paramsis shared withtype: 'page', which already forwarded it). Both are declared in zod too, so parse keeps them — without that, an item would validate and then render#because strip-mode parse dropped the fields the renderer reads.@object-ui/layout— the(item as any).componentRef/paramscasts in the two component branches (and the page-params site) become typed access.@object-ui/plugin-designer— the exhaustiveRecord<NavigationItemType, …>type-meta map gains acomponentbadge entry (indigo,Puzzle);appDesigner.navTypeComponentadded to the designer's English fallback and all 10 locales (all-locales-key-parityenforces the sweep).layoutgains"type-check": "tsc --noEmit && tsc -p tsconfig.test.json"with the fix(plugin-map): drop themaplibre-gl@6default import + gate type-check in CI (#2911) #2915pathsoverride (verified: no TS6059 flood, and the guard's new test-coverage rule is satisfied viatsconfig.test.jsonon thepackages/typesmodel). The@object-ui/layoutentry incheck-type-check-coverage.mjsis deleted; the guard now reports 42/45 viatype-check.End-to-end proof (validates → routes → renders)
navigation-model.test.tsparses a component item and assertscomponentRef/paramssurvive (safeParsesuccess alone would not catch strip).resolveHref.test.tsgains a component-targets suite —/component/<ns>/<name>, params querystring (non-strings as JSON), missing-ref dead link,metadata:directory/metadata:resourcenested paths, and template-var params resolving viacontextValues(dropped when unscoped).AppSchemaRenderer.test.tsxrenders a component item through the real sidebar and asserts the anchor's href.Verification
layouttsc --noEmit(was the 2 errors)layouttsc -p tsconfig.test.jsontypesbuild + tests/examples tsconfigsplugin-designersrc + test tscapp-shelltsc --noEmiti18ntsc --noEmitnode scripts/check-type-check-coverage.mjs🤖 Generated with Claude Code