Files
codegraph/vitest.workspace.mts
T
Colby Mchenry 7bbc1fb7f6 fix(tests): the test suite no longer writes to the developer's real home dir (#2275) (#2295)
Running the suite on a machine with Claude Code configured could wire the
CodeGraph prompt hook into the developer's own ~/.claude/settings.json:
every upgrade test whose fake upgrade succeeded ran the real post-upgrade
prompt-hook self-heal, which detected the real global Claude profile and
wrote it. Daemon suites likewise left records in the real
~/.codegraph/daemons. On Windows a HOME-only redirect would not have
helped, since os.homedir() reads USERPROFILE there.

- The prompt-hook writer is now injected through UpgradeDeps
  (wirePromptHook); the CLI passes the real defaultWirePromptHook and the
  upgrade tests a recorder. New tests pin that a successful upgrade calls
  the recorder and that the real writer never touches a configured profile.
- A vitest setupFiles entry gives every engine test file a throwaway home:
  HOME/USERPROFILE (plus HOMEDRIVE/HOMEPATH/APPDATA/LOCALAPPDATA on
  Windows), XDG_CONFIG_HOME, and GIT_CONFIG_GLOBAL (seeded with a dummy
  identity) point into it, and CLAUDE_CONFIG_DIR/CODEX_HOME/COPILOT_HOME/
  HERMES_HOME are cleared. Spawned CLI/MCP children inherit it. A sandbox
  test asserts os.homedir(), the Claude profile, the daemon registry, a
  child process and git's global config all resolve inside it.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 06:18:46 +00:00

64 lines
2.5 KiB
TypeScript

import { svelte, vitePreprocess } from '@sveltejs/vite-plugin-svelte';
import { defineWorkspace } from 'vitest/config';
/**
* Two projects, one command (`npm test` still runs everything).
*
* The split exists because of exactly one suite. `ui-package.test.ts` mounts
* `@colbymchenry/codegraph-ui`'s components against a mock adapter (task
* CG-61), and to do that it needs three things the engine's suites must never
* see:
*
* - the **Svelte plugin**, to compile `.svelte` and `.svelte.ts` modules;
* - **jsdom**, because a component without a document is not a render;
* - `resolve.conditions: ['browser']`, so `svelte` resolves to its client
* build rather than its server one (`mount()` throws on the server).
*
* That last one is why this is a workspace rather than one config with a
* couple of extra fields. `browser` is a package-resolution condition, not a
* test setting: applied globally it would also hand the engine's suites the
* browser builds of `web-tree-sitter` and friends, and the failures that
* causes look nothing like their cause.
*
* The engine project `extends` the shared base, so the env vars, Node guard and
* home-dir sandbox in `vitest.config.mts` still apply to every engine test. The
* ui project does not — see the note on it.
*/
export default defineWorkspace([
{
extends: './vitest.config.mts',
test: {
name: 'engine',
include: ['__tests__/**/*.test.ts'],
exclude: ['**/node_modules/**', '**/dist/**', '__tests__/ui-package.test.ts'],
},
},
{
// Deliberately NOT `extends`: a workspace project CONCATENATES the base's
// `include` with its own, so extending here would run all 200-odd engine
// suites a second time inside jsdom (and two of them fail there, for
// reasons that have nothing to do with anything). This project stands
// alone, and it needs none of the base's spawn-related env anyway.
plugins: [
// The same preprocessor `ui/svelte.config.js` builds with, so the test
// compiles what the package ships.
svelte({ preprocess: vitePreprocess() }),
],
resolve: { conditions: ['browser'] },
test: {
name: 'ui',
globals: true,
include: ['__tests__/ui-package.test.ts'],
environment: 'jsdom',
server: {
deps: {
// `@xyflow/svelte` ships uncompiled `.svelte` files, so it has to go
// through the plugin above rather than be externalised to Node,
// which has no idea what a `.svelte` file is.
inline: [/@xyflow\/svelte/],
},
},
},
},
]);