typescript-patterns

Topics in the source

• TypeScript Development Patterns
• When to Activate
• Core Principles
• 1. Strict Mode Is the Baseline
• 2. any Is a Bug, Not a Tool
• 3. Public APIs Get Explicit Types, Locals Get Inference
• Type Design
• Interfaces vs. Type Aliases

TypeScript patterns and best practices for building robust, type-safe, and maintainable applications. The compiler is most useful when it can prove your program's shape, so the guiding principle here is: push the type system to do real work instead of fighting it. This skill is the "how." For the "what" and "when" (the decisions about which pattern to reach for), see the TypeScript rules — rules/typescript/coding-style.md and rules/typescript/patterns.md in this repository, installed as rules/ecc/typescript/coding-style.md and rules/ecc/typescript/patterns.md. Writing new TypeScript or JavaScript code Reviewing a PR that touches .ts or .tsx files Refactoring existing TypeScript to remove any, tighten types, or add strictness Designing types, generics, or module boundaries for a new feature Setting up a new TypeScript project or upgrading tsconfig.json Debugging type errors that cascade through a codebase (usually a design problem, not an annotation problem) strict: true (which enables strictNullChecks, noImplicitAny, strictFunctionTypes, and the rest) is not optional in a healthy codebase. If a codebase cannot compile under strict, that is a migration task, not an excuse to leave t

This is an excerpt. Refer to the complete source and its current requirements.