Assist_Design/CODEBASE_ANALYSIS.md

Codebase Analysis: Remaining Errors & Redundancies

🔴 Critical Type Errors

1. Portal API Client Method Case Issue

Location: apps/portal/src/features/checkout/services/checkout.service.ts

// ❌ ERROR: Property 'post' does not exist on type 'ApiClient'. Did you mean 'POST'?
return apiClient.post("/checkout/cart", { ... });
await apiClient.post("/checkout/validate", cart);

Fix: Use uppercase method names

return apiClient.POST("/checkout/cart", { ... });
await apiClient.POST("/checkout/validate", cart);

2. PricingTier Export Issue

Location: apps/portal/src/features/catalog/components/index.ts:29

// ❌ ERROR: Module declares 'PricingTier' locally, but it is not exported
export type { PricingDisplayProps, PricingTier } from "./base/PricingDisplay";

Fix: Remove PricingTier from local export since it's now imported from domain

export type { PricingDisplayProps } from "./base/PricingDisplay";

3. Checkout Hook Type Issue

Location: apps/portal/src/features/checkout/hooks/useCheckout.ts:115

// ❌ ERROR: Type 'null' is not assignable to parameter type 'OrderConfigurations | undefined'
const cart = await checkoutService.buildCart(orderType, selections, simConfig);

Fix: Handle null case

const cart = await checkoutService.buildCart(orderType, selections, simConfig || undefined);

4. Response Helper Type Issue

Location: apps/portal/src/lib/api/response-helpers.ts:91

// ❌ ERROR: Property 'data' is missing in type

Fix: Ensure response structure matches expected type

---

🟠 High Priority Redundancies

1. SIM Action Request Types Duplication

Location: apps/portal/src/features/subscriptions/services/sim-actions.service.ts

Problem: Portal defines its own request types instead of using domain types

// ❌ Portal defines locally
export interface TopUpRequest {
  quotaMb: number;
}

export interface ChangePlanRequest {
  newPlanCode: string;
  assignGlobalIp: boolean;
  scheduledAt?: string;
}

Domain already has (packages/domain/sim/schema.ts):

// ✅ Domain has validated types
export type SimTopUpRequest = z.infer<typeof simTopUpRequestSchema>;
export type SimPlanChangeRequest = z.infer<typeof simPlanChangeRequestSchema>;
export type SimCancelRequest = z.infer<typeof simCancelRequestSchema>;

Impact:

• Portal types lack validation (no min/max for quotaMb, no format validation for scheduledAt)
• Types could diverge over time
• No runtime type checking before API calls

2. SIM Configuration Schema Missing

Location: apps/portal/src/features/catalog/hooks/useSimConfigure.ts

Problem: Broken imports from wrong domain

// ❌ Wrong imports
import {
  simConfigureFormSchema,        // Does not exist
  simConfigureFormToRequest,     // Does not exist
  type SimConfigureFormData,     // Does not exist
  type SimType,                  // Exists in domain/sim
  type ActivationType,           // Does not exist in billing
  type MnpData,                  // Does not exist in billing
} from "@customer-portal/domain/billing";  // Wrong domain

Fix: Create proper schemas in domain/sim or domain/orders

---

🟡 Medium Priority Issues

3. BFF Auth Workflow Type Issues

Location: apps/bff/src/modules/auth/infra/workflows/workflows/whmcs-link-workflow.service.ts

Problem: Type '{}' is not assignable to type 'string'

// Lines 144-147: Empty object assignments to string fields

Fix: Ensure proper string values or handle empty cases

4. Prisma Type Issue

Location: apps/bff/src/modules/id-mappings/mappings.service.ts:71

Problem: Prisma.IdMapping does not exist

// ❌ ERROR: Namespace has no exported member 'IdMapping'

Fix: Check Prisma schema or use correct type name

5. Users Service Type Issue

Location: apps/bff/src/modules/users/users.service.ts:535

Problem: Type '{}' is not assignable to type 'string'

// Line 535: Empty object assignment to string field

---

🟢 Low Priority Cleanup Opportunities

6. Validation Schema Organization

Current State: Good separation between common/validation.ts and toolkit/validation/ Recommendation: Keep current structure, toolkit is for utilities, common is for validation

7. Domain Package Structure

Current State: Well-organized with clear separation Recommendation: No changes needed, follows good DDD principles

8. BFF Service Architecture

Current State: Good separation of concerns Recommendation: Consider extracting shared validation logic to domain layer

---

📋 Implementation Priority

Phase 1: Fix Critical Type Errors (30 minutes)

1. Fix API client method case (post → POST)
2. Remove PricingTier from local export
3. Handle null simConfig in checkout hook
4. Fix response helper type issue

Phase 2: Remove Type Duplications (1 hour)

1. Replace Portal SIM request types with domain types
2. Create missing SIM configuration schemas
3. Update imports to use correct domain

Phase 3: Fix BFF Type Issues (30 minutes)

1. Fix auth workflow string assignments
2. Fix Prisma type reference
3. Fix users service string assignment

Phase 4: Cleanup & Documentation (30 minutes)

1. Update any remaining documentation
2. Run full type check
3. Verify all functionality works

---

🎯 Success Criteria

• ✅ All TypeScript errors resolved
• ✅ No duplicate type definitions between Portal and Domain
• ✅ All validation schemas centralized in Domain
• ✅ Portal uses Domain types exclusively
• ✅ BFF uses Domain types exclusively
• ✅ All tests passing
• ✅ Type checking passes across all workspaces