Frontend Vitest suite is ~3x slower than it needs to be: every spec re-imports the full module graph

[cteyton]

Problem

The frontend Vitest suite takes ~51s in CI and ~55s locally (173 files, 2365 tests). Profiling shows the bottleneck is not insufficient parallelism — the suite is already CPU-saturated (~600s of worker CPU spread over 11 cores ≈ the observed wall clock). The bottleneck is that every test file re-imports the whole module graph from scratch.

Vitest's default isolate: true gives each test file a fresh module registry. Measured cost of that:

• Importing @packmind/ui costs 1.27s (of which @chakra-ui/react alone is 831ms).
• ~150 of the 173 spec files import @packmind/ui.
• That accounts for roughly 190s of the ~250s total import time.

In other words, Chakra + the design kit are being evaluated ~150 times per run instead of once per worker.

Measurements

Tight interleaved A/B, same machine (11 cores, macOS, Node 24.18.0, Vitest 4.1.10, Vite 8.1.5). Nx cache was bypassed throughout (--skip-nx-cache, then direct ./node_modules/.bin/vitest invocations).

Config	Wall clock	import	setup
Baseline (current)	56.9s / 55.0s	252–262s	25s
pool: 'threads' + deps.optimizer.web	57.7s / 51.7s	237s	26s
isolate: false	22.9s / 19.4s	41–60s	2.3s

Two things worth calling out:

1. isolate: false is a ~2.5–3x win. Sharing the module registry per worker collapses ~150 imports of Chakra down to ~11 (one per worker). setup drops 10x for the same reason.
2. pool: 'threads' and deps.optimizer are worth nothing. An earlier, looser measurement suggested ~10%, but that did not survive a back-to-back A/B on a quiet machine. Ambient machine load dominates at that magnitude — don't bother with these.

Also ruled out: the vite-plugin-checker in apps/frontend/vite.config.ts is not gated on VITEST (unlike the reactRouter() plugin right above it), but it does not actually spawn tsc under Vitest — its checker only activates via configureServer for the dev server. Not a contributor. Gating it would be cosmetic only.

What it costs

Exactly 15 of 173 files leak state under isolate: false. They cluster into three groups:

Shared ApiService / axios module singleton (7 files)

• src/services/api/ApiService.test.ts
• src/domain/accounts/api/gateways/AuthGatewayApi.test.ts
• src/domain/accounts/api/gateways/OrganizationGatewayApi.test.ts
• src/domain/accounts/api/gateways/UserGatewayApi.test.ts
• src/domain/change-proposals/api/gateways/ChangeProposalsGatewayApi.spec.ts
• src/domain/git/api/gateways/GitProviderGatewayApi.spec.ts
• src/domain/skills/api/gateways/SkillsGatewayApi.test.ts

Clipboard global (2 files)

• src/shared/components/inputs/CopiableTextField.spec.tsx
• src/shared/components/inputs/CopiableTextarea.spec.tsx

Component specs (6 files)

• src/domain/change-proposals/api/queries/ChangeProposalsQueries.spec.tsx
• src/domain/deployments/components/redesign/DeploymentsOverviewRedesign.spec.tsx
• src/domain/git/components/ConnectionDrawer/ManageReposPanel.spec.tsx
• src/domain/git/components/ManageGitProvider/__tests__/GitProviderAdvancedPanel.spec.tsx
• src/domain/marketplaces/components/MarketplaceDetailLayout.spec.tsx
• src/domain/spaces/components/SpacesManagementPage/SpacesManagementPage.test.tsx

Suggested fix

Step 1 — bank the win now, without fixing all 15 files. Split into two Vitest projects in apps/frontend/vite.config.ts: the leaky list stays isolated, everything else shares the registry.

const LEAKY_SPECS = [
  'src/services/api/ApiService.test.ts',
  'src/domain/accounts/api/gateways/*.test.ts',
  // ...the 15 files listed above
];

test: {
  projects: [
    {
      extends: true,
      test: { name: 'shared', isolate: false, exclude: LEAKY_SPECS },
    },
    {
      extends: true,
      test: { name: 'isolated', isolate: true, include: LEAKY_SPECS },
    },
  ],
}

