frontend: optimize build pipeline — turbo prune, route splitting, dev overlay

[BrewingCoder]

Problem

• Docker frontend build takes ~10 minutes for a one-line change
• Local yarn dev Vite startup takes ~3 minutes
• Root causes: entire 50+ package monorepo copied into Docker for yarn install, no route-based code splitting, no dep pre-bundling, tsc runs before every build

Plan

Step 1 — build:fast script

Add build:fast to src/frontend/package.json that skips tsc -noEmit. Used for dev builds and Docker; existing build script (with type check) stays for CI.

Step 2 — Vite optimizeDeps tuning

Add optimizeDeps.include in vite.config.ts for antd, apollo, recharts, framer-motion, firebase, codemirror, etc. Forces pre-bundling on first startup instead of on-demand.

Step 3 — Route-based code splitting

Convert all 9 eagerly-imported core routes in ApplicationRouter.tsx to React.lazy. Wrap in <Suspense>. Reduces initial bundle and Vite processing time.

Step 4 — Vanilla-extract: skip

136 .css.ts files across both frontend and packages/ui — migration not worth the churn.

Step 5 — turbo prune Dockerfile

Rewrite frontend.Dockerfile as 3-stage build:

1. pruner stage — runs turbo prune @holdfast-io/frontend --docker to output only the ~8 workspace packages the frontend needs
2. builder stage — installs pruned deps, runs build:fast
3. frontend-prod stage — nginx runtime (unchanged)

Step 6 — Dev compose overlay

New infra/docker/compose.dev-frontend.yml — mounts src/frontend/build directly into nginx container. One-line change deploys in ~5 seconds instead of 10 minutes.

Expected Impact

Change	Docker build	Local dev
build:fast	-30-60s	—
optimizeDeps	—	-30-60s
Route splitting	—	-60-90s
turbo prune	-3-5 min	—
Dev compose overlay	eliminates rebuild	—
Total	~10 min → ~3 min	~3 min → ~60s

Files to modify

• src/frontend/package.json
• src/frontend/vite.config.ts
• src/frontend/src/routers/ProjectRouter/ApplicationRouter.tsx
• infra/docker/frontend.Dockerfile
• infra/docker/compose.dev-frontend.yml (new)

[github-actions]

AI Triage: Optimize frontend build pipeline (Docker, Vite, code splitting, turbo prune) to reduce build time from 10 min to 3 min and dev startup from 3 min to 60s.

Labels applied: enhancement, area:frontend, priority:high, component:docker

[BrewingCoder]

Implementation Complete ✓

All optimizations are implemented and deployed on the dev VM. Here are the results.

---

Hardware

Dev machine (Windows 11) — where local builds run:

• CPU: Intel Core i9-14900K (24 cores / 32 threads, up to 6.0 GHz)
• RAM: 64 GB
• Storage: NVMe SSDs
• Node: v22.14.0, Yarn 4.6.0

Dev VM (Ubuntu 24.04) — where Docker builds run:

• CPU: Intel Core i7-3930K (4 cores / 4 threads, 3.2 GHz, Sandy Bridge-E, 2011)
• RAM: 8 GB
• Docker: 28.2.2
• Note: This is a Proxmox VM on aging hardware — times reflect a real but constrained environment

---

Before vs After

