feat: initial support for graphql.persisted
#240
Merged
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.
Related to 0no-co/gql.tada#77
This is an initial PR to support
graphql.persisted
as an LSP target, the goal is to provide semantic diagnostics for:Another goal is to provide a code-action to generate the
hash
associated with this invocation where we'll check whether there is a missing, or missmatched hash present and then present the user with a prompt to generate a SHA256 for the document we have found through following the TypeArgument.We could also provide diagnostics for missmatched arguments, i.e. when the hash isn't correct compared to the hash we calculate for the referenced document but because we want to allow for ease I opted out of that.
Risks of the above choice could be that a document evolves but the user forgets to generate a new persisted-hash.
Another choice we could make is to continuously maintain a
persisted-operations.json
file while development happens so that the user can feed this to their GraphQL server during dev, otherwise we might need to insert thedefinitions
so normal query-texts can be sent during development. This in turn would force our hand in providing some kind of build tool that omits these arguments, an alternative would be to tell folks to do the followingThe workflow enabled by this addition would be the following
The benefit of using the document as a type-argument is that when the bundle is built the user will have no references to the query-text left. For some GraphQL clients this could pose an issue and force us to add the
definitions
as the second argument for instance.