Getting TS in Svelte might be a blocker for some, but I think the underlaying advantage comes in that the TS tools are just a stricter version of the JS tools. Everyone using Svelte gets improvements in tooling from this, not just folks with TS.
- Migrate svelte-preprocess into core (and/or take enough functionality that it's not needed)
- Create "svelte/svelte-language-tools" repo in main org
- Add
svelte-language-server
- Add
svelte-vscode
- Create a new
svelte check
tool (or build this into the main CLI) which uses the LSP to validate - this makes LSP calls against all .svelte files to run TS/JS tooling for errors
- Add
- Do some work on svelte-langauge-server
-
This is to allow the editor support to work out of the box, and for a user to be able to safely make assumptions that if they wrote
<script lang="typescript">
(and they have the dep) that it will work. -
Adding TypeScript support to Svelte can take a lot of tips from prior art done on Vue. Vetur acts as the higher level tooling framework for both providing the JS and TS tooling support in scripts. This pattern keeps most of the work in the LSP level, which means all editors can use it, the vscode extension would just be one client of many. If folks have other popular IDE integrations, they could live in this repo too.
-
Adds a way to validate on CI, and for folks without the extension.
Luckily, both vscode-svelte and svelte-langauge-server have already been built and worked on by UnwrittenFun and he's interested in moving those to the org. They both are solid foundations to build upon, from looking through the code.
I think one of the first blockers on making it something recommended by default, is finding a way to make sure that reactive designators are handled in both JS and TS.
Because the $:
syntax does more work than TypeScript can know about $: x = count + 1
would probably need transforming into something like const x = () => { count + 1 }
as an in-memory transform, so that the variables exist in the "TS representation" of the LSP (but not on disk)
I think you can get autocompletion, but I'm not sure how feasible typechecking would be here in a cheap way.
For inside {}
the LSP could make API requests to the known script tags above and request all the variables at the top level scope (basically the equivilient of adding a newline in that script and then checking what's available.)
In theory you could type check each one by making a unique TS document for all of them, with exposed globals from the main script - but that could be quite slow, and it's hard to say how well that could scale.
Start work on a real LSP for htmlx.
Thanks for putting effort into this! One thing that I haven't seen mentioned much in the various discussion around Svelte TS support is proper handling of
<script context="module">
. The existing Svelte typescript preprocessing solutions break when variables are defined in module context, and also used in the component-level script tag, because Typescript doesn't know about the module-level variable definitions.This comes up most often in Sapper code, e.g.
Anyway, just wanted to bring this up in case it hasn't been a part of the design you're considering. Thanks again!