test: bootstrap Vitest coverage across JS workspaces

[partyplatter08-lab]

Summary

/claim #54

• wire package-level test scripts into the existing Turbo pnpm test pipeline for desktop, Storybook, web-cluster, and shared JS/TS packages that were missing them
• add minimal Vitest configs so each new suite has an explicit local test entrypoint
• add example tests covering desktop’s existing suites, Storybook Vite config, web-cluster metadata resolution, shared Vite alias resolution, database password hashing, env public URL fallback, embed URL construction, recorder MIME selection, shared tsconfig presets, utility helpers, web contract schemas, Effect API contract exports, backend video rules, web-domain optional schema decoding, React UI Button rendering, and Solid UI ProgressCircle rendering
• declare package-local Vitest dev dependencies and update the lockfile so filtered package tests do not rely on hoisted binaries

Validation

• pnpm install --frozen-lockfile --ignore-scripts
• pnpm test --filter=@cap/desktop --filter=@cap/storybook --filter=@cap/web-cluster --filter=config --filter=@cap/database --filter=@cap/env --filter=@cap/sdk-embed --filter=@cap/sdk-recorder --filter=tsconfig --filter=@cap/utils --filter=@cap/web-api-contract --filter=@cap/web-api-contract-effect --filter=@cap/web-backend --filter=@cap/web-domain --filter=@cap/ui --filter=@cap/ui-solid
• pnpm exec biome check apps/desktop/package.json apps/storybook/package.json apps/storybook/vitest.config.ts apps/storybook/storybook-vite.test.ts apps/web-cluster/package.json apps/web-cluster/vitest.config.ts apps/web-cluster/src/cluster/container-metadata.test.ts packages/config/package.json packages/config/vitest.config.ts packages/config/vite/relativeAliasResolver.test.ts packages/database/package.json packages/database/vitest.config.ts packages/database/crypto.test.ts packages/env/package.json packages/env/vitest.config.ts packages/env/build.test.ts packages/sdk-embed/package.json packages/sdk-embed/vitest.config.ts packages/sdk-embed/src/vanilla/cap-embed.test.ts packages/sdk-recorder/package.json packages/sdk-recorder/vitest.config.ts packages/sdk-recorder/src/core/mime-types.test.ts packages/tsconfig/package.json packages/tsconfig/vitest.config.ts packages/tsconfig/base.test.ts packages/utils/package.json packages/utils/vitest.config.ts packages/utils/src/helpers.test.ts packages/web-api-contract/package.json packages/web-api-contract/vitest.config.ts packages/web-api-contract/src/desktop.test.ts packages/web-api-contract-effect/package.json packages/web-api-contract-effect/vitest.config.ts packages/web-api-contract-effect/src/index.test.ts packages/web-backend/package.json packages/web-backend/vitest.config.ts packages/web-backend/src/Videos/EffectiveVideoRules.test.ts packages/web-domain/package.json packages/web-domain/vitest.config.ts packages/web-domain/src/utils.test.ts packages/ui/package.json packages/ui/vitest.config.ts packages/ui/src/components/Button.test.tsx packages/ui-solid/package.json packages/ui-solid/vitest.config.ts packages/ui-solid/src/ProgressCircle.test.tsx packages/ui-solid/src/jest-dom.setup.ts

Greptile Summary

This PR bootstraps Vitest coverage across 16 JS/TS workspaces that previously had no test scripts, adding vitest.config.ts files, package-local vitest dev dependencies, and example test suites for each package.

• Wires \"test\": \"vitest run\" into the Turbo pipeline for desktop, storybook, web-cluster, and all touched packages, with consistent ~2.1.9 version pinning and matching lockfile updates.
• Adds 16 new test files covering password hashing, env fallback logic, MIME type selection, embed URL construction, schema validation, Effect context tags, video rules, Solid/React component SSR output, and more.
• The ui-solid setup file (jest-dom.setup.ts) is registered as a vitest setupFile but is empty — no dom matchers are configured — and the storybook plugin-count assertion hardcodes the raw array length rather than checking plugin identity.

Confidence Score: 4/5

Safe to merge; the new test files and configs are additive and don't touch any production code paths.

All 16 new test suites exercise real logic and the assertions have been verified against their implementations. The two findings are limited to a misleading empty setup file and a fragile plugin-count assertion — neither affects production behavior or breaks the new tests as written.

packages/ui-solid/src/jest-dom.setup.ts — registered as a setup file but empty, which will silently break any future test that relies on dom matchers.

Important Files Changed

