-
Notifications
You must be signed in to change notification settings - Fork 46
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
NON_NULL_TYPE node is missing BANG SyntaxKind #142
Comments
@kpeters-cbsi thank you so much for submitting this! It seems like we are missing the BANG (!) token in the AST. The node gets recorded as as NON_NULL_TYPE, but it doesn't have the token that actually makes it NON_NULL. This is an easy fix, and I can fix and publish a patch for you tomorrow. |
We are missing BANG token in the AST when a NON_NULL_TYPE gets created. Although the node created is indeed NON_NULL_TYPE, it's also important to keep the original set of tokens. The NON_NULL_TYPE after this commit looks like this: ```txt - [email protected] - [email protected] "\n " - [email protected] - [email protected] - [email protected] "Int" - [email protected] "!" ``` fixes #142
We are missing BANG token in the AST when a NON_NULL_TYPE gets created. Although the node created is indeed NON_NULL_TYPE, it's also important to keep the original set of tokens. The NON_NULL_TYPE after this commit looks like this: ```txt - [email protected] - [email protected] "\n " - [email protected] - [email protected] - [email protected] "Int" - [email protected] "!" ``` fixes #142
So when will we see a new release incorporating this fix? |
today! I found another issue sort of related to this in #143 which you'll run into as soon as you have more than one variable, for example: mutation MyMutation($custId: Int!, $b: String ) {
myMutation(custId: $custId)
} the to_string() version of the doc is entirely nonsensical: mutation MyMutation($custId: , Int!$b: String) {
myMutation(custId: $custId)
} |
@kpeters-cbsi you can now install |
Description
This applies to
apollo-parser
v0.2.0When a mutation is parsed into a Document
doc
,doc.toString()
does not correctly preserve the "required" state of the variables.Steps to reproduce
Execute the following Rust program:
Expected result
Should produce a semantically identical copy of the response having
$custId
marked as required.Actual result
Produced a copy of the response where
$custId
was not a required variable.Environment
The text was updated successfully, but these errors were encountered: