RFC: <script type="ts/module">

[gertcuykens]

One of the directions modern web components are moving is declarative html. A bit likejsx but the other way around :) Now for html / js @rictic made a extension https://github.com/Polymer/vscode-plugin that brings auto completion for web components and their attribute defenition look up to a next level. https://youtu.be/zxcfPACo4-g?t=1h3m42s So that part is already done and backed by Google. Notice that we are talking web components in general here not just polymer.

The problem is there is no html inline ts solution yet. We can't really expect from the polymer team to integrate <script type="ts/module"> by themself in that extension.

Now because ts is baked in vscode, inline html / ts compile support should be baked in as well. My first step is to convince everybody that if vscode can handle inline html / ts it would clear the way for using typescript web components by default. Right now typescript is not being used in polymer components because having two separate files, one for ts, one for html takes away the main strong point of declarative component programing. Jsx proved already that html and js logic can be used together as a great way to structure your code. At Google they do the same but in a more html declarative way.

EDIT1:

• vscode need to be doing intellisense on <script type="ts/module"> content in html files
• vscode option to transpile example.ts.html to example.html with the script contents and script type replaced.

filename: example.ts.html

<link rel="import" href="../polymer/polymer-element.html">
<dom-module id="hello-world">
  <template>
    <style>
      :host {
        display: block;
        box-sizing: border-box;
        border: 1px solid red;
        margin-top: 10px;
        padding: 0px 5px;
      }
    </style>
    <p>Test <slot></slot></p>
  </template>
  <script type="ts/module">
    class HelloWorld extends Polymer.Element {
      _hello: string = 'Hello World'
      static get is() {
        let test: string = 'test intelli'
        test.toUpperCase()
        return 'hello-world';
      }
      static get config() {
        return {};
      }
      constructor() {
        super();
      }
      connectedCallback() {
        super.connectedCallback();
      }
    }
    customElements.define(HelloWorld.is, HelloWorld);  
  </script>
</dom-module>

EDIT2: Note I am also looking into how close ES20XX syntax and typescript syntax are going to get that a future browser can just ignore all the typing syntax and read <script type="ts/module"> just like ES20XX javascript :) The browser doesn't need to look at the typings at all, just be smart enough to ignore typings that's it. If the two syntaxes matches close enough that can't be much to ask for browser vendors and the ECMA262 community right?

tc39/ecma262#717

[roblourens]

If I understand correctly, it sounds like you want to compile ts which is inlined in html. Is that right? If so, I guess this should be a bug on TypeScript, not vscode, because that would be something they enable for any editor, not something vscode does.

[gertcuykens]

I need both of you, for example inline html / ts syntax highlighting etc, so I need typescript and vscode on the same page. For example I suspect a answer form typescript that the tooling should strip out and inject code instead of the compiler so they would refer me to vscode. Both groups should discuss it in my eyes.

[roblourens]

Everything from syntax highlighting to compilation is provided by typescript, so it would have to start with them. Some tool could take the current stuff and use it to compile TS embedded in html, but I don't really see that fitting with what vscode does today. Would rather see some other tool do that first.

[mhegazy]

The tsserver supports embedded js (and ts for this matter). VSCode will need to extract the script tag contents, and send them to the server. all other LS operations should work regularly from this point on. No work on the tsserver-side should be needed, so microsoft/TypeScript#11739 should be closed, and this issue reopened (unless there is another issue tracking this work on the vscode side).

It is worth noting that this is hte same support that VS 2015 uses to drive intellisense and other Language Service features in empeded JS code in script tags.

Also pinging @dbaeumer, @waderyan and @egamma

[egamma]

CC @aeschli

[amitmerin]

The subject rose on a discussion with the Polymer team about how to work with TypeScript within an HTML file.
As @gertcuykens mentioned, splitting each component into an HTML file and a ts file that creates a js file adds a fare amount of complexity.

1. Does TypeScript (tsc) work on an embedded TypeScript block within an HTML file?
I understand from @mhegazy comment that the answer is 'yes', but fail to find any documentation.

2. what would be the output of such a file after compilation and how will it effect the structure of the project?
This is where we need better understanding from both TypeScript and VSCode so the guys from Google Polymer working on tools and extensions know how everything fits.

The outcome of this would be to create a clear path for Polymer developers to use and enjoy the great power of TypeScript without compromising productivity.

[mhegazy]

1. Does TypeScript (tsc) work on an embedded TypeScript block within an HTML file?

The TS language service does not do any HTML parsing or understanding. Sorry if i made it sound like so, let me explain.

Mapping a section of a file to different language service is a common feature in a lot of editors/IDEs; for instance editing XML in a VB file, or Doc Comments in a JS file. Similarly editing the contents of JS script tag is handled by the JS language service, where as the rest of the file is handled by the HTML language service. this concept is usually referred to as mapped buffers. where the editor maps sections of the source to be handled by multiple language services.

For the TS language service, the open file command request accepts an optional scriptKindName; in the absence of scriptKindName, the script kind is inferred from the file extension, but an editor can send a file name a.html for instance and then specify that the kind is TS and the TS language service will treat it as such. There is also an optional fileContents that allow the editor to send the contents of the file instead of reading them from disk.

To put this all together, the editor has an HTML language service that understands HTML, once it finds a script tag, it will extract the contents (no HTML left here, just JS/TS code) into a new temp buffer, send that to the TS language service and specify scriptKindName as JS/TS. From this point on all TS language service features should work, e.g. completion, quick info, errors, etc.. the only one that needs changes is formatting, the editor needs to set EditorSettings.baseIndentSize to the base indentation of the script block.

Hope this provides enough information on how mapped buffers work in tsserver and TS LS.

2 what would be the output of such a file after compilation and how will it effect the structure of the project?

I would expect that the polymer build pipeline will have a similar work flow as outlined above. Before calling the typescript compiler to check errors or generate output, the host (i.e. the build driver, or whoever is calling tsc) would extract script blocks, pass them to the compiler, get the output and place it in the matching script block in the output.

[amitmerin]

Thanks @mhegazy for the thorough answer, it puts most of the peaces in place. Lets let the Polymer team figure out how they want to take it from here.

[gertcuykens]

Looking at the vscode plugin source code I realize this need to be done first https://github.com/Polymer/polymer-analyzer/issues/387

Still need some input if I need to issue for the tsc compiler itself to go from example.ts.html to example.html by just using the command line tsc --html for example. Or if we need to make a completely new separate compiler for it that extends the tsc compiler?

[mjbvz]

As noted in the comments, I believe this is functionality that an extension or tooling would be able to provide. The recent addition of TypeScript support for Vetur may be a good starting reference for how this could work: vuejs/vetur#94