This should take the suite from ~51s to roughly ~20s in CI.

Step 2 — retire the list file by file. The 7 gateway specs share a single root cause (a module-level axios instance in ApiService), so one fix likely clears all of them at once. Each file removed from LEAKY_SPECS moves into the fast project.

Step 3 (optional, smaller) — split the @packmind/ui barrel. packages/ui/src/index.ts re-exports everything including PMCodeMirror, which drags in 6 CodeMirror language grammars (lang-css, lang-json, lang-rust, lang-vue, lang-xml, lang-yaml, legacy-modes). Only 10 frontend components actually use it, but all ~150 spec files pay for it. Moving PMCodeMirror behind a subpath export would trim the non-Chakra portion of the barrel. Note this becomes largely moot once Step 1 lands, since the graph is then evaluated once per worker rather than once per file — worth doing for dev-server and build times, not for tests.

Notes

• Worth doing before reaching for Nx Cloud: this removes the work rather than distributing it.
• Benchmark numbers vary by ±10s with ambient machine load. Any future A/B on this suite must be run back-to-back on a quiet machine, or the result is noise.

🤖 Generated with Claude Code

[cteyton]

@michel go.
Opens a PR only if your local benchmarks provide significant improvements (at least less than 35 seconds).
Otherwise, just add a comment in this github issue, explaining that no improvement were found, this would be fine.

[cteyton]

✅ Michel — READY, starting implementation

The issue asks to speed up the frontend Vitest suite by disabling per-file module isolation (isolate: false) for most specs while keeping a short list of state-leaking specs isolated, via Vitest's multi-project config in apps/frontend/vite.config.ts. The fix, the exact mechanism, the leaky-file list, and the acceptance gate are all specified; cteyton's comment makes the deliverable a binary benchmark decision (PR if the suite drops under ~35s locally, otherwise a comment saying no improvement was found).

I'll open a PR against agent/issue-436 when done.

My analysis & plan

What the issue wants

Split the frontend Vitest run into two projects: a fast shared project with isolate: false (module registry reused per worker, so Chakra/@packmind/ui is evaluated once per worker instead of once per file), and an isolated project with isolate: true for a small list of specs that leak global/module state. Only Step 1 is required to bank the win; Steps 2 (fix the axios/ApiService singleton so gateway specs can rejoin the fast project) and 3 (split PMCodeMirror out of the @packmind/ui barrel) are explicitly optional and largely moot for tests once Step 1 lands.

