TypeScript support

[sonnyp]

we should support TypeScript

We can iterate on this and go like this

• add a new language "TypeScript" without compilation
• Add support for compilation
• Add instructions on how to enable TypeScript support in Extensions.js - TypeScript should not run if it's not enabled
• add support for type checks with Biome LSP
• port Welcome demo to TypeScript
• have the build-aux/library.js compile TypeScript main.ts files to equivalent main.js files (and run biome formatter over them)
• Add TypeScript support to workbench-cli
• port more demos to TypeScript?

[vixalien]

I suggest to use esbuild for converting TS to JS since that's faster and will be noticeable when frequently recompiling. Also, esbuild is just a compiler and not a typechecker so it fits the requirements.

For types, we will decide what types we need to use. Christopher Davis has nice precompiled types here: https://gitlab.gnome.org/BrainBlasted/gi-typescript-definitions. Although I'm unsure on the rate on which they get regenerated.

I'll try to familiarise myself with LSPs as I don't really know how they work currently and how they're used in Workbench.

[sonnyp]

Is esbuild able to retain line numbers?

For types, we will decide what types we need to use.

Evan is working on merging the various projects so let's wait for that?

[sonnyp]

A couple of thoughts on this

Evan is working on merging ts-for-gir and gi.ts gjsify/ts-for-gir#144 but we don't need to wait for it to get started.

There is now a TypeScript SDK extension https://github.com/flathub/org.freedesktop.Sdk.Extension.typescript that we can use and recommend similar to the Rust and Vala SDK extensions.

We use Biome for formatting and diagnostics of JavaScript. Biome also supports TypeScript so let's try using Biome as well for TypeScript.

I don't want to write all demos in both JS and TS - so we should write them in TS and have a tool that automatically strips the types to generate the .js files in demos and run the formatter on them. At build time. I'm not sure if typescript compiler is the best tool for this. It might make code optimizations and changes we don't want ? I know that Babel is able to do this and has a retainLines option but if we can use the typescript compiler that's better. We will have a similar setup for Python with types (cc @theCapypara )

I think the best way forward is

1. Make the script to compile ts demos to js and port only "Welcome" to TS
2. Add TypeScript support to Workbench using only what we have currently with Biome
3. Add type checks
4. Port all demos to TS (internship?)

Each step can be done and merged independently

[vixalien]

Is esbuild able to retain line numbers?

No, but I'm failing to understand why it's necessary

we don't need to wait for it to get started.

That means we won't get type checking. Which is the entire point of typescript. Or did you mean we can use one of gi.ts or ts-for-gir while waiting for the merge?

I don't want to write all demos in both JS and TS - so we should write them in TS and have a tool that automatically strips the types to generate the .js files in demos and run the formatter on them.

tsc will do that, but will be extremely slow. esbuild is a faster approach.

No tool that I know of will retain lines, at least on purpose. This is because typescript also has features that cannot be mapped to JS and as such will require different code, such as enums or decorators. However, most tools will generate source maps.

These are all my concerns, and some of them may not be valid. What do you think?

[sonnyp]

GJS does not support source maps ATM which means that if the compiler doesn't retain lines we get wrong line numbers in stack traces.

That means we won't get type checking.

You are commenting on a sentence that ends with "to get started" :)
As in to get started working on this.

No tool that I know of will retain lines

As I said; Babel does.

[vixalien]

GJS does not support source maps ATM which means that if the compiler doesn't retain lines we get wrong line numbers in stack traces.

I have a weird idea: since workbench can intercept the errors, what if we get the correct line numbers from the intercepted errors using a generated source map before logging the error? Of course I don't know if it's feasible and it could be better if upstreamed to GJS.

You are commenting on a sentence that ends with "to get started" :)

Sorry. My brain possibly skipped that part 😓

As I said; Babel does.

Hmm. Okay, Babel can be used initially then. But this does not inspire confidence, imo:

Babel will make an effort to generate code such that items are printed on the same line that they were on in the original file. This option exists so that users who cannot use source maps can get vaguely useful error line numbers, but it is only a best-effort, and is not guaranteed in all cases with all plugins.

[sonnyp]

yeah ok I guess that even if we get the right error line we still get the wrong column

maybe inaccurate stack traces is not that bad until GJS gets source maps - we can put up a warning

[sonnyp]

Great news, GJS has merged support for source maps https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/938

It will ship with GNOME 48. That means we can get accurate stack traces for both TypeScript and JavaScript (compiled from TypeScript at build time) see workbenchdev/demos#201