Improve Type Safety in team.ts and Remove Remaining `any` Usage

[Harxhit]

Summary

Improve type safety in team.ts by removing remaining usages of any and replacing them with proper Fastify, Prisma, TypeScript, and application-specific types.

Contexts

The team routes currently contain several usages of any that bypass TypeScript's type checking and reduce maintainability.

Examples include:

const server = request.server as any;

(app as any).authenticate

(request.user as any).id

(request as any).user = payload

Several routes currently rely on unsafe casts for authentication, request user access, and middleware execution. Existing shared Fastify/JWT type definitions should be reused where available instead of introducing duplicate definitions.

This file contains a large number of authenticated routes, making it a good candidate for consolidating authentication-related typings and removing unsafe casts throughout the module.

Tasks

• Identify all remaining any usages in team.ts
• Use existing Fastify/JWT type definitions where available
• Replace server as any with appropriate Fastify types
• Replace app as any with appropriate Fastify types
• Replace request.user as any with properly typed user access
• Replace (request as any).user with proper request typing
• Improve authentication middleware typing
• Reuse shared authentication types instead of creating duplicates
• Verify TypeScript passes without introducing new type errors
• Update tests if required

Acceptance Criteria

• No any usages remain in team.ts
• Existing shared Fastify/JWT types are reused where applicable
• Authenticated user access is properly typed
• Authentication middleware uses proper Fastify types
• Request objects no longer require unsafe casts
• TypeScript checks pass successfully
• Existing team functionality continues to work
• Tests pass successfully

Area

backend

Difficulty

Good First Issue

[github-actions]

Hi @Harxhit,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[Harxhit]

/backend

[github-actions]

The issue has been classified as backend.

@Harxhit, please review and triage this issue when available.

The backend label has been applied and the issue has been routed accordingly.

[Satvik-art-creator]

@Harxhit I would like to work on this..

[Srejoye]

Took a pass through routes/team.ts — there are 9 any usages, all falling into two repeated patterns:

1. The inline preHandler boilerplate (request.server as any, (app as any).authenticate, (request as any).user = payload) — duplicated nearly verbatim across 5 route definitions (lines 29-32, 161-164, 227, 289, 331). This same block also appears in follow.ts, connect.ts, analytics.ts, event.ts, profiles.ts, so the real fix is a single shared authenticate preHandler + a module augmentation, not a per-file patch.
2. (request.user as any).id (lines 36, 167, 230, 290, 332) — request.user is typed by @fastify/jwt as the decoded JWT payload, but that type isn't currently constrained to include id/username.

Proposed fix approach:

• Add a JWT module augmentation in src/types/fastify.d.ts (alongside the existing FastifyRequest.cookies augmentation) declaring payload and user shapes for @fastify/jwt, e.g.:

  declare module '@fastify/jwt' {
    interface FastifyJWT {
      payload: { id: string; username: string };
      user: { id: string; username: string };
    }
  }

This alone removes the need for (request.user as any).id across the file — request.user.id becomes correctly typed.

• For the preHandler boilerplate: extract the existing pattern into a single shared authenticate decorator/preHandler (likely already exists as app.authenticate per the profiles.ts/auth.ts usage — routes/team.ts should just consistently use app.authenticate like auth.ts does, rather than the defensive server as any / (app as any) fallback chain). This removes request.server as any and (app as any).authenticate entirely.
• (request as any).user = payload on line 32 becomes unnecessary once app.authenticate is used consistently, since the decorator itself sets request.user.

Affected files: primarily apps/backend/src/routes/team.ts; apps/backend/src/types/fastify.d.ts for the FastifyJWT augmentation (shared, benefits other route files too, though this issue scopes to team.ts only per the parent issue #541's file-by-file breakdown).

Test considerations: No behavioral change expected — npm run typecheck (or tsc --noEmit) should pass with zero any in team.ts and no new errors elsewhere from the FastifyJWT augmentation. Existing __tests__/team.test.ts should pass unchanged since this is purely a typing refactor; if app.authenticate wasn't previously used in this file, confirm the auth-failure (401) test cases still behave identically with the decorator-based preHandler.

I'd like to pick this up under GSSoC'26.