Scenario	Before	After	Change
Docker full build (cold — yarn cache miss)	~18–19 min	~18–19 min	No change (yarn install dominates)
Docker source-change rebuild (warm yarn cache)	~10 min	~17 min (VM) / 108s Vite step only	Worse raw, better UX → use dev overlay
Docker fully cached (no source changes)	—	4s	Instant
Dev compose overlay (local build + serve)	N/A (didn't exist)	~41s	Eliminates Docker rebuild entirely
Local yarn build:fast (dev machine)	~3–4 min (with tsc)	40.7s wall / 30.9s Vite	~5× faster
Local yarn dev Vite cold start	~3 min	Improved via optimizeDeps.include	Pre-bundles heavy deps

---

What Was Implemented

1. build:fast script (src/frontend/package.json)

"build:fast": "NODE_OPTIONS='--max-old-space-size=32768' vite build"

Skips tsc -noEmit. The existing build script (with type checking) is preserved for CI.

2. Vite optimizeDeps.include (src/frontend/vite.config.ts)
Forces pre-bundling of 14 heavy dependencies (antd, apollo, recharts, firebase, codemirror, etc.) on first startup instead of on-demand. Reduces cold Vite startup time.

3. Route-based code splitting (src/frontend/src/routers/ProjectRouter/ApplicationRouter.tsx)
All 10 route components converted to React.lazy. Produces separate Vite chunks — browser loads only the code for the current route.

Confirmed chunks deployed:

AlertsRouter.js, DashboardRouter.js, TracesPage.js, LogsPage.js, PlayerPage.js,
ConnectRouter.js, IntegrationsPage.js, LogAlertRouter.js, SettingsRouter.js

4. build:fast turbo task (turbo.json)
Added build:fast task with "dependsOn": ["^build", "typegen"] — workspace deps build normally (producing their artifacts), then frontend runs vite build without tsc.

5. Docker Dockerfile (infra/docker/frontend.Dockerfile)
Switched Docker build command to:

RUN --mount=type=cache,target=/root/.turbo,sharing=locked \
    TURBO_CACHE_DIR=/root/.turbo npx turbo run build:fast --filter=@holdfast-io/frontend...

Note: turbo prune approach was attempted but abandoned — rrweb sub-packages reference rrweb/tsconfig.base.json which prune omits, causing @rrweb/types:build to fail in the pruned context. Full monorepo copy is retained; the main win is build:fast skipping tsc.

6. Dev compose overlay (infra/docker/compose.dev-frontend.yml)

services:
  frontend:
    image: nginx:stable-alpine
    build: !reset null   # skips Docker build entirely
    volumes:
      - ../../src/frontend/build:/build/frontend/build
      ...

Dev workflow:

# One-time setup (or after any code change):
cd src/frontend && yarn build:fast      # ~41s on dev machine

# Start/restart frontend container:
cd infra/docker
docker compose -f compose.yml -f compose.hobby-dotnet.yml -f compose.dev-frontend.yml up -d frontend

Container restarts in ~3s. Total turnaround per code change: ~44s vs ~10 minutes.

---

Notes

• Docker cold builds still dominated by yarn install across the full monorepo — this requires either turbo prune (blocked by rrweb) or extracting the frontend into a separate repo to fundamentally fix
• The dev overlay eliminates the Docker build penalty for iterative development
• CI continues to use turbo run build (with tsc) for type safety

[BrewingCoder]

Measured Build Times (additional detail)

Two additional Docker builds were measured on the dev VM after the initial deployment:

Build A — warm yarn cache, no source change (19m 29s total)

After git pull that changed only turbo.json and frontend.Dockerfile:

• Yarn install step: 832s (13m 52s)
• Turbo build step (all deps + frontend build:fast): 312s (5m 12s)
  • @holdfast-io/frontend:build:fast: 1m 48s
  • All dep packages (rrweb chain, ui, browser): parallel, ~3m total

Build B — real source change (1 line added to index.tsx), turbo cache warm (17m 18s total)

• Yarn install step: 828s (13m 48s)
• Turbo build step: 197s (3m 17s)
  • All dep packages: instant (turbo cache hits)
  • @holdfast-io/frontend:build:fast: 1m 48s

Root cause analysis

The yarn install step (~830s) runs on every Docker build regardless of source changes. On this VM (i7-3930K, 4 cores, 8GB RAM), resolving and linking 50+ workspace packages takes ~14 minutes even when all packages are in the Yarn Berry cache volume. This is a CPU/memory constraint — workspace resolution is sequential and memory-intensive.

Docker layer caching appears to be limited here due to disk pressure (31GB disk, ~22GB used during builds with Docker image store + build cache). Layers get evicted before the next build can reuse them.

What this means for the dev workflow

Scenario	Time	Notes
Full Docker build (any source change)	~17-19 min	Yarn install dominates
Full Docker build (fully cached, no changes)	4s	All layers hit
yarn build:fast locally (i9-14900K)	40.7s	No Docker involved
Dev overlay (local build + container restart)	~44s	Recommended for dev

Recommendation

For day-to-day development, use the dev compose overlay — it completely bypasses Docker's yarn install step. Full Docker rebuilds are for CI/release builds only. On better-resourced hardware (faster CPU, more RAM), the yarn install step would be significantly faster.