Excessive Usage of `any` Type Reducing Type Safety

[divysaxena24]

Description

The codebase contains 3,900+ occurrences of the any type. This bypasses TypeScript's type safety and reduces code reliability, maintainability, and developer experience.

---

Problem

• Extensive use of any disables type checking
• Increases risk of runtime errors
• Makes refactoring and debugging difficult
• Reduces IDE support (autocomplete, type hints)

---

Root Cause

• Lack of well-defined interfaces/types for core data structures
• Rapid development without enforcing strict typing
• Missing TypeScript strict mode configurations (possibly)

---

Expected Behavior

• Codebase should use strong typing with proper interfaces/types
• Minimal or no use of any unless absolutely necessary

---

Actual Behavior

• Overuse of any across components, services, and models
• No clear type definitions for key entities

---

Suggested Fixes

1. Identify Core Data Structures

Define interfaces/types for commonly used entities such as:

• User
• Beneficiary
• SecurityQuestion

Example:

interface User {
  id: string;
  name: string;
  email: string;
}

---

2. Replace any with Specific Types

Before:

let user: any;

After:

let user: User;

---

3. Enable Strict Type Checking

Update tsconfig.json:

{
  "compilerOptions": {
    "strict": true
  }
}

---

4. Gradual Refactoring Strategy

• Start with critical modules (Auth, API services)
• Replace any incrementally
• Use unknown instead of any where type is uncertain

---

Environment

• TypeScript Version:
• Angular Version:
• Node Version:

---

Additional Notes

• This issue impacts overall code quality and scalability
• Fixing this will significantly improve maintainability and reduce bugs
• Can be broken into smaller issues (module-wise refactoring)

[drtechie]

@divysaxena24, the scope of the issue is insanely huge. How do you plan to fix it?

[divysaxena24]

Thanks for pointing this out - I completely agree that the scope is very large, so attempting to fix all 3,900+ any usages in a single PR wouldn’t be practical or safe. My plan is to address this incrementally with a structured approach to minimize risk and avoid breaking changes.

Proposed Approach

1. Baseline Analysis & Prioritization

First, I’ll analyze the distribution of any usage across the codebase to identify high-impact areas

• Prioritize critical modules such as:
• Auth / User management
• API service layer
• Shared models / utilities
  These areas will give the most benefit early since they are widely used

2. Introduce Core Types & Shared Interfaces

Define reusable and well-structured types for commonly used entities, such as:

interface User {
  id: string;
  name: string;
  email: string;
}

interface ApiResponse<T> {
  data: T;
  message: string;
  status: number;
}

This will allow types to propagate naturally across components and services

3. Incremental Refactoring Strategy

Replace any on a module-by-module / file-by-file basis
Focus on:

• Function inputs/outputs
• API responses
• State management structures
• Where exact types are not immediately clear, I’ll use unknown instead of any to maintain type safety

4. Gradual Strict Mode Adoption

Instead of enabling full strict mode at once, I’ll introduce stricter checks in phases:

• Start with "noImplicitAny": true
• Gradually move toward "strict": true
  This avoids widespread build failures and keeps changes manageable

5. Prevent Regression

Add linting rules such as:

• @typescript-eslint/no-explicit-any
• Allow exceptions only when absolutely necessary and explicitly documented

6. PR Strategy

Break this into smaller, focused PRs:

• Each PR will target a specific module or feature
• Keep changes reviewable and easier to test
  This also allows continuous improvement without blocking other development work

Expected Outcome :

• Improved type safety and reduced runtime errors
• Better developer experience (autocomplete, type hints)
• Easier refactoring and long-term maintainability