Add support for Apollo Connectors Mapping Syntax

[phryneas]

[github-actions[bot]]

You can download the latest build of the extension for this PR here: vscode-apollo-0.0.0-build-1752596687.pr-230.commit-a561ce6.zip.

To install the extension, download the file, unzip it and install it in VS Code by selecting "Install from VSIX..." in the Extensions view.

Alternatively, run

code --install-extension vscode-apollo-0.0.0-build-1752596687.pr-230.commit-a561ce6.vsix --force

from the command line.

For older builds, please see the edit history of this comment.

[phryneas]

I think this is in a good state right now, so I'll wait a bit for feedback from testing before we can hopefully get this in next week or so :)

[dylan-apollo]

@phryneas this language is going to show up in a few more places now, I'm just wondering how hard it will be to extend syntax highlighting to these as well?

1. In both @source and @connect, the http.headers value is a list of objects or a single object. If an object it has a value property (string), which contains { }, then the content within those { } is this same language.
2. Very similar to 1, but only for @connect, the string of http.GET, http.POST, http.PUT, http.PATCH, and http.DELETE can contain expressions within { }.

I believe @BoD said we can use semantic tokens (or whatever they're called) via LSP for JetBrains now, so maybe this is complex enough that we should look into that route?

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 59a455f61f55777affba0ed59be5af6ede9dc283

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
vscode-apollo	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[phryneas]

@phryneas this language is going to show up in a few more places now, I'm just wondering how hard it will be to extend syntax highlighting to these as well?

1. In both `@source` and `@connect`, the `http.headers` value is a list of objects or a single object. If an object it has a `value` property (string), which contains `{ }`, then the content within those `{ }` is this same language.

2. Very similar to 1, but _only_ for `@connect`, the string of `http.GET`, `http.POST`, `http.PUT`, `http.PATCH`, and `http.DELETE` can contain expressions within `{ }`.

That would be a duplication of most of syntaxes/graphql.connectors.json, with some adjustments. Probably not too complex.

I believe @BoD said we can use semantic tokens (or whatever they're called) via LSP for JetBrains now, so maybe this is complex enough that we should look into that route?

Semantic tokens won't work for the documentation, and they only work once rover is installed & active, while this approach would always work. Usually, semantic tokens are used to refine the highlighting of a textmate grammar, not to completely replace it, as afaik it can also be a lot slower and might lag behind while typing. In the end, it could also be very difficult to get semantic tokens working for "almost right" code with minor syntax errors (e.g. in situations where you haven't finished typing yet), which oftentimes still kinda works in textmate highlighting - but I don't know how forgiving you can make your parser there.

In the end, it's your call to make.

[phryneas]

Okay, finalizing the colors. Here are a few impressions:

Here you can see that the object syntax (top) is different from the selection syntax (bottom). This mimicks the colors that GraphQL syntax is using:

Another thing to point out is that builtin functions are highlighted differently:

The colors look very different here, but that's theme-specific. I'm using entity.name.function for a random function name and keyword.builtin, entity.name.function for known function names.

[phryneas]

Yeah, happy to huddle on that property colorization issue.

From how I've interpreted it, most languages have two approaches and highlight them differently:

JavaScript:

const value = 1
// object construction (props and values)
const foo = {
  prop: value
}
// object destructuring (props and aliases)
const { 
  prop,
  prop: alias 
} = foo

query (value: "1000") {
  # objects in arguments (props and values)
  field(arg: {
    prop: $value
  }) {
    # field selections (fields and aliases)
    field
    alias: field
  }
}

And in the connectors syntax I tried to apply that similarly:

# inside lit: object construction with props and values
$({
  prop: $value
})

# outside lit: field selection with aliases
alias: field
field

As that doesn't exist in a vacuum, here the GraphQL example from above next to it so you can see how the color choices are similar:

And the JS example:

PS: interesting to see how GitHub itself doesn't make that distinction in their code highlighting