Currently when a string with the gql tag exists but is commented, there will be an exception:
{ GraphQLError: Syntax Error ./xxxx/container-component.tsx (2:1) Cannot parse the unexpected character "/".
@jonaskello , you are right, I will fix it soon.
Also, I need to add support for gql(...) (use it as function)
IIRC the checks are now done with regexp. I think maybe a better approach would be to parse it into an AST using babel or typescript. That would probably be more accurate than a regexp. But of course it would be more complex to implement and maybe slower too.
@jonaskello Yeah sure it makes sense. Do you have a reference or example for checking a code file as AST? I'll give it a try :)
Also, it might be possible to run something like https://www.npmjs.com/package/strip-comments before running the regex...
@jonaskello
strip-comments seems to work great (see unit tests)
Please see https://github.com/dotansimha/graphql-code-generator/pull/192
What do you think?
Fixed in 0.8.19 :)
IMO, using strip-comments is a simpler solution and therefore better :-). If there are more advanced code-analysis needed later we can look into parsing into an abstract syntax tree at that point.
Yea well, this wasn't a good move. See #196 ;) I think it will require an approach that @jonaskello mentioned and go with AST.
Just my two cents. In VSCode I am using https://www.npmjs.com/package/@playlyfe/gql to essentially highlight and intellisense graphql queries. That would mean it can parse it just fine and apparently works cross-language, so it might be worth investigating. Perhaps it's possible it could fulfill a duty of file watcher as well to have generated types refreshed automatically?
@jonaskello @FredyC
We recently merged this: https://github.com/dotansimha/graphql-code-generator/pull/907 , now the codegen will parse the code file as AST and extract the documents from it.