Improve Type Safety Across the Codebase and Remove Remaining any Usage

[Harxhit]

Title

Replace Remaining any Types in auth.ts with Proper TypeScript Types.

Summary

Remove remaining usages of any in the authentication module and replace them with proper TypeScript interfaces, Fastify types, and request/user type definitions to improve type safety and maintainability.

Contexts

The authentication system still contains several any usages that bypass TypeScript's type checking. While the current implementation works, these areas can hide bugs and make refactoring more difficult.

Examples include:

request: any
reply: any
(request.user as any).id
(request.user as any)?.id

These should be replaced with proper interfaces and type declarations.

Tasks

• Identify all remaining any usages in the auth.ts.
• Replace middleware request: any with proper Fastify request types
• Replace middleware reply: any with proper Fastify reply types
• Create a typed interface for authenticated JWT payloads.
• Extend Fastify request typings to support request.user
• Remove type assertions such as (request.user as any)
• Verify type safety with TypeScript checks
• Update or add tests if required

Acceptance Criteria

• No any types remain in the auth.ts file.
• Authenticated user payload has a dedicated interface
• request.user is properly typed through Fastify type augmentation
• TypeScript passes without type assertions to any
• Existing authentication flows continue to work
• Tests pass successfully

Suggested Implementation

Create a dedicated JWT payload interface:

interface AuthenticatedUser {
  id: string;
  username: string;
}

Extend Fastify request typings:

declare module 'fastify' {
  interface FastifyRequest {
    user: AuthenticatedUser;
  }
}

Replace:

(request.user as any).id

with:

request.user.id

Replace:

request: any
reply: any

with:

request: FastifyRequest
reply: FastifyReply

Area

backend

Difficulty

Medium

[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.

[Kishor0009]

/assign

[ramnnn2006]

hello!

[ramnnn2006]

i would be glad to work on this issue....

soo , iwent through auth.ts and found the spots, mainly (request.user as any).id in the /logout and profile routes, plus the untyped request: any, reply: any in the authenticate decorator in app.ts which is what forces the casts in the first place.

here's my plan:

• define an AuthenticatedUser interface for the jwt payload
• since the project uses @fastify/jwt, augment the FastifyJWT interface in src/types/fastify.d.ts instead of redeclaring user on FastifyRequest, so it doesn't clash with the plugin's own typings
• type the authenticate decorator with FastifyRequest / FastifyReply
• drop all the as any casts and verify with tsc, then run the existing tests

i have a good understanding of things so i can pick this up right away! thankyou @Harxhit