/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: