What and where
frontend/src/constants/navigation.ts
export function findNavItem(id: string): INavigationItem {
const found = ALL_NAV_ITEMS.find((item) => item.id === id) ?? ...;
if (!found) throw new Error(`Unknown navigation item: ${id}`);
return found;
}Called at module scope from bottom-nav-items.ts and products-sheet.tsx.
Current vs expected
Now: the parameter is a loose string, so a typo or a renamed id compiles cleanly and then throws during module evaluation of the root-layout bundle, which takes the whole app down at import rather than degrading.
Expected: an unknown id is a compile error. The id space is a closed, hardcoded set that TypeScript can express.
Why it matters
The blast radius is the entire app, and the failure appears at import time, far from the rename that caused it.
Status and why it is still open
Partly addressed: the lookup now searches every group and their children, so the reachable id space matches the table and productsNavItem resolves. That removes the likeliest cause.
The typing itself is deferred: deriving type NavItemId = (typeof userNavItems)[number]["id"] | ... needs the item arrays converted to as const satisfies readonly INavigationItem[], which changes their inferred type and has to be checked against every consumer that indexes or mutates them. That is wider than a review-fix pass.
How to test
Change one id in a findNavItem("...") call to a string that does not exist. Today tsc passes and the app throws on load; after the fix, tsc should fail.
Trail
- Review finding 66,
reviews/REVIEW-2026-07-26-MOBILE-BOTTOM-NAV-BY-AREA.md
- Flagged by CodeRabbit, Codex and two Claude reviewers
- Partly fixed in commit 3b62639 on
feat/mobile-bottom-nav
What and where
frontend/src/constants/navigation.tsCalled at module scope from
bottom-nav-items.tsandproducts-sheet.tsx.Current vs expected
Now: the parameter is a loose
string, so a typo or a renamed id compiles cleanly and then throws during module evaluation of the root-layout bundle, which takes the whole app down at import rather than degrading.Expected: an unknown id is a compile error. The id space is a closed, hardcoded set that TypeScript can express.
Why it matters
The blast radius is the entire app, and the failure appears at import time, far from the rename that caused it.
Status and why it is still open
Partly addressed: the lookup now searches every group and their
children, so the reachable id space matches the table andproductsNavItemresolves. That removes the likeliest cause.The typing itself is deferred: deriving
type NavItemId = (typeof userNavItems)[number]["id"] | ...needs the item arrays converted toas const satisfies readonly INavigationItem[], which changes their inferred type and has to be checked against every consumer that indexes or mutates them. That is wider than a review-fix pass.How to test
Change one id in a
findNavItem("...")call to a string that does not exist. Todaytscpasses and the app throws on load; after the fix,tscshould fail.Trail
reviews/REVIEW-2026-07-26-MOBILE-BOTTOM-NAV-BY-AREA.mdfeat/mobile-bottom-nav