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 here 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.

Note that the feedback so far from vscode was that I should discuss first with typescript compiler developers.

microsoft/vscode#14032

EDIT: HTML inline TS Error handling and inteli sense is on its way in https://github.com/Polymer/polymer-analyzer/issues/387

But I need some extra approval or solution for transpiling example.ts.html to example.html For me tsc --html would make the most sense to do that part in the command line.

tsc --html would 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>

EDIT: 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

[basarat]

Other discussions :

Overview of the need for TypeScript extensibility : #6508

Request by the angular team to allow evaluating a detached buffer : #5470 (still needs proposal)

Personal Thoughts

Providing true high fidelity native experience is simplest with JSX as it is just a fancy JavaScript Object Literal. Whereas templates have embedded ifs, repeats with scope changes that can be hard to analyze.

Pure HTML is simpler but that is not what is being requested 🌹

[mhegazy]

tsserver supports embedded JS, and TS, though no one uses the embedded TS at the moment. i have replied to the issue on VSCode issue tracker in microsoft/vscode#14032 (comment)

[gertcuykens]

I need your help on the [email protected] mailing list, for a "use strict comments"; proposal that would enable plain typescript code in browsers without the need for transpiling. Basicly expanding // and /**/ so that all typings information just get ignored by the browser as comments but not by vscode for example. The subject of my mail was expanding comments proposal

[mhegazy]

I need your help on the [email protected] mailing list, for a "use strict comments";

I am not sure i agree that this is the correct way to standardize types in ECMAScript. Treating type annotations like comments is not any different from JSDoc today, and that has proved to be an insufficient solution to the original problem.

[gertcuykens]

I agree but it makes the tooling less complicated and the adoption rate for using typescript higher if a developer would just need to open their html page in vscode. I think once adoption is big enough we can get rit of "use strict comments"; and do it your way instead once everybody is used to the typing syntax. If i am not mistaken the build in proposal for real typing was suggested in 2014 but isn't going anywhere, so comments is more like plan b.

[mhegazy]

if a developer would just need to open their html page in vscode.

I do not see why this would not be possible today, or why it needs TC39 to standardize it to work. I have commented on microsoft/vscode#14032 wit details.

If i am not mistaken the build in proposal for real typing was suggested in 2014 but isn't going anywhere, so comments is more like plan b.

I do not think this proposal has better chances in TC39 either. but I could be wrong.

[gertcuykens]

Ok thanks, just to let you know @rictic the google engineer who is in a airplane right now will be working on it soon to help put the pieces all together. Can't wait to see the result, typescript alone is already amazing but together with their webcomponent analyzing tool, man that's like going to the moon in web development world :)

[mhegazy]

I think the correct way to handle this is to add a new typescript plugin for polymer. the plugin would be the main entry point from IDEs and would get the HTML first hand; the plugin then can defer to the TS language service for the TS and JS code sections (and would tell the TS LS about the which language the content is).
More information can be found at https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin.
Also a similar effort, though is not identical, is the Vue extension for VSCode, see https://github.com/octref/vetur
For the build part, I am assuming you already have a build driver that does the TS to JS transformation.

[mhegazy]

Marking as duplicate of #6508