Roadmap to new transformation

[dummdidumm]

The new transformation which transforms Svelte to TS code instead of TSX code for intellisense purposes has been in beta for a while now, and I think it's stable enough to switch to it. This is a breaking change which needs some coordination, so I'm writing down the steps here:

1. We want the new transformation to be more fine grained with respect to the allowed attributes on elements - for example only allow the href on a tags. At the same time we want to minimize the reliance on svelte2tsx. Therefore we need these transformation in Svelte core. [feat] add html typings svelte#7649 adds these. Also (feat) enable actions to enhance typings on applied element #1553 for better action typings. (Update: Not merging the HTML PR for now)
2. Try out typings in [feat] add html typings svelte#7649 to see how we can incorporate them in svelte2tsx
3. Test out things with SvelteNative (cc @halfnelson) and Svelte NodeGUI (cc @shirakaba ) - both likely need adjustments (adding the new required functions in the template and adding support for on:X events). Depending on the outcome it may be better to bury our hopes of doing on:X event typings and instead keep onX typings.
4. If experiments succeed, merge [feat] add html typings svelte#7649 and do a new release of Svelte
5. Do one last release with the old transformation with any bug fixes that may have been merged in the meantime
6. Merge (fix) keep colon while transforming events #1549 , adjust svelte-jsx.d.ts so that the old typings are removed - only keep some of the interfaces that people might have used to enhance their typings. Add the typing mentioned in (fix) keep colon while transforming events #1549 so breakage on events is minimal for peole
7. Release a new version of the Svelte extension with the new transformation turned on by default
8. Wait for a few weeks for bug reports or things we might have missed.
9. Release svelte-check 3.0 with the new transformation only. This requires peer dependency bumps for Svelte and TypeScript. We should also bump the node version to latest 14 so we can bump the LSP version under the hood later without it being another breaking change

@jasonlyu123 what do you think about these steps? Did I miss anything?

[shirakaba]

I'm afraid I haven't been actively working on Svelte NodeGUI for over a year now, and it never received a great amount of usage, so I probably won't be getting too involved with this! But I have added what feedback I can to #7649. Thank you very much for keeping custom renderers in mind, though!

Broadly speaking, the main issue with custom renderers (beside naming of event handlers, as I've described) up until now has been that when you assign bind:this to a variable, it strictly expects that bound variable to extend HTMLElement, though in reality the closest common ancestor of a Svelte NodeGUI element is Node or, though I can't totally recall, Element. Requiring extension of HTMLElement means that we have to do a lot of difficult stubbing out just in order to satisfy TypeScript, and I'd rather be able to let the users know exactly what APIs there are, rather than claiming to be HTMLElement, only for them to find that in practice most of the APIs throw new Error("Stub - not implemented") when actually used!