TypeScript support

[tbillington]

This is intended to be a tracking issue for TypeScript support. Feel free to edit.

• Writing TypeScript in <script> tags in components.
• Importing TypeScript code into Svelte files (including editor support?!).
• Importing Svelte components into TypeScript code.

Some of these are partially supported now. I have been able to import Svelte components into TS and manually declaring their type using rollup-plugin-typescript. I've also been able to import TS code into Svelte components, however their is no support for suggestions/error highlighting on the editor side (from what I've seen).

[GarrettGeorge]

For <script> tags we could use inspiration from <style> tags which use the lang attribute.

Ex:

<script lang="ts">
  export default {...}
</script>

[Kiho]

@tbillington First item is not supported at all, however item 2 works fine with VS Code Svelte Plug-In and you can adjust behavior little bit with root level tsconfig.json. For item 3, I doubt it but if you really need typing support in ts modules, then you can possibly make it work with pre-process like this repo.
I was not able to make work that with arrow function though....

[colah]

This is only tangentially related, but I sometimes wish I could give TypeScript-like type specifications for my svelte components data. I'm not exactly sure why -- it's not like I frequently pass in the wrong type of data. I guess some plausible benefits are:

• When I start writing a component, I'd like to get the data it will take clear in my head. Normally I do this by including default values for all the data properties, but sometimes there are things I can't make a default value (eg. a large object that will get generated elsewhere).
• I'd like to make it easy to determine what the valid inputs to my component are.

[DrSensor]

https://github.com/kaisermann/svelte-preprocess

[fjorgemota]

@DrSensor I'm not sure if this fixes the issue.

I mean, it's very easy to use that package to just transpile the typescript code to valid javascript and let the Svelte compiler work with that...

BUT, it's not easy IMO to do the semantic check of the code, which Typescript is able to do.

For example...How to type-check this code?

<p>This is a top-level element.</p>
<Nested/>

<script>
	import Nested from './Nested.html';

	export default {
		components: {
			Nested
		}
	};
</script>

That type of thing is definitely not easy to do with Typescript semantic checkings on svelte-process, IMO..

By the way...A good suggestion would be to check this PR: vuejs/vetur#94 - which adds Typescript support to Vue for usage with VSCode..

[fjorgemota]

Hey.

I've been thinking about how to add support for Typescript (and probably other languages that compiles to Javascript) on Svelte and I concluded a few things about it:

• First, adding support for transpilation (without any semantic checking) is easy by using Svelte Preprocess, at least for code between <script></script> HTML tags (i.e it's not that easy to support code on event handlers, conditions, loops and tags, for example, because this would need the parsing of the Svelte code in the same way that Svelte compiler does);
• Second, adding semantic checking (like type-checking, which Typescript does) is not that easy, because:
  • We would need to parse Svelte components to provide type-checking specifically for nested components...That would include discovering methods that the nested component includes, for example;
  • We have no way actually to parse Svelte conditions, loops, tags and event handlers (on:click) without reinventing the wheel (i.e without writing code specifically to that, because there are no public methods that the Svelte compiler provides to do that), so type-checking on these places are out of question;
  • We would need to parse a few things like ref:<id> attributes and type refs attribute accordingly;
  • Even by solving these two points, the type-checking would not be very complete because the code generated by Svelte is not typescript itself, so if Svelte changes to v2 with a few breaking changes (i.e change of the name of a few methods), for example, we would need to adapt the definitions used in the checking accordingly or the compilation would continue to pass, but with runtime errors obviously.

For now, I see a few possibilities:

• Expose a few public ways to access the AST seen by the compiler, so it's easy to detect (what should be) javascript expressions on the Svelte component;
• In the future, publish a way to generate typescript code directly from the svelte compiler, so all the hard work would be done by the typescript checker (this is basically generate jsdoc/typescript/flow #58);

Yeah...it's not exactly a simple thing to do....

[mindplay-dk]

I've also been able to import TS code into Svelte components, however their is no support for suggestions/error highlighting on the editor side (from what I've seen).

@tbillington I'd be happy if I could just get that to work - I'd be able to keep the complex code in services in TypeScript, and call into those services from the Svelte app, which would then solely act as the UI and a sort of lightweight "controller" that dispatches service methods.

While I'd love to have type safety everywhere, I'm not sure it's extremely necessary on the UI side, since Svelte is quite declarative - if I can keep any complex stuff out of Svelte and in TypeScript, the coupling between the Svelte app and services could be fairly thin, so it doesn't worry me much.

Having to currently choose between Svelte with plain JS (ugh) and TypeScript without Svelte, there isn't really any choice - I'm afraid a lot of TypeScript users feel the same. I'm not fond of React or JSX, but it has TypeScript support, so, sadly, there isn't much of a choice at the moment...

[kylecordes]

The big challenge here is that really good TypeScript support is not a mere add-on. Rather, a top-notch TypeScript experience would come from pervasively designing a future version of Svelte (or any other similar library/framework/compiler/tool) from the ground up this way. It would perhaps require that Rich deeply embrace TypeScript, and (if other libraries have been any guide) take a few iterations to get really good. The results would probably end up working great with TypeScript, but contain things that feel unnecessary or a little awkward for someone consuming them from plain JavaScript.

(TypeScript and JavaScript are technically perfectly compatible, but there is a bit of a cultural gap.)

Making Svelte be really TypeScripty is also a bigger lift than, for example, the TypeScript-centric design of Stencil. The latter benefits from using VDOM/TSX (TypeScripty JSX), for a good developer experience, while more work would be needed to integrate the Svelte template compiler into the TypeScript compiler phase system somehow, to create similar goodness here.

[Rich-Harris]

Svelte 3 is being designed with TypeScript support in mind. I'm not enough of an expert in TypeScript to know exactly what's involved in getting things like auto-complete working inside templates, but the design is fundamentally much more TS-friendly than Svelte 2.

I'll be chatting with folks in the near future about what'll be involved in getting first-class TS support into Svelte, and I have a good feeling about where we'll be a couple of months from now. I'm a TS devotee myself (Svelte itself is written in TS) and I'd love to be able to use it in my own components, so know that it is a high priority!

[mindplay-dk]

@Rich-Harris thanks for the update! that is great news! 😄

[dgreene1]

I’d be interesting in using Svelte once TS support is more out of the box. Stencil provides it already, but Svelte has more usage.

[fjorgemota]

How is this going to work? Is there any news related to this issue?

I would like to know if we're going to get type checking support in Svelte components, for example, and if that would depend directly on editor support or some type of flag passed to svelte compiler itself (?), specifically.

[stereosteve]

There was some discussion in the discord a week ago about hooking into the TypeScript compiler API... but that would be no small task.

A possibly more 💩solution would be to support both html-based and javascript/typescript-based svelte files. A typescript file could export html and css template literals... it'd be easy for a tool to convert from one to the other.

For example the flight booker example:

const tomorrow = new Date(Date.now() + 86400000);

let start = [
    tomorrow.getFullYear(),
    pad(tomorrow.getMonth() + 1, 2),
    pad(tomorrow.getDate(), 2)
].join('-');

let end = start;
let isReturn = false;

// reactive declarations would require let
$: let startDate = convertToDate(start);
$: let endDate = convertToDate(end);

function bookFlight() {
    const type = isReturn ? 'return' : 'one-way';

    let message = `You have booked a ${type} flight, leaving ${startDate.toDateString()}`;
    if (type === 'return') {
        message += ` and returning ${endDate.toDateString()}`;
    }

    alert(message);
}

function convertToDate(str) {
    const split = str.split('-');
    return new Date(+split[0], +split[1] - 1, +split[2]);
}

function pad(x: any, len: number) {
    x = String(x)
    while (x.length < len) x = `0${x}`;
    return x;
}

// here there could be template tags e.g. svelteCSS
export const css = /* css */`
select, input, button {
    display: block;
    margin: 0.5em 0;
    font-size: inherit;
}
`

// here there could be template tags e.g. svelteHTML
export const html = /* html */`
<!-- https://github.com/eugenkiss/7guis/wiki#flight-booker -->
<select bind:value={isReturn}>
	<option value={false}>one-way flight</option>
	<option value={true}>return flight</option>
</select>

<input type=date bind:value={start}>
<input type=date bind:value={end} disabled={!isReturn}>

<button
	on:click={bookFlight}
	disabled="{isReturn && (startDate >= endDate)}">book</button>
`

TypeScript does complain that A label is not allowed here about the reactive declarations... but other than that you'd get all the nice editor features and whatnot.