Writing Typescript

---
{"description":"Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).","name":"writing-typescript"}
---

# TypeScript Development

## Scope

- Use for `.ts` and `.tsx`, Node.js services, React apps, typed APIs, and TypeScript design advice.
- Do not use for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates.
- Follow the repository's TypeScript version, tsconfig, package manager, framework, test runner, and lint rules.
- Do not add dependencies or switch frameworks unless the project already uses them or the user approves.

## Reference Reads

- Read only the references needed for the task.
- Read `references/principles.md` for non-trivial TypeScript changes or reviews.
- Read `references/patterns.md` for data models, validation, async flow, or module boundaries.
- Read `references/react.md` for `.tsx`, hooks, component state, forms, performance, or React tests.
- Read `references/testing.md` before adding or changing TypeScript tests.
- Read `references/linting.md` before changing lint config, lint commands, or slow lint workflows.

## Defaults

- Preserve strict typing; do not weaken compiler options to pass checks.
- Use `unknown` for untrusted input. Avoid `any`; isolate it only for unavoidable interop.
- Validate API, JSON, env, storage, and form data at the boundary before typed use.
- Use discriminated unions for variants, async state, and domain states.
- Use guard clauses and focused helpers. Avoid deep nesting, global state, and mixed concerns.
- Use the project's error conventions; prefer unions or `Result` for recoverable failures.
- Pass dependencies explicitly; avoid inheritance, singletons, and hidden module state.
- Avoid unsafe casts, non-null assertions, broad index signatures, boolean-flag state, and new app enums where literal unions fit.

## Comments and JSDoc

- Use JSDoc or TSDoc for exported APIs and non-obvious public properties or methods.
- Avoid merely restating property, parameter, or type names.
- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or interoperability quirks.
- Keep comments short. Move longer rationale to docs, issue links, or design notes.
- Do not comment obvious code.
- Keep tests readable without comments; add one only for unobvious fixtures, timers, concurrency, browser setup, or regression context.

## Testing and Verification

- For behavior changes, include success and failure tests. For React, cover affected user-visible states.
- Use focused test, typecheck, and lint commands for the changed file, package, or workspace while editing.
- Run the project's configured typecheck, tests, lint, and format checks for the changed package or workspace before final output.
- Keep coverage, end-to-end tests, and expensive debug diagnostics off the hot path unless they are the task.
- Report checks run, failures, and unchecked risks. Do not claim success without a clean check or an explicit reason it was skipped.

## Failure Handling

- If project root is unclear, identify the nearest `package.json` and `tsconfig.json`; in monorepos, state the selected package.
- If strict compiler options are absent, do not silently weaken new code. State the gap and keep the change locally type-safe.
- If validation needs a schema/form library not already used, ask before adding it; otherwise use a narrow type guard.
- If typecheck or tests fail, quote the exact diagnostic or failing assertion, state the cause, and fix the type/model boundary before widening types.
- Do not run destructive shell commands. For broad or risky changes, state the risk and ask before acting.

## Final Response

- Files changed:
- Checks:
- Skipped checks:
- Risks/follow-ups: