Improve Type Safety in cards.ts and Remove Remaining any Usage

[Facelessism]

Summary

This PR improves type safety in cards.ts by removing the remaining usages of any and replacing them with existing Fastify/JWT typings that's already available in the codebase. Auth-related type assertions have been eliminated, error handling has been made safer through an explicit type narrowing and a shared Fastify/JWT definitions are now reused where applicable.

Closes #547

---

Type of Change

• Bug fix
• New feature
• Refactor (no functional change)
• UI / Design change
• Tests only
• Documentation
• Infrastructure / DevOps
• Security

---

What Changed

• removed all any usages from src/routes/cards.ts
• replaced request.server as any and (app as any).authenticate with properly typed fastify decorator access
• reused existing Fastify/JWT type augmentations for request.user and auth related logic
• replaced catch (error: any) with safer error handling using explicit type narrowing
• eliminated manual user type assertions by relying on the shared JWT user typing
• verified the TS compilation without introducing any new type errors

---

How to Test

1. go to apps/backend
2. run npm run typecheck and verify it completes without any errors
3. start the backend server and run the card routes
4. verify the authentication protected routes continue to function as expected

---

Checklist

• My code follows the project's coding style (pnpm -r run lint passes).
• TypeScript compiles without errors (pnpm -r run typecheck).
• I have added or updated tests for the changes I made.
• All tests pass locally (pnpm -r run test).
• I have updated documentation where necessary.
• No new console.log or debug statements left in the code.
• Breaking changes are documented in this PR description.

---

Screenshots / Recordings

---

Additional Context

[vercel]

@Facelessism is attempting to deploy a commit to the Prashantkumar Khatri's projects Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Hi @Facelessism,

Thanks for opening this pull request.

This PR has been automatically classified based on the files modified.

Applied Labels

• gssoc:approved
• backend

Primary Review Area

• backend

Reviewer

@Harxhit has been identified as the primary reviewer for this pull request.

If you have any questions regarding the affected area or implementation details, feel free to reach out to the assigned reviewer.

Thank you for your contribution!

[github-actions]

CI — Checks Failed

Backend — FAIL

Check	Result
Lint	PASS
Test	PASS
Typecheck	FAIL

Mobile — SKIP

Check	Result
Lint	-
Test	-

Web — SKIP

Check	Result
Build	-

---

Last updated: Sun, 21 Jun 2026 10:48:25 GMT

[Facelessism]

Hey @Harxhit
Do review the attached PR and do let me know if there are further changes needed with it.
Thank you

[Harxhit]

Checked this out and tested locally. This is a clean, well-scoped refactor — every any in cards.ts is genuinely removed (not relocated or suppressed), and the new typings are all backed by augmentations that already exist in the repo.

Verified ✅

• Typecheck passes — npm run typecheck (tsc --noEmit) completes with no errors.
• Lint passes — npx eslint src/routes/cards.ts is clean.
• Tests pass — npx vitest run src/__tests__/cards.test.ts → 21/21 green. The suite exercises the refactored error branches: OWNERSHIP → 403 (create & update) and LAST_CARD → 400 (delete), confirming the switch from catch (error: any) to the hasErrorCode guard is behavior-preserving.
• request.user.id is sound: typed as AuthenticatedUser via the @fastify/jwt augmentation in src/types/fastify.d.ts, so the (request.user as { id: string }) casts were safely removable.
• app.authenticate / server.authenticate are properly typed on FastifyInstance, so dropping (app as any) and request.server as any is correct.
• hasErrorCode guard is correct — the service throws via Object.assign(new Error(...), { code: '...' }), so code is an own string property; 'code' in error && typeof error.code === 'string' narrows correctly. It's actually slightly stricter than the old error?.code === '...' — an improvement.
• No unsafe casts introduced — the any casts are replaced by a real runtime type guard.

Suggestions

1. (nit / optional) In the preHandler, request.server is typed as FastifyInstance on which authenticate is non-optional, so the typeof server?.authenticate === 'function' runtime guard is somewhat redundant — though a reasonable defensive check that matches the existing pattern. Fine to leave.
2. (nit / follow-up, out of scope) The same as any auth pattern still exists in sibling route files (profiles.ts, event.ts, nfc.ts, team.ts, follow.ts, analytics.ts). Worth a follow-up issue to apply the same treatment now that the typings are proven to support it.

Nothing blocking. Behavior is unchanged and verified by the existing card tests.

_{Reviewed locally — ran npm run typecheck, npx eslint src/routes/cards.ts, and npx vitest run src/__tests__/cards.test.ts against the branch.}

[Facelessism]

@Harxhit
As I can see this PR has been on hold for a week with no clearly specified reason so far. If this prevails longer, more and more merge conflicts will keep forming with time.
Do look into this ASAP
Thank you

[Harxhit]

@Facelessism Fix merge conflicts and then pin me please.

[Facelessism]

@Harxhit

[Harxhit]

LGTM. Approving

[github-actions]

Congratulations @Facelessism on getting PR #579 merged!

Thank you for your contribution to the project.

To receive the appropriate GSSoC labels and recognition, please mention @Harxhit in the #get-labels channel on our Discord server and share your merged PR link.

[Facelessism]

@Harxhit I noticed it way too late, but the good first issueand type: tags are missing from this PR

[Harxhit]

@Harxhit I noticed it way too late, but the good first issueand type: tags are missing from this PR

I have added valid labels and please mention your pr in the get-labels sections next time to get valid labels.