Summary
Improve type safety and error handling in public.ts by replacing unsafe catch block error access with getErrorMessage(err) and adding proper typing for the cl parameter in card.cardLinks.map().
File
apps/backend/src/routes/public.ts
Contexts
The public.ts route currently has two type-safety issues:
-
Some catch blocks may directly access err.message or use inconsistent error handling patterns. Since TypeScript treats catch errors as unknown, this can lead to unsafe access and lint/type issues.
-
The card.cardLinks.map() callback currently raises:
Parameter 'cl' implicitly has an 'any' type.
Adding an explicit or inferred type for cl will improve maintainability and ensure safer mapping logic.
A shared utility getErrorMessage(err: unknown): string already exists and should be used for standardized error extraction.
Tasks
Acceptance Criteria
Area
backend
Difficulty
good first issue
Summary
Improve type safety and error handling in
public.tsby replacing unsafe catch block error access withgetErrorMessage(err)and adding proper typing for theclparameter incard.cardLinks.map().File
apps/backend/src/routes/public.tsContexts
The
public.tsroute currently has two type-safety issues:Some catch blocks may directly access
err.messageor use inconsistent error handling patterns. Since TypeScript treats catch errors asunknown, this can lead to unsafe access and lint/type issues.The
card.cardLinks.map()callback currently raises:Parameter 'cl' implicitly has an 'any' type.Adding an explicit or inferred type for
clwill improve maintainability and ensure safer mapping logic.A shared utility
getErrorMessage(err: unknown): stringalready exists and should be used for standardized error extraction.Tasks
public.tsgetErrorMessage(err)clparameter incard.cardLinks.map()Acceptance Criteria
getErrorMessage(err)err.messageaccess remains in targeted codeclno longer has implicitanytypeArea
backendDifficulty
good first issue