Consider using TypeScript

liquidev commented

2024-08-19 18:45:48 +02:00

(Migrated from github.com)

I like not having additional build steps. However, developing the rkgk frontend is quite a pain without access to type annotations, so I've been considering ways on how to add support for TypeScript in the project.

https://github.com/tc39/proposal-type-annotations seems kind of dead, or might be far off into the future. So we can't just wait.
JSDoc is a real pain to use. I'd rather not have types than litter over my codebase with doc comments containing nothing but type annotations.
tsc is kind of slow, which makes it a hard sell, as I prefer fast builds, but other TypeScript compilers are not as available from system package managers.
- I'd prefer to avoid npm if possible.
  - Yarn seems like a viable alternative for npm, because it emphasizes reliability and security, which aligns with my core values. However, it's another package manager you'd have to install, which is not ideal. (Either way you would have to install another package if we went with tsc instead.)
swc seems like a promising Rust-native alternative, but it has no easy introduction on how to integrate it into an existing Rust project. Therefore I'd need to do some serious research before integrating it into our pipeline.
- There's a CLI available on NPM, which is probably convenient to use, but again - requires npm.

I timed tsc on rkgk and it looks just about bearable:

________________________________________________________
Executed in  428.02 millis    fish           external
   usr time  761.63 millis  380.00 micros  761.25 millis
   sys time   77.25 millis   80.00 micros   77.17 millis

I might consider integrating it into the build later to see how I feel about it.

I like not having additional build steps. However, developing the rkgk frontend is quite a pain without access to type annotations, so I've been considering ways on how to add support for TypeScript in the project. - <https://github.com/tc39/proposal-type-annotations> seems kind of dead, or might be far off into the future. So we can't just wait. - JSDoc is a real pain to use. I'd rather not have types than litter over my codebase with doc comments containing nothing but type annotations. - `tsc` is kind of slow, which makes it a hard sell, as I prefer fast builds, but other TypeScript compilers are not as available from system package managers. - I'd prefer to avoid npm if possible. - Yarn seems like a viable alternative for npm, because it emphasizes reliability and security, which aligns with my core values. However, it's another package manager you'd have to install, which is not ideal. (Either way you would have to install another package if we went with `tsc` instead.) - `swc` seems like a promising Rust-native alternative, but it has no easy introduction on how to integrate it into an existing Rust project. Therefore I'd need to do some serious research before integrating it into our pipeline. - There's a CLI available on NPM, which is probably convenient to use, but again - requires npm. --- I timed tsc on rkgk and it looks just about _bearable_: ``` ________________________________________________________ Executed in 428.02 millis fish external usr time 761.63 millis 380.00 micros 761.25 millis sys time 77.25 millis 80.00 micros 77.17 millis ``` I might consider integrating it into the build later to see how I feel about it.

devildefu commented

2024-08-24 17:38:17 +02:00

(Migrated from github.com)

swc seems like a promising Rust-native alternative, but it has no easy introduction on how to integrate it into an existing Rust project. Therefore I'd need to do some serious research before integrating it into our pipeline.

There's a CLI available on NPM, which is probably convenient to use, but again - requires npm.

You probably don't want swc, because it doesn't support type checking:

SWC only transpiles the code and doesn't perform type checking. Therefore, it's recommended that you continue to use tsc for detecting any type errors.

I was looking for an alternative to tsc for one of my projects a few years ago, and from my experience, if you want type checking from TypeScript then I think your best option is still tsc. There are ways to "mix" swc and tsc, running tsc in the background, etc., but ymmv.

> * `swc` seems like a promising Rust-native alternative, but it has no easy introduction on how to integrate it into an existing Rust project. Therefore I'd need to do some serious research before integrating it into our pipeline. > * There's a CLI available on NPM, which is probably convenient to use, but again - requires npm. You probably don't want `swc`, because [it doesn't support type checking](https://swc.rs/docs/migrating-from-tsc#notes): > SWC only transpiles the code and doesn't perform type checking. Therefore, it's recommended that you continue to use tsc for detecting any type errors. I was looking for an alternative to `tsc` for one of my projects a few years ago, and from my experience, if you want type checking from TypeScript then I think your best option is still `tsc`. There are ways to "mix" `swc` and `tsc`, running `tsc` in the background, etc., but ymmv.

liquidev commented

2024-08-24 18:21:48 +02:00

(Migrated from github.com)

Mixing swc with tsc was what I had in mind - the LSP still shows you errors as you type, plus we could run tsc to catch them in CI. I just don't want it slowing down my iteration times.

Mixing `swc` with `tsc` was what I had in mind - the LSP still shows you errors as you type, plus we could run `tsc` to catch them in CI. I just don't want it slowing down my iteration times.

riki referenced this issue

2025-09-01 17:03:19 +02:00

Consider porting the frontend codebase to TypeScript #104

riki commented

2025-09-01 17:03:32 +02:00

Owner

Merged from #104

JavaScript is cool and all, but porting the codebase to TypeScript would greatly increase its maintainability.

It wouldn't be a simple task though, requiring us to change some idioms we currently use:

async listen
usage of event handlers, which aren't very TypeScript-friendly AFAIK

There's also the question of how long will it last. Theoretically nothing should break if we only depend on Vite, but I haven't used NPM enough to know.

Merged from #104 --- JavaScript is cool and all, but porting the codebase to TypeScript would greatly increase its maintainability. It wouldn't be a simple task though, requiring us to change some idioms we currently use: - `async listen` - usage of event handlers, which aren't very TypeScript-friendly AFAIK There's also the question of _how long will it last._ Theoretically nothing should break if we only depend on Vite, but I haven't used NPM enough to know.

Rows
Columns

Consider using TypeScript #24