Task 3's implementer independently hit and fixed this exact bug
(a vi.fn() given a zero-arg implementation, then invoked via a spread
of unknown[] args inside a vi.mock factory, fails tsc -b with TS2556).
Applied the same fix (explicit vi.fn<...> generic type) to the other
occurrences of this pattern still written the old way in this plan's
Task 3 and Task 4 sections, so those implementers don't have to
rediscover it from scratch. Task 5, 10, and 11's occurrences were
checked and found to already use safe patterns (single literal-arg
calls, or bare vi.fn() with no implementation) that don't trigger this.
Claude-Session: https://claude.ai/code/session_01NhxA4npAXAxmCDEJt6kxSH
Task 3's review surfaced that the plan's original vi.importActual-based
mocking for Shop.test.tsx/Home.test.tsx/Book.test.tsx would execute the
real data-layer modules, which import the real Supabase client and
construct it at module-load time via createClient(VITE_SUPABASE_URL,
...) -- throwing "supabaseUrl is required" in a test env with no .env
file, before the test even runs.
Switched all three to mock ../lib/supabase directly instead, matching
the pattern Task 3's own products.test.ts already uses successfully.
Also fixed 3 occurrences of `err instanceof Error ? err.message :
String(err)` in the planned Shop.tsx/Home.tsx/Book.tsx error handling
-- fetchProducts/fetchServices throw the raw Postgrest error object
(not necessarily an Error instance), so this would have rendered
"[object Object]" instead of the real message in the mocked test
scenario.
Claude-Session: https://claude.ai/code/session_01NhxA4npAXAxmCDEJt6kxSH
