-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Description when print a AST graphql object #1521
Comments
@amian84 You are using legacy SDL syntax. You should use standard syntax for descriptions: type Object1{
"""description of attribute att1"""
att1: String
} In that case, description would be preserved in |
Hi @IvanGoncharov , i'm trying with the standard syntax as you commented me. But the parser fails when trying parse the description const graphqllang= require('graphql/language');
var test= graphqllang.parse(`type Test{
"""Description"""
a:String
}`);
|
@amian84 It looks like you are using |
@IvanGoncharov perfect, I updated and works perfect, now I've to face another problem... graphql-faker doesnt work with standard syntax for descriptions heheh Thanks for all |
@amian84 It's tracked here: graphql-kit/graphql-faker#41 |
Well shoot, I'd been using Although fwiw we do have places in our SDL files that should be the new "quote-comments" (so I'm moving these comments over to those now) but we also have other places that are just commenting out "dead code" and/or making "notes to the maintainer" that aren't made as "javadocs/jsdocs" for the next node, i.e.: type Foo { ... }
# old code
# asdf
# asdf
" Bar. "
type Bar { ... } I'm trying to write a tool that loads I have this tool basically working, but currently the For expediency, I'll probably just convert these ...just as more use-cases for old-/non-description comments, see in-SDL comments that apply to a set of nodes, i.e.: extend type Query {
# These next few queries are for our zaz module
# with a longer description of the past rationale that
# relates to both fooQuery and barQuery. I don't mean for
# this to be pulled into the javadocs of `fooQuery` but I still
# want it for my future maintainers to read.
" fooQuery description. "
fooQuery { ... }
" barQuery description. "
barQuery { ... }
} I get "old comments are not the new descriptions", but it still seems like a mistake to drop them from the AST and break the isomorphism of If I wanted to fork graphql-js to keep them around just for us, does this seem doable or are there precedence/ambiguity/etc. reasons that led to them being handled this way? |
@stephenh This is definitely something we want to add in the near future. Please see this issue for more context and a possible workaround. |
@danielrearden oh great! My fault for not seeing that newer issue. :-) Thanks for the quick response! |
Hi, currently I've parsing a graphQL schema with parse function to AST object. Later I split the schema into different array of object to store into different files, one per type (interface, object type, enums...).
When I print the partial AST object to string again, this function avoid the descriptions attribute.. Then I lost all schema description. There are any solution for that or maybe this will be implement as new feature?
Example:
type Object1{
#description of attribute att1
att1: String
}
When print the AST object I lost descriptions
type Object1{
att1: String
}
The text was updated successfully, but these errors were encountered: