-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normalize drive letter in file path #980
Conversation
# Conflicts: # packages/vscode-tailwindcss/CHANGELOG.md
I hadn't merged this because I wasn't ready to because I wanted to do more testing but after all the Windows issues some people have I'm going to because it's better than the status quo (plus in my testing it does fix at least one project with problems). Thanks for this! Weird thing is that some of my projects work perfectly and then some don't and I can't figure out when VSCode decides |
And I think I figured it out. At some point somewhere the vscode-uri package updated for |
@thecrypticace I had the same issue. An Astro based project worked fine, but an ASP.NET project didn't. The ASP.NET project is the one I was having all the issues with which was leading me to think it was coming from one of those extensions, or just a lack of support for Razor views/syntax which is an issue but is unrelated. Even with v0.12.1 I still wasn't getting IntelliSense in one of my workspaces, and what I just realized is I had it pinned in my taskbar with the same incorrect casing that GitHub Desktop was using. Un-pin, re-open, re-pin and now it's working. Picomatch has two options not currently used, one is for Windows and the other is for case sensitivity. My first attempt at fixing this set the case sensitivity flag if the OS was Windows. That worked but still has room for error since an equality check could fail even though picomatch would pass, and then you're chasing other random bugs. From what I was reading in the VSCode issues they don't make any guarantees that the casing of the file path you get on Windows is accurate. A commonly reported issue from extension authors is open a workspace with Their stance seems to be extension authors who care about casing should use the path they're given and check with the filesystem via The ESLint extension had to work around this exact issue, you can see some of their helpers here ( |
What a nightmare 😱 I guess I have some work ahead of me lol — going to do an audit of all filesystem path stuff in intellisense and the language server. Also going to set up Windows CI alongside all this too. |
I've been trying to figure out why my files don't always get picked up by this extension. I tracked it back to an issue in VSCode where opening a workspace using a different casing than what's on disk can cause the 'wrong' value to be passed into this function, and then matching doesn't work. Even after I corrected the config on my end I was still having an inconsistent experience. What I then found was my pattern had an uppercase
C
(#960) while my file path had a lowercasec
. Normalizing both paths seems to fix this but I'm not sure if there's other spots that may need to be updated too.Some background on the VSCode issue since it was driving me nuts for weeks, if not months. The folder my repo is in uses PascalCase, but I apparently added it to GitHub Desktop using camelCase. Every time I opened a file, or the workspace, from GitHub Desktop it would pass VSCode a path like
c:/myProjects/Project
, but on disk it's actuallyC:/MyProjects/Project
. This meant the value ofdocument.uri
had a different case than thepattern
had so picomatch wasn't returning true. This was made worse by VSCode caching these file paths inC:\Users\<user>\AppData\Roaming\Code\User\workspaceStorage\<workspace>\state.vscdb
. Correcting my path in GitHub Desktop, deleting the cache, and the drive letter normalization change here looks to fix my problem and I get IntelliSense again.