502
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill citypaul/.dotfiles --skill typescript-strict- SKILL.md18.2 KB
Overview
This skill documents TypeScript strict-mode patterns and architectural conventions for writing safe, maintainable TypeScript. It focuses on strict compiler settings, immutable data, dependency injection, schema organization, and clear type vs interface guidance. Use it as a checklist and pattern guide when authoring or reviewing TypeScript code.
How this skill works
The skill inspects and prescribes rules for code organization, type safety, and runtime validation: strict tsconfig flags, no implicit any or unchecked indexed access, and explicit immutability with readonly. It recommends schema-first validation at trust boundaries, single-source schemas, dependency injection for testability, and using types for data and interfaces for behavior contracts.
When to use it
- When enabling or auditing TypeScript strict mode in a project
- When designing data schemas and validation for APIs or resolvers
- When structuring code for dependency injection and testing
- When defining domain data and service contracts
- When enforcing immutability and explicit error handling patterns
Best practices
- Enable compilerOptions.strict and related safety flags (noImplicitAny, strictNullChecks, noUncheckedIndexedAccess, exactOptionalPropertyTypes).
- Never use any; prefer unknown for truly unknown values and validate with schemas before narrowing.
- Define schemas once (shared src/schemas) and import them where needed to avoid duplication.
- Inject all external dependencies via parameters or factories; avoid new inside business logic.
- Use type for immutable data structures (readonly fields, ReadonlyArray) and interface for behavior contracts and DI boundaries.
- Prefer Result<T,E> patterns over throwing exceptions for expected error flows.
Example use cases
- API endpoint that validates input with a shared Zod schema and returns typed, validated data.
- Factory-based service that accepts repositories and gateways so tests inject mocks easily.
- Domain models declared as readonly types passed through use-cases and adapters.
- Migration of a codebase to strict mode by enabling tsconfig strict flags and fixing uncovered issues (unused params, implicit any).
- Library entry points that accept unknown input and parse with schema before using to ensure runtime safety.
FAQ
Types express immutable data, compose well with unions and mapped types, and work naturally with readonly and utility types for safer data modeling.
When should I keep validation logic co-located?
Co-locate validation when a schema is small and used only by one module; extract to shared schemas when the same rules are used by multiple modules or trust boundaries.