NyxCode

@thorlucas I was thinking of something different: The proc macro writes to a file in the build directory (or maybe somewhere else, not yet sure). Then, in a test (or...

@cauthmann I think you misunderstood what I was saying - We could write the files in the proc macro, then have a test read those files. The test will definetely...

> We could write the files in the proc macro, then have a test read those files. The test will definetely run after all proc macros are expanded. Hm, didn't...

@Andful I just came back to this issue, over a year later, and we ended up with something similar-ish. We did *not* end up generating a separate type for each...

I still believe that, at least by default, exporting one file per type is the right choice. Exporting into a minimal number of files while not duplicating types would only...

Hey! Definetely something we can add in the future! In the meantime, you can either use - a type override (specifying the typescript type manually): `#[ts(type = "number")] field: Decimal`...

Interesting! I haven't thought about this idea as much as I should have, so I'm still a bit fuzzy on what the concrete use-cases are. What libraries / frameworks do...

Maybe we could start with something tauri-specific? If the only focus was on tauri, we might be able to generate everything a user would want: ```ts export function my_command(args: {...

To illustrate this idea, here's an example of how this *could* work: `ts-rs` could expose `#[ts(function)]`, which would generate a struct implementing `TSFn` or something like that. The trait would...

Right! Also, arguments or return types might need to be imported. This is why I think we need some runtime representtion of a function, just like `TS` is our runtime...