e8523d270e
- Removed `ciTargetName` from `nx.json`. - Updated `package.json` to include new dependencies: `@types/seedrandom`, `fast-check`, `happy-dom`, and `@nestjs/schedule`. - Modified `pnpm-lock.yaml` to reflect the addition of new packages and their versions. - Improved project documentation in `PROJECT_CONTEXT.md` to clarify the use of Zod schemas and Angular framework decisions. - Introduced new Angular components and patterns in the `.agents/skills/frontend-angular` directory, including examples and reference materials for Angular 21+ features.
45 lines
2.6 KiB
Markdown
45 lines
2.6 KiB
Markdown
# 0008 — Angular for the overlay frontend
|
||
|
||
- **Status:** Accepted
|
||
- **Date:** 2026-05-07
|
||
|
||
## Context and problem statement
|
||
|
||
`PROJECT_CONTEXT.md` explicitly deferred the overlay framework choice to Stage 2, noting that Vanilla TypeScript + Lit "is likely a better fit" for bundle size and Twitch review simplicity. The overlay app was scaffolded with Angular as a placeholder. A decision is required before building any real overlay components.
|
||
|
||
## Decision drivers
|
||
|
||
- **Bundle size.** Twitch reviews extensions manually; a smaller bundle reduces scrutiny risk and load time over arbitrary stream content.
|
||
- **Developer velocity.** Familiarity with a framework dominates iteration speed, especially for a solo build.
|
||
- **Component model fit.** The overlay has three display states and a PubSub subscription — straightforward enough for any framework.
|
||
- **Existing scaffold.** The Angular app already exists in the workspace; switching adds setup cost with no immediate payoff.
|
||
|
||
## Considered options
|
||
|
||
1. **Angular.** Full framework; already scaffolded; developer is expert-level.
|
||
2. **Lit.** Web-component library; ~15–20 KB; closer to the platform.
|
||
3. **Vanilla TypeScript (hand-rolled).** Minimal; total control; no dependency; highest maintenance burden for reactivity.
|
||
|
||
## Decision outcome
|
||
|
||
**Chosen: Angular.**
|
||
|
||
The developer is very familiar with Angular and unfamiliar with Lit. Velocity matters more than the marginal bundle-size improvement. Angular's production build with `@angular/build` treeshakes aggressively; the overlay's initial budget is set to 1 MB error / 500 KB warning in `project.json`, which is comfortably achievable. The three overlay states map naturally to standalone Angular components with signals for reactive state.
|
||
|
||
## Consequences
|
||
|
||
### Positive
|
||
|
||
- No framework ramp-up time; patterns (signals, standalone components, `HttpClient`, RxJS) are immediately available.
|
||
- `@angular/build` produces well-optimised production bundles with differential loading and full treeshaking.
|
||
- Existing workspace tooling (`@nx/angular`, ESLint, Vitest via `vitest-angular`) works without additional configuration.
|
||
|
||
### Negative
|
||
|
||
- Baseline bundle is larger than Lit or vanilla (~120–200 KB gzipped vs ~15–20 KB). Mitigate with lazy routes if the expanded view grows significantly.
|
||
- If Twitch introduces strict size limits in a future review cycle, migrating is non-trivial.
|
||
|
||
### Neutral
|
||
|
||
- Revisit if the production bundle consistently exceeds 400 KB gzipped after Stage 2 is complete. At that point, incremental Lit migration (replacing individual components) is feasible without a full rewrite.
|