[New] End-to-End Type Safety with TypeScript Across Frontend and SDK

[Topmatrixmor2014]

Category Labels: frontend, sdk, typescript, type-safety, refactor

Summary: Achieve full end-to-end type safety by converting remaining JavaScript files in the frontend to TypeScript, adding strict TypeScript configuration, and sharing types between the frontend and SDK.

Background: The frontend has a tsconfig.json and the SDK (sdk/src/types.ts) defines TypeScript types. However, some frontend files may still be JavaScript (.js/.jsx) rather than TypeScript. The SDK types may need to be shared with the frontend to avoid duplication. The shared/ directory contains errorCodes.js (JavaScript, not TypeScript).

Problem Statement: Mixed JavaScript/TypeScript codebase reduces type safety. Duplicated type definitions between frontend and SDK create maintenance burden and risk of inconsistency. Full TypeScript strict mode catches bugs at compile time rather than runtime.

Objectives:

1. Convert remaining .js/.jsx files in frontend to .ts/.tsx.
2. Enable strict: true in tsconfig.json and fix resulting type errors.
3. Create a @finchippay/shared-types package or use the SDK types in the frontend.
4. Convert shared/errorCodes.js to shared/errorCodes.ts.
5. Add tsc --noEmit to CI and fail on type errors.

Scope:

• In scope: TypeScript conversion, strict mode, shared types package, CI enforcement.
• Out of scope: backend TypeScript conversion (future issue), contract Rust type generation.

Detailed Implementation Requirements:

1. Audit frontend for .js/.jsx files:
   • Run find frontend -name "*.js" -o -name "*.jsx" | grep -v node_modules | grep -v .next.
   • Convert each to .ts/.tsx with proper type annotations.
   • Key files: jest.setup.ts (already TS?), config files, utility scripts.
2. Update frontend/tsconfig.json:

   {
     "compilerOptions": {
       "strict": true,
       "noImplicitAny": true,
       "strictNullChecks": true,
       "noUncheckedIndexedAccess": true
     }
   }

   • Fix all new type errors incrementally.
3. Create shared/types/ package or symlink:
   • shared/types/index.ts — re-exports from sdk/src/types.ts.
   • Frontend imports from @finchippay/shared-types or ../../shared/types.
   • Types: Payment, Account, Analytics, Tip, Webhook, TurretDeployment, etc.
4. Convert shared/errorCodes.js → shared/errorCodes.ts:
   • Add ErrorCode type: { code: string; status: number; message: string; description?: string }.
   • Export typed error code map.
5. Update SDK sdk/src/types.ts:
   • Ensure all API response types are defined.
   • Add JSDoc comments for each type.
6. Update frontend/lib/api.ts (or wherever API calls are):
   • Add return type annotations using shared types.
   • Example: async function getAccount(pk: string): Promise<Account>.
7. Update CI:
   • Ensure npm run type-check runs tsc --noEmit.
   • Fail CI on type errors.

Expected Architecture:

shared/
├── errorCodes.ts               (converted from .js)
└── types/
    └── index.ts                 (NEW: shared type definitions)

frontend/
├── tsconfig.json               (updated: strict mode)
└── **/*.ts[x]                  (converted from .js[x])

sdk/src/
└── types.ts                    (updated: complete types)

Acceptance Criteria:

• No .js/.jsx files remain in frontend source (excluding config files).
• strict: true enabled with zero type errors.
• Shared types eliminate duplicate type definitions.
• shared/errorCodes.ts exports typed error codes.
• Frontend API functions have proper return types.
• tsc --noEmit passes in CI.
• CI: Frontend type-check passes. SDK build passes.

---

---

CI Validation: This issue includes acceptance criteria that must pass CI checks in .github/workflows/ci.yml. PRs solving this issue must pass all relevant CI jobs before merging.

[divinemike019]

Hi! I'd like to contribute to this issue.

I have extensive experience building and migrating large TypeScript codebases, with a strong focus on shared type systems, SDK integration, and maintainable frontend architecture. I'll migrate the remaining JavaScript files to TypeScript, enable and resolve strict TypeScript checks, and consolidate shared models between the frontend and SDK to eliminate duplicate type definitions. I'll also convert shared utilities such as shared/errorCodes.js to TypeScript where appropriate, ensuring the solution remains fully backward-compatible and aligns with the project's existing structure.

In addition, I'll update the TypeScript configuration as needed, resolve any resulting type inconsistencies, and add or update tests to validate the refactor. The goal is to achieve true end-to-end type safety, improve developer experience, and catch potential issues at compile time without introducing regressions.

[IamHarrie-Labs]

Hey Fren!

I checked out the issue and identified that the project still has a mix of JavaScript and TypeScript, which makes it harder to maintain consistent type safety across the frontend and SDK. I can complete the TypeScript migration, consolidate the shared types, enable strict type checking, and ensure everything passes CI without introducing regressions.

I'd love to work on this.
Kindly assign it to me.

[grantfox-oss]

🦊 GrantFox — @IamHarrie-Labs has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #396)
2. Your PR will be reviewed by the FinChippay maintainers

Good luck! Track your progress on GrantFox.