test(core-tools): resolve macOS symlink path mismatches in tests - #27990

Summary

This PR resolves macOS-specific test failures in EditTool and WriteFileTool caused by path resolution mismatches. On macOS, /var is a symbolic link pointing to /private/var. While the production code correctly resolves paths to their real paths (starting with /private/var), the mock workspace context and some test assertions expected the unresolved paths (starting with /var), leading to boundary validation and assertion failures.

Details

We applied targeted, platform-aware fixes to align the test environment with the production path resolution behavior:

1. Mock Workspace Context (packages/core/src/test-utils/mockWorkspaceContext.ts):

   • Updated createMockWorkspaceContext to resolve all input directories to their real paths using fs.realpathSync. This ensures that on macOS, any directory starting with /var/... is correctly resolved to /private/var/..., matching the behavior of the production code and fixing 30 failures in edit.test.ts and boundary failures in write-file.test.ts.

2. WriteFileTool Tests (packages/core/src/tools/write-file.test.ts):

   • Updated three specific test cases to resolve expected paths to their real paths using resolveToRealPath before asserting:
     • 'should throw an error if path is a directory': Resolves dirAsFilePath to its real path before asserting the thrown error message.
     • 'should return error if reading an existing file fails (e.g. permissions)': Resolves filePath to its real path before asserting that fsService.readTextFile was called with it.
     • 'should return $errorType error when write fails with $errorCode': Resolves filePath to its real path before constructing the expectedMessage used in assertions.

3. EditTool Tests (packages/core/src/tools/at-reference-resolution.test.ts):

   • Added comprehensive integration tests to verify that EditTool successfully creates new files in nested subdirectories when the path is prefixed with @/ or @\ and the first segment does not exist, without creating a literal @ directory.

Related Issues

How to Validate

Step 1: Run the modified test suites on macOS

Run the following commands on a macOS machine to verify that all tests pass successfully:

npx vitest run packages/core/src/tools/edit.test.ts
npx vitest run packages/core/src/tools/write-file.test.ts
npx vitest run packages/core/src/tools/at-reference-resolution.test.ts

Expected Output: All 125+ tests pass successfully with zero failures.

Step 2: Run the test suites on Linux/Windows (Regression Check)

Run the same commands on Linux or Windows to ensure zero regressions:

npx vitest run packages/core/src/tools/write-file.test.ts packages/core/src/tools/at-reference-resolution.test.ts

Expected Output: All 63 tests pass successfully with zero failures.

Step 3: Run linting and type checking

Verify that the codebase remains fully compliant with the project's engineering standards:

npm run lint && npm run typecheck

Expected Output: Zero linting or type-checking errors.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
  • Windows
    • npm run
    • npx
  • Linux
    • npm run
    • npx