Add syntax highlighting to graphql-tools

[klis87]

Please add support for highlighting for graphql-tools, or add a settings like EmbeddedQueryParser in .gqlconfig with startTag and endTag to enable highlighting.

The convention in graphql-tools is to declare types like this:

const typeDefs = `
  interface Node {
    id: Int!
  }
`;

[kumarharsh]

@klis87 the .gqlconfig file is something you have to edit. To add support, modify the example gqlconfig file in the readme with a regex which would match your file. In this case, it'll be:

/* .gqlconfig */
{
  ...
  query: {
    files: [
      {
        match: 'ui/src/**/*.js',
        parser: ['EmbeddedQueryParser', { startTag: 'const typeDefs = `', endTag: '`' }],
      }
    ]
  }
}
}

I'm not familiar with gqltools, but I don't think adding support for syntax-highlighting might not be trivial for this kind of code - this plugin will have to go through every template string in JS/JSX files and attempt to highlighted it as gql - I don't think that's possible with vscode.

[klis87]

@kumarharsh It is possible because gql tags for react-apollo client are highlighted, so doing the same for typeDefs must be also possible.

[kumarharsh]

@klis87 - yes that is possible. But I feel like it can cause issues:

1. Is it guarenteed that users will always write:

const typeDefs = `
   ...
`

and not:

const type_defs = `
   ...
`

or any other variation?

2. What if someone has to put two sets of graphql queries in a file? They can't use the typeDefs variable, because that's already used.

const typeDefs = `
  { ... query 1 }
`;
...

const typeDefs2 = ` // won't highlight
  { ... query 2 }
`;

Granted, the gql and Relay.QL tags can also suffer from this problem:

import Relay_XX from 'react-relay';
const frag = Relay_XX.QL`
  fragment on ... {}
`

but I feel that this convention doesn't cause clashes for the code below it. On the other hand, the graphql-tools convention seems flaky to me, as I've tried to highlight here.

But, I'm not aware of how the code for graphql-tools looks like, so maybe my reservations might not matter in reality. What are your thoughts?

[klis87]

I agree with you that it might be dangerous to assume typeDefs convention. But would it be possible to make code highlighting configurable? for example as vscode setting like:

{
  "GQLCodeHighlitingPatterns": [
    {
      "path": "src/**/*.js",
      "startTag": "const typeDefs = `",
      "endTag": "`"
    }
  ]
}

Then it would be flexible and everyone could set things up to a specific tools/frameworks.
And graphql-tools convention is to have one typeDefs const per file.

[kumarharsh]

I don't think vscode allows that. Because the syntaxes are defined in JSON, and the config file can't have a say in that. I think it'll be super hard to support it and still retain any amount of flexibility.

[kumarharsh]

I found a related issue on VSCode pertaining to this: microsoft/vscode#130 (comment)

[klis87]

Ohhh, pity. So there is nothing what could we do? Could we add typeDefs as hardcoded rule in graphql syntax or you would prefer not to?

[kumarharsh]

I'd prefer to wait for a better solution to this, or if more people are interested, then maybe we can figure out an approach which works best.

One suggestion: you can write a simple tagged template function named gql, which just returns whatever is in the template. Then, you'll get the syntax highlighting too!

[klis87]

Ok, so let's wait, Thank you for custom gql tag, this would actually work :)

Btw, I guess this library won't work for dynamic types right? Which you set programatically. If that is so, would you consider adding ability to introspect schema from a graphql server endpoint? In a similar fashion like in apollo-codegen, which can generates flow types from graphql endpoint.

[kumarharsh]

Yes, that is one thing we might add (possibly). There is an open issue for apollo support in the gql library where you can give your inputs.