Reasoning for generating bindings via cargo test?

[tedmielczarek-fastly]

Hi there! I'm looking at using ts-rs in a project to keep type definitions in sync between Rust and TypeScript code. The only issue I've run into so far is that the bindings are generated from tests (running cargo test) and there doesn't seem to be any alternative or way to configure that. Our Rust code gets compiled to WebAssembly, so this method doesn't work by default. We can work around it by explicitly running cargo test --target=<host>, but it's a little awkward. We also already have our Rust and TypeScript code built in the same build invocation and invoking cargo test in the middle of that doesn't seem feasible. For the moment we're looking at committing the generated bindings, but that means we'll require a manual step to regenerate them which doesn't seem ideal.

I've used other binding generation tools in the past and this is the first one I've seen take this approach, so I'm curious as to what the reasoning was behind the choice? I looked around at other crates that generate bindings from Rust code and the only one that generates external language bindings from Rust code appears to be cbindgen.

The cbindgen docs provide two ways to use it:

• Installing a standalone CLI tool
• In a build.rs

These both seem sensible and I could work with either of them.

[NyxCode]

Hey!
The reason for this is that we leverage the compiler to do name resolution.

If you #[derive(TS)], we only generate a impl TS for YourType { .. }, together with a #[test], which just calls YourType::export_all().
The actual generation of the TypeScript bindings then happens at runtime, either in a test or by calling the methods on TS directly.
Whatever method you chose, something needs to call <YourType as TS>::export_all().

This allows us to robustly support dependencies, type aliases, recursive exports, and things like that, without having to re-implement parts of the compiler to do name resolution, figure out imports, substitute type aliases, expand macros, handle conditional compilation, etc.

Could you explain in more detail why running cargo test --target=.. doesn't work for your use-case?
We do have a CLI in progress, but that will more or less just call cargo test internally, so I assume that won't help either.