Type Safety Review

The Problem

TypeScript promises type safety, but developers routinely undermine it. Sprinkling any silences the compiler while hiding real bugs. Missing null checks crash at runtime despite TypeScript’s strict mode. Overly broad union types force unsafe type assertions downstream. The result is TypeScript that provides a false sense of security — the types compile, but the code still throws Cannot read property of undefined in production.

The Prompt

Review the following TypeScript code for type safety. Act as a TypeScript architect enforcing strict mode best practices.

CONTEXT: [e.g., React frontend, Node.js API, shared library]
STRICT MODE: [yes/no — is strict: true in tsconfig?]

CODE:
[paste your TypeScript code here]

Analyze across these type safety dimensions:

1. **any / unknown Audit**
   - Flag every `any` type — is it truly unavoidable or just lazy?
   - Should `any` be replaced with `unknown`, a proper type, or a generic?
   - Check for implicit `any` from missing return types or parameters

2. **Null Safety**
   - Are optional values checked before access (nullish coalescing, optional chaining)?
   - Is the non-null assertion operator (!) used? Is it justified?
   - Do function signatures accurately reflect when null/undefined is possible?

3. **Generic Correctness**
   - Are generics used where types repeat with different parameters?
   - Are generic constraints (`extends`) applied to prevent misuse?
   - Are generics over-engineered (3+ type parameters for simple use cases)?

4. **Type Narrowing**
   - Are discriminated unions used instead of type assertions?
   - Do switch/if chains exhaustively handle all union members?
   - Is `as` type assertion used? Could a type guard replace it?

5. **Interface Design**
   - Are interfaces lean (no optional properties that are always present)?
   - Are shared types in a central location (not duplicated across files)?
   - Do function parameters use the narrowest possible type?

6. **Runtime-Compile Alignment**
   - Do types match actual API responses (validated with zod/io-ts)?
   - Are external data boundaries typed and validated?
   - Could a type assertion mask a runtime shape mismatch?

For each issue, provide:
- **Location**: File and line
- **Risk**: What bug this could cause at runtime
- **Severity**: unsafe (runtime crash) / weak (reduced safety) / style (improvement)
- **Fix**: Properly typed replacement code

Example Output

## Type Safety Review: 7 issues found

### Unsafe: Unvalidated API Response
Location: src/api/users.ts:15
Code: `const data = await res.json() as User[]`
Risk: If API shape changes, `as` hides the mismatch — accessing data.name crashes.
Fix:
  import { z } from 'zod';
  const UserSchema = z.object({ id: z.number(), name: z.string() });
  const data = z.array(UserSchema).parse(await res.json());

### Weak: Implicit any in Event Handler
Location: src/components/Form.tsx:28
Code: `const handleChange = (e) => setState(e.target.value)`
Risk: No type checking on event properties. Typos in e.target.value go unnoticed.
Fix: `const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => setState(e.target.value)`

### Style: Overly Broad Union
Location: src/types/index.ts:5
Code: `type Status = string`
Fix: `type Status = 'pending' | 'active' | 'archived'`

When to Use

Run this when reviewing TypeScript pull requests, migrating from JavaScript, or auditing a codebase before enabling strict mode. Particularly valuable for shared libraries and API boundary layers where type mismatches cause the most damage. Use it to systematically eliminate the any types that accumulated during rapid development.

Pro Tips

• Include your tsconfig — strict mode settings dramatically change what counts as an issue. Paste the relevant compiler options for accurate feedback.
• Focus on boundaries — type safety matters most at data entry points: API responses, form inputs, URL params, localStorage reads. Interior code is only as safe as these boundaries.
• Ask for a migration plan — if the review finds many any types, follow up with “Rank these by risk and give me a step-by-step migration plan.”