Replies: 2 comments 7 replies
-
|
This is a tricky thing because according to the graphql specification https://spec.graphql.org/June2018/#sec-Comments
So once a document is parsed into a runtime representation (eg the objects like Types and fields and arguments in graphql instead have a description. https://spec.graphql.org/June2018/#Description This is captured in a first class way when you create the runtime representation of a type or field or argument eg But this linting package has decided to use Now it turns out is not so simple. There is a runtime representation of a type AND there is an AST representation of that type and the 2 are related BUT not the same
BUT its tricky because imagine this valid type definition This results in 1 runtime object type Well it turns out that However in line with the graphql spec - the
However.... We do have an experimental class If this feels confusing - it is because we have competing demands here - we have a graphql spec saying comments dont matter, we have some people who dont want them stored for memory reasons (including the AST elements) and then we have some like yourself who DO want to capture comments. So given these design trade offs we decided in the main
We would be interested in seeing how you changed SchemaPrinter to include comments say. |
Beta Was this translation helpful? Give feedback.
-
|
Ahh interesting code - basically you grab the comments on GraphqlSchema objects from the possibly attached AST definitions This will work because Nice |
Beta Was this translation helpful? Give feedback.
-
|
Correct. Seems to do the job without significant side effects, I think. What do you think about adding this feature? |
Beta Was this translation helpful? Give feedback.
-
|
I think this would be a great feature We would need another option in the schema printer options like you have and I think it would be off by default say but then the code that I saw would work well I think Are you proposing to make a PR here? |
Beta Was this translation helpful? Give feedback.
-
|
Option with off default makes sense. Yes, I would propose a PR. Not sure of the end-to-end process for this project but I can take a stab at it if you could point me in the right direction. |
Beta Was this translation helpful? Give feedback.
-
Simply fork the graphql-java into your own copy and then make the code changes. You can then raise a PR against graphql-java from that fork The code you linked is pretty much ready to go and needs to be retrofitted back into SchemaPrinter |
Beta Was this translation helpful? Give feedback.
-
|
WIP PR #3287 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We use graphql-eslint for schema linting and frequently use ESLint configuration comments when disabling rules.
Our schema is defined programmatically and we generate SDL using SchemaPrinter. However, the comments we add in Java code do not get printed to SDL by
SchemaPrinter.So, we ended up modifying
SchemaPrinterto support our programmatic comments. This seems to work well for this purpose and our code changes seem to be relatively simple.Would like to suggest this as a feature.
PS: I saw similar request previously discussed in Consider adding support for GraphQL comments to SDL creation but the schema linting angle was not part that discussion and makes this need more significant than just documentation need.
Beta Was this translation helpful? Give feedback.
All reactions