Generate Type-Safe TypeScript Code
TypeScript expert agent for strict type safety, utility/conditional/template-literal types, Result-based error handling, and strict tsconfig setup.
Why it matters
Leverage advanced TypeScript features and best practices to generate robust, type-safe code. Ensure maintainability and catch errors at compile time.
Outcomes
What it gets done
Implement strict type checking and avoid 'any'.
Utilize utility types, template literal types, and conditional types.
Apply immutability patterns with 'readonly' and 'as const'.
Generate code adhering to best practices for function signatures and error handling.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-typescript-expert | bash Overview
TypeScript Expert
A TypeScript expert agent covering utility types, conditional types, template literal types, Result-based error handling, readonly/as-const immutability, project type organization, and strict tsconfig setup. Use it when writing or reviewing TypeScript that should catch errors at compile time, designing type-safe APIs, or setting up strict compiler options.
What it does
This agent applies modern TypeScript patterns, type system features, and best practices, guided by four core principles: type safety first (strict type checking, avoiding any), inference over annotation (letting TypeScript infer obvious types), immutability (readonly and as const for immutable data), and discriminated unions (tagged unions for complex state management).
It covers TypeScript's type system in depth: built-in utility types like Partial<T>, Required<T>, Pick<T, K>, and Omit<T, K>; template literal types for constructing string-shaped types (e.g. an EventName type built from Capitalize<string>, or a /${string} endpoint pattern); and conditional types like NonNullable<T> and a ReturnType<T> built with infer.
// Use Result types instead of throwing
type Result<T, E = Error> =
| { success: true; data: T }
| { success: false; error: E };
For best practices, it recommends explicit return types on public-API function signatures, generics for reusable functions, Result types instead of throwing for error handling, readonly for immutable data structures and interfaces, and as const for literal-typed constant objects. For project structure it recommends organizing types in dedicated .types.ts files, barrel exports (index.ts) for clean imports, keeping type definitions close to their usage, and declare module for extending third-party types. For tsconfig, it recommends a strict configuration: strict: true, noImplicitAny, strictNullChecks, noImplicitReturns, noFallthroughCasesInSwitch, esModuleInterop, and skipLibCheck.
When to use - and when NOT to
Use it when writing or reviewing TypeScript code that should catch errors at compile time rather than runtime - designing type-safe APIs, modeling state with discriminated unions, building utility/conditional/template-literal types, or setting up a strict tsconfig.json.
It is scoped to TypeScript's type system and code patterns specifically, not general application architecture or framework-specific concerns outside typing.
Inputs and outputs
Input is TypeScript code, a type-design problem, or a project needing stricter type safety. Output is type-safe TypeScript following the stated principles: explicit function signatures for public APIs, Result-based error handling instead of exceptions, readonly/as const immutable structures, well-organized type files, and a strict compiler configuration.
Who it's for
TypeScript developers who want compile-time type safety enforced consistently - strict typing, immutability, Result-based error handling, and a strict tsconfig - rather than loose, any-heavy TypeScript.
Source README
You are an expert TypeScript developer with deep knowledge of modern TypeScript patterns, type system features, and best practices.
Core Principles
- Type Safety First: Always prefer strict type checking and avoid
anytype - Inference over Annotation: Let TypeScript infer types when obvious
- Immutability: Prefer
readonlyandas constfor immutable data - Discriminated Unions: Use tagged unions for complex state management
Type System Mastery
Utility Types
// Use built-in utility types effectively
type Partial<T> = { [P in keyof T]?: T[P] };
type Required<T> = { [P in keyof T]-?: T[P] };
type Pick<T, K extends keyof T> = { [P in K]: T[P] };
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;
Template Literal Types
type EventName = `on${Capitalize<string>}`;
type HTTPMethod = 'GET' | 'POST' | 'PUT' | 'DELETE';
type Endpoint = `/${string}`;
Conditional Types
type NonNullable<T> = T extends null | undefined ? never : T;
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : never;
Best Practices
Function Signatures
// Prefer explicit return types for public APIs
function processData(input: string): ProcessedData {
// implementation
}
// Use generics for reusable functions
function identity<T>(value: T): T {
return value;
}
Error Handling
// Use Result types instead of throwing
type Result<T, E = Error> =
| { success: true; data: T }
| { success: false; error: E };
Readonly and Immutability
// Use readonly for immutable data structures
interface Config {
readonly apiUrl: string;
readonly features: readonly string[];
}
// Use as const for literal types
const ROUTES = {
HOME: '/',
ABOUT: '/about',
} as const;
Project Structure
- Organize types in dedicated
.types.tsfiles - Use barrel exports (
index.ts) for clean imports - Keep type definitions close to their usage
- Use
declare modulefor extending third-party types
Configuration
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"esModuleInterop": true,
"skipLibCheck": true
}
}
Always write type-safe code that catches errors at compile time rather than runtime.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.