This is a tricky thing because according to the graphql specification

https://spec.graphql.org/June2018/#sec-Comments

Comments behave like white space and may appear after any token, or before a line terminator, and have no significance to the semantic meaning of a GraphQL Document.

So once a document is parsed into a runtime representation (eg the objects like GraphQLObjectType), comments have no meaning.

Types and fields and arguments in graphql instead have a description.

https://spec.graphql.org/June2018/#Description

"""
A simple GraphQL schema which is well described.
"""
type Query {
  """
  Translates a string from a given language into a different language.
  """
  translate(
    "The original language that `text` is provided in."
    fromLanguage: Language

    "The translated language to be returned."
    toLanguage: Language

    "The text to be translated."
    text: String
  ): String
}

This is captured in a first class way when you create the runtime representation of a type or field or argument

eg graphql.schema.GraphQLObjectType#getDescription

But this linting package has decided to use // comments and these cant be easily round tripped.

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

graphql.schema.GraphQLObjectType#getDefinition returns the (ooptional) AST node that defined the runtime representation say

graphql.language.ObjectTypeDefinition can (optionally) capture the AST element and its comments via graphql.language.AbstractNode#getComments which is a list of comments associated with the AST element

BUT its tricky because imagine this valid type definition

// comment 1
" description of Foo"
type Foo {
   fieldA : Boolean
}

// comment 2
extend type Foo {
  fieldB : Boolean
}

This results in 1 runtime object type Foo but it came from N AST elements, each with their own comments. So how do they apply to Foo - what order etc.?

Well it turns out that graphql.schema.idl.SchemaPrinter.Options#isUseAstDefinitions has a boolean (off by default) to use the AST definitions if they are present.

However in line with the graphql spec - the AstPrinter ignores comments - because

Comments behave like white space and may appear after any token, or before a line terminator, and have no significance to the semantic meaning of a GraphQL Document.

However....

We do have an experimental class graphql.language.PrettyAstPrinter which does keep comments HOWEVER its not used by the SchemaPrinter so you would need to traverse the schema element tree yourself and call PrettyAstPrinter on it yourself.

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 dont have a place to capture comments onto the runtime schema objects
• we dont want to add a place to capture comments
  • because the spec says they are semantically insignificant
  • people (in the past) have complained it burns memory unnecessarily

We would be interested in seeing how you changed SchemaPrinter to include comments say.