30 lines
2.1 KiB
Markdown
30 lines
2.1 KiB
Markdown
# 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.
|
||
|
||
## Key Changes
|
||
- 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.
|
||
|
||
## Recommended CI/CD Setup
|
||
1. Provide at least 8GB of RAM (12GB+ preferred) to the type-check job.
|
||
2. Run package checks: `pnpm type-check:packages` (invokes `tsc --noEmit` for each workspace package).
|
||
3. Run application checks: `pnpm type-check:apps` (executes the BFF and Portal scripts sequentially).
|
||
4. Optional: `pnpm type-check:workspace` runs `tsc -b --noEmit` against the shared libraries for an incremental baseline.
|
||
|
||
## Local Development Tips
|
||
- 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.
|
||
|
||
## Follow-Up Ideas
|
||
- 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.
|