Acceptance gate (from cteyton's comment — this is the real spec)

"Opens a PR only if your local benchmarks provide significant improvements (at least less than 35 seconds). Otherwise, just add a comment in this github issue, explaining that no improvement were found."

So the implementation phase MUST: (1) apply Step 1, (2) benchmark before/after back-to-back on the worker, (3) if the suite runs under ~35s open the PR, else post a GitHub issue comment stating no significant improvement was found and open no PR. Benchmark numbers are noisy (±10s per the issue); run baseline and patched back-to-back and prefer the patched wall clock as the decision value.

Where / how

• Only file to change (Step 1): apps/frontend/vite.config.ts — the test: { ... } block (currently lines 116-134). Replace the flat config with test: { projects: [ {extends: true, test: {name: 'shared', isolate: false, exclude: LEAKY_SPECS}}, {extends: true, test: {name: 'isolated', isolate: true, include: LEAKY_SPECS}} ] }. extends: true inherits the root test config (setupFiles ./src/test-setup.ts, environment: 'jsdom', globals: true, include, testTimeout: 15000, coverage). Keep the shared root include/setupFiles/etc. at the top-level test so both projects inherit them. Vitest here is 4.1.10 (root package.json) with Vite ^8.1.5 — test.projects is the current (post-workspace) API and supports extends: true and per-project name. Node is pinned to 24.18.0 (.nvmrc).
• Test target: nx show project frontend → test target runs vitest with cwd: apps/frontend. So include/exclude globs are relative to apps/frontend (e.g. src/services/api/ApiService.test.ts). For direct benchmarking use ./node_modules/.bin/vitest run from apps/frontend (or nx test frontend --skip-nx-cache); bypass the nx cache when timing.
• The reactRouter() / Checker plugins above are already handled (reactRouter is gated on !process.env.VITEST; the issue confirms the checker is not a Vitest contributor). No plugin changes needed.

Leaky-spec list — IMPORTANT drift finding

The repo has drifted from the issue's profiling snapshot: it now has 92 spec files (not 173) and 53 import @packmind/ui (not ~150). Of the 15 files the issue lists as leaky, only 11 still exist; these 4 do NOT exist and must be dropped from LEAKY_SPECS:

• src/domain/change-proposals/api/gateways/ChangeProposalsGatewayApi.spec.ts (no such test file)
• src/domain/change-proposals/api/queries/ChangeProposalsQueries.spec.tsx (only a stub .ts under domain/editions/stubs)
• src/domain/deployments/components/redesign/DeploymentsOverviewRedesign.spec.tsx (component exists, no spec)
• src/domain/marketplaces/components/MarketplaceDetailLayout.spec.tsx (no such file)

The 11 confirmed-present leaky specs:

• src/services/api/ApiService.test.ts
• src/domain/accounts/api/gateways/AuthGatewayApi.test.ts
• src/domain/accounts/api/gateways/OrganizationGatewayApi.test.ts
• src/domain/accounts/api/gateways/UserGatewayApi.test.ts
• src/domain/git/api/gateways/GitProviderGatewayApi.spec.ts
• src/domain/skills/api/gateways/SkillsGatewayApi.test.ts
• src/shared/components/inputs/CopiableTextField.spec.tsx
• src/shared/components/inputs/CopiableTextarea.spec.tsx
• src/domain/git/components/ConnectionDrawer/ManageReposPanel.spec.tsx
• src/domain/git/components/ManageGitProvider/__tests__/GitProviderAdvancedPanel.spec.tsx
• src/domain/spaces/components/SpacesManagementPage/SpacesManagementPage.test.tsx

Using globs (as the issue sketches, e.g. src/domain/accounts/api/gateways/*.test.ts) is fine — non-matching globs simply match nothing, so the 4 stale entries are harmless if left as globs, but the concrete list above is cleaner. Root cause per issue: ApiService (apps/frontend/src/services/api/ApiService.ts) creates an axios instance; the 7 gateway specs share a module-level singleton — Step 2 (optional) would fix all 7 at once.

Implementation plan

1. Baseline benchmark: from apps/frontend, run ./node_modules/.bin/vitest run (nx cache bypassed) and record wall clock (run twice, back-to-back).
2. Apply Step 1 to apps/frontend/vite.config.ts: two projects, shared (isolate:false, exclude LEAKY_SPECS) + isolated (isolate:true, include LEAKY_SPECS), both extends: true. Define LEAKY_SPECS from the 11 confirmed files above.
3. Re-run the full suite and confirm it still passes. Because the codebase drifted, isolate: false may surface additional leaky specs beyond the listed 11 (previously-isolated behavior masked them). If new failures appear only under the shared project, move those specific files into LEAKY_SPECS and re-run until green — do NOT flip the whole suite back to isolated. Log which files were added.
4. Patched benchmark: re-run back-to-back and record wall clock.
5. Decision gate: if patched wall clock is under ~35s (significant win vs baseline), open a PR (gitmoji + Conventional Commit, no auto-close keywords, single commit for the config change). Otherwise open no PR and post a GitHub issue comment on Frontend Vitest suite is ~3x slower than it needs to be: every spec re-imports the full module graph #436 explaining the measured before/after and that no significant improvement was found on this machine (noting worker core count, since the win scales with import-cost × files and the suite is ~half the size of the profiled snapshot).
6. Validate touched project: ./node_modules/.bin/nx lint frontend. (nx test frontend is effectively the benchmark run.)

Notes for implementer

• Steps 2 and 3 are optional and out of scope for the primary win; do Step 1 only unless time permits and the benchmark shows Step 1 alone is insufficient.
• Keep the top-level test include/setupFiles/testTimeout so both projects inherit via extends: true; only name/isolate/include/exclude differ per project.
• Prettier runs as a pre-commit hook — don't run it manually.