avoiding-any-types

The any type bypasses TypeScript's type checking, allowing runtime errors from unexpected data shapes. Replacing any with unknown and type guards catches type mismatches at compile time, preventing bugs from APIs, JSON, and user input before code executes.

Convert any parameters to unknown, then implement type guards to validate data before access. Use the pattern: accept unknown input, check its shape with a type guard function, narrow to a safe type, then access properties. This ensures runtime validation matches your type assumptions.

Unknown is type-safe; it blocks all operations until you prove the data's shape through a type guard. Any disables all checks. Unknown forces explicit validation, making type errors visible during development instead of crashing in production.

Use unknown for the response type, then write a type guard to validate the response structure before accessing fields. This pattern safely handles APIs that may return unexpected or missing properties without relying on any.

Yes. Replace any declarations with unknown incrementally, adding type guards where needed. This gradual approach maintains type safety improvements without requiring a full codebase rewrite, making migration manageable for large projects.

Use runtime validators that check property existence, types, and expected values. Type guard functions return a boolean and narrow the type, allowing TypeScript to treat validated data as safely typed after the guard passes.