I assume we probably also wanna commit the generated bindings so that we can keep track of them (and might even be required for build to succeed).

@Alystrasz thoughts?

Aight, the only thing missing is GameInstall and InstallType but I'm struggling with getting InstallType working and that's a dependency for GameInstall.

Given that I could use this PR for #139 (otherwise I'll have even more duplicated definitions), I'd just merge what we hav here and keep GameInstall and InstallType duplicated ^^

Added docs as well now ^^

Now it should be done for real :P

I assume we probably also wanna commit the generated bindings so that we can keep track of them (and might even be required for build to succeed).

We want to avoid people modifying TS bindings instead of Rust classes (despite your documentation saying not to :))
Is there a way to generate bindings just before building? We'd have issues with Typescript linting during development though...

We want to avoid people modifying TS bindings instead of Rust classes (despite your documentation saying not to :))

Uh, I don't quite see where I tell the reader to modify them. I just tell them how to (re-)generate the bindings if changes to the corresponding Rust class were made. Or am I misunderstanding something? ^^

Is there a way to generate bindings just before building? We'd have issues with Typescript linting during development though...

We can create them just before building by simply running cargo test as a prerequesite step when running npx tauri dev/npx tauri build. The issue with that approach however is that running cargo test takes some time to complete and once we add unit tests the runtime of cargo test will only increase. So given our long compile time, this is probably not a preferred approach.

AFAIK it is possible to only run certain unit tests but the way ts-rs exposes them means any new binding added will require modifying the list of specific tests to run.

Therefore the best approach is probably to check in CI if running cargo test modified any files in the bindings/ folder as that implies that someone either committed a manually changed version or forgot to commit a new binding (though the latter would already fail in CI anyway).

Question is, do I have to do this in this PR still or can I just make a TODO issue and do it in the next PR? ^^"

Uh, I don't quite see where I tell the reader to modify them. I just tell them how to (re-)generate the bindings if changes to the corresponding Rust class were made. Or am I misunderstanding something? ^^

Nah, documentation tells developers to edit Rust classes, and not bindings.

We can create them just before building by simply running cargo test as a prerequesite step when running npx tauri dev/npx tauri build.

Can we integrate bindings generation in the file watcher (i.e. if you update a Rust class while running npx tauri dev, typescript file is updated as well)?

Question is, do I have to do this in this PR still or can I just make a TODO issue and do it in the next PR? ^^"

We already have a bunch of issues, let's do this here :)

We can create them just before building by simply running cargo test as a prerequesite step when running npx tauri dev/npx tauri build.

Can we integrate bindings generation in the file watcher (i.e. if you update a Rust class while running npx tauri dev, typescript file is updated as well)?

File watcher stuff is handled by Tauri. I'm not aware of a way to hook that to add a call to a custom function on file change. And even then as soon as we start doing unit testing, it would mean that all unit tests are re-run the moment any time the developer presses save on a file. That's a lot of additional compute needed that not everyone has (e.g. me when working on FlightCore on my puny laptop :P)

Question is, do I have to do this in this PR still or can I just make a TODO issue and do it in the next PR? ^^"

We already have a bunch of issues, let's do this here :)

Welp, guess I have to figure out how to actually do this in CI then ^^"

Question is, do I have to do this in this PR still or can I just make a TODO issue and do it in the next PR? ^^"

We already have a bunch of issues, let's do this here :)

Welp, guess I have to figure out how to actually do this in CI then ^^"

Turns out using ChatGPT this was actually easier than I anticipated. Anyway done with 49c454a now. Also did a few test runs to ensure that it fails if binding changes are not committed ^^

To add some more context to this PR, I did some more research into TypeScript interfaces generated from Rust.

Compared to ts-rs, alternatives are:

• wasm-bindgen which appears to only do JS not TS. Also more aimed at WASM, so not a better alternative
• typescript-definitions saw no update in 4 years, so I rather not use it and have it break in the future, so not a better alternative
• Using schemars as described here. Also looks a lot more cumbersome to use (build TypeScript type at runtime from JSON schema), so not a better alternative
• tauri-bindgen-ts might be a higher level library but it's WIP in alpha with no commits since 4 months ago. Further it just uses ts-rs in the background, so again not (currently) a better "alternative".

Hence I'd argue that ts-rs is the best choice here ^^

And as for generating bindings, I'd argue that committing generated bindings is the way to go as otherwise TypeScript linting will fail until running cargo test at least once which requires a mostly compiled codebase (and will take even longer once we add unit tests) and we have CI in place to catch any issues regarding uncommitted (changed) bindings or accidentally committed WIP test bindings ^^