Add support for GraphQL injections in ECMA (JS/TS) without `gql` tag

[souserge]

I noticed that Helix automatically injects GraphQL syntax highlighting when a template literal in TypeScript/JavaScript is tagged with gql:

helix/runtime/queries/ecma/injections.scm

Lines 25 to 31 in d0218f7

	; Parse the contents of gql template literals
	((call_expression
	function: (identifier) @_template_function_name
	arguments: (template_string) @injection.content)
	(#eq? @_template_function_name "gql")
	(#set! injection.language "graphql"))

However, my GraphQL queries are pre-processed using a function called graphql as is the standard practice with many GraphQL TS tools, including gql.tada and @graphql-codegen/cli. They cannot work together with the gql tag, no matter the implementation.

Should there be a way to enable the injection without the tag? E.g. a common practice is to add /* GraphQL */ before the string literal to signal to tools that the string is a GraphQL query:
https://github.com/search?q=%22%2F*+GraphQL+*%2F%22&type=code

The official VSCode plugin supports the following options:
https://github.com/graphql/graphiql/blob/main/packages/vscode-graphql-syntax/tests/__fixtures__/test.ts

[kpbaks]

I am not familiar with the JS/TS ecosystem, but I know we allow prefix comments to inject languages into strings in nix, which works well. I think it would be a good idea to extend the queries to support this for GraphQl.

[forivall]

Other common prefix comments are /* gql */, and it's also commonly supported with #graphql at the beginning of a string like the following:

const gqlString = `#graphql
query FooQuery {
  id
}`;

I'm not sure if this second format can be supported though, as i havent worked with injection queries in helix yet.

[sjbarag]

Thanks for the link @souserge! Managed to get that working in #14727, but tagged template literals with a type argument will require an update to tree-sitter-typescript too (tree-sitter/tree-sitter-typescript#350)

[souserge]

Thank you so much @sjbarag ! I know nothing of Scheme so wouldn't be able to check the code, but can offer help with testing the feature today/tomorrow.

[forivall]

looking at and testing out the new injections, it looks good from me (i just had to rebuild from master 😢 )

(@souserge the code isnt actually scheme, it's a lisp-like DSL specific to tree-sitter for pattern matching on the syntax trees. See https://docs.helix-editor.com/guides/injection.html#adding-injection-queries and https://tree-sitter.github.io/tree-sitter/3-syntax-highlighting.html#language-injection for more info)

[kpbaks]

I think this issue can be closed as resolved since #14727 got merged.

[sjbarag]

@kpbaks There's one remaining syntax gap left that'll be filled by tree-sitter/tree-sitter-typescript#350 + this repo updating its version of tree-sitter-typescript¹. I've no objections to closing this, but it may be worth splitting off a followup issue for that edge case 🤷‍♀️

Footnotes

1. Or forking that definition and switching to a fork. Since I'm not a maintainer I can't advocate for that — I've got no skin in the game. ↩

[kpbaks]

My bad @sjbarag. I was a bit to hasty in my conclusion. Lets leave the issue open until the tree-sitter-typescript pr has been resolved.

[sjbarag]

No worries! We added a bunch to this issue. Your comment got me to nudge the tree-sitter-typescript owners anyway :)