Types

Apply the TypeScript Style Guide's type conventions in the context of the current task.

Workflow

1. Inspect the consuming repository's conventions and configuration.
2. Let explicit repository conventions take precedence over this opinionated guidance.
3. Apply, review, or explain only the guidance relevant to the task.
4. State important tradeoffs when the appropriate model depends on context or judgment.

Boundaries

• Keep TypeScript and ESLint responsible for checks they can enforce automatically.
• Do not introduce unrelated TypeScript Style Guide conventions merely because this skill is active.

<!-- BEGIN CANONICAL GUIDE CONTENT -->

Types

When creating types, consider how they would best describe our code.
Being expressive and keeping types as narrow as possible offers several benefits to the codebase:

• Increased Type Safety - Catch errors at compile time, as narrowed types provide more specific information about the shape and behavior of your data.
• Improved Code Clarity - Reduces cognitive load by providing clearer boundaries and constraints on your data, making your code easier for other developers to understand.
• Easier Refactoring - With narrower types, making changes to your code becomes less risky, allowing you to refactor with confidence.

Type Inference

As a rule of thumb, explicitly declare types only when it helps to narrow them.

<Note> Just because you don't need to add types doesn't mean you shouldn't. In some cases, explicitly declaring types can improve code readability and clarify intent. </Note>

Explicitly declare types when doing so helps to narrow them:

// ❌ Avoid
const employees = new Map(); // Inferred as wide type 'Map<any, any>'
employees.set('Lea', 17);
type UserRole = 'admin' | 'guest';
const [userRole, setUserRole] = useState('admin'); // Inferred as 'string', not the desired narrowed literal type