fix(vscode): normalize paths on Windows#18627
fix(vscode): normalize paths on Windows#18627dwelle wants to merge 1 commit intooxc-project:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows-specific bug where the VSCode extension fails to re-lint files on change/save due to inconsistent drive letter casing in file paths. The issue occurred because different parts of VSCode's API return workspace URIs with different casings (e.g., /c:/ vs /C:/), causing Map lookups to fail.
Changes:
- Added
normalizeWorkspacePath()method to consistently lowercase URI paths on Windows - Updated all Map operations (
set,delete,get) to use normalized paths - Added comprehensive documentation explaining the Windows path casing issue
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| private normalizeWorkspacePath(uri: Uri): string { | ||
| const path = uri.path; | ||
| return process.platform === "win32" ? path.toLowerCase() : path; | ||
| } |
There was a problem hiding this comment.
Consider adding unit tests for the normalizeWorkspacePath method to verify that it correctly handles different path casings on Windows. For example, test that paths like /C:/Users/Project and /c:/users/project both normalize to the same value on Windows, while paths on other platforms remain unchanged.
This would help prevent regressions and document the expected behavior, especially since the issue being fixed (path casing on Windows) is somewhat subtle.
There was a problem hiding this comment.
if we wanna test this, should we mock process.platform.win32 since the tests are only running on linux?
There was a problem hiding this comment.
should not be needed when .fsPath is used 🤞
|
Can you test your problem by avoiding |
fix #18514
The fix was vibecoded by Claude Code
How I tested:
$ cd editors/vscode$ pnpm run compile$ pnpm run packageCode_HdT82plwSF.mp4