Extension providing language support in ES6 template strings

[mquandalle]

I’m not sure this question is best suited for the bug tracker, but since I wasn’t able to get an answer on StackOverflow, I’m taking my chance here. Sorry if this isn’t the right place.

So my question is about how extensions could provide language support (autocompletion, linter, syntax highlighting, snippets, etc.) for tagged ES6 template strings? My particular use case is about GraphQL queries that are very likely to be defined in JavaScript/Typescript files like in the below Facebook/Relay example:

Tea = Relay.createContainer(Tea, {
  fragments: {
    tea: () => Relay.QL`
      fragment on Tea {
        name,
        steepingTime,
      }
    `,
  },
});

Here I would like my GraphQL extension to support its features inside of the tagged Relay.QL string. Is there any way to do that currently?

[bpasero]

@jrieken @alexandrudima can you chime in

[jrieken]

@mquandalle Your string misses a $ proceeding the curly bracket. For details see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

[mquandalle]

@jrieken, I think you misunderstood my question as I’m not talking at all about expression interpolation but about tagged template literal. In my example the Relay.QL tag is used to indicate that the string is using the GraphQL language. I’ve seen similar examples for the jade template language, something like:

class MyComponent extends React.Component {
  render() {
    return jade`
       h1 Hello world
    `;
  }
}

My question is how a VSCode extension could provide language services (again: auto-completion, snippets, syntax highlighting, etc.) for some specific tagged string in ES6 code.

[jrieken]

Sorry my mistake...

That's an interesting question! Your extension should register a CompletionItemProvider. You can do that for different kinds of document/files (see DocumentSelector), like only for certain typescript files, but not (yet) for a specific scope inside the document. The model is collaborative so your provider only has to return result for its domain and the rest will be done by other providers for the language, e.g. TypeScript.

You might wonder if you can re-use syntax trees or type information which today you unfortunately cannot. An ideas is to expose the connection to the TypeScript service from the TypeScript extension but that's not done. Speak up if you need that.

[mquandalle]

Is there already any support for embedded languages in VSCode? For instance a php language would say that things outside of the php tags should be handled by the html language service.

The idea would be to do something similar for ES6 template strings, so that in the two above examples GraphQL and Jade extensions could provide their services—and that could potentially be useful for other embedded languages as well such as SQL queries As you say I could provide an extra TypeScript/JavaScript extension that wouldn’t do anything outside of its desired scope, however that’s sounds to be too hacky and wouldn’t allow things like syntactic coloration. I would prefer a build-in abstraction for embedded languages.

(BTW I can’t re-open this issue, but if fixing it requires some changes in VSCode maybe it should be re-opened?)

[jrieken]

Exposing the scopes when registering a provider is this: #719.

The syntax colouring is done with TextMate grammars which have the context of injection. Tho our support for them isn't all there yet. Assigning to @alexandrudima for the details.

[kastermester]

Supporting this would be very neat indeed! I would also love to use (and if no one else is building it, to build) such an extension.

[wmertens]

Expanding on the subject: Tagged template strings are becoming popular and can contain anything. These are the problems that I think need solving:

• mark a string as a certain syntax based on its called function. E.g.

    styled.div`color: red`

  should mark color: red as being SASS, running the SASS syntax highlighting and code completion on it.
• define what interpolations should be when syntax highlighting. E.g.

    styled.h1`font-size: ${props => props.big ? '2em' : '1em'};`

  might pass font-size: INTRPL; to the syntax highlighter.

This would for sure be amazing.

[mikeal]

For me and many others this feature is migrating from the "cool to have" category to the "absolute necessity" category.

The vast majority of HTML and CSS I write are now in template literals. Myself and many others are using emerging toolchains that programmatically create elements similar to react but unlike ESX users we lack syntax highlighting even though we are using features of the actual language rather than additional compiler toolchains.

There's also an amazing emerging toolchain called regl that many 3d programmers are moving to which implements WebGL+features in template literals which also lacks proper syntax highlighting because this feature is missing.

[wmertens]

See also #2793 (comment)

[plievone]

For me and many others this feature is migrating from the "cool to have" category to the "absolute necessity" category.

@mikeal As a workaround for now I create new throwaway documents from template literals, synced with the original. That way the embedded language can be anything (HTML, CSS, SQL, shell, etc), and language services such as syntax highlighting, completions, formatting, commenting, snippets, etc, work as expected (but won't know about the larger environment). Even nested templates work quite ok, and edits are visible at the same time to both the host language and the template language, in a side-by-side view.

You can try the concept here: https://marketplace.visualstudio.com/items?itemName=plievone.vscode-template-literal-editor

Other issues that are related and may benefit from this workaround are #130, #1751, #2000, #2793, #13039. The UX leaves much to be deserved but for some use cases it seems to work very well for now. I raised the original issue here #22694, before drafting this proof-of-concept extension.

[ForbesLindesay]

This is the main thing preventing me adopting typescript & vscode for everything.

[rbiggs]

I use tagged template literals extensively for creating HTML components in JavaScript. When Atom sees a tagged template literal that begins with html, such as

html`<li>${data}</li>`

it will automatically style the open and closing brackets of the tags so that they stand out. Similarly, on Github, if you use html, javascript or css before triple back ticks, it will complete treat the content as that mime type for highlighting.

Better syntax highlighting for template literals, especially tagged ones, is the number one feature I'd like to see in the next version of Code. And it would also set it apart from the pack.

When template literals were first introduced I thought they were useless. And now I can't do anything DOM-related without using them. So, for me at least, better support for parsing and understanding template literals is essential.

[justinfagnani]

To echo @mikeal and @rbiggs, some of the Polymer team is now experimenting with tagged template literals as a way to write HTML templates. We're working on a tagged template based library that looks promising for future Polymer ( https://github.com/PolymerLabs/lit-html ).

The only downside is that the editing experience inside the literal parts it not very good w/o at least syntax highlighting. But we'd also like to see code completion, docs, etc. based on the dom.d.ts types. We'll look into writing extensions for this soon I suspect.

[noinkling]

Just want to add: it would be nice if such functionality could also use comment hints as a generic fallback, that way people wouldn't be 100% reliant on smart-interpretation of template literals (although that's nice as well).

[mjbvz]

For lit-html, try:

• lit-html syntax highlighting extension: https://marketplace.visualstudio.com/items?itemName=bierner.lit-html
• Lit-html IntelliSense TypeScript plugin: https://github.com/Microsoft/typescript-lit-html-plugin

---

Writing an extension that contributes syntax highlighting for tagged template is already possible, and TypeScript plugins allow you to also get IntelliSense and other editor features in these. Our goal is to continue improving the TypeScript plugin story. Eventually we'd like to VS Code extensions to contribute TypeScript plugins so that no extra install or configuration is necessary. I'll keep this issue open until we get to that point

If any one else is interested in writing an extension/plugin for another embedded language, please let me know. There's already a plugin for styled components and I've also written a library that should simplify authoring these types of plugins

[mjbvz]

VS Code Extensions can now bundle ts server plugins. This allows extension authors to write a vscode extension that adds syntax highlighting + intellisense for template strings.

Two extensions are already making use of this:

• vscode-styled-components — Syntax highlighting, IntelliSense, and error reporting for styled-component CSS strings.
• lit-html — Syntax highlighting, IntelliSense, and formatting for lit-html template strings

If you are interested in writing an extension for a template string embedded language, take a look at how the implementation of these extensions. And let me know if you run into any problems or have any questions about the new contribution point (please open a new issue or post a question to stack overflow)