Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
[email protected]
Minor Changes
#3521
aa6dbbb4
Thanks @acao! - Fix many schema and fragment lifecycle issues, not all of them, but many related to cacheing. Note: this makescacheSchemaForLookup
enabled by default again for schema first contexts.This fixes multiple cacheing bugs, upon addomg some in-depth integration test coverage for the LSP server. It also solves several bugs regarding loading config types, and properly restarts the server and invalidates schema when there are config changes.
Bugfix Summary
schemaCacheTTL
which can be configured in the IDE settings (vscode, nvim) or in the graphql config file. (1)on
type!)schemaCacheTTL
settingNotes
schema.graphql
orintrospection.json
will always provide a better experience. many graphql frameworks have this built in! Otherwise, we must use this new lazy polling approach if you provide a url schema (this includes both introspection URLs and remote file URLs, and the combination of these).Known Bugs Fixed
package.json
is detected but doesn't contain graphql config #2820Test Improvements
What's next?
Another stage of the rewrite is already almost ready. This will fix even more bugs and improve memory usage, eliminate redundant parsing and ensure that graphql config's loaders do all of the parsing and heavy lifting, thus honoring all the configs as well. It also significantly reduces the code complexity.
There is also a plan to match Relay LSP's lookup config for either IDE (vscode, nvm, etc) settings as they provide, or by loading modules into your
graphql-config
!Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown#3521
aa6dbbb4
Thanks @acao! - IntroducelocateCommand
based on Relay LSPpathToLocateCommand
:Now with
<graphql config>.extensions.languageService.locateCommand
, you can specify either the existing signature for relay, with the same callback parameters and return signature (of a string delimited by:
characters), or you can return an object with {uri, range} for the exact set of coordinates for the destination range. the function can be sync or async.Relay LSP currently supports
Type
andType.field
for the 2nd argument. Ours also returnsType.field(argument)
as a point of reference. It works with object types, input types, fragments, executable definitions and their fields, and should work for directive definitions as well.In the case of unnamed types such as fragment spreads, they return the name of the implemented type currently, but I'm curious what users prefer here. I assumed that some people may want to not be limited to only using this for SDL type definition lookups. Also look soon to see
locateCommand
support added for symbols, outline, and coming references and implementations.The module at the path you specify in relay LSP for
pathToLocateCommand
should work as such.Passing a string as a module path to resolve is coming in a follow-up release. Then it can be used with
.yml
,.toml
,.json
,package.json#graphql
, etcFor now this was a quick baseline for a feature asked for in multiple channels!
Let us know how this works, and about any other interoperability improvements between our graphql LSP and other language servers (relay, intellij, etc) used by you and colleauges in your engineering organisations. We are trying our best to keep up with the awesome innovations they have 👀!
Updated dependencies [
aa6dbbb4
,aa6dbbb4
,aa6dbbb4
]:[email protected]
Minor Changes
#3521
aa6dbbb4
Thanks @acao! - Fix many schema and fragment lifecycle issues, not all of them, but many related to cacheing. Note: this makescacheSchemaForLookup
enabled by default again for schema first contexts.This fixes multiple cacheing bugs, upon addomg some in-depth integration test coverage for the LSP server. It also solves several bugs regarding loading config types, and properly restarts the server and invalidates schema when there are config changes.
Bugfix Summary
schemaCacheTTL
which can be configured in the IDE settings (vscode, nvim) or in the graphql config file. (1)on
type!)schemaCacheTTL
settingNotes
schema.graphql
orintrospection.json
will always provide a better experience. many graphql frameworks have this built in! Otherwise, we must use this new lazy polling approach if you provide a url schema (this includes both introspection URLs and remote file URLs, and the combination of these).Known Bugs Fixed
package.json
is detected but doesn't contain graphql config #2820Test Improvements
What's next?
Another stage of the rewrite is already almost ready. This will fix even more bugs and improve memory usage, eliminate redundant parsing and ensure that graphql config's loaders do all of the parsing and heavy lifting, thus honoring all the configs as well. It also significantly reduces the code complexity.
There is also a plan to match Relay LSP's lookup config for either IDE (vscode, nvm, etc) settings as they provide, or by loading modules into your
graphql-config
!#3521
aa6dbbb4
Thanks @acao! - IntroducelocateCommand
based on Relay LSPpathToLocateCommand
:Now with
<graphql config>.extensions.languageService.locateCommand
, you can specify either the existing signature for relay, with the same callback parameters and return signature (of a string delimited by:
characters), or you can return an object with {uri, range} for the exact set of coordinates for the destination range. the function can be sync or async.Relay LSP currently supports
Type
andType.field
for the 2nd argument. Ours also returnsType.field(argument)
as a point of reference. It works with object types, input types, fragments, executable definitions and their fields, and should work for directive definitions as well.In the case of unnamed types such as fragment spreads, they return the name of the implemented type currently, but I'm curious what users prefer here. I assumed that some people may want to not be limited to only using this for SDL type definition lookups. Also look soon to see
locateCommand
support added for symbols, outline, and coming references and implementations.The module at the path you specify in relay LSP for
pathToLocateCommand
should work as such.Passing a string as a module path to resolve is coming in a follow-up release. Then it can be used with
.yml
,.toml
,.json
,package.json#graphql
, etcFor now this was a quick baseline for a feature asked for in multiple channels!
Let us know how this works, and about any other interoperability improvements between our graphql LSP and other language servers (relay, intellij, etc) used by you and colleauges in your engineering organisations. We are trying our best to keep up with the awesome innovations they have 👀!
Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknownUpdated dependencies [
aa6dbbb4
]:[email protected]
Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknownUpdated dependencies [
aa6dbbb4
]:[email protected]
Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknownUpdated dependencies [
aa6dbbb4
]:[email protected]
Patch Changes
03ab3a6b
,aa6dbbb4
]:@graphiql/[email protected]
Patch Changes
03ab3a6b
]:@graphiql/[email protected]
Patch Changes
03ab3a6b
]:@graphiql/[email protected]
Patch Changes
#3602
03ab3a6b
Thanks @thomasheyenbrock! - Avoid using deprecated Component.defaultProps for icon titlesUpdated dependencies [
aa6dbbb4
]:[email protected]
Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown[email protected]
Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknownUpdated dependencies [
aa6dbbb4
]:[email protected]
Minor Changes
#3521
aa6dbbb4
Thanks @acao! - Fix many schema and fragment lifecycle issues, not all of them, but many related to cacheing. Note: this makescacheSchemaForLookup
enabled by default again for schema first contexts.This fixes multiple cacheing bugs, upon addomg some in-depth integration test coverage for the LSP server. It also solves several bugs regarding loading config types, and properly restarts the server and invalidates schema when there are config changes.
Bugfix Summary
schemaCacheTTL
which can be configured in the IDE settings (vscode, nvim) or in the graphql config file. (1)on
type!)schemaCacheTTL
settingNotes
schema.graphql
orintrospection.json
will always provide a better experience. many graphql frameworks have this built in! Otherwise, we must use this new lazy polling approach if you provide a url schema (this includes both introspection URLs and remote file URLs, and the combination of these).Known Bugs Fixed
package.json
is detected but doesn't contain graphql config #2820Test Improvements
What's next?
Another stage of the rewrite is already almost ready. This will fix even more bugs and improve memory usage, eliminate redundant parsing and ensure that graphql config's loaders do all of the parsing and heavy lifting, thus honoring all the configs as well. It also significantly reduces the code complexity.
There is also a plan to match Relay LSP's lookup config for either IDE (vscode, nvm, etc) settings as they provide, or by loading modules into your
graphql-config
!Patch Changes
#3521
aa6dbbb4
Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:.graphqls
ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown#3521
aa6dbbb4
Thanks @acao! - IntroducelocateCommand
based on Relay LSPpathToLocateCommand
:Now with
<graphql config>.extensions.languageService.locateCommand
, you can specify either the existing signature for relay, with the same callback parameters and return signature (of a string delimited by:
characters), or you can return an object with {uri, range} for the exact set of coordinates for the destination range. the function can be sync or async.Relay LSP currently supports
Type
andType.field
for the 2nd argument. Ours also returnsType.field(argument)
as a point of reference. It works with object types, input types, fragments, executable definitions and their fields, and should work for directive definitions as well.In the case of unnamed types such as fragment spreads, they return the name of the implemented type currently, but I'm curious what users prefer here. I assumed that some people may want to not be limited to only using this for SDL type definition lookups. Also look soon to see
locateCommand
support added for symbols, outline, and coming references and implementations.The module at the path you specify in relay LSP for
pathToLocateCommand
should work as such.Passing a string as a module path to resolve is coming in a follow-up release. Then it can be used with
.yml
,.toml
,.json
,package.json#graphql
, etcFor now this was a quick baseline for a feature asked for in multiple channels!
Let us know how this works, and about any other interoperability improvements between our graphql LSP and other language servers (relay, intellij, etc) used by you and colleauges in your engineering organisations. We are trying our best to keep up with the awesome innovations they have 👀!
Updated dependencies [
aa6dbbb4
,aa6dbbb4
,aa6dbbb4
]: