Memory & TypeScript Tooling

Current Status

TypeScript diagnostics now run with a unified configuration shared across the monorepo.
Portal and BFF type-check reliably on machines with ~8–12GB available RAM when using the provided Node.js memory limits.
Package builds remain incremental and continue to emit declaration files for downstream consumers.

Introduced tsconfig.base.json to centralise shared compiler options.
Each package/app now owns a single tsconfig.json (plus tsconfig.build.json for the NestJS app) instead of dozens of per-area configs.
Removed the .typecheck staging folders and the chunked run-chunks.mjs workflow.
Standardised type-check scripts to call tsc --project <tsconfig> --noEmit with explicit memory budgets.
Root tsconfig.json references the reusable libraries (domain, logging, api-client, validation-service) for fast incremental builds.

Provide at least 8GB of RAM (12GB+ preferred) to the type-check job.
Run package checks: pnpm type-check:packages (invokes tsc --noEmit for each workspace package).
Run application checks: pnpm type-check:apps (executes the BFF and Portal scripts sequentially).
Optional: pnpm type-check:workspace runs tsc -b --noEmit against the shared libraries for an incremental baseline.

Use pnpm --filter <workspace> run type-check:watch (where available) for continuous feedback without emitting build artefacts.
Keep NODE_OPTIONS memory ceilings from the scripts; they balance speed with predictable RAM usage on developer laptops.
When additional capacity is available, bump --max-old-space-size to 8192+ in CI to future-proof larger schemas.

Monitor CI telemetry to validate the new memory headroom and tune limits as the codebase grows.
Evaluate splitting large schema modules only if memory pressure returns; the current setup avoids premature fragmentation.
Consider enabling strict extensions such as noUncheckedIndexedAccess once the pipeline is stable again.