Conversion to TypeScript?

[eliandoran]

This is a bit of a reply to some of the replies in zadam#4646 regarding type management, but it's actually something I've thought for some time now.

I don't think rewriting the server to Rust is currently a good candidate due to the sheer difficulty of implementing such a change. Nevertheless, we can consider for the future an approach I saw in NextCloud: rewrite in Rust (or other high-performance language) only the most performance-sensitive stuff. In our case it would be most likely the search and tree functionality.

To me, adding types to Trilium is almost mandatory. And the sole reason to that is that types makes it easier to navigate through a repository where you don't know everything about it. I've worked with JavaScript projects before and as soon as the application grows in complexity to anymore more than trivial, it becomes hard to navigate through it once you start forgetting all the details about the implementation.

When it comes to adding types, there are really only two possibilities that would make sense: JSDoc and TypeScript. For me, I'm not very fond of JSDoc since I found it to be a bit unwieldy compared to TypeScript. Also important is that TypeScript introduces some safety features that are really helpful: for example checks for nullish values, and of course any type inconsistencies.

Feel free to pitch in if you have any ideas or if you agree or disagree to this.

cc. @rom1dep @rauenzi @meichthys

[eliandoran]

Just for reference,

There are around 490 JavaScript files, out of which 279 files are client-side.

The biggest concern I have with this kind of change is that there is very limited test coverage in the project. Which means that if we break something, it will not be immediately clear that we broke it.

Also, I've read in an article about converting codebases to TypeScript that Rome was not built in a day: we don't have to convert everything at once, we can do it progressively until we finally manage to convert everything.

[eliandoran]

Not directly related, but see zadam#2905 for a PR which added TypeScript support to the frontend/backend scripting system.

[zerebos]

I'm only on my phone right now so I won't be as detailed, but I think overall a conversion to Typescript is definitely something worth tackling. As already stated this can be done slowly over time, I've done this before with projects successfully. I always recommend starting with the API first because it allows developers to get a clean set of types for their plugins to work with and also gives us as the maintainers an idea of what we are really exposing.

That said, it's not a small undertaking or without risk since there's no real testing especially for the frontend. It would also introduce another build step for the frontend.

Another thing to consider is what has been tossed around before—do we want the backend to be JS/TS at all? We could switch to go or rust for speed and memory purposes. If we did that, it would lessen the typescript burden technically.

[zadam]

@eliandoran I suggest to not wait for "approval" from others. If you want to do it, just do it.

[zerebos]

True, doesn't hurt to get started on a branch when you have time @eliandoran 😉

[eliandoran]

@rauenzi , first PR is ready: #13

[zerebos]

I'm impressed you did this so quickly!

[zerebos]

I haven't done much for the frontend currently, I have had too many other obligations of late. But that doesn't prevent others from tackling the frontend if they want 😄 I also am admittedly still fairly a novice when it comes to TypeScript anyways.

[Magnethius]

TypeScript definitely feels like the right call for the immediate future. It'll make the code way easier to navigate, and the type safety is a big win. Plus I think it would Mae the transition easier, if we ever decide to switch to Rust or another backend down the line.

[eliandoran]

@Magnethius , feel free to review the first PR in this series if you have experience with TypeScript: #13

[meichthys]

Closing this since this idea is well underway: https://github.com/TriliumNext/Notes/issues?q=is%3Aissue+typescript+is%3Aclosed+in%3Atitle+TypeScript+