[html] allow extensions to provide computed custom data

[sijakret]

Hi,

vscode has a setting html.customData (and css.customData) which allows extending the set of html tags known to the internal language service.
Currently users need to configure the list of custom-element.json files manually in the settings.
Are there plans to implement an automatic discovery of these files from the installed npm packages?

If not, maybe this could (and should) be done via an extension.
There is a corresponding contribution point. However, it seems to be pointing to a static file only. Also, it looks like changes to that file are not monitored so a hacky approach like overwriting some sort of temp schema file does not seem viable as well.
Is there any away for an extension to signal updates to the custom data it is contributing?

If so, a generic extension could provide logic + settings to discover these definitions and expose them to vscode once discovered. I would be happy to implement this. It would streamline consuming web component libraries quite a bit compared to having to manage paths manually in the vscode settings.

This looks like the most relevant thread on the web component side: WICG/webcomponents#776

Side note: Some libraries already ship cusomt-elements.json files. They indicate their presence with a "customElements" field in the package.json. It's just that no one seems to pick them up..

[thepassle]

They indicate their presence with a "customElements" field in the package.json.

Additionally, if a package uses a package exports map, it may be under:

{
  "exports": {
    "./customElements": "./custom-elements.json"
  }
}

[sijakret]

The whole domain seems a bit fractured.
There also seems to typescript path via HTMLElementTagNameMap that allows extending the language service. It is used by https://github.com/mjbvz/vscode-lit-html under the hood. This also works.

I think the main gotcha here is that it only works in template literals in code (*.ts) files. Not sure why but my uneducated guess is it leverages the typescript infrastructure. At least in my case I did not manage to get type completion etc. in a *.html file.

Maybe https://github.com/microsoft/typescript-lit-html-plugin can just be extended so it also works in all html contexts and not just in template literals in code. That would also be an option for projects with typescript I guess..

Edit: Maybe related: mjbvz/vscode-lit-html#55

[aeschli]

I'd like to avoid that the HTML server is getting into understanding project configuration files (e.g. package.json). There's no single well-established standard and I/we are not experts in a field that quickly progresses.
So having an extension doing that would be great.

As you mentioned, extensions can contribute custom data, but only as a static data.

We could extend the customData contribution points to allow a URL as well. Then extensions can point it to a URL with computed content using a Text Document Provider.

If you are interested of making that change, I'd be happy to take a PR (for both css.customData and html.customData)

[sijakret]

Thanks for the reply!

So that would mean basically only one change in vscode: allow URLs and not only paths.
This means an adaption of extensions/[html/css]-language-features is required, correct?
This looks like the place to start, since it looks like the path setting gets locked down to a path here.

vscode/extensions/html-language-features/client/src/customData.ts

Line 53 in 94c9ea4

dataPaths.push(resolvePath(rootFolder, path).toString());

(analogously for css).

The second part would be to create an extension that actually contributes customData as a url to a virtual document which document it provides itself dynamically via document content provider API, correct?

I think part two is really straightforward.
I will get back to you in case I get stuck with part one :)

[aeschli]

Yes, exactly.
To get the content of a URL you can do it like here:

vscode/extensions/json-language-features/client/src/jsonClient.ts

Line 208 in 7ca1f2c

return workspace.openTextDocument(uri).then(doc => {

[sijakret]

OK, I have this pretty much working (modified vscode + extension) locally.

I have one major issue with dynamically updating the virtual doc.

• This is the way to signal changes to a virtual document: https://code.visualstudio.com/api/extension-guides/virtual-documents#update-virtual-documents
  This works and provideTextDocumentContent is actually called again to serve the updated data.
• However, I don't see any way for the html-language-features extension to listen to changes to virtual documents.
  The closes thing I have found is workspace.onDidChangeTextDocument however this one seems to NOT fire on virtual document changes (at least not if the doc is not opened, which mine will never be) and seems generally excessive.

Is there maybe an additional gap here? Or is there a public API I am missing?

[aeschli]

You create a document with workspace.openTextDocument(uri), and hold a reference to it?
workspace.onDidChangeTextDocument(..) should be triggered when you fire a change event in the provider.
We rely on that in the JSON extension. Can you double check?

[aeschli]

Maybe the cleaner alternative would be to use a FileSystemProvider. That would avoid the creation of TextDocuments.

[sijakret]

You create a document with workspace.openTextDocument(uri), and hold a reference to it? workspace.onDidChangeTextDocument(..) should be triggered when you fire a change event in the provider. We rely on that in the JSON extension. Can you double check?

Ok. I will double check!

Using Filesystem Provider would mean pointing to a temp file and overwriting that on changes right?

Thanks for your help!

[aeschli]

Check out https://code.visualstudio.com/api/extension-guides/virtual-documents#file-system-api
It's another way of providing virtual resources. A bit more API to implement on on the provider side.