TypeScript
This document describes recommended TypeScript usage for both frontend and backend projects in this repository.
Overviewβ
TypeScript is the preferred language for new frontend and backend services due to its strong tooling, improved maintainability, and type-safety over plain JavaScript.
When to useβ
- Frontend: All new Next.js / React apps.
- Backend: Node.js services (NestJS, Express) and serverless functions.
Getting startedβ
Install:
pnpm add -D typescript
pnpm dlx tsc --init
Minimal recommended tsconfig.json settings:
{
"compilerOptions": {
"target": "ES2022",
"module": "ESNext",
"moduleResolution": "Node",
"strict": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"skipLibCheck": true,
"resolveJsonModule": true,
"noImplicitAny": true
}
}
Recommended toolingβ
- Linter & Formatter: ESLint + Prettier with
@typescript-eslintparser and rules. - Type-aware linting: enable ESLint
parserOptions.projectfor type-aware rules where needed. - Runtime helpers:
ts-nodeor build withtscand run compiled output.
Best practicesβ
- Enable
strictmode and avoidanywhen possible. - Prefer narrow types and explicit return types for public APIs.
- Use DTOs / interfaces for boundary types (API inputs/outputs).
- Keep runtime validation (Zod / io-ts) for external inputs β types are design-time only.
Examplesβ
Simple typed function:
interface User { id: string; name: string }
function greet(user: User): string {
return `Hello, ${user.name}`;
}
Using with Prisma (backend): keep Prisma models typed and map them to DTOs where appropriate.
Frontend / Backend notesβ
- Frontend: Integrate with Next.js app router and enable
isolatedModuleswhen using Babel. - Backend: Use TypeScript with NestJS (recommended) and enable compiler checks in CI.
CI / Buildβ
- Run type checks in CI:
pnpm dlx tsc --noEmit. - Fail builds on type errors when merging into main branches.
Further readingβ
- See the
tech-stackdoc for framework-level guidance and thefrontend/backenddocs for architecture-specific conventions.