-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fix: lsp server paths for windows, special chars, fragment/object cache #2072
Conversation
🦋 Changeset detectedLatest commit: 4a3bf20 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest changes of this PR are available as canary in npm (based on the declared |
using the standard `vscode-uri` package, this should fix the parsing of file URIs by `graphql-language-service-server` in cases such as: - windows without WSL - special/unicode characters in filenames - likely other cases previously we were using the old approach of `URL(uri).pathname` which was not working! this should fix issues with object and fragment type completion as well I think
348e466
to
04a2552
Compare
Codecov Report
@@ Coverage Diff @@
## main #2072 +/- ##
==========================================
- Coverage 65.70% 63.34% -2.36%
==========================================
Files 85 94 +9
Lines 5106 5443 +337
Branches 1631 1715 +84
==========================================
+ Hits 3355 3448 +93
- Misses 1747 1990 +243
- Partials 4 5 +1
Continue to review full report at Codecov.
|
fixing windows and unicode-containing file paths
using the standard
vscode-uri
package, this should fix the parsing of file URIs bygraphql-language-service-server
in cases such as:previously we were using the old approach of
URL(uri).pathname
which was not working! it was url-encoding these characters which is not helping anyone hahafixing object and fragment definition cache across OSes
also, when switching back from
fileURLToPath
, we left one case inGraphQLCache
which may impact how the fragment and object type cache are being loaded with a global file glob. this existing feature has led users to expect fragments and objects to load magically from config without configuration and we will need to change it, but for now we will keep the magic glob from rootDir. this is set from the graphql config rootDir so if that is overridden, it breaks how this cache works. we need in the future for users to specify the files or globs where fragments or object type definitions are contained.also for #2066 made it so that graphql config is not loaded into the file cache unnecessarily, and that it's only loaded on editor save events rather than on file changed events
fixes #1644 and #2066 and I think also #2071