fix(tests): use junction symlinks for Windows compatibility#1750
fix(tests): use junction symlinks for Windows compatibility#1750Hrishi75 wants to merge 1 commit into
Conversation
Two test files create directory symlinks via raw `symlinkSync(target, path)`, which fails with EPERM on Windows for users without admin privileges or Developer Mode. Passing junction as the third argument switches Windows to a junction (no elevation required); on POSIX the type argument is ignored by Node, so behavior is unchanged on Linux/macOS. Matches the existing pattern in `packages/plugins/workspace-worktree/src/index.ts` where production code already uses junction fallbacks on Windows for the same reason. Verified locally on Windows 11 by stashing the change, confirming the EPERM failure reproduces at both call sites, then re-applying and confirming both tests pass.
Greptile SummaryThis PR fixes two test fixtures that create directory symlinks, passing
Confidence Score: 5/5Safe to merge — two minimal, targeted one-line fixes that bring test fixtures in line with the established production pattern. Both changed lines are test-only fixtures that create directory symlinks. Passing No files in the changeset require special attention. A follow-up could address the similar bare
|
| Filename | Overview |
|---|---|
| packages/core/src/tests/project-resolver.test.ts | Adds "junction" type to symlinkSync for the symlinked-checkout test fixture — correct fix for Windows EPERM; non-Windows ignores the argument. |
| packages/web/src/tests/projects-route.test.ts | Adds "junction" type to symlinkSync for the alias-directory test fixture — same correct pattern as the core change, no behavioral difference on POSIX. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["symlinkSync(target, path, 'junction')"] --> B{Platform?}
B -->|Windows| C["Creates NTFS junction\n(no admin required)"]
B -->|macOS / Linux| D["Creates directory symlink\n('junction' argument ignored)"]
C --> E["Test passes ✓"]
D --> E
Comments Outside Diff (1)
-
packages/plugins/agent-kimicode/src/index.test.ts, line 1005 (link)Untreated directory symlink — this call creates a directory symlink (
realis created withmkdirSync) and will still fail withEPERMon Windows without admin privileges or Developer Mode, the same root cause fixed in the two files changed by this PR. Passing"junction"here would bring it in line with the updated tests and the production pattern inworkspace-worktree/src/index.ts. The same pattern appears at lines 1046, 1047, and 1319 in this file, though those targets are.jsonlfiles rather than directories and would need a different resolution (hardlink or explicit skip).Prompt To Fix With AI
This is a comment left during a code review. Path: packages/plugins/agent-kimicode/src/index.test.ts Line: 1005 Comment: **Untreated directory symlink** — this call creates a directory symlink (`real` is created with `mkdirSync`) and will still fail with `EPERM` on Windows without admin privileges or Developer Mode, the same root cause fixed in the two files changed by this PR. Passing `"junction"` here would bring it in line with the updated tests and the production pattern in `workspace-worktree/src/index.ts`. The same pattern appears at lines 1046, 1047, and 1319 in this file, though those targets are `.jsonl` files rather than directories and would need a different resolution (hardlink or explicit skip). How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
packages/plugins/agent-kimicode/src/index.test.ts:1005
**Untreated directory symlink** — this call creates a directory symlink (`real` is created with `mkdirSync`) and will still fail with `EPERM` on Windows without admin privileges or Developer Mode, the same root cause fixed in the two files changed by this PR. Passing `"junction"` here would bring it in line with the updated tests and the production pattern in `workspace-worktree/src/index.ts`. The same pattern appears at lines 1046, 1047, and 1319 in this file, though those targets are `.jsonl` files rather than directories and would need a different resolution (hardlink or explicit skip).
Reviews (1): Last reviewed commit: "fix(tests): use junction symlinks for Wi..." | Re-trigger Greptile
Summary
"junction"as the third argument tosymlinkSyncin two test files so they no longer fail withEPERMon Windows for users without admin privileges or Developer Modepackages/plugins/workspace-worktree/src/index.tswhere junctions are already used as a Windows fallbackWhy
On Windows,
symlinkSync(target, path)defaults to a directory symlink, which requiresSeCreateSymbolicLinkPrivilege— i.e. Administrator privileges or Developer Mode. For non-admin contributors without Developer Mode, this fails withEPERM: operation not permitted, symlink .... Junctions are functionally equivalent for directory targets in these tests and do not require elevation.The Node.js docs confirm the type argument is ignored on non-Windows OSes, so Linux/macOS behavior is unchanged.
Files changed
packages/core/src/__tests__/project-resolver.test.ts:218— test "matches a flat local config launched from a symlinked checkout"packages/web/src/__tests__/projects-route.test.ts:227— test "POST /api/projects > reconnects to the existing project ID when the same path is registered again"Test plan
EPERMat thesymlinkSynccall sitespnpm --filter @aoagents/ao-core test— no regressionspnpm --filter @aoagents/ao-web test— no regressionspnpm typecheckcleanubuntu-latest(verifies POSIX behavior unchanged)windows-latest