Re: [w3c/webcomponents] Editor support for WebComponents (#776)

> We would be very interested in contributing infrastructure to a non-Polymer-branded analyzer that VS Code and the rest of the ecosystem can easily use. We would also be very interested in reading this information from package.json and using it to drive webcomponents.org, rather than doing analysis on published npm packages.

@justinfagnani That's awesome to hear! Thanks.

I think your long list is "JSON metadata WC should generate for empowering other tools", which would be a superset of what editor needs. Let's limit the scope of the discussions here...

For VS Code's HTML we are currently only thinking about declarative contributions (like JSON files), not JS plugins like [TS Server Plugins](https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin). We might do it in the future though, so you could wire a ARIA-validation-plugin into the HTML Language Server.

> Given that the typings, definitions, and jsdoc tags are interop points between tools, I think we should start with defining their formats.

I agree. We should start specifying a contract between the JSON file and [editor features](https://code.visualstudio.com/docs/extensionAPI/language-support) & [LSP methods](https://microsoft.github.io/language-server-protocol/specification). With this you can work on improving the Analyzer and us on the HTML Language Server to support this contract.

For example:

- When JSON adds a tag definition (with attributes/self-closing-or-not and other metadata), editor should:
  - Handle [LSP Completion](https://microsoft.github.io/language-server-protocol/specification#textDocument_completion) for tag/attributes
  - Handle [LSP Hover](https://microsoft.github.io/language-server-protocol/specification#textDocument_hover) for tag/attributes (show description)
  - Provide [Diagnostics](https://microsoft.github.io/language-server-protocol/specification#textDocument_publishDiagnostics) if a required attribute is missing, or if a non-self-closing tag is self-closed.

Notice the JSON data might be reused for VS Code's css/emmet support too. For example, CSS selector completions should include custom tags, and emmet should expand custom tags.

> We've started looking at adding better analysis support to the lit-html VS Code extension, and the biggest immediate roadblock is the lack of integration between the HTML and TypeScript Language Services

Feel free to tag me or @mjbvz in the specific issues.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/776#issuecomment-443507926