Support TypeScript embedded in HTML files.

[KeithHenry]

It would be very useful for TypeScript to be embedded in HTML files.

Problem

Newer browsers can use HTML imports to reduce the number of requests when loading components. This is used especially in custom elements and libraries that extend them (for instance Polymer).

For instance, suppose I have a custom element with CSS, HTML and script components. I add it to my page with a single statement:

<link rel="import" href="my-component.html">

Then my-component.html looks something like:

...
<template>
    <style>
        ...
    </style>
    <p>HTML content!</p>
</template>
<script>
    // Javascript to create custom element
</script>
...

This can be made to work with with TypeScript with <script src="typescript-output.js"> but that results in another server round trip and loses the bundling of CSS, HTML and script that makes the HTML import pattern so useful.

The output of the TS transpile should be included in the component HTML when presented to the user.

Solution

One way to do this would be to support a .tshtml file format (or possibly .tml or .ts.html).

This would behave in editors like HTML, but any <script> tags in the file would be TypeScript.

The Javascript emitter would produce a .html file with the contents of any <script> tags converted to the target JS version. Any content outside of <script> tags would be included unchanged.

This would be consistent pattern for users, anyone familiar with .tsx transpiling to .jsx or .cshtml in Razor should recognise the behaviour.

A file format like .ts.html would work with current HTML editors without any changes, but would also add risk for any projects that already had files with that naming format. Perhaps it could be combined with <script language="TypeScript"> tags to avoid that.

Risks

If TypeScript doesn't support being embedded in HTML one of two things are likely to happen for all projects that want to use the HTML import browser feature:

1. Third party tools to post-process .ts output into .html files will emerge (they probably already have) or...
2. These libraries and the people that use them just won't use TypeScript.

At the moment these are limited to a few fairly bleeding edge libraries, mostly those using custom elements, shadow DOM and the like. However I'd argue that these are exactly the sort of projects that we want to use TypeScript.

[tony19]

I'm confused. Isn't this a suggestion for browser vendors (and not TypeScript itself)? Or are you suggesting that tsc transpile these new file types into HTML?

The new file extension is probably unnecessary, as the <script> supports the type attribute, which would allow a new type specifically for TypeScript (e.g., text/typescript). One could use a build tool, such as polymer-build, to split an HTML file into TypeScript and non-TypeScript streams, allowing for transpiling inline TypeScript and then rejoining into the original file (see demo).

[fgirardey]

TypeScript is a build tool, the need is to take an HTML file with TypeScript code embedded in and output another HTML file with JavaScript compiled code embedded in.

TypeScript need to support that natively as WebComponents interest is rising very fast.

[tony19]

@fgirardey Well, TypeScript is technically a programming language (see first sentence in the README) 🙂 . The typescript package in npm includes a compiler (tsc), which seems to be the target of this issue.

I agree that it could be useful for tsc to have some kind of transpilation support for inline TypeScript in HTML, but my point is that a new file extension is not necessary for that because HTML files can already contain TypeScript (in a <script type="text/typescript"> tag). Support already exists for splitting scripts from HTML files (via build tools that aren't difficult to use IMO), so I doubt that built-in tsc support for transpiling inline TypeScript is going to make a huge impact, but I could be wrong.

[fgirardey]

I agree that it could be useful for tsc to have some kind of transpilation support for inline TypeScript in HTML, but my point is that a new file extension is not necessary for that because HTML files can already contain TypeScript (in a <script type="text/typescript"> tag).

I agree with that, we don't need to add a file extension and yes, tsc should (IMO) transpile TypeScript code embedded in HTML files within <script type="text/typescript">.

I don't see any good reason to not... Someone has some?

[KeithHenry]

@tony19 That's one of the options I've been looking into - use a third party to find <script type="text/typescript"> and transpile the content. The problem isn't that build tools can't do it, the problem is that there are loads of different build tools that all do it in different ways with different dependencies. There's lots of different ways to do it, but why can't tsc do it?

In addition - at the moment most editors don't support <script type="text/typescript"> or <script type="text/x-typescript">. They're unlikely to support whatever build script I come up with, while tsc support gives them a single standard they'll all come round to.

I suggested the filename extension because I find it's extremely useful to have different file names for input and output. my-component.tshtml gets transpiled to my-component.html and you can tell at a glance which is input and which output.

If there isn't a file extension difference, what should tsc do if no output location is set in tsconfig? Would it overwrite the original file, auto generate a new filename or just fail?

It's not a requirement, just a nice to have.

[ryanwebjackson]

I second this. TypeScript is already included in HTML files; there's just not a parser that operates on those files/sections of them, that I know of.

[idchlife]

It will be very handy for quick projects or hand-made admin panels actually

[Chris2011]

In vue files, you can type: lang="ts" but I think type="text/typescript" will be an official way.

[KeithHenry]

Why is this out of scope?

[mhegazy]

First sorry for closing without adding an explanation.

The request here is achievable today using the compiler API. one example of this already available is the vetur VSCode extension (see vuejs/vetur#94 for more details on how this works).

A vue file, similar to other templates, can be preprocessed by a third-party tool that "extracts" the parts that needs to be "checked" and use the TS compiler API to check them and report errors.
That said, given the range of options out there for templating languages and techniques, adding native support for these in the TS compiler is not scallable. and thus outside the scope of the TS project at the time being. the API should however enable such scenarios.

There is a similar discusssion in #19891