Filename	Overview
apps/storybook/storybook-vite.test.ts	New test importing vite.config directly; plugin-count assertion is fragile (see comment)
packages/ui-solid/src/jest-dom.setup.ts	Registered as a vitest setupFile but contains only export {} — dom matchers are never configured
packages/ui-solid/vitest.config.ts	Adds Solid SSR plugin and registers the empty jest-dom setup file
packages/database/crypto.test.ts	Tests hashPassword/verifyPassword — functions are self-contained and don't touch the encryption-key path, tests look correct
packages/env/build.test.ts	Tests lazy-proxy env loading with vi.resetModules() before each test; ordering is correct
apps/web-cluster/src/cluster/container-metadata.test.ts	Tests ContainerMetadata Effect layer; process.env and global fetch are properly stubbed/restored
packages/web-backend/src/Videos/EffectiveVideoRules.test.ts	Covers settings override priority, explicit-false preservation, and password hash collection — all assertions match the implementation
packages/utils/src/helpers.test.ts	Tests UUID round-trip, class merging, progress circle geometry, display-progress falsy-zero handling, and email restrictions — all correct
packages/ui/src/components/Button.test.tsx	SSR snapshot tests for Button; checks class names, link rendering, kbd hint, and spinner inline style — all match the implementation
packages/ui-solid/src/ProgressCircle.test.tsx	Verifies ARIA attributes, variant class names, and clamped stroke-dashoffset values — math matches the component's radius/circumference calculation
packages/sdk-recorder/src/core/mime-types.test.ts	Stubs MediaRecorder global before each call; priority selection and fallback tested correctly
pnpm-lock.yaml	Adds package-local vitest ~2.1.9 entries for each new workspace; consistent version pinning

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/ui-solid/src/jest-dom.setup.ts:1
**Empty setup file has misleading name**

The file is registered as a Vitest `setupFile` in `ui-solid/vitest.config.ts` and its name implies it should extend Vitest's `expect` with `@testing-library/jest-dom` matchers (e.g. `toBeInTheDocument`, `toHaveAttribute`). Currently it only exports an empty object, so any future test that calls those matchers will fail with a cryptic "is not a function" error rather than a clear "jest-dom not configured" message. If DOM matchers are not needed, the `setupFiles` entry and this file should be removed; if they are needed, the file should contain `import "@testing-library/jest-dom"` and the package should be added as a dev dependency.

### Issue 2 of 2
apps/storybook/storybook-vite.test.ts:7
**Plugin-count assertion is fragile**

`toHaveLength(2)` checks the number of top-level entries in the raw `plugins` array literal — it passes regardless of whether the plugins are correct objects and will break silently when a third plugin is added to the config. Consider asserting on plugin identity instead (e.g. checking a plugin's `name` field), or at minimum checking `>= 2`.

```suggestion
		expect(config.plugins!.length).toBeGreaterThanOrEqual(2);
```

_{Reviews (1): Last reviewed commit: "chore: revise bounty claim package" | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[greptile-apps]

Empty setup file has misleading name

The file is registered as a Vitest setupFile in ui-solid/vitest.config.ts and its name implies it should extend Vitest's expect with @testing-library/jest-dom matchers (e.g. toBeInTheDocument, toHaveAttribute). Currently it only exports an empty object, so any future test that calls those matchers will fail with a cryptic "is not a function" error rather than a clear "jest-dom not configured" message. If DOM matchers are not needed, the setupFiles entry and this file should be removed; if they are needed, the file should contain import "@testing-library/jest-dom" and the package should be added as a dev dependency.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/ui-solid/src/jest-dom.setup.ts
Line: 1

Comment:
**Empty setup file has misleading name**

The file is registered as a Vitest `setupFile` in `ui-solid/vitest.config.ts` and its name implies it should extend Vitest's `expect` with `@testing-library/jest-dom` matchers (e.g. `toBeInTheDocument`, `toHaveAttribute`). Currently it only exports an empty object, so any future test that calls those matchers will fail with a cryptic "is not a function" error rather than a clear "jest-dom not configured" message. If DOM matchers are not needed, the `setupFiles` entry and this file should be removed; if they are needed, the file should contain `import "@testing-library/jest-dom"` and the package should be added as a dev dependency.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Plugin-count assertion is fragile

toHaveLength(2) checks the number of top-level entries in the raw plugins array literal — it passes regardless of whether the plugins are correct objects and will break silently when a third plugin is added to the config. Consider asserting on plugin identity instead (e.g. checking a plugin's name field), or at minimum checking >= 2.

Suggested change

	expect(config.plugins).toHaveLength(2);
	expect(config.plugins!.length).toBeGreaterThanOrEqual(2);

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/storybook/storybook-vite.test.ts
Line: 7

Comment:
**Plugin-count assertion is fragile**

`toHaveLength(2)` checks the number of top-level entries in the raw `plugins` array literal — it passes regardless of whether the plugins are correct objects and will break silently when a third plugin is added to the config. Consider asserting on plugin identity instead (e.g. checking a plugin's `name` field), or at minimum checking `>= 2`.

```suggestion
		expect(config.plugins!.length).toBeGreaterThanOrEqual(2);
```

How can I resolve this? If you propose a fix, please make it concise.