Comments should have no significance to the semantic meaning about parser HOT 7 CLOSED

I just have to note that this is just a draft specification requirement. So for now, support for this feature can wait a bit.

from parser.

Agree that it may wait, but for example HotChocolate and all graphql syntax highlighting plugins I've used already support it.

I've started implementing #33, as we might have to just switch to HotChocolate otherwise.

As a side note (which may be extracted into a separate issue), the current parsing logic (not the entities) doesn't seem to match the structure of the spec. I don't know if it's due to the historical development reasons, or the GraphQL spec have evolved quite far, but I think it would be great to refactor the parser to match the structure of the specification. For example (as defined in the spec):
Document has a list of Definitions.
Definition is either ExecutableDefinition, TypeSystemDefinition or TypeSystemExtension.
ExecutableDefinition is either an OperationDefinition or FragmentDefinition.
etc.
And parse the input using exactly the same hierarchy. It will allow the code to match the spec 1:1, and future changes would be much easier to implement. What do you think? I can come up with the implementation POC if you think it's worthwhile

from parser.

Document has a list of Definitions.
Definition is either ExecutableDefinition, TypeSystemDefinition or TypeSystemExtension.
ExecutableDefinition is either an OperationDefinition or FragmentDefinition.
etc.

The structure of the parser document is the same, isn't it?

from parser.

The current 2018 spec says the same thing about comments, by the way, that they are treated as white space. This seems like an important fix

from parser.

Fixed by #105 ?

from parser.

Yes (optional). Also see #104 and #80

from parser.

Also see #101 (comment)

